Driving innovation through mainframe modernization with Kyndryl & AWS

So, um welcome to the Kindred sponsored session. Um what we're gonna do in this session is walk you through Kindred's view of how you should set about doing mainframe modernization um in uh I guess the mid 20 twenties and also um some uh exciting announcements that we pleased to do in partnership with AWS.

So, um sit back, enjoy and between the three of us over the next uh 45 minutes or so, um we will uh take you through this little journey. We're gonna do Q&A at the end. Um but um so uh save them up until then.

So what we're gonna talk about here, we're gonna give you a little bit of view of how the market is sitting today, what the expectations of customers are that we're talking to what we would expect them to, to come forward in terms of what they're planning to do around mainframe modernization.

Um we're then gonna talk a little bit about what those patterns of modernization look like and how AWS plays a or can play a significant role in the mainframe modernization that you said about doing.

Um and then we'll get into the announcements and the new capabilities that Kindred is uh announcing today and then obviously we'll wrap up.

So the first thing, um mainframes are gonna be here for a long time. Um they are very resilient. Um the results that you see in the middle here. Uh there's a link in the bottom right hand corner to an independent survey that uh Kindred had done earlier this year and we released the results in uh September 90% of the respondents and it was about 500 odd respondents.

Um and, you know, they weren't all Kindred uh Kindle customers. Um about 90% of them said, you know, mainframes are in our business. They're gonna stay here for uh for the foreseeable future. However, 95% of them said we are going to move some workloads off. Few of them said we're going to move it all off. But a lot of them said, you know, we're moving into a hybrid world where the mainframe is going to be here. And, you know, a hyper scale or AWS in this instance is going to be uh you know, the part of the hybrid cloud solution that we put together here and those that were choosing to uh to move workload off. They said on average 37% of our workloads are gonna move off.

So this sort of fits the Kindle model that we touch on a little bit later about the right platform for the right, workload and in a hybrid cloud world. Um you know, you're going to have to decide where you put the uh where you put your applications, how you may split them, et cetera.

So why are people setting about doing this uh modernization that we're talking about? About 50% of them are on data access. You've seen all the announcements this week around generative AI and the need for data, the the need to look at data in different ways. So a lot of people saying look, I've got the crown jewels of my business, sit on the mainframe in a variety of different mainframe, uh data sources. I wanna open up that data, bring it into a new environment, play around with it, do things with it. Some will say no, I just want to leave the data on the mainframe but I wanna access it from an AWS environment, you know, but I gotta do it. There's all of my business data uh is sitting there 48% want improved innovation. What can I do differently in an AWS environment? Um you know, can I do new innovative things on the mainframe itself? How do I bring those two worlds together to address current business needs and future business needs that I might have the last one improve flexibility. I want to decide where I put my applications, how I split my applications across the platforms? Where do I move the data to back to the, the data accessibility point. I want flexibility in what I'm gonna do.

And then those who have already started to modernize, what were they kind of seeing as the result of doing it? On average? Um you know, people were seeing sort of $25 million worth of savings. Uh those that were doing what we call modernize with or move off, we're seeing an 11% improvement in profit and those that were doing a modernize on. So, you know, literally just modernizing their mainframe environment, we're seeing a 9% improvement in profit. But as you can see, the end results are, you know, positive improvement for any company doing any form of modernization.

So what are those kinds of modernization that they're doing? And we've touched on them a little bit uh in the first couple of slides and interestingly, it's about a third, a third, a third split between modernizing on the platform doing integration between mainframe and AWS and also the amount of people who are actually going to move stuff off um is, you know, once again about a third and these are the three patterns that we talk about and I will say the integrate with pattern in the middle can be attached to a modernize on people start to do modernization on the platform, then go oh if I do this. In addition, I can now start to um access applications, access data from an AWS platform. So they'll then drift into the integrate with. And in many instances, a move off starts with a, an integrate with because moving off, um, you know, certainly from what we're seeing with customers, it's a complex thing to do. It's not impossible. Um, as, you know, many people have demonstrated but it is very complex. Um and so people want to see um early results from having started to move down the cloud path. So even those who are doing a move off pattern will start with an integrate with, they'll build some new AWS apps, maybe access existing applications and data. So even a move off pattern for a customer can start with an integrate with.

