The Real Modernization Problem
DDC ITS' Laticia Carrow connects with Kyndryl's Misty Decker to talk COBOL and break down the real mainframe modernization problem
SPONSORED CONTENT
Meet the XDC Family
Since its inception, z/XDC and its predecessors have evolved alongside z/OS and mainframe programmers. Features and functionality have been added and improved as z/XDC users have needed them, growing the product as the market has changed. c/XDC and dump/XDC are the latest and greatest extensions to the z/XDC feature set, bringing robust debugging powers to new environments.
z/XDC
c/XDC
dump/XDC
Video Transcript
Laticia Carrow: Hi everyone, my name is Laticia Carrow, and welcome to this TechChannel interview. Today we are interviewing Misty Decker. Welcome, Misty. How are you?
Misty Decker: I'm doing great, Laticia. I am so happy to be here.
LC: I am ecstatic to see you. It's such a pleasure to have you on today. I want to get straight to it because you are a legend, and just tech royalty, and we are just so happy to have you. Let's get straight into it. Can you just introduce yourself and tell us a little more about you, just in case those of us that don't know?
MD: Okay, sure. I lead our mainframe modernization practice here at Kyndryl, and I spent 30 years at IBM hardware development manager, software development release manager. I was the release manager for the first release of z/OS, and I was relatively new at the company when I helped merge all of the individual mainframe operating system components into the first release of OS/390. So I go way, way back and I spent a few years at Micro Focus leading product marketing for mainframe modernization, and basically my whole life revolves around mainframe and making the most of it in the present and the future, right? So mainframe modernization is my whole thing.
LC: Mainframe modernization. That's a hot topic, wouldn't you say?
MD: It is. I get a lot of different comments. There's a lot of confusion around just that word that the word itself modernization just leads to a lot of conversations.
LC: Why is that? What's that all about?
MD: Well, in this space, the word modernization itself is kind of vague, right? It sounds like you're taking something old and you're making it new, but what does that mean? I launched the modernization working group at the Open Mainframe Project specifically because of this confusion. We are trying to define modernization as not the technology that's involved, but how the systems are meeting the modern needs of the business. It's about fit for purpose and delivering present and future value with whatever you have. So the mainframe is thoroughly modern, but if you're not using those modern features, then taking advantage of those modern features of the mainframe you already have sitting right there in your IT data center—that is modernization. If the mainframe is no longer serving the needs of your business and you need to do something different, moving off of that mainframe is modernization. Taking your applications where they are and updating them to better deliver what you're trying to deliver to your customers is modernization, whether it's on the mainframe or off the mainframe. So I try to level it up beyond the technology and the programming language and really talk about taking whatever you have, your legacy systems. It doesn't matter how old they are if they're already operational. If you wrote the program two years ago, it is now legacy because legacy, well, if you think about it, legacy just means what you already have in your environment.
And how you update what you already have in your environment is very different from writing something new from scratch. Legacy modernization really is just about updating, tweaking what you've got to deliver better value for what you need today and tomorrow, regardless of the technology that's involved. My favorite author, Marianne Bellotti, I totally adore her and her book, "Kill It With Fire." She said secretly all software development is legacy modernization. I love that quote because if you think about it, the same things that you need to do with a mainframe application in order to make it take advantage of cloud, you would have to do if you have a Java application when you were a startup and now you're growing to be bigger and now you need to integrate with cloud services. So legacy modernization has nothing to do with the technology. It has everything to do with having something already established already in use that you now need to modify to do something different.
—Misty Decker, Kyndryl
LC: So what do you say to those folks that are saying, well, I don't want to utilize this word modernization because I don't think that I'm modernizing. Isn't it just an update? You agree? It's just an update. We're updating just like we do updates to anything else. And then some folks would say, it's innovating. Well, isn't that tomato, tomato? How would you, I hate to be that person, but…
MD: I have this conversation all the time, Laticia. It's very confusing because many people are using the exact same word for very different things. That's it. And this space is just filled with bias, unquestioned bias, right? So you have people who grew up with cloud computing or they learn to program on Java or C, and they just assume that the mainframe is old or that COBOL is hard to learn and they don't even bother to look. I had a wonderful conversation with a university professor a few years ago and he said, well, there's nothing new in the mainframe, and I listed five things in 30 seconds, and he's like, I didn't know any of this was going on. Well, that's because you aren't looking right. But us in the mainframe space, we have the same issue where we just assume anything that's being developed in cloud, and the new technology is just a repackaging of what we've always done on mainframe. And some of that is true, but we should also actually look at it with an open mind. So that's my big push is just trying to get everybody to look at the technology that's available with an open mind and without letting go of your bias and your predisposed opinions and plan a path forward for what the business needs, what the organization needs based on business needs, not on the technology.
LC: So, what's the best practice to do that? What's the best way that they can do that without the pushback?
MD: Well, organizationally, every single project, whether you call it modernization or digital transformation or a cloud-first strategy or whatever, you always need to put front and center the business goals. So, I have a chart, when I talk to customers, I talk about why digital transformation projects fail and the statistics are eye-popping. 75% to 90% of digital transformation projects fail or underachieve—that's a lot. It's usually not technology-related. It's organizationally. It was a five-year program and you got a new CTO who has a different vision, or organizationally, you didn't have the right skills involved, or organizationally, you didn't take into account the human fear of change or that organizational situation where you've got a tiger team building the new system, and you're telling the mainframe team that they're going to be replaced and their job is no longer going to be there, and now they're not helping the projects move forward. So the biggest reason these projects fail are usually not technology-related. They're people-related.
So, from the chart that I always show them, as I say, you need to start with the business objectives. You need to get everyone aligned around why you're doing this and how you're doing this and how it's going to achieve value to your business. And then I put up a chart and it lists not business objectives: and it lists cloud, IoT, mobile-first. Those are not business objectives. Those are technology-first objectives. And then I list the business objectives: cost-efficiency, faster deployment to market, better customer experience. Those are business objectives. The technology is not the end all, be all. It is not the objective. It is a servant of people and organizations and delivering value to your customers. And if we constantly keep that in front of mind, especially as an organizational leader who's trying to drive these transformational projects, that will in itself write a lot of these bad decisions. If you're looking at it from what are we trying to accomplish, not how are we trying to accomplish it, and always keep that front and center, that solves a lot of the problems right there.
LC: That mission first people, first mindset. So, from an individual's perspective, how would they approach it? Because that's completely different.
MD: Absolutely.
LC: What's your suggestion there?
MD: So, just a few years ago, if you would ask me this question, I would've said, you need to reach out to, and I did say, you need to reach out to the other side of the aisle and start having conversations, build alliances, build relationships and be open to the fact that there's multiple ways to solve a problem. That's all still true, but more and more people are saying, "The right platform for the job." "I'm open to moving mainframe applications to cloud." Cloud people are saying, "I'm open to some applications doing better on a mainframe." There is some of that progress, but what I'm now hearing is, "Right platform for the application."
But in my experience, most of the time, to me, those are danger words, because when I hear them from a mainframe-oriented person, I hear, "But in my experience, most of the time there's no need to move the application." And when I hear it from a cloud person, I hear, "But in my experience, most of the time, you'll achieve better value if you move to the cloud." In my experience, most of the time before you've investigated the customer situation, the customer's business priorities, those trade-offs that they're willing to make, am I going to say everything needs to be as secure as it possibly can? Or am I saying I need to be on the cutting edge of the latest innovations? What are those trade-offs that the customer is willing to make? If you come to the table with an opinion that most of the time, and you need to justify that narrow slice of when you should do something different, you are not starting with the business objectives, you're starting with the technology point of view. Does that make sense?
LC: Lots of sense. Yes. Yes. So again, you've just got to be super open-minded, so that you can be able to collaborate effectively, right? Wow, that's a big deal.
MD: It's the same thing in the DEI space, right? There are so many really good people out there that just have no idea that what they're doing is harmful or painful for somebody else, and you have to constantly question and get the feedback in order to be able to engage with people in a better way, in a more open-minded way. And I think we have the same thing in technology. If the only people you're talking to are mainframers, or the only people you're talking to are cloud-first, clouders, I don't know. I just coined a new term. So if those are the only people that you're talking to and the only voices that you're listening to, then it's really hard for you to step out of your bias. And even then when you step out and talk to people that are different from you, you have to constantly reassess, am I hearing what they're saying with an open mind? Or am I doing that thing where you're arguing with your significant other and you're just waiting for them to finish saying what they're saying so you can tell them how they're all wrong. We don't want to do that in the technology space. We need to actually listen to the other person's point of view and go back to those business needs and those trade-offs.
Every business problem has an on-the-mainframe solution, has an off-the-mainframe solution, and often there's a "with," hybrid solution to every single one of these business problems. I want to take advantage of generative AI. Okay? You can do that by moving your application and your mainframe data off the mainframe. You can do that on the mainframe. And there's hybrid ways of doing that. Every single business problem usually. Alright, every single business problem, usually, most every business problem has an "on" way of doing it, an "off" way of doing it, and a "with" way of doing it. And you choose based on those other business priorities and those other levers, not based on the technology.
LC: So with all of that and the modernization, in your opinion, is it hard for organizations to say, well, we're going to go ahead and modernize and we are going to standardize at the same time? Is that a thing?
MD: Yeah. Another really, really interesting thing about mainframe modernization is the level of fear, unspoken fear related with this. You have a very stable environment that is the heart of your business, and people are terrified to change anything, whether it's modernize on, off or with, they're terrified to touch it. They've probably seen somebody come in and try to modernize before them and fail miserably and maybe even got fired. So there is a lot of fear, a lot of bias in this space. So it really comes down to just trying to get beyond that. I try to tell people that there's hope now. There's been a lot of change in just the last few years. So follow the bouncing ball and of course it all comes down to money. You ready? Okay.
LC: Ready.
MD: The pandemic happened, right? So prior to the pandemic, the calculation was do I take the risk of modernizing and updating my mainframe environment, whether it's moving it off, terrifying, expensive, or even updating it in place, right? People would buy a z15 and then not use any pervasive encryption. I mean, why are you spending the money? Because they were making the minimal amount of changes on their mainframe environment just to keep the lights on because their competitors are building a new mobile app and using IoT, and they had to remain competitive. So they made a very logical business trade-off pandemic happens, and the risk associated with not updating your mainframe environment is now right there in front of you. You can't ignore it anymore. You've been accepting unspoken risk for your business, and you're not able to respond quickly to a very dynamic business environment. So now in 2020, all of these people are starting to get serious about actually spending money on modernizing their mainframe environment, whether it's updating in place or moving off, they're now serious. What happens when there's money in the market? Everybody rushes in. So now we have tons of new vendors standing up. We have new players like all the hyperscalers stand up mainframe modernization practices. They're hiring mainframers where they never had anybody before. You have IBM releasing new technology, you have mergers and acquisitions like crazy.
I just built a chart over the weekend that showed some of the market consolidation happening in the mainframe space. The amount of change in mainframe modernization over just the last three or four years is mind-blowing. I've never seen this level of transformation from an industry point of view in my 30-something years as a mainframer. It is just really accelerating. So what that means is now not only do you have the ROI from a business justification point of view, but there's all this new technology too. So the options to keep expanding and those failures that you've seen in the past are no longer relevant. I hear mainframes tell me, well, back in 1997, a major bank failed to migrate their mainframe application to a distributed server. I'm like, but it's a completely different game.
When you pull out those dated horror stories, you are making yourself look like you're out of touch, right? If you're going to quote horror stories, recent horror stories and dive down into the why did it fail? Because just because something failed doesn't mean it's going to fail again. We need to continue to learn from those and evolve. It's a totally different game. Just in the last couple of years, anybody, I'm saying this now, anybody that did an assessment of what to do with their mainframe applications and they paid a consultant to come in and do it two years ago, you need to update that assessment. It's still a very different game.
LC: So with that, now that we have all the AI, we have access and keys to the city, is COBOL still the problem? Was it ever the problem?
MD: COBOL? Talk about bias. COBOL. COBOL was, I call it the language made for the people. So by the people, for the people. So COBOL was created because at the time, the only people that really knew how to program were being developed in the university space. Scientists and academics and Grace Hopper insisted that they develop an open-source language that could run on any platform in a way that anyone could program. So that's why COBOL is so verbose. It's intentional so that it's an easy lift to get to it. So COBOL being complex has never been the problem. It's a perception. It was secretaries and accountants that were writing those earliest COBOL programs, and you're a university graduate, you came out of university. And for those people, that's for people that don't know anything. But I'm educated and I don't need to deal with COBOL because I can deal with C, right? Because I'm smart enough to deal with C. So COBOL has never been a problem. There's been an unconscious bias against it, unfortunately. But the pervasiveness of it shows how valuable it was to have an accessible language that anybody could use. There's nothing wrong with the language.
And from a modernization point of view, an application built out of COBOL is just an application. COBOL, and any programming language is just a construction material. So one person builds their house out of stone, another person builds it out of wood. Wood is the oldest construction material available, but yet we build beautiful homes out of it. So the age of a construction material has nothing to do with the product that you build out of it, the application. So that's never been the problem. The skills, never been the problem. People not wanting to program because of the bias—there's some of that. That's pretty easy to get over if you just actually show people that they have a real job. I say the biggest issue with getting skills to work on COBOL is that the jobs we give them is, "Here's this old thing nobody cares about, nobody's accelerating. There's no new innovation. I just want you to keep the lights on." It has nothing to do with the programming language. It's the job. Who would want that job? There's not going to be any rewards. There's not going to be any promotions. The people working over here on Java, on cloud, they get to do all the cool stuff. They get to innovate. So when you have people in jobs that allow them to innovate and to be rewarded, they're not going to care if it's COBOL. So to me, that's the real COBOL problem. It's not COBOL at all. It's the applications that aren't maintained and the jobs that we create for people to maintain those applications is not a good job.
LC: It sounds like a marketing problem.
MD: I think there's a big part of that. There's a lot of perception involved here, right? Yeah. One of the ways you get around bias is by educating people, and you educate people through marketing. So, definitely.
LC: Do you have any last tips for us before we part today for modernization for the mainframe?
MD: Always. Always. Maybe even put a sticky on your board right in front of your face. Why am I doing this? Every single thing you do, why? What is the business value that I'm doing this for? Just the why always, not the how.
LC: The why not the how. That's excellent. Thank you so much, Misty. How can people reach you if they have further questions?
MD: I'm accessible on LinkedIn and I'm on Twitter, but not in any serious professional capacity. If you want to see pictures of snakes in my backyard, you go to Twitter.
LC: There are snakes in your backyard?
MD: I live in the wilderness. Yeah, there was a bear walking around my house looking in the windows just a few months ago. So yeah, I did not get a picture of the bear. But the 6-foot black snake. Yeah, I post pictures of him.
LC: Wow. Amazing. Well, thank you, Misty. I appreciate you. Misty Decker with us today, here with the TechChannel interview. Thank you so much for joining us, and I hope that you have a wonderful day. Thanks so much, Misty.
MD: Always a pleasure, Laticia.
LC: Appreciate you. Bye-bye.
MD: Bye.