Skip to main content

With Uncertainty, Comes Opportunity: The Shifting IBM Z Workforce

Reg Harbeck: Hi. I'm Reg Harbeck and I'm here for the second of a pair of podcasts with Jeff Cherrington. On our first podcast we sort of talked about the background of ASG [Technologies] and Rocket Software and just all that you know, happened in the history of mainframe computing and enterprise computing and how they participated. We sort of got right up to the current day and we promised you more, and so here we are. We're going to start taking a look to the future. You know Jeff and I were just chatting before we started recording, and the future is not all bright. But we in the mainframe have the opportunity to contribute to the brightness of the future by deliberately proactively seeing what's coming and making plans you know, knowing that yeah, sometimes things are going to be rough, but we've got the platform that can make it through. We've got the people, we've got the organizations. So maybe Jeff if I can start off with just some initial thoughts from you about that.
Jeff Cherrington: Well Reg, thank you very much. And for those of you in the listening audience I've not had a chance to meet, I'm the vice president of product management for the infrastructure modernization business unit at Rocket Software—what was previously known as the z Systems business unit—and I've had a good opportunity here in these podcasts with Reg to explore a little bit of the history of Rocket Software, which clearly reflects the history of the mainframe in enterprises around the world. As we move past that recap if you will then and start looking toward the future, we do see the future as bright. I know Reg is making a journalistic point in the way he phrases things, but we believe the future remains bright for the mainframe—albeit we've got some challenges to face. Certainly the one that's before us in conversations Reg and I have had outside of this podcast, it is that we're going through a generational shift and it's a particular kind of generational shift in that there are professionals who have maintained mainframes, who support its infrastructure, who have done that for 30, 40, in some cases even 50 years—and in fact Reg is going to have some interesting observations about the longevity of careers in the mainframe. In that context those people who started with the mainframe very, very early in the availability of the technology, we came to a period, and then when the next generation of technology professionals came forward—and it has happened to coincide with the explosion of personal computing and then networked computing using distributed platforms. [These were] very attractive opportunities for folks to exercise their creativity, to find good jobs that provide good income, and so when we think of the generation after mine, the Generation X by self-selection, most of them got trained to academic education around these new emerging technologies, and they became a huge swell of new IT professionals that entered the market and helped us power the world that we have today. Without those professionals, we wouldn't have the things that we've got with the internet and with all of the personal productivity we can get from our distributed environments. But they never really embraced the mainframe. Their plates were full. They had enough to do and so as we now come to the point where, inevitably, the most experienced mainframe professionals are reacting to that inflection point in their lives where they're going to depart from the daily workforce and pursue other objectives, whether it's retirement or consultancy or part-time work or whatever, it may be that means there's a great deal of new opportunity opening up. I've said consistently for nearly two decades now, nature abhors a vacuum. When that vacuum occurs around the maintenance of these critical mainframe backbones in large data centers for critical businesses that run the world, global banks, federal governments, there are going to people who step up to take those roles and we are seeing it. We are seeing that the IT professionals that are after Generation X—whether you call them millennials or Generation Y or whatever may be the case—they are actually saying wow, there's a lot going on here. There is an opportunity and I can do this. I can take the skills I've learned. I can take my Java skills, my networking skills for TCP/IP. I can take my skills with machine learning and artificial intelligence and I'm going to find a place where I can contribute and be important to the work that's being done by my enterprise.
Reg: As such a positive optimistic view, and I agree with it—you know it's sort of interesting to see that in the context. First of all, you're referring to the workforce that is super populated with non-mainframers and I think that's one of the challenges we've had as mainframers is all the people getting promoted into management have been from non-mainframe backgrounds, just because there's so many more of them. I mean they weigh politically very heavy compared to our mainframe because so few people draw to mainframe that runs more workload than anything else combined. And so as a result the workload is not the politically deciding factor, but rather the number people there are to be promoted into management. And so to see people starting to come back into the mainframe is good and I think it's interesting as you have mentioned. I actually wrote a whitepaper 18 years ago, 2004, about the need to get a new generation of people on the mainframe. I called it Mainframe Continuity Planning, published some articles about it, went around presenting on it and you know, 18 years later, we're just getting there now. One of the reasons is because mainframers love their jobs and they also love their jobs a lot more than the alternative of being retired. The one exception that I always joke is what's the average mainframer's retirement plan? It's to come back as a high-priced consultant doing the same job. I've had to back off on that one because I found that HR is much better than negotiating salaries than mainframers are. That said, there is this real opportunity to move to a new generation now of mainframers as those spots open up, but there's also a really important challenge—and that challenge is that we don't realize it but mainframers are people of a spooky integrity. They are so reliable, so honest and so nerdy you know. They're the kind of people you would trust with your car keys you know, and the problem is that is not normal. You know if you go anywhere any other group of people, even people in organized religion, you're going to have bad apples, and we have almost none of them on the mainframe. That's a really important challenge because we now need solutions to respond to that. So given all that, Jeff, back to you: What are your thoughts about how we can make sure that those forward-looking solutions are dealing with a new generation on the mainframe?
Jeff: Wow. There's so many dimensions to the answer to that question. One I think I spoke to in the last session, and one that I feel is critical is we as the providers of mainframe technology. Those of us in the independent software vendor space who are creating new ways to engage with the mainframe have to understand that these new emerging professionals have completely different sets of expectations. I think about the young people that I have an opportunity to work with who are the age of my children. I can be you know very transparent and say I've got adult children now. At least in parts of the west, the Western Hemisphere, they've never known a time when they didn't have high-speed internet access. They've never known a time when they didn't have pads, touch-friendly ways to interact with their technology. And so if we're going to be successful as I expect we will be to help our customers continue to harvest the tremendous value and the major investments they've made in mainframe technology, we—what's the phrase salespeople will use so often? We've got to skate to the puck. We've got to meet these people where they are, and so as a consequence a lot of the investments that are being made by my organization at least, and others I'm sure, is that we've trying to take what has been a fairly mechanical interaction with the mainframe through the legacy 3270 green screen. I imagine at this point most of the people who are listening here for this particular podcast know what a 3270 screen is, but there are so many as you say who are in influential positions within technology—architects, thought leaders, executives—who've never actually seen one, certainly never been hands-on with one, and as a consequence there's no affinity. We've got to be able to bridge that gap so that it becomes familiar, and so we do. We make substantial investments in applying new visualization technologies—data visualization particularly for the mainframe, which generates such huge volumes, just unbelievable volumes of granular metrics that can provide incredibly important information but which no one in our emerging professional generation would have the patience or the desire to go through line by line, page by page, in a 3270 screen. There needs to be ways to abstract meaning up out of that morass of metrics so that the emerging professionals who don't have the benefit of 40 years of experience, of being there the day a new mainframe model or early software version of z/OS is announced. They don't have that history to depend on [but they] can still be successful, and so that's where we make investments. So that not only do our customers as corporate enterprises can be successful, but the individuals who are engaging with the products we offer can be successful—and that's just the beginnings of the conversations. Certainly we have to reach out. We in the industry broadly—whether it's independent software vendors, IBM, or the enterprises that use them—we've got to reach out to the younger generation and let them know they're wanted, they're needed, and they can actually do some really interesting things. Reg you know I've been around the industry for awhile. I don't know if you've ever been introduced to a gentleman by the name of Cameron Seay.
Reg: Oh, he's one of my personal heroes. He and I just finished co-writing a mainframe textbook.
Jeff: Absolutely so and like you, I admire him so significantly. Dr. Cameron Seay is a man who is promoting the idea that universities must be taking mainframe just as they have classes in Java, just as they have classes in encryption and data security. They need to be having some of the same sorts of classes for mainframe even as universities did when I went through my university training many years ago. And he makes such a persuasive and compelling case that he is attracting students. He brings students in, goes through what would be considered a boot camp. Any of us who were around mainframe during the Y2K—the year 2000 scare—we saw lots of young professionals come through short courses—9 weeks, 12 weeks—and then be put on the front lines of doing development, and they've become successful. I've got friends who fit that category, some of whom are vice presidents, senior vice presidents in technology for really significant firms. The same way now Dr. Seay is promoting let's have these boot camps. Let's take students who have already been trained to the fundamentals of technology, the fundamentals of programming, the fundamentals of infrastructure management, and have them take that foundation and apply it to now the mainframe which has the same needs—maybe different controls, maybe different jargon—but at the end of the day it's still a matter of keeping the infrastructure up and operating so that applications can perform necessary work for the enterprise. He takes people through this training, many of whom come out, get jobs very quickly and some of whom are already progressing up into the ranks within large enterprises. This is just one example of one man who is driving something really significant and we should take the moment and say and he does this in context frequently of the Historically Black Colleges and Universities (HBCUs), and I can't tell you just how much I admire that and how much benefit it's bringing to young people and bringing to enterprises that hire these young people.
Reg: Absolutely and you know, that's a neat segue in some ways to a much fuller understanding of mainframe modernization, because too often we've treated modernization as basically adding more graphics and bells and whistles and really that's not what it was ever really about. What modernization—and it's only valid manifestation has ever been is about humanization, but not just humanization for paying customers but humanizations for the people behind the curtain who are doing the work. And you know I think we have really in the past treated mainframe workers as put up with, you know the clunkiness of it. Because you've got a nice career and you've got a specialty that nobody else has, and so be happy with that. But in fact the opportunity that we're now seeing organizations take to reach out and humanize the mainframe for a new generation, and with that new generation then take all of the digital native perspectives they have and re-humanize the mainframe as it become—it takes on its mantle really a key player in the world of IT that has to play fair with all the other platforms, [and] so much so that as we were talking about previously—and I think you have some more thoughts on that—there's even the opportunity to enable organizations to move various workloads back and forth between the mainframe and the other platforms based on the business value. If you want to maybe add some thoughts about that.
Jeff: Absolutely Reg, and it's something that I have spoken about and written about in a number of different forms. At the end of the day for an enterprise to be successful with a given workload, a body or work that needs to be done should transact on the platform that best fits the profile of the technology and the commercial policies that the organization is trying to pursue. And while I'll always be a fan of the mainframe, clearly there are good opportunities to run important workloads that don't need the security, that don't need the high availability, that don't need the quick and proactive serviceability that the mainframe platform offers. It can run very successfully on distributed platforms and it should. It's one of those things that's just—it's a natural part of human nature, as you say humanizing the interaction with data and the interaction with technology. I like to recognize what's just an unavoidable reality about dealing with the mainframe from a commercial posture: It has a very large line item in the budget. We can go out and we can buy a server, a distributed server depending on what your needs are, for $25,000 or $10,000. Or in small businesses they just might go out and buy a healthy server at the local Best Buy and be happy with that. Those are trivial purchases within a larger enterprise. The line item that comes in from IBM for the hardware and the software stack that they provide is so large it rises to the top. It's like cream when you're milking the cows in the field. It comes right to the top and the first thing any CFO, any controller will do is go wow, this is really big. How can I save some percentage points off this? It will always be that case. No CFO, no finance management person worth their weight wouldn't do that, and as a consequence it gets attention outsized to what the actual cost to the enterprise is. You and I, Reg, we both write, we talk, we've seen others write and talk—if we do diligent cost accounting, the mainframe remains one of the least expensive computing platforms. It also puts itself at a disadvantage because originally it was built to have cost accounting as part of the processing, and so it captures every little thing and can assign a value to it, a cost. Try to do that in a distributed data center that has 10,000 servers, miles of cabling, lots of folks scrambling around trying to keep everything up and running and I will tell you with great authority: they don't do a good job of capturing the soft costs, those that are not going to be ending up on an invoice, and so consequently they don't build that cost into their analysis. At the end of the day it is a difficult situation for many enterprises because there's an impulse. A CFO comes in or a new technology leader comes in or a CEO has spoken to his peers or her peers and says: I want off the mainframe. Okay, understand the direction but getting off the mainframe, really getting off the mainframe, means taking what is productive code effectively letting an enterprise run its business, that contains all of its business rules accumulated over decades that is sitting there and getting the job done, and going through a really expensive and really risky process to end up at the same place you started.
Reg: Sure.
Jeff: I've got a billing system. It's working great. Statements go out on time. I can answer questions in my call centers. I've got an economic model that I can make sense out of. I can spend 10 million dollars and move it off the mainframe and onto a distributed architecture, and after I've spent the 10 million dollars I'm right back where I started. I've got statements going out; I've got people answering phones. Hopefully it's as stable and reliable as what I had but I've just then spent a lot of time not creating new capabilities, not creating new competitive advantage. It's a difficult, difficult business case to make and I'll go just one bit further and then Reg, I'll ask for your thoughts. And that's why we at Rocket, we take a look at the market and we want to ensure that we work with enterprises so they can tackle mainframe modernization in the way that makes sense for them. For many, it means platform preservation. We've made investments in the mainframe. It is core to our business. We don't want to take on that cost, that risk or that loss of time to market to try to move off the mainframe. We simply want to be able to make working with our mainframe better, easier, faster, and more accessible to our emerging professionals. We certainly cater to that market, but at the same time—as we said at the very beginning of this discussion—there are some workloads that don't need everything the mainframe offers. And in those cases, we certainly think there's a valid case to be made for workload migration to move it off the mainframe onto distributed, and we also want to make sure that we are constantly providing for that market as well. And certainly we here at Rocket do have specific tailored opportunities to support folks, particularly around the workload management itself, to move workloads off the mainframe—and candidly, we've finding some enterprises move them back onto the mainframe. They took something off the mainframe, they thought it would work great on distributed but they don't get the security, they don't get the reliability, they don't get the response times that they wanted. They bring it right back onto the mainframe where it can operate successfully. Again so Reg, share with me your thoughts. How does that reflect what you've seen when you talk to industry leaders and your peers?
Reg: Well you know one of the things that really occurs to me as I listen to you is just how interesting that it is that the mainframe is the place so many of our most leading-edge ideas originated, but they were called something else. So for example I remember back in the mid 80s we had systems application architecture, SAA, come out, and shortly after the concept of client/server was really popular. But the idea of basically having platform invisibility was the intention. So you could run an application on the mainframe and distributed and you know midrange, and the user wouldn't need to know. Then you take a look at a concept such as DevOps or even ITIL you know, and how they kind of grew up on the mainframe, and then everybody else sort of said hey, this is a good idea, and they tried to implement them more explicitly in other platforms. Then we have the opportunity to bring that learning from doing it more intentionally on other platforms back to the mainframe and finding a way to take the positive aspects of that legacy and then help the mainframe not only move its game forward but also move its game to be playing fair with others. So to see that whole concept of SAA that you know was really emerging in the 80s finally starting to really come true now—we don't need to worry so much about which platform as long as there is somebody who's doing it for us. And that's the issue with cloud, of course: you know if cloud is just somebody else's computer, you've missed the point. You know the idea [with] cloud: you move from which technology to which qualities of service, but you'd better specify the right qualities of service. And that's where we get back to you better have somebody in your organization who understands what your mainframe is giving you that you trust so that you get a genuine apples to apples comparison as you're making a decision about a move forward with your various applications. So I think that whole concept of simplifying in a way that does not eliminate important details but rather you know, trusts the people who are telling us those details to give us an answer that we can translate into business value instead of having to focus on bits and bytes at every step of the process. What do you think?
Jeff: So you do bring forward this idea of the current mainframe professionals in place being some of the most trusted individuals in the enterprise, and as you say we mainframe professionals of my generation as a class I think have actually—we've lived up to that trust. I would bet that there are many executives in enterprises that at this time don't realize just how valuable that trust is because of the great deal of potentially harmful latitude that their mainframe professionals have. A systems engineer who has broad access for a global financial data center could probably do things that would affect the entire world economy—at least in the short term, potentially even in the long term—and yet the things that we hear is oh my gosh, they're so annoying. They want to tell me all of this detail that I don't really care about, and they're so expensive. Can't we do something different? I do think that we don't—and I won't say so much we, but my peers, my friends in the industry—don't get all of the recognition and the credit they deserve for managing that so well. It is something that I think is an unheralded hallmark of the generation of professionals and the benefits that we've received.
Reg: You remind me of an anecdote I like to tell [which] is, you know back starting in 2004, after I wrote my whitepaper and was presenting about it, I would describe a cartoon we've mostly all seen. You see these two professionals or scientists, whatever, at a blackboard—I would say whiteboard now but back then it was a blackboard. And you see on the left-hand side an absolutely mess of details, and on the right hand side this simple elegant solution. And the one is saying to the other, I think you need to be more explicit in the middle here. And in the middle you see a cloud and it says, "then a miracle happens." And the issue is that we do that, especially with the mainframe, and what we forget is that miracle is actually the people. You know I mean IBM makes an excellent platform you know, and IBM and the ISVs and all the other participants you know participate in that. But it's only with the involvement of the ecosystem, the community of just outstanding people who aren't afraid of getting themselves personally involved in their job—so much so that one of the things I like to joke about the mainframe is the technology that's been around for so long it's often operated by a crank. You know and we all have favorite mainframers like that who are a bit crusty, but boy are they brilliant you know. And until we can appreciate the importance of people like that in our environment and the trustworthiness—you know we find it harder to sort of encourage a new generation of you know, if not cranky people at least people who care that much about what they're doing. I think that's one of the big things. So that said you know, maybe as we look forward from your perspective you know, how do you see this all coming together in a way that you guys are really going to participate in making happen?
Jeff: Well there's one thing that I think is critical and it builds on the conversation we were having earlier about how do we bring in the new emerging professionals and how do we make them successful? And the phrase that I've applied to it is we need to ensure that we democratize the data on the mainframe—you know, no apologies. We certainly know that there are subsystems on the mainframe that are not well-suited to being integrated with distributed systems. They were built 10 years, 20 years, even longer before distributed systems emerged—you know no harm no foul there. But we're past that time and it is time to make sure that our VSAM files, our VTAM files, our IMS files, our sequential files—the data that's on the mainframe for good reasons and will remain on the mainframe—is accessible to everyone in the IT organization supporting the enterprise when there is a need to be filled. We want to be able to ensure that we are doing data virtualization that allows for externalization of that data in formats that are familiar to our emerging professionals using the same techniques and technologies that they learned in university and that they may have worked on in the early parts of their careers, so that the mainframe simply does become just one more data source that they can reach out to when they need to integrate it into a bigger process with other tech stacks within the enterprise. That's again where we are investing significantly. It's where we think we have particular advantages for the marketplace, and clearly we are hearing the marketplace has keen demand for. It's an interesting area because it takes us into everything that deals with accessibility, reliability, traceability—because while there are those in our industry who listen to what I say and are immediately going oh Jeff, Jeff, come on buddy. That was solved by extraction, transformation, and loading ETL years and years ago. The executives I talk to say we can't live like that. The time it takes to extract the data, write it on some other media, do whatever transformations we want to do and then load it into someplace else so it's accessible to my distributed processing, my distributed AI, my distributed ML, I'm already 5 minutes, 10 minutes, an hour behind and I live in a real-time world. So where we focus is let's democratize the data that's on the mainframe and make it available real-time so that we can become integrated into all of the real-time processes that are occurring within the other tech stacks in the data center.
Reg: Well especially with the new hardware technology like AI coming onto the mainframe so you can do real-time AI with your data in place. That just seems so relevant.
Jeff: Absolutely it does. It certainly does.
Reg: So that said, we've gone quite a good long time. I should probably finish up, but are there any additional thoughts you have about the situation and the future of the mainframe and how Rocket-ASG are going to contribute to that?
Jeff: No, the thing I'll always say is never count the mainframe out. You know from times when we were the emerging professionals in the industry, Reg, we will have heard—people have said the mainframe is too big. The mainframe is dying. The mainframe has no place to go. And here we are, 30 years, 40 years in my career at least later, and the mainframe persists and it persists for very valid reasons. The security is not the least of it. Certainly the trustworthiness of those who work around it is not the least of it. The availability and the response time is not the least of it. And it will continue to be critical for some of the most largest and significant employers around the world for as long as I can see, and we Rocket Software are dedicated to making sure that we keep it vital and we make it accessible to the emerging professionals who do want to engage with it.
Reg: Awesome. Well Jeff, it has been such a treat to have these conversations and of course you and I know we're going to have lots more conversations—
Jeff: Absolutely.
Reg: And who knows? We may even record some of them but—and thank you so much for taking the time for these.
Jeff: Reg, thank you so much for the opportunity. Thank you to the folks at TechInfo and TechTalk, and certainly if you have questions, look for me on LinkedIn. Always happy to engage.
Reg: Awesome. Thank you very much and—
Jeff: Cheers.
Reg: I'm Reg Harbeck and please look for future podcasts from me and also check out for all the other neat things they offer including subscriptions and such.