So in the AWS environment, what are we talking about doing here? We're talking about embracing and adopting the AWS Mainframe Modernization Service or the M2 platform goes under a couple of different short names. So why are they doing this? What are they looking to to gain benefit from as they integrate their mainframe environment with AWS or the AWS Mainframe Modernization Service?

First one is application platform engineering. So this is integrated dev ops between the AWS world and all the AWS tools that you have and the tools that you can also use to do to do integrated dev ops with the mainframe. So they're looking for increased agility, their application developers can start to adopt the same processes, some of the same tools, etcetera. But once again, it's helping to improve agility data integration. And AI, obviously, we've touched on this a couple of minutes ago, they're looking to open up all their different data sources. And for those of you that, you know, are not from a mainframe environment in the audience, we're not just talking about relational data sitting inside db two. For example, you've got data sources that go back 2030 40 years that are still sitting there and doing stuff with a lot of data in that people want to gain access to. And lastly, they're looking to move off, right. They're looking to take some of the applications that no longer makes sense to be in the mainframe environment, maybe um you know, ref factoring them or rela and moving into an AWS mainframe modernization environment.

So these, you know, all of these services you can gain from the AWS M2 platform. So first thing that Kindred is very pleased to announce is that alongside the other key partners in the AWS M2 platform, Kindred has been tapped as the first managed service partner to join the M2 platform. What this actually means is that Kindred brings its considerable depth and breadth of experience in the mainframe environment. We have about 8000 odd engineers with an average age of about 36 or 37. Uh we run somewhere in the order of 6.5 million MIPS under management. So it's a huge enterprise that we have in terms of being able to manage the mainframe environment. And we're marrying that with the skills and capabilities that AWS bring to the table with the AWS M2 platform.

So we're marrying these two together with Kindred as a managed service provider to help customers who are going down this path of being able to modernize on, integrate with move off with AWS in a mainframe environment and between the Kindred skills and the AWS technology and capabilities. We we believe this will be a good partnership for any customer wanting to embark on this journey.

So we're now going to move on to the next section which gets into some more of the technical sides of the announcements that we're going to make. So I'll pass it over to Anthony to carry on.

Thank you. Can you guys hear me? Very good. So uh just to recap, right, there's three use cases from a modernization perspective that we're talking about modernization on mo integrate with and move off, right? So what i will be covering moving forward is the move off case, right?

So as you can see on the slide, it's deceptively simple. This is just a visualization, right? Uh what I would like to make sure that you guys take away is three key main points before you embark on your modernization journey.

Number one, make sure your migration target off of mainframe is at least 1 to 3 years away. 1 to 3 years away. This is not simple, right?

Number two, right is um make sure your mainframe contract renewal is at least 2 to 4 years away. A to make sure that that happens.

And then what we found out is it makes a lot sense. A lot of sense if the spend is more than a million dollars on your mainframe per year, right. If you're spending more than a million dollars, it makes sense to move that off of the mainframe.

So those are the three critical points I wanna mention before I dig into the presentation.

So from a journey perspective, modernization, journey perspective, there's five steps starting off with analyze, right? In the analyze phase, what you have to do is you have to look at the application portfolio of your mainframe. It could be Cobol or PL/1, not just one application but the whole application portfolio. This will enable you to start understanding the prioritization based on pain versus gain. And the way that you come around that pain versus gain is to understand the business value, the agility that it brings and the complexity, the feasibility. Those are the three criteria that you got to evaluate, to understand the pain versus gain.

Once you have that, then you need to understand do the thorough analysis using Blue Insights, Blue Edge Insights uh from AWS, that's a AWS modernization service. We use it also. And uh Eric here will walk us through a little bit of a deep dive on that. But use that to understand the dependencies of the Cobol application. If you look at most of the mainframe applications, they're very tightly coupled, right? They're very tightly coupled between each of the modules, right. So you need to understand those dependencies and also the data dependencies, right? And how the data is, once you have a clear understanding of that, you got to embark on a POC, right?

