Episode #3: The Findings: 2022 Mainframe Modernization Business Barometer Report

2022 MAINFRAME MODERNIZATION BUSINESS BAROMETER REPORT

Rob Anderson

Good day everyone and thank you for joining us. My name is Rob Anderson. I'll be today's host, and I'm excited to welcome our panel of three wonderful modernization industry vets to the show. First, we have David Wurman, Global VP of Sales for Application Modernization here at Advanced. He brings nearly four decades of experience and quite a long track record in mainframe modernization with him to the table. Welcome, David. Next, we have Tim Jones, Tim's Managing Director of Application Modernization here at Advanced. And aside from skipping our ship, he has many years of experience in the space as well. Finally, we have, of course, last but not least, John Regan, John's Head of Development Central Services here at Advanced. You guys have met John before on some of our previous shows. He heads delivery of the services most of you are here to learn about today, and he does so with over 25 years of experience in this space.

ow, we recently published our: 2022

And together we work to establish a representative population of potential respondents based first on whether they had a mainframe, second, where they were in the world. And third, the industry that they hailed from. You can see the table on the right provides respondent counts by industry and geography. And as mentioned in the report, the attempt here was to ensure that this smaller population was as representative of the broader population of mainframe users and their distributions in sector place. This survey was conducted in May and June of this year, and it targeted 416 individuals. Most of those folks were enterprise architects, CIOs, or heads of IT application managers and or program or project managers that are responsible for modernization tasks. This primary research was split into two stages, first Coleman Parks conducted the main survey, which consisted of a q and a type of exchange.

The team in advance gave Coleman parks our demographics requirements. Then we created a questionnaire under the watchful eye of the experts at Coleman Parks. The team there conducted the actual survey against an anonymous population of respondents who met our demographic criteria. So, we at advanced, were never exposed to the identity of any of the respondents that answered the survey. There is a degree of anonymity that came along with this process, which is very important.

The second phase of this research consisted of 10 long form interviews. So basically, Coleman Parks came back to us with the results of the initial survey. We were able to create a follow up questionnaire to gather more info based on answers to the survey that stood out to us and then Coleman Parks went back and conducted those 10 interviews again with an anonymous population, The aggregate of these two exercises, both pieces of, of primary research are what fed the report that we published.

at was their top priority for: 2022

Now, let's jump into the actual conversation here, guys. The first thing that, that I'd like to touch on is the spend. I don't think that this is going be a surprise to anyone, but mainframes are expensive. There's a reason they are secure, they're phenomenal transaction machines, and they're tried and true and have been the trusted workhorses of business for the better part of 40 plus years. We do know from a lot of our conversations that the costs of keeping these systems running is increasing while the cost of alternative infrastructure like cloud providers is decreasing. So, there's a really interesting conversation happening out there about what to do when it comes to the value that is coming from mainframe spend. John, question for you. You know, when, when you're in the field speaking with folks who are looking to make a move or who are on their way, has there been anything especially recently, let's say within the last 12 months that stood out to you as a common driver that may not have been something that you've seen in the past or, or that seems much more underlined than before?

John Reagan

Money's always at the root of most people's modernization plans. Normally it starts off about the money. But increasingly I think we're starting to see the, the skills being an issue. The fact that all the guys who know anything about the mainframe are getting older and getting white beards like me, and they're starting to think about maybe retiring. So that's increasingly becoming an issue for people where they can't find the skills required to keep their mainframes going. so, I'd say that's become much more of a driver over, over the last few months and years. Maybe some security issues as well. I think we touch on that as well, in the presentation, aren't we?

Rob Anderson

We will. The basic economics of course is scarcity increases, as does price, and, and that that is the connection.

Tim Jones

65 million is of course a big number, as you said, we know mainframe is expensive. I think the thing it highlights to me is just how much of that 65 million spend is, if you like, keeping the lights on. So, maintenance costs, the hardware costs, and actually only 13% of that spend is really driven towards innovation, which is going move the organization forward.

Rob Anderson

