Modernizing Mainframe Applications – Tim Jones, Advanced

This is Textron TV. Hey guys. Thanks for the throw.

We're here with Tim Jones who's managing director for at modernization at Advanced and we're talking about what's going on with mainframes. They have a new barometer report out. So we're going to dive into that in a second Tim.

Welcome the show. Thank you very much, Mike. Thanks for inviting me.

I think we've been talking about modernization on mainframes for the better part of two decades now. So what is the current state of the art? Where are we are people still staying in the Mainframe or they migrating from the Mainframe and for that matter?

It seems like modernization means different things to everybody who looks at it. So what are we seeing right now? It does indeed.

Yeah. I mean, there's lots of organizations still running big Mainframe systems. We've seen lots of people move away slowly over time.

But of course in the financial services industry in healthcare, we still see huge Mainframe installations, and I think in general people would like to move but of course it's in as complex those applications. We're probably written 20 30 even 40 years ago, and of course, we do know that the Mainframe just keeps on running and it's not a problem today. So it's something to push out to next year the year after Maybe.

But what we saw through the pandemic, of course with a lack of resources, we saw that situation change and I'm sure we can get into some low stats as we go through this discussion today. So one left out at you or what surprised you most since you know seems like both of us are very around the block a couple of times. So, you know as you look at all this stuff, what exactly is making you go?

Wow, I didn't think that that would be the case. Yeah, that's a couple of things actually, I mean we've been in the business of modernizing applications about 35 years. So this always a steady stream of people who were looking to move from one Legacy platform or applications something more modern, but what we've seen is that situation accelerates.

So if we look at if we look at before the pandemic then we saw 11% of organizations that undertaken some form of modernization initiative on their Mainframe States. If we look at that post pandemic that's risen to 90% So 90% of organizations that we talk to in these Enterprise organizations Banks and insurance companies government bodies have started to modernize because I think it's a case of we can't wait until next year. We need to address it now.

I think there's some other interesting stats that Name out of a survey and Report when you look at the top reasons for modernizing Mainframe, of course historically it's it's a very stable platform, but it's very expensive to run. Of course. There's the shrinking talent pool.

So many of these applications are written in in Cobalt and we also see lots of other languages like assembler even and my father's 80 years old and he started his career writing in assembler, but we still see lots of that code today. So there's a typical responses. It's cost or we want platform consolidation, of course in the last couple of years.

We've seen Cloud move to the top of that list. But the thing that really surprised Us in the latest survey is that people see security as the biggest risk to the organization and we did go wow, why can that be because of course a mainframe system is typically a very secure platform. But of course in order to really utilize the data that sits on those Micro Systems, you need to be able to extract that out.

And so when you get all these different integration points into the main frame and you need to get data out, then of course, you've got another type of skill set and a whole new set of processes and of course in that it creates risk and organizations are looking to implement single policies to manage that risk. So we were really surprised that that jumped to the to the top of the list. so security come out first second was the Strategic shift to the cloud and then third was the high cost of licenses and so on and then of course, we got things like the shrinking talent pool as I talked about So what is your sensor how many people are kind of re hosting applications as part of their modernization effort and shifting to the cloud versus saying going in and turning an existing application into maybe something that's written in Java using microservices.

What's the mix of that look like? Well, it's interesting. That's one of the questions that we ask.

So when you embark on your strategy modernization, what approach do you take and I'm sure you might that you've heard of the the five Arts. Sometimes called the seven hours depending how you look at it. But in the five hours we get refactor.

We get rehost or re-platform. We get replaced rewrite or retire. And top of that list is to refactor.

So that's to take your application which is written in Cobol or software AG's natural and then to convert it to something like C sharp or Java. So you can as a couple of different approaches for that one is that you can use an automated conversion technique and other is that you could do that incrementally and replace some of your services with Services written in new language types. And that's I think it comes out top of the list because it's seen as the lowest risk most predictable way to undertake that modernization but second is rehostery platform and that's what we used to call if you like the lift and shift.

So you take your Coble application you take it off for the moment frame and you move the cross you drop it onto your target platform. And sometimes that can be the right approach to take if you're looking to reduce your your run costs then that's often the quickest way to get there. Of course the challenge there is that your left potentially with the same language that you had before and some of the technical debts that you had in the application that you wanted to move.

Third. Of course is to replace so replace with some form of pots package of commercial off the shelf package and that suitable for some applications. If you turn about a finance application, which doesn't change particularly often then that could be good solution.

Um fourth on the list is to rewrite and of course if you were to speak to the development community, that would be their preference I suspect because you take your old application understand what functionality was in there build your list of requirements going to rewrite, you know application. But of course, we also know that's probably the longest time to value and of course the highest risk and we've seen lots of projects that start offers, you know, a three year timeline at turnout to be six years because it was just more complex than than everybody thought it would be but of course you can then end up with an application that is if you like cloud enabled clad optimized with macro and micro Services out to the gates. And then the final are is to retire that application.

So occasionally an application can be consumed within some other program that's going on elsewhere in the organization. So top of the list as I said is refactor, but when you look at any Mainframe, there's not normally a single application that runs on it. It's normally collects the Fabrications.

So it's probably fair to say that in this case one size does not fit all so often people will take on a different disposition strategy for different collections of their applications. And what application that you want to read Factor might be the right course of action to take whereas another one you may replace with cuts package and another one you might use to rehost so it depends it's a matter of understanding what you've got where you want to get to and and taking a balanced view on it. If I refactor and you start to see people adopt more devops processes and practices as they go to rebuild or rewrite those applications versus the more traditional waterfall kind of approaches that have been historically used in Mainframe organizations.