Um the projects that actually took the whole mainframe modernization in one swath, only 6% of them were successful, right? So you got to start off with a POC, right? In the POC and the POC I. So the reason why we serialize this is to make it simple to look at, but this is a iterative chart, right? You start off with the POC, go through the five steps, then go back to what's the next Cobol or PL/1 application go through these five steps again, that's how you start layering your modernization journey, not taking and increase the probability of success.

So we're back at square one analyze, once you analyze, you have two patterns to transform from a migration perspective, one is the factor, right? And the second is repla so in re factor, that's where you get the most modernization, right? And when you look at modernization starts off with infra modernization, data, modernization, ab moralization, and process modernization, right? The operating system is operating, how you operate it when you move off in a cloud native way changes, right?

So in a re factor, the infra modernization happens when you move from the mainframe hardware to m two hardware, right? Data modernization happens when you move off of db two vs am I ms those hierarchical databases to aurora or amazon r ds, right? Then the application modernization happens when you move out from Cobol to java, right, or.net and uh and also from an operational modernization. What happens is now you can embark on cloud apps, you can manage your app in a very cloud native way using all the innovation that AWS s provide from cloud watch, all the way to the dev se s tools, right? From uh AWS cloud build cloud commit and and the like, right? So that is what the factor.

So from a refactor perspective, you get the most migration uh most modernization, excuse me. The second pattern that I talked about is rela from a rela perspective. What happens is you actually get infrastructure modernization but then you emulate the run time using micro focus, right? And this is where it's almost a lift and shift, there's no recording of the application. So it's mostly uh a lift and shift that happens in refactor.

So to recap two migration patterns, refactor and rela refactor has the most modernization then you start developing, then you start developing, breaking out your um application to macro services. I know this is not native to cloud, there's also a macro service and a microservice. The reason why you want to look at macro services is there's it's speed at which you can do a POC, right? So it's more coarse grain than a microservice, right?

So you got, you got those options and you develop that and then you test it and deploy it and operate it, right? And when you do all this, what happens is now you have access to ac I cd pipeline process dev cops. You can also include that. So you're modernizing the process piece of it.

So to bring all this together, this was simple from a process step perspective, but we had to pull in a lot of tools, platforms, services starting off with deploy and operate. If you look at deploy and operate, we bring in our service called Kindred Cloud Native Services, right? In Kindle Cloud Native Services, we actually have built in three innovations that I'll talk to you about in the coming slides.

Now, the other one is we partnered with AWS and we have this Factory for AWS three factor that actually uses and accelerates all the tooling and innovation that Blue Edge has provided along with the best practices that we provide as part of the 61% mps that we manage in the market, right? And last but not least, we also use AWS data application with Precisely to really accelerate and making making sure that the data is migrated, moved across the environments.

Good. You guys with me so far? Just a show of hands, right? How many of you have mainframes in your organization? Very good. Thank you.

Now, number two question, how many are you guys planning to migrate off of mainframe? Some of them? Ok. Remember this booth 980 go hit booth 980. We love to help you. Ok? And and make sure that uh you, you have successful outcomes. Ok. Moving on.

So the Kendra's technology accelerators that we actually launched as uh that we have as part of our portfolio is a service, the Kendrell Cloud Native Service that comes with foundational services that gives you the consult, implement and manage around landing zone designs, right, as well as infrastructure designs that you are required to make sure that you follow the cloud adoption framework of AWS, right?

The second one which is Kindred Bridge, that is the platform that we provide to give uh give our clients an integrated experience across their it uh uh footprint, it's not just cloud, the the clients that we manage have on prem, they have multi cloud. So Kinder Bridge gives that facility by providing observable across all these footprints from an AIOPS perspective.

We have our AI OPS that have patents and also patents on ML models on how to correlate all the uh how to correlate all the events and monitors to give you actionable insights, right? And last but not least which is new as part of this announcement is the Resource Manager for Kendre, right RM four K that we have integrated with the M two service. When the M two service gets deployed, this gets deployed to keep monitoring the health of the application and the whole stack and it enables the integration into Creal Bridge.

So three accelerators, the service, the platform and the resource manager which is sits on M two, get let's move on. And the four new capabilities that we released is Kindle C native services for uh for AWS mainframe modernization dev se cops with AWS three platform factory for AWS three factor and AWS data application with Precisely right.