Definitely. And, and I think a lot of folks see that spend as a hedge against the risk of change as well. But we'll see some more of the information that we've gathered, that it does seem to be changing a little bit too.

So, one of the questions that we asked, is what is the most prominent language in your mainframe estate? There are a couple of questions here that, that I think it's worth noting. The statistical relevance of the population size. So, 416 is, is certainly a great representation. And the strategic feedback that they provided us about, you know, where their heads are and where their businesses are is, is extremely useful. And we can correlate a lot of the attitudes out there in the market through those conversations. But when you ask a question like this, it can be skewed simply because the number of respondents is low compared to the number of total people who might have languages on mainframes. So, while we do include this to show, that there is a diversity of different languages out there, I wouldn't lean super hard on this being the definitive representation of the entire mainframe market. I don't think it's a surprise that COBOL is up top. But gentlemen, is there anything else that stood out about this to you?

Tim Jones

think of Assembler, you know,: 1960

David Wurman

The one comment that I would make Rob about the Assembler would be that, in the mainframe environment, the Assembler tends to be associated with the platform, you know, in doing certain types of functionalities, and some of that functionality gets replaced or goes away when you move off that same platform. So, in some cases, a simpler might be, prominent in the estate, but it might not be as prominent in its requirement in terms of code volume, to be migrated off the estate.

Rob Anderson

That's a great point.

So top reasons for modernizing mainframes. Just a quick comment, you'll notice that in many of these, the total adds up to over a hundred percent. The reason for that is that people could provide rank order answers. So, you could have, you know, the top language, the second top language and so on. So that is an aggregate representation of those rank orders. We have not completely lost our minds, uh, and that's why it looks that way. So, top reasons for modernizing mainframes, this was probably the most interesting discovery that we made this year in the past. The answers tend to be the answers that we've heard as modernizers for quite some time. There's technical debt, it's cumbersome, it's hard to find the people that know how to work on this stuff, etc.

Security issues, this is the first year that security issues rose to the top of the list. We're very surprised by this. In fact, this was a big topic of the follow up interviews that were conducted because we wanted to understand what that meant. Anybody who knows mainframes knows that mainframes are inherently incredibly secure. What turns out that when we dug a bit deeper with the respondents, we are being Coleman Parks research, of course, asking questions that we were interested in the answers to, it really came across three areas. The first area is security compliance. So having somebody on staff that understands the languages, databases, and environment enough that they can attest to, and step through all of the compliance stuff that's necessary. At whatever rate is necessary for the compliance standard that you're trying to meet.

Second is the increasing attack surface that comes with connectivity to the mainframe to support other modern platforms. So, as you're innovating, say, on, you know, the company mobile app to make sure that you can do, I don't know, take a picture and deposit a check instantaneously, for example, something along those lines. Those innovations require, in some cases APIs and, and other pieces of third-party software to connect to things that the mainframe touches or the mainframe itself. It appears as though the opinion is that as that attack surface increases in size, the risk of there being a security issue with one of those ancillary pieces, rises as well. And finally, and I thought this was the most interesting, was that more this year than we've seen in the past, people are trusting the hyperscalers to secure their infrastructure.

In other words, AWS, Google Cloud, Microsoft, Oracle, IBM and others are better suited to secure the infrastructure than we are in house. We would rather place that risk in their hands by using their, you know, massive infrastructure than taking that entire thing on ourselves. Which was really interesting. So, it turns out at least from the follow up conversations that, that we had with folks, that it isn't the security of the mainframe itself that's in question. It really is security more broadly speaking and its impact on, on the mainframe. Guys, do you have any thoughts about this?

John Regan

I think we're seeing an increasing number of people who want to target the cloud for, I think for this very reason. So, the cloud also is a good target from a mainframe modernization perspective, because typically mainframe workloads tend to be pretty choppy. So, there's busy times of the day, busy times of the month where you need more resources, you need more processing power. So of course, that's perfectly suited to a cloud environment where you can dial things up and down. But when you add that to the fact that you can also then rely on the cloud providers to provide your security and to make sure things are constantly patched and constantly updated and everything is as secure as it possibly can be, you couple those two things together so that the ability to dial up and down resources and the security, then I think it's a very powerful offer.