We have and I guess that's tied into people's view that I want to get to the Cloud. Of course when we look at our survey results. I think 68% of people want to go directly to the cloud.

To deliver some of those benefits, but of course attached to that. Is that whole devops pipeline? And certainly one of our customers interestingly most most of our projects undertaken in the US about 70% But one of our customers in the UK saw the turnaround time on implementation of changes on the Mainframe, it was two weeks.

And when they moved to their Standard devops Process, then they could deliver to releases a day. So to move to that high level of agility and to conform with the devops process in the rest of the organization. I think that is a key driver.

I don't think that people are prepared to wait for change now. I think if we go back 20 years then we talked about software changes. And we said yes.

Well that release will be on a cycle of one a month and that was okay. I think organizations Drive change far more quickly than I used to and that level of expectations there. So yeah, absolutely a place into the devops pipeline.

What's been the impact of digital transformation we hear a lot about it, and I guess a lot of applications may be calling on data that resides in a Mainframe. But is that a factor in the decision-making process for modernizing applications? I I think it is I think over the years people if you like have stretched those Mainframe applications and you can see that people have written integration points that lay to for instance put a web application on the front of your Mainframe data.

If you like one of our customers has developed a mobile application that looks like every other mobile application. But actually the data being served up is coming from the Mainframe and that can take you so far but I think you start to get challenged by the limits of how you can process that data. So I think that situation has has changed I think for people to be able to move if you like to the next level and internet of things and really modern Technologies and be able to support and move that Mainframe application forward then of course the time I think is comfort for Change and come out of those environments.

Are you seeing a lot more Linux running on mainframes these days because it seems like that's one of the big pushes that IBM has underway, but it's not clear to me if the customers are on board or not. Yeah, I think that some of the customers are on board and actually inside I have business most of our projects are to come off the mount train and that could be to go to a Linux platform Microsoft Windows platform. It could be to go into Cloud.

So people may going to AWS or into a****** or Google Cloud Oracle Cloud IBM Cloud, but then there are some customers who actually quite happy with the Mainframe but there are some cost benefits a from moving from the if you like the traditional cos processes on to Linux running on Mainframe and some of the projects to be undertaken all to take those applications and convert them to job, but leave them running inside Linux on the Mainframe. So, of course you can get some cost benefits and you get an application that's written in if you like a modern language that's easy to support and then that gives you the the option over the longer term to then take that job replication and move it off the Mainframe at some future points. So it can't depends really we see some organizations who want to take the leap and go directly from Mainframe straight into the cloud.

Some people want to come off the Mainframe. Onto Linux but maybe keep it on premise or in a private cloud with the option to move to to Cloud later and some want to take that first step where they just want to take those code applications converted to Java and continue to run it on the Mainframe you so that's different flavors of modernization that you can implement. For a long time we consider the Mainframe to be the realm of a particular set of high priest.

But do you think it's becoming just another node on the distributed computing system environment and we're starting to be able to use similar tools to manage it and this whole notion of you know, the Mainframe is being something separate and distinct from everything else is starting to fade away as the as the Walls Start to crumble a little bit between the Mainframe and all these other platforms. Yeah, I 20 it is I'm in the Mainframe as you said can I run Linux and and that's absolutely a step forward. I think the challenge that we see an organizations though is that these applications are written in pretty old languages like COBOL and In fairness, there's lots of cobal developers still out there.

I remember back in the 1990s advertisements in on the British Publications computer weekly saying if you don't get on board and learn Java, then you'll be working at your local burger place flipping burgers. And of course clearly that's not changed with 30 years on from that point, but it is a reality that those COBOL developers are starting to retire and then moving at the market. We know that there's not new people coming into this Market.

You don't come out of college or university Having learned COBOL. So I think the pressure is Shrinking Talent port to a certain extent. So yes, my frame is is absolutely more open than it used to be.

And but it's still not as easy to move those workloads to the cloud as it would be if you had applications running on x86 processors somewhere in your business and we've seen customers of ours that have taken if you like the low-hanging fruits taken those environments that's it on x86 that moved into cloud and then I've got the monolithic Mainframe application still running the corner that is now present a challenge for their business or organization. Hmm. So once that one thing you see people do when they start out to modernize Mainframe applications, that just makes you shake your head or a Converse.

That is what's your best advice to folks before they get started. Yeah, well, I've been in this business for some years and if I go back in my career, maybe 10 to 15 years ago probably half the projects that we took on with customers was off the back of a customer failing to complete to rewrite of that application. It was taking too long.

They're easy to get off the platform. And so they're coming to us to accelerate that that process. Um, my advice would be to complete an assessment first.

So really understand what it is that you've got on the Mainframe consider those different dispositions strategies. Whether it be refactor re host rewrite retire replace. And come up with a clear plan ahead of actually starting that program.

I think it's very easy to go. We need to replace this Mainframe application our preferences to go and rewrite it and you kind of carry on headlong into that and it takes you a lot longer so I think complete a thorough assessments understand what you strategy is. It should be aligned to the rest of your organization and make sure that you've got a clear plan with a very clear approach that focuses on the mitigation of the risk to ensure the most predictable outcome.

All right, folks. Once again failing to plan is planning to fail. Hey, Tim.

Thanks for being on the show. Thank you very much. Indeed Mike.

Thank you for your time. Thank you. All right back to you guys in the studio.