What I will do is I will cover KCNS for AWS mainframe modernization service and the other three will be covered by Eric. So I'm really excited to, I actually uh created this service with my team and it is, we bought three innovations as part of this service.

One is from a tooling perspective. If you look at traditional MSPs, they have tools that they use to manage the customers workloads that actually they deploy as part of their managed service. What we have done, we took that out. We do not use any third party tools to manage our customer services. Our customers workloads, we use AWS native services to do that. What that does is number one on boarding time reduces drastically from months to days at one customer, it was an outlier but it was 15 minutes. right.

Number two, right is if you look at from a client perspective, their time to revenue significantly increases. Number three, lot of clients are really conscious about their sustainability goals, right? By taking out that extra third party tools and infrastructure, we have significantly reduced the carbon footprint of managed workloads. right.

Fourth. uh but last but not least cost, we also have uh reduce the cost by at least 20 to 30%. Why? Because clients don't have to pay for the third party tools to monitor and manage their workloads. You guys with me makes sense good.

So and that that is the service that we have introduced. And um that's innovation. number one tools. Innovation number two is delivery model, right? The delivery model, we went from a waterfall it til siloed storage, admin, storage, admin, uh network, admin server, admin type of management style, delivery style to squad based sa based site, reliability engineer based that is backed up and understands the whole stack, not just one silo of the stack.

So and the way that we actually do our management is through dev s principles and deploying infrastructure as code, integrating our deployment practices and delivery practices into the dev ops processes of our customers, right? So that it actually the provisioning time of the infrastructure is seamless because it's integrated into the dev ops pipelines. So that's the second innovation.

The third innovation that we did was in pricing, right? From a pricing perspective, we were, are you based resource unit based? Any, any customer here that has an outsourcer understands what resource unit based is. It's a fixed scope monthly charge. There's ups and downs on it that we charge, right. What we have done there is we have modified that and we made it percentage based pricing based on how much the client consumes of the hyper scalar spend, right?

So you guys don't, we don't have to understand what you're gonna spend up front, you spend, you go up, you go down, we charge by that. Ok?

With that, what I want to do is I want to pass the baton to my colleague here, Eric to walk us through the other three accelerators.

All right, thanks Anthony. Welcome.

All right. So we've got, we sort of got the moving parts laid out a little bit now and now we need to kind of figure out how to bring this all together. And so the factory that we announced and the capabilities that kind of come with it, you know, think about it as, ok, Anthony talked about doing a POC and so forth and then he talked about, ok, the landing zone is going to look like this and he talked about the tools are over here. Ok? Now we need a project that's going to get all of that kind of organized, right? And, and so AWS has a factory notion and we're kind of, we're, we're going to instantiate that we're going to bring that to life and, and bring the skills and experiences that, that, that go with that. The mainframe modernization service

Once you get things to the run time is good, the tools that are in it are good that makes it easy to provision quickly, all of these different kinds of environments. But how do we use them? How do we build those wave plans after we've established what we can do? How do we put the sequencing and dependencies? How do we think about the data?

Okay. There's a number of techniques that you can, you can apply there, maybe leave the data where it is for a while, maybe move some of it. These are complicated things based based on our experiences and, and so we help kind of set up the factory to do those kinds of things, right? And, and so it's, it's really all about instantiating this and then looking at it end to end and holistically during that period from, we've decided we're going to move off and we've decided we're going to use blue age and we're going to generate the java, the poc said that's going to work fine.

Now, how do we, how do we get there? How do we get there from here and, and, and make it happen? Now, one of the other things that will come with this as part of leveraging our experience is y you know, the code artifacts that we can run the tools on and so forth. That's all good. But because we run mainframes all the time, we know that there's, there's some hidden uh value coming out of that mainframe. You, you know, there may be utilities there that are doing all kinds of interesting printing and so forth. And if you go down and look at some of the batch jobs, we can convert the batch jobs. But what about thing, the things they call? Right. And so one of the things that, that i know we've learned over the past couple of years of, of working in this space is it's great to talk about the code artifacts and have a good factory to go with them. But you need to also think about kind of the rest of of, of what's there and that's important in the beginning and it's even more important if you're going to try to move almost everything off, right.