David Wurman

I see more people saying, Okay, I'm going to move a subset of my applications or a pretty good, you know, portion of my portfolio off the mainframe, and I'm going to move it to a cloud environment. Well, as John was saying, the cloud environment is already provisioned, let's just say with active directory or some means for adding, deleting profiling individuals. So, when they're looking at, you know, the, the applications that existed or have existed for decades on the mainframe, and they say maybe those applications had some built in security aspects to them, I don't want to say hard coded, but they had some, you know, means of security. And now the rest of the organization is kind of moving into this other security realm as John was kind of pointing out. That becomes a big issue for me in modernizing, like, I'm going to be moving these applications or modernizing applications. I need to kind of move it, the application security that I was doing before and the mainframe into more of this hybrid environment or maybe a cloud focused environment. And so, I can see that, you know, the more of that that goes on, how security can now start rising to the top as you're taking that element outside the mainframe.

Rob Anderson

Very good, very good. So as, as a bit of a follow up to the, the cloud conversation, um, we were curious, you know, what is the target platform? Obviously cloud conversion, pardon me, cloud migration is, is tends to be the topic at hand. Um, but there are lots of combinations of destinations depending on the workloads. And, and Dave you sort of hinted at this, you know, peeling away certain workloads and, and dropping them in the place that makes the most sense is, is a best practice. Um, we, we have seen an increase in focus on public cloud platforms as a target. Um, but there are still quite a few workloads that land in private cloud, private data centers, um, hybrid cloud environments, not just hybridized by the mainframe, um, but, you know, hybrid between distributed systems and, and also hosted mainframe environments. So, we're seeing a, a small group say, uh, you know, we, we love the mainframe, we wanna stick with the mainframe. We just don't wanna have to worry about, um, facilities costs. And, and there are options out there for that. Does anything stand out to you guys about this? And, and in your experience, especially in the day to day with these folks, what have you found? Is there a different feeling amongst people when it comes to, uh, cloud versus other alternatives? In recent times?

John Regan

I'd say people either tend to be in it or not in it. So, some people are very keen on cloud and are bought into the whole concept and the benefits of moving to the cloud, and they don't really want to hear about anything else. And then you've got some other guys who are still quite skeptical, maybe they think they can do a better job of securing their own environments than the cloud providers can do, you know. So, it seems to be a very split market out there, although increasingly more and more people are, are deciding that the cloud is the right way to go as far as I can see.

Tim Jones

I think it's interesting, Rob, that cloud has taken poll position on that slide now, and I think in lots of the conversations we have, people probably don't go directly from mainframe to cloud. They go from mainframe to some data center somewhere or some private cloud with the opportunity to move to cloud at some point in future. I think what we’ve seen probably post pandemic is that acceleration directly to cloud. And I think that lots of organizations have moved their X 86 workload across the cloud, and now you've got the big mainframe kind of in the corner that they need to move that workload there too, as part of that overall platform consolidation and strategy.

Rob Anderson

That's a good point.

David Wurman

I know that what I've seen on that last slide was that Tim's point, like the idea of moving to cloud, but they might not have a full cloud strategy for the enterprise kind of figured out. And so, it's the private cloud or data center option that middle ground is a safer lower risk environment, less technical change for them. And so sometimes they'll go to that environment for a number of years, two years, three years, five years, whatever it might be, and then go to the cloud. And you know, in retrospect they say, if I had a clear path to the cloud already today, I might just skip the middle step. But a lot of them are still figuring out the details, especially of, you know, perhaps a mission critical decades old application that is, you know, a core intellectual property piece of the business.

Rob Anderson

Sure, I could see that. And the risk that comes with making changes to that, they see it as an intermediary step. Definitely. Right.

I found this interesting, curious about you guys' thoughts. Java has grown in popularity as the enterprise development language over the years, so there's no huge surprise there, but Python is gaining, and obviously the use of Python and the use of Java are for tools for very different purposes. Python tends to be a bit more mobile app focused, and Java tends to be a bit more enterprise focused, but of course we have C#.net and others. Is there anything tangible or what are you guys seeing out your day-to-day experience that might speak to this a little bit?