And what we found is this is another great opportunity to leverage the aws platform because they've got solutions to a lot of those things. But you have to kind of know that this old mainframe tool, oh, that actually can be replaced by something over in aws and iy, you know, only experience and you build up that list is, is kind of a part of what we can bring to bear here from a from a factory perspective. So that's part of what is shown here as we look at, as we look at the, as, as we look at the rest of the, the value that we bring. It's really about that expertise. It's really about enabling and, and getting the kcns set up. And then the other part that we will bring in is again that broader kindred perspective where, you know, it's great. We've got the kcns part that'll take care of the java that we've converted. But wait a minute, you know, there's actually a mobile app also running over here in aws. So we need to stitch that together from a uh observable perspective. We'll use those aws tools, but we not need to think about how that all correlates and how we look at that.

And so a thing i always tell customers is that from a kindle perspective, we're always worried about day 234 and beyond. And so we bring up a lot of these questions. Uh and we help out on those kinds of things right up front as, as we're, as we're executing the transformation. So that's, that's kind of the factory notion. It's the end to end idea uh that we have, ah, as part of this announcement.

Now, re the desk ops part, ah, you know, again, there's capabilities within the mainframe modernization service that, that, ah, we can, we can take advantage of. But this one, this one's i guess this one's kind of complicated in terms of the fact that it supports multiple scenarios, right? And so the first scenario is is really that of leveraging aws as a platform to do c i cd and to do things even if you're still targeting the mainframe. And so this leverages ah the ah open text slash micro focus, et cetera, et cetera ah capabilities that are in the mainframe modernization service. This will help you look at your cobal and and other mainframe code and, and, and ask yourself, am i, am i really getting the speed and the agility in its current form? Maybe I should start with some modernization there and, and we might bucket that under our modernized on kind of capabilities. But uh there's there's there's a lot of value to be gotten there. You can improve the velocity and you can improve the uh i mean, i can click through here and start to show some of those benefits. Ah one of which is also kind of the cost, right? You can you can keep the mainframe mp s utilization down by doing some of those tests in a mainframe modernization service run time that's running on aws. But then finally when you go into production, you'll drive it through and, and have it running in the cobalt run time, for example, uh that you're running it in today.

So that all sounds a little bit complicated. And so some of the accelerators and the expertise that we bring to bear as part of this capability are, are really going to jump start you in doing that. Now, how does that relate back to full move off modernization? Well, we find often that there are, are things that you need to think about in your applications that you could take care of right now. Right? You know, it's a anthony talked about, sometimes you go back to analyze and you actually fix the cobalt before you convert it to java, right? And so this is not, it's not a uh you know, sequential process like he said, right? I mean, if you ah use the ah blue age tools and you go through and you realize, wow, if i just fix this cobalt here, that would clean up this thing coming out the other end. And so by getting to a modern dev ops model by using the aws capabilities around ah ah development tools and using things like git to put the source in. You're, you're moving to a place where your developers are going to be more ready, but you're also going to be getting those code assets uh more ready for what ultimately is the modernization.

So underneath of this, there's a bunch more details we don't have time to talk about with sample pipelines and how this all fits together. And so our teams have have been working with this, we've been working with aws since, since kind of the, the beginning of the, of the mainframe modernization service. And so we're kind of ready to, ah, you know, ready to go at it, ah, on, on real projects with you, ah, in this particular area.

Now, the other thing here is that we can also plug some of this into our bridge and so that you can kind of get that visibility over what's going on, right? Because if you, again, if you think back to the factory, you might have multiple of these things going on and you're gonna want to have kind of visibility into the dev ops activity that's going on. And so we use this bridge as an aggregation mechanism for you and for us again, depending on where we're helping you ah in this journey to to see what's going on. Ok?

So that is the quick view over what we're doing with the relat. But the important thing is there's kind of two sub scenarios, right? The first of which targets the mainframe, but in a much more modern way, the second of which then really supports uh when you do use the blue age ah ah path, ok? And the micro focus uh part of it as as well. And when you talk about mainframe modernization service, there are those two capabilities.