John Regan

We are predominantly seeing people wanting to go to Java and C# because I think people have already a built-up capability in those areas. But I think new technologies are coming and will eventually overtake some things. My daughter has just finished her maths degree and she's learned Python and R which seemed to be very popular at the moment. So, I think, you know, as things develop and she didn't do anything in Java, as things move forward, we will find other technologies coming to the fore. So, whilst at the moment Java and C# are prevalent, that probably won't always be the case at all.

Tim Jones

I think that's probably fair, John. And I guess to your point, Rob, Python is a hugely popular language, and if you look at the recruitments of skills for a particular language, I think Python edges.

Java nowadays. But I guess for the sort of systems that you take off a mainframe, if you think of the transaction processing, then I think probably C# and Java are better suited. Had that changed over time, be interesting to see. But I think that's the case today.

Rob Anderson

I think that's a great point and interesting to see in five years, you know, maybe solidity and rust find their way onto this list, but I won't count my chickens before they hatch. We a great question come in. What about mainframe modernization in place? Several organizations are finding that cloud isn't delivering what they expected. And, and I think this raises a good point. There is no silver bullet when it comes to modernization, and I think that's one of the key pieces what you're trying to accomplish, the systems that you're trying to replace, the culture that you have within your company, and everything that revolves around that is really going to dictate what's best. We do call it from a, from a marketer's perspective, application consolidation. So that is, you know, taking everything to a single dialect of COBOL on the mainframe to simplify maintenance or something along those lines. We do plenty of those as well. And it really depends on the circumstances when we're talking about cloud migration and a lot of the themes that we're discussing today, there is a broad trend, but there will always be, you know, in the details those on mainframe modernizations and so on.

So, I found this one interesting and, and I I'm curious about what you guys think. There is, obviously mainframes are monolithic in nature. That's, that's the story and in most cases, at least from my perspective, correct me if I'm wrong here, but, but it appears as though when we step into these engagements, the priority is, extrication from the platform and then stepping into the function of the applications themselves and, and how those can be modernized as a kind of a secondary process. You know, taking off small bites as we go, it appears as though that that seems to be the same thing that folks are preferring, optimizing incrementally, peeling away different pieces based on need. There's also this concept of macro services, looking at the broader picture and dividing it into small functional pieces that make logical sense to remove and, and essentially getting to the cloud or getting to the target environment first and then peeling things away to optimize from within. What are you guys seeing?

John Regan

Typically, our projects are a steppingstone on someone's journey to modernization. So typically, we are moving someone to a better place for them to move forwards. It's not the end of the journey. So that fits in well with what you just said about on mainframe modernization because you know, a lot of modernizations about trying to standardize a little bit on the technologies you've got and reduce your reliance or maybe more bespoke or more uncommon technologies. So that's, you know, about a quarter of our projects any one time, on mainframe modernization to move people forwards. Moving incrementally is very much the key to most people. Any kind of, you know, mass event is not good really in general for most organizations. So, moving them forwards to somewhere where it's easier for them to then modernize is great.

We did a modernization for an insurance company in the UK that finished maybe six or seven years ago, and in the intervening six or seven years, they've modernized, they've rewritten and modernized about 50% of the functionality of the application, but they could, that's taken them six years. They could have never done it as a standalone project just starting from scratch. It's only because they're in a modern, they happen to be in an escrow server type world, it's only because they're already there. They could modernize a little piece at a time, you know, and move things forwards and change some functionality and, you know, make things more as they want them to be. So, so what we did was enabled them to then move forwards a pace that they could manage.

Rob Anderson

When we think about modernizing workloads and what people are trying to accomplish when they do that. And John, you know, as you point out rewriting things and optimizing things for the environment that they're sitting in, one of the questions that we ask folks is, hey, listen, you know, clearly getting to the cloud is a growing trend in our space. What is it that's so attractive? And to me there isn't anything super surprising here. Obviously, scalability and elasticity, you know, the horizontal scale of cloud is, is what makes it so easily flexible, infrastructure as a code, you know, the ability for there to be automated orchestration is that, is application driven is cool and unique and required to accomplish a lot of new and innovative things. What are you guys hearing out there? What were your impressions?

Tim Jones

I think your point about scalability, I mean, it's interesting that is top of the list above having a managed cloud solution. I do wonder, Rob, whether that's a result of the pandemic. I think where we saw that impressed into demanding some areas coming into certain systems. If you've got fixed CPU ceiling, people are hitting that. So, I can totally see why the horizontal scalability becomes really attractive in the post pandemic time that we're in there. So, it'd be interesting to see how that might have changed over time if we, if we had that data.

Rob Anderson

Yeah, agreed. I think that horizontal scalability was really underlined when in the early days of the disruption of the pandemic for sure.

So John, you, you spoke about this early on and, and this, the available skills to work on this stuff is a recurring theme across all of the subjects that were covered both from the original questionnaire as well as the follow up interviews, from the downstream effect on the cost of acquiring and retaining resources to the risks associated with, with various technologies or environments that have very few people out there able to work on them. It does appear as though the, the feeling is that skills are decreasing more rapidly than in the past. And whether that is, you know a feeling that's come simply because of the macro environment or whether that simply is a side effect of the fact that, as John said, time goes on and people get older and, you know, retirement is, is on the horizon for a lot of folks. It does feel to our respondents as if yes, the skills are decreasing, and it does seem like they're decreasing more rapidly than previously thought. Are there any exterior actors on this that, that you guys can comment on that you've seen in the past 12, 18 months?

Tim Jones

ecause I remember back in the: 1990

John Regan

I mean, we've heard about some organizations who've literally started their own training schools to get themselves some programmers for the skills that they're lacking, you know, so they're taking people out of college and trying to persuade them to learn assemble or something. It doesn't seem to have been that successful because ultimately, they don't want to learn it because what goods it for the future, you know? They don't have the experience of the systems to help them understand it. So, you know, it's a steep learning curve. A lot of the people now, especially when the people they're trying to replace, you know, have been working with COBOL and Assembler for 30, 40 years. So, the new guys coming in are not only need to learn the COBOL and Assembler, but they're also lacking the 30, 40 years of experience. So, it's a tough, it's a tough gig to get people in.

David Wurman

The comment that I would make on that is that it's not only kind of the technical experience, but it's the, this notion of a subject matter expert within an organization who knows these applications who might have been developed over literally decades. And so, how did they, do something with the database integration with the application? How did they integrate security? Why did they choose to architect the database in such a way that now the applications are layered over it? If I'm trying to take the applications off, I actually have to go and decouple how the database, you know, is a common aspect among all applications. And so, the person who did that work, those people are, you know, are eventually, as John said, they're planning to retire at some point. And so, I think a lot of organizations have kind of kicked the can down the road because they've had a luxury to do so.

But in some cases, they wait a little too long and we get brought in and then the first step is analysis, and then we get back, you know, feedback like, well, we don't quite know why that works that way, although we, our organization designed it. So, it's not just, I need somebody with COBOL skills, I need somebody with IDMS skills or IMS database skills. I need somebody who knows why we did what we did 20 years ago so that we can redo it or undo it or do it better now. And I think that's one of the, you know, the technical debt penalties that you pay for kind of waiting a

Rob Anderson

It's a great point. And, that is a call out that we, that we saw across a lot of the interviews was, you know, our modernization process was made substantially easier by doing it while the people who understood the legacy systems were still aboard, and, you know, hadn't retired or moved on to other things. And both from a modernization process and understanding the logic perspective, but also post modernization, you know, working with the teams to unpack whatever maintenance they may be doing after the fact, because in the end, you know, you still have similar structures. So that's an incredibly good point. And, and of course it depends on the technology you're dealing with and, and the systems and applications you're dealing with as to how much of a risk the resource scarcity really is.