All right. So the other use case that was mentioned earlier deals with data replication. And here again, this is this is one of these, this is one of these tools that has uh multiple i sub cases that you can support. And so first and foremost, you will need as part of running the factory, you will need to figure out, you know, are you gonna ah are you going to move the data? Are you going to copy the data, ah what's going to happen there? And, and so you can kind of get some value from this particular capability ah in in that case, but perhaps the more interesting cases are i'm leaving this data on the mainframe for a long, long time. But you know, it's been a little bit problematic to get at the data that i want for the new capabilities that i'm i'm trying to do out on aws.

And so you're sitting here with a powerful aws w environment and you're sitting over there with some really good data. Now, how do we quickly get this, get this going? And, and so i think about this in terms of two kinds of use cases, one which is more of a bulk move that is going to establish a place where you can start doing analytics and a i and so forth. And you know, we need to say a i a couple of times but y you know a i starts with good data, right? And this technology combined with our ah skills around how to leverage it are are going to accelerate that for you. It's kind of it, it's not the glitzy part of a i but, but you, you know, if you don't have good data, we all know that, ah is, is going to uh make your results not so valuable.

The second case, which gets much more into, ah what i would call, yy, you know, traditional applications that are, that are doing, you know, getting information, you know, a few rows at a time or a few objects at a time. That's also an important use case that we support here, right? Because you can set up this pipeline using the precisely capabilities that are part of mainframe modernization service and and get, you know, quote, quote near real time. Now, some of you will want to argue with me about what does that mean? Is it, are we talking milliseconds or are we talking a few seconds and so forth? But what we find is that everybody needs some of that, right? And actually if you look at things architecturally, i i find that without leveraging these kinds of capabilities, you get all kinds of interesting architecture anomalies, right?

I mean, i look at applications all the time that have mobile front ends, they have middle tiers and then you know, the real data is back there on the mainframe. And if you don't have something like this, there'll be some bright developers that start putting caches way out near the mobile app and then the security guy or gal figures out that that's happening and you end up spending a lot more money to kind of moderate all of that by having a capability like this, you get yourself architecturally cleaner and you know, there's a lot of architect in me and, and i like what we can do with this from that perspective. But the thing i would tell you about this and where, where the kinder value is going to come in is there gets to be a pipeline that makes this happen, right? And somebody's got to watch that somebody's got to care and feed for that as you go forward over time because you're going to be in this situation for possibly many years based on some of the survey data that richard talked about earlier.

So this isn't kind of the straw house, you need to build this uh y you know, in a much more solid and sustainable long term kind of way. And, and so we think that ah with, with our skills and accelerators and these capabilities, we've got a pretty good, we've got a pretty good match here, right? Ah now, the whole notion of moving or, or copying this data off also comes with some other side effects which can be, you know, reducing the mps that you're that you're ah ah consuming because if you have less people coming in and doing those read transactions, for example, that's going to reduce the mps.

The other part about these kinds of technologies and this one in particular is it kind of takes you from what we would have classically talked about over the years as a, from an etl to more of an elt where you're doing the transformation of some of those data sources on the cloud where we've got tools to do that and so forth. And so for those of you that are counting mps, right? Ah, that's another possible savings point, uh, a along the way.

So with all of these, there are kind of the agility, speed and velocity uh kind of benefits, but then there's also kind of the financial ah realities of this. And and again, some of you might be as focused on those as you are on the uh o on the technical elements. So i, so i kind of bring that up as kind of a final ah a final thought here.

So with that, I think we hand it back to richard or back to anthony. All right. Yeah. So let's uh i know we've, we've covered a lot of things, right, in terms of accelerators, in terms of new capabilities, right? So what i'd like to do, i'd like to bring all of this back together from a client journey perspective, right?

So the first thing that they've got to do from a client perspective is to provision the environment to provision the m two environment so that you have a platform. So that's the number one provisioning of aws resources then on top of that, once you do that, you got to build and deploy those applications, then you have to operate those applications, you have to monitor and then you have to have the right insights that have the right correlation to actually optimize the performance of the application and the cost metrics of the application.