We asked which of the two, which are the consequences of choosing not to modernize. And this list changes every year as we get new consequences listed from respondents. I found it interesting that the increased risk associated with system failure and downtime, was as high as it was and wondered whether, some of the sort of headline issues that appeared in during the pandemic fed these opinions. I think, you know, to the point of the conversations that we had earlier, you know, talent is a huge component of it. Gentlemen, what stood out on this, on this to you?

John Regan

I've got a story for you, Rob. So, one of our projects that we did, that finished a couple of years ago was for a county, and the west coast of America, who should remain nameless. It was the prison system, so the system that managed all the prisoners in, the prisons in that county. And we were almost ready to go live. We were about six weeks away from going live. And the mainframe, the system was currently running on broke. It was their own mainframe in-house, mainframe broke. The guy came to try and fix it, and he said, Yeah, not really going to work out for you guys. It's broken and you know, it's going to need all these parts and blah, blah, blah. Meanwhile, there were all these people backed up in the prisons, no one could be admitted, you know, it was a bit of a crisis over a sort of three, four-day period.

So, we spent intensive time talking to them, deciding whether to go live immediately with that system. In the end, the guy managed to patch out their mainframe with some, uh, you know, a bit of a scrap heat challenge kind of situation. And he said, you know, it'll probably, it might last a week, might last two weeks if you're lucky, but when it goes again, that's it, mate, you've had it. So, the following weekend we went live with their system, and so they just about made it in time, let's say before they were in a lot of trouble. Cause if they hadn't have had the project going on, they hadn't have had a replacement system, they'd have had to, buy new mainframe or whatever they'd have had to do, they'd have had to pay, you know, potentially millions to upgrade that mainframe for the one system that was there running on it. You know, because they, what could they do, you know, the prisons out to, to let people in and out to let people out, you know, were due to release. So, they literally didn't know who was due for release, you know, anything about the prison system without them, without the system.

Tim Jones

The interesting thing for me, just on that slide, Rob, and I think we see it on a previous slide, is, you know, cost is some way down the list kind of at a midway point. We talk about how expensive mainframe is and of course any modernization project needs to prove itself in terms of ROI. You wouldn't do it to then cost you, costs you before, but it's interesting to see the list has moved, it's more focused on risk and the constraints that that environment or the lack of skills then impose on the organizational business. So, it's that sort of risk of doing nothing or inability to, to, to move to meet market can be more important than just the cost of the mainframe itself.

John Reagan

I'd agree, Tim, although the cost always needs to work, so the money always needs to add up for people to move forward. So, whilst that might not be a consequence for them, ultimately there always ROI and that has to work for people for them to move forwards.

So, I think on this slide, we were just seeing that our prevalent is, that people want to, that are doing modernization projects. So certainly in the past, when we've asked people this question, it's been, you know, there's been a far fewer people who are actively doing modernization projects or maybe they did one five years ago or whatever, you know, but the vast majority of people are doing something about modernizing, you know, it's not as, as I think when somebody said earlier, Dave, I think said earlier, there's no more kicking the can down the road.

David Wurman

It's interesting. John, that you know, you and I have been kind of working closely together for over a decade, and it just seems within the past, I don't know, 24, 36 months, that there's been an uptick. I don't know whether its cloud related, you know, the increased, kind of comfort level to move things to the cloud. I don't know whether it's, this perfect storm perhaps of that in addition to people getting to a critical age, and kind of aging out of the workforce, or aging out of the desire, you know, to put in the extra time and energy, or realizing that, you know, a modernization effort, you know, isn't done overnight. You know, these applications are essentially optimized over decades and you're not going to replace them over decades.

You want to replace it much more quickly than that to get a better ROI, obviously. But it's not done overnight. You have to start, you know, the journey, with the first step. So it just seems like there's this uptick and an interest level to initiate a project and kind of move forward with a project, you know, where, as an example, we can talk to people for five or 10 years about all the pros and cons, but I think a lot of those people that we spoke to previously are now making that jump for a variety of reasons.

Rob Anderson

invented the five Rs back in: 2010

For the purpose of this questionnaire, we defined each of these outright so that we were sure that we wouldn't get a confusion of terminology, from refactor. Essentially what we are referring to is, converting code using automated tooling. Rehost/re-platform is to retain the existing application code. So, you know, rehost, COBOL, for example replace would be to purchase software packages to replace the functionality. Rewrite/re-engineer is to change the function and architecture of the applications as they're modernized. Retire is to turn them off entirely. We've seen in the past that refactor tends to be the most popular approach because of all the things that we spoke about earlier. But obviously that everyone's situation isn't the same. I think, Tim, you had mentioned the, the commentary in the nineties there was, you know, hey, there won't be any COBOL programmers left. Well, it turns out COBOL is a very popular programming language, and while it may not be the top choice for computer science graduates, it's still, you know, very widely practiced. And there may be a situation, especially in the financial sector that tends to move a bit, little bit more slowly from a modernization perspective where you have a great team of COBOL developers that's not going anywhere, and it's the infrastructure that you're most concerned about. Then Rehost works in that case. In the early days, I guess when I was involved in the modernization industry, the conversation often began with, you know, we had this mainframe, we know what it does, so we're just going to write modern versions of those applications and turn the mainframe off and we'll be good to go. There was essentially a struggle that would ensue and a scope that would creep into infinity through that process and it appears as though the brute force rewrite re-engineer type of an approach to modernization, at least in, in the broader sense has lost some of its steam that it had in the past, likely because of some negative experience associated with it. What do you guys think? What are your thoughts on, on these?

Tim Jones

I don't think it's unsurprising what we see there, Rob, that's probably remained pretty consistent. I think over the years we've done this. I think it's probably fair to point out as well that, you know, one size doesn't necessarily fit all. So, you may have a mainframe with 30 applications, and of course you can take a different approach, but each set of those applications, so some could be replaced by COTS and some you may choose to refactor. So, it's probably, it's a combination of those things that might be what you were about to say, John.

John Regan

That's exactly what I was about to say actually, Tim. It's not a one size fits all, and that's right. And actually, you know, for one organization, all of those strategies might be applicable for different applications. Part of it to me depends on the sort of longevity of the application and how long you think it's still going to be in place. You know, if it's something that's never going to go away, then maybe the effort of rewriting or re-engineering it, it, it could be worth it? But, and if it's something with a very short lifespan, then maybe rehosting it can be okay, but refactor somewhere in between, you know, so something that's got a fairly decent lifespan, is key to the business, but basically performs the functionality that you need there, maybe a refactors the way to go. So, it sort of depends on the business need and how long is it going be around to what is the right strategy maybe for each application.

David Wurman

One of the things that we've seen, in kind of the first step of an initiative is to kind of assess, you know, what is there and the platform and the environment. And a lot of customers will come back to us and say, I want to see if you can validate my assumptions. In other words, I have a set of assumptions based upon what I think I know, but I want you to come in here, take the first step, show me your assessment, and then tell me is it a good idea for me to try to rewrite these specific applications? Is it a good idea for me to move this piece off the mainframe and maybe keep this on, or if I move them, you know, everything off to put this in a particular environment and that in a particular environment, and will they work well together? So, a lot of times people have a sense for kind of what they want to do, but they just want to get another opinion, and then they just want to get some more insight to help them, you know, validate their roadmap.

Rob Anderson

Absolutely. And understanding what other people who find themselves in similar situations have done. Because I mean, it’s like you guys have said, it's not always a black and white answer. It depends on so many different pieces. I think this also leads us to the, well, if I can get us there, I'm having all kinds of fun times. I think we spoke to some degree about this, you know, why someone chooses a particular strategy. What I'd like to jump to is some of the challenges experienced. And I, I think that this is a really important part of the conversation because we both as industry participants, and as you know, myself as a marketer, focus on, the act of modernizing. But one of the things that I think is really important when it comes to finding success, vendor selection, ensuring that you've got the, the right resources, doing the right things to make sure that, that this is as smooth a process as possible is understanding some of the troubles that people have run into before.

I said it at the top of the, the hour. If looking for a silver bullet to modernize, then you will not find it. It's not a simple process. The industry exists as an industry for a reason. It is primarily driven by very complex systems, and experience in both using the systems, understanding the architecture of them to today's comment earlier, as well as experience. Going through modernization as an exercise is a humongous prerequisite for realizing success. An array out of bounds issues with older languages versus newer languages is, it's just one of a million different things that can potentially come up that you might not realize is a hurdle that you have to jump over. The process of modernization, simply beyond designing a target state and of course, quality challenges, not all tools and teams are created equal. And that's an incredibly important part of, the process of sussing out the direction that you want to go. Gentlemen, do you have some commentary on this piece and, and some of the challenges that you've seen and, and what to consider in overcoming?

John Regan

I think it's key, Rob, for people to talk for any organization who's embarking on a modernization to talk to as many people as possible, because for any organization, they will only go through a few modernizations over quite a long period where there's people out there, you know, vendors like us and any of other vendors who offer migration services, who this is what we do. So, we've seen a lot of projects. One of the things that we can bring to the table ask some people like us, is experience, which is a key, a key thing really for people to leverage to help them make the right decisions and the right way to go forwards. Because these projects aren't like normal IT projects, normal IT projects you're trying to affect change and you're testing the whatever you wanted to change has changed. With a modernization quite often you're testing the exact opposite that nothing changed, you know, everything's as it was, but just something, you know, you got new language or a new platform or something's changed. So, when you start doing that, there are quite a lot of challenges.

Mainframes are very forgiving. They do their best to carry on under all circumstances. And that's not quite the same in more modern environments where, you know, where you do something mad, you know, on the mainframe, it'll just try its best to carry on and do its best with you, whereas new environments will go, hang on a minute, that's mad. You're not allowed to do it.

So, there are a lot of challenges in these projects and we've, you know, we've got the experience, you know, us and people like us have got the experience of being able to deal with those challenges. So, it's vital for people to leverage that experience, I think is a key.

Rob Anderson

And planning for that to be part of the, you know, allocation of time, resources, thought, etc is a big piece too.

We asked folks, you know, when you have a modernization need, what are some of the challenges that you run into as you're expressing that need from within the organization? I thought it was interesting these answers have remained the same over the years, but a lot of it revolves around a general lack of IT understanding from key decision makers in the company, and the role of, innovation engines like cloud, for example. When in your experience, gentlemen, do any of these stand out particularly to you? I know fear of change has certainly been one that we've run into a few times as well.

And finally, there is a massive movement for ESG initiatives across the globe and reducing greenhouse gas emissions. And we were curious, as we are every year, where does that conversation come into play in the modernization process? And there is always a, a substantial lean towards an improvement from an environmental impact perspective that comes with modernization. And it does appear as though these initiatives are more of a priority among especially larger global organizations within the past year than they have been in the past and we've seen quite a bit of commentary, especially in the follow up interviews about that impact. And of course, you know, the economies that come with scale removing the facilities costs and overhead from an individual and taking it into a multi-tenant environment, obviously, you know, simply has some of, of those economies of scale at play. Any thoughts on the ESG side of things?

John Regan

I think mainframes are, you know, a lot of the older ones certainly are still water cooled, so there's a whole bunch of stuff going on, to keep them running a lot of electric required. So, I'm sure it does help people sustain their ability goals to get onto more modern equipment that will be a lot more efficient.

Tim Jones

And I think, I think you're right, Robert, I think that every large organization has a policy around sustainability and, you know, the improvements of green, so to speak. I don't think it's a deciding factor to maybe modernize, but I think it's something that they look for as an outcome to improve the position there. Absolutely.

Rob Anderson

Excellent. And, and that brings us to the end of our, of our talking points and overview. Folks, hopefully your biggest takeaway from this conversation is that there is no one size fits all answer to modernization. The most important thing that you can do is understand your options, understand what others have learned going through the process, and listen to the experts, things to pack before your journey, so to speak. If you haven't given the mainframe Modernization Business Barometer report a read, I highly suggest that you do.