Episode #2: Solving application modernization challenges with the mainframe

Rob Anderson 0:00

Good morning, afternoon or evening, everybody and thanks for joining us for today's discussions. I have John Curry and Rebecca Huber with IBM consulting here with me today. Thank you, guys, both for being here. Jon's IBM Partner and Worldwide Practice Leader for mainframe application modernization. And Rebecca is CTO of application modernization for IBM Consulting. Rebecca, besides being a fellow Clemson alum, can you expand a little bit about your background and role at IBM consulting?

Rebecca 0:31

Yes, right now I have the role of CTO for application modernization as you just said, that basically means that I helped clients, modernise their applications be there on the mainframe be that also on the cloud that I've done as well. I've done a lot of cloud migrations over the years. But when I first started at IBM, I started off as a mainframe developer and I worked for many years for clients here in Europe as a mainframe developer. And then I moved on to other cloud type things. So that's, that's what I do at IBM for the German speaking part of Europe.

Rob

Cool. Thanks, John, tell us about yourself.

John 1:13

I've been at IBM for 20 plus years, a lot of different experiences. Most recently, I was in the IBM technology group with a focus on IBM Z or mainframe was in that role for about four years. Prior to that, I was in the IBM Cloud organisation for about five years to have a lot of both, you know, distributed and in cloud experience, as well as IBM Z experience. And I moved over into the consulting group about a year ago, with, you know, focus on mainframe application modernization, which I feel like is a good combination bringing together you know, kind of that hybrid cloud strategy, of cloud with Z and merging the technology. So yeah, it's been a wonderful experience so far, and have the opportunity to work with partners like you guys.

Rob 2:00

Well, thank you both, again, for being here. It really is an honour. It's great to have your experience and insight. I'd like to start the conversation today with a little bit of context around how advanced and IBM consulting work together. Our partnership spans quite a few years, and quite a few project successes as well. I think that this fact sometimes surprises folks, since advanced application modernization division focuses a lot of our energy on Z OS and the mainframe, but the reality is that modernization looks different for each client. I think we're going to talk a lot about that today. And with our technology, focus revolving around Natural Adabas, CA Gen, IDMS and COBOL, we tend to act as a module of larger transformation initiatives being led by IBM Consulting. John, can you help paint a picture of how our partnership works from your perspective?

John 2:56

Sure, I think, you know, when, when IBM and IBM Consulting looks at their partner ecosystem, both in identifying leveraging, and then, you know, embarking on projects together, there's a lot of factors involved in that. And I think one thing that we've tried to do over recent quarters is really refine that list, you know, focus with each partner with their core competency, and really, you know, drive the opportunity base, and, you know, and then obviously, work through, you know, the actual engagements, you know, with the partners that have the greatest skill, and, you know, reputation reliability, and obviously, the track record you mentioned, so I think from, from our perspective, you know, we've really looked at that looked at it from that lens, and also, when you look at it globally, right, there's a lot of nuance region to region globally. So, then it's, you know, which partners play in which regions and in how do we leverage them and, you know, in each of those regions, because we have different needs in each region. So, from an Advanced IBM perspective, I think, you know, that long track record, you know, the experience of the trust, you know, and then being able to leverage our experiences together both as, as references, as well, as you know, just what went well, what didn't go well. And then also, again, looking forward to that refinement. And when you're speaking about, you know, Z and mainframe specifically, you know, one of the key challenges is skills, right, and the, you know, in being able to transform the platform, so that, you know, ageing skills, you know, are skills that are harder to find are less dependent, you know, we're putting less dependency on those going forward. So that's another element to it as well.

Rob 4:40

And, I mean, we really do have a long track record. We've done IDMS migrations for the US Postal Service transformation for some of the largest financial institutions in the world.

And it's been over quite a period of time. It's interesting, you know, you get to know teams get to know one another over the years on the battlefield so to speak. And throughout that history, we've seen our clients behaviour and preferences change quite a bit from Y2K to a rise in cloud adoption around the onset of the pandemic, it does seem, at least from the broader perspective as the dust from that great COVID migration has settled a little bit, which appears to have had an influence on how companies view their modernization strategies. John, can you talk a little bit about some of the trends that you're seeing and IBM consulting in this regard?

John 5:38

Sure, so to kind of comment on what you said about the pandemic, right, I think, you know, during that time, people, you know, have very limited access to a lot of things, and, you know, through that was born a lot of online capability, maybe even FastPath, to the point of, you know, some shortcuts, and not to say that there's anything wrong with that, right, at the end of the day, you do what you need to do in those kind of desperate times, but, you know, maybe at the at the expense of, of excessive risk, or compliance or other things. And I think, you know, kind of circling back to some of those decisions in some of those implementations to figure out, you know, what was appropriate, and what wasn't, is important. And I think, you know, a lot of institutions are doing that. But, you know, kind of moving forward from that, you know, there's the traditional challenges that, you know, I think a lot of clients are facing with respect to, you know, cost pressures. You know, and I think from that, also, a lot of clients are at a crossroads, because of the fact that low hanging fruit, you know, the lift and shift type things, you know, it's kind of been done. So now it's like, okay, the easy work was done that now, where are we and where do we want to go. And I think, when you're at that crossroads, it's harder to kind of see a path forward, because now you're needing an overall strategy, and you're needing a programme to implement over multiple years. Another challenge that comes into that I mentioned cost pressure already, but then, you know, who has the stomach, or who has the budget to do those long term and embark on those long-term projects. So it's, it's figuring out how to set a strategy, but, and also break it up into manageable parts that can show return on investment that can justify the spend, you know, and that, you know, are steps that lead you to an ultimate result, as opposed to, you know, maybe bifurcated and then cause you to have different challenges, because now you're not, you're not moving everything forward in one. logical path.

Rob 7:37

And it is interesting how that sort of increase in difficulty as time goes on really is an absolute. Rebecca, how are you seeing things across the pond?

Rebecca

Um, well, at the beginning, I think that a lot of people thought it was that maybe easier to move things off the mainframe than they thought was going, that's actually turned out to be. So, we're beginning to see actually, we're beginning to revaluate the value of the mainframe for me, and how can I leverage investments that I've made in in software, because that's what it's been. It's not just legacy software, it's software that somebody has developed software that's performed for years and years out doing a lot of the most significant transactions worldwide. And so, it's not something that you can easily simply move pieces of somewhere else. It has to be a very well-considered thing. So therefore, we're seeing things where maybe even if you do want to move off coming from, you're still going to want to have a period of time where you still would need to access things on the mainframe, or maybe you realise it should maybe pieces should stay on the mainframe. So, we're seeing more things around API enablement, accessing the data on the mainframe, maybe consolidating things, harmonising things on the mainframe optimising what you've got. And the other thing is maybe skilling up, it's creating, like a kind of academy, if you will, on the mainframe, we see a lot of younger people that mean, it's not that you have to be old in order to learn these technologies. You just have to have the appetite for it. And we're beginning to see young people who are actually doing that.

Rob 9:24

As you mentioned, it really isn't a clear-cut thing. And I think there were a lot of a lot of lessons learned in the in the difficult process. That was, it does seem as though there is a bit of a clear understanding of the delineation between what Cloud appropriate and mainframe optimised workloads look like. And it seems as though that's continuing to emerge and mature. John, are you are you seeing this on your side, and can you expand a little bit about it?

John: 10:00

Yeah, sure. So, it's funny, because I think that one challenge that a lot of us face, either as an owner within an enterprise or as a consultant is, there really isn't any absolutes. Right? There's no exact right answer. And there's no exact wrong answer. I think. Ultimately, there's different paths to move forward. And, depending on what your ultimate objectives are, you know, that that path will ultimately find itself that said, you know, you mentioned certain things that are appropriate on the mainframe, obviously, current core transactions and maintaining of core data, you know, it's something that the mainframe does very well, and, you know, when you look at financial institutions, and in other, you know, huge systems of record, you know, that's an environment that, you know, the mainframe is built for, and continues to drive forward. And so, you know, that's an environment that I don't think we'll ever move off the mainframe, but again, you know, depending on the client and their ultimate motivation, you know, they can they can choose to do what they want, I think, again, kind of using that, that, you know, that financial institution example, you know, you know, traditional bank, right, you have your kind of digital front end, and right, where you do your mobile banking, you know, partner payments, online banking, things like that, you know, that front end stuff, obviously, is where you're meeting your customers. And that's really the, you know, that that cloud elements, and then you kind of have the middle stuff, right, the operational processing, you know, services, order fulfilment, things like that. And that's where I think you can probably look at that as your best area to optimise, you know, what, what would make sense to stay on the mainframe? Or what makes sense to stay close to the data in that core transaction from a latency standpoint, and then what makes sense to maybe move off either from an efficiency from a MIPS reduction from, you know, you know, an optimization standpoint, and I think that, you know, that's kind of that breakdown that I talked about, in terms of looking at a programme that, you know, breaking it into pieces, and then figuring out what's right for each of the pieces.

Rob: 12:08

So, Rebecca, what are your thoughts on this?

Rebecca: 12:16

I'm just adding on to what John has said, yes, we want clients to be able to have a choice. You know, where to run whatever, the workload is where it's most appropriate based on all the factors that you mentioned before. But even if the decision is yes, I want to get off the mainframe. Or if maybe one recognises the value of the mainframe for the workload you've got, you're going to need a hybrid solution. So, we tend to refer to it as hybrid cloud. Because even in the interim, you're still going to take some time to do a lot of these transformations where you have the way you're maybe digitally moving to, or if you're extending things on the hybrid cloud, you're still going to need this mixture of both worlds. And, you know, what we're seeing is people are recognising this set is not an old platform, it's got a lot to offer in the way of integration. And so, you can run a lot of the workload on the set or even integrate with it. And that provides a good option so that you've got a path forward. And it's a way of doing it gradually.

Rob: 13:14

And it's a great point that you raise, you know, we both work with, with the hyperscalers pretty regularly and cloud and hybrid environments. In fact, we work together to migrate some of Suncor energy's workloads to Azure A while back, given your unique role in the space. John, can you talk a little bit about how you approach design and consumption planning and circumstances where migration of workloads to the cloud is involved?

John: 13:44

Yeah, sure, in First off, before we get to the design and consumption planning, I think, you know, just really grounding client in their motivation. Right. And I think that's important. And that's for any workload in in for whatever, you know, optimization or modernization effort you're looking to embark in, you know, what do they ultimately looking to get out of it? Right? Is it a cost reduction? Is it a miss reduction? Is it a, you know, better integration with other platforms is, you know, driving more value out of the platform from the standpoint of integrating AI or some sort of data analytics. So, from that standpoint, it because ultimately, if you don't satisfy the business need, you're not going to hit the mark with whatever, you know, effort to you choose to take. So, from that standpoint, I think, really, it's leveraging, you know, our tool base and our knowledge to really understand the interdependencies of the application to understand, you know, its mode of operation and its current state. But then there's still probably, you know, some hurdles as you look to migrate, right, because are you going to need to run an emulator, are you going to need to do other things to ultimately optimise that that workload But when it hits, it's, it's, you know, its final state. And so, I think, you know, there's a lot that goes into that. And, you know, those are the key things that, you know, leveraging our skill set our experience, you know, similar projects, you know, help us to define and, and give us the tooling and the, you know, kind of baselines to establish those kinds of results. Yeah.

Rob: 15:23

Definitely.

And, and, you know, it's interesting because especially as the sort of the nuance of the design of the target has evolved in in recent years and months, a lot of folks who are considering modernization initiatives look to alliances like ours, to elucidate best practices that will reduce the risk and potential pain of their journey. We know from the survey that inspired our modernization report that modernization expertise and risk reduction are positively correlated, at least in the survey respondents that we spoke to, in other words, the likelihood of failure rises substantially with project teams who are new to modernization, regardless of the target. And so thus, from, from our perspective, a key best practice to ensure that there's appropriate modernization expertise involved at every stage of a project, especially in the planning and assessment phases. Rebecca, can you talk about a best practice or two that emerged from your perspective?

Rebecca

Well, I think the one thing is yes, you need this, this sort of special unicorn type person, probably that knows everything, but there's people don't normally exist, there's very few. So therefore, you need a team of experts. In my opinion, you need the people who understand the old world enough that they can even tease out some of the more subtle things that may be occurring in the source code or in the particular technology that you're trying to migrate from. Or to modernise. Or to optimise, there's, there's many different flavours that you might choose to modernise something. So, you need those people on the team. But more importantly, you need somebody else who understands that target. What is it that I what would be an appropriate target? Can I really reach the objectives that the client is trying to reach? Because there's a lot of people that will tell you, oh, it's going to be much better, because I'm going to move to cloud. But if you really dive deeper, they haven't really done all of the, let’s say, the considerations that you need to regarding cost regarding what sort of risks there might be from moving the workload apart, or even re implementing it, you might not even have the ability to truly test it with a reasonable amount of effort. So, all of these things need to be considered, it needs to be considered by people that understand even the in between world, what we call the coexistence architecture is also a very important thing. Because typically, these projects do not get done overnight. So, you have a period of time where you need the target up and running. And some, some of the pieces are maybe already on the target, but you still need to be able to get back into the old world. And it might remain that way, forever, that you have this sort of hybrid world. So, you need people who understand target, and you also enough of the old world, and you have some experts from the old world. So, I think that's, that's why you really want to have the people who have done it before.

Rob: 18:36

Couldn't agree with you more. And I think, especially from a project management and executive perspective, it can be surprising for folks to experience the difference in planning and execution that come alongside both the domain that you're working in, as well as the target, like you mentioned before. And, you know, I know we sound a bit like a broken record, but you know, domain expertise and tooling capability is also incredibly relevant from a best practices arena, based on exactly what you're looking at. So, it isn't just the expertise, but the tools that they have, at their, at their behest, you know, we always we always liken it to piloting a fighter jet. You know, you can, anybody can get a fighter jet with enough money, but it takes a skilled pilot to really fly it to its capability. And the same thing goes with a lot of this tooling. And I think those are related. You know, for example, if you're moving, you know, IDMs to dB two on mainframe, like we did together with the USPS, you'd want to be sure as a client that you're working with trusted advisors who know their way around the technology, as well as the tooling that have a track record to back it up as an as a partner as well as a customer because as you mentioned before, these are not short endeavours, they're not painless endeavours, it takes a great deal of teamwork concentration and expertise to get it done the right way. And it does very much depend on the target.

Rob: 20:16

With respect to some of the technology specific stuff. Rebecca, can you comment a little bit on your thoughts there? Do you think I'm in the right arena with that opinion?

Rebecca: 20:23

Well, yes, I think technology is important. But it's not the only thing. One of the things that I think that we personally bring, personally, I've been brings to the table as consulting. We have industry expertise, because I think you're moving into the day applications, which may probably be core applications, because as John already mentioned, a lot of the low hanging fruits already been done. So now you're talking about looking and taking apart potentially core business applications. So, you really need to understand what that means for that particular business. What does that mean for a bank? So, you need to have people who understand the banking processes, maybe even consider, like, things like, is it appropriate, maybe they move it to package. And for that, you really need to have the people who understand the banking. But again, it's part of the little mosaic that you have of the team, you really need to have the people who also understand the technology, and you need to have that all together as one team. And the most important thing is also understanding what is it that the client is actually trying to achieve, because if you're not careful, and you're too much fascinated by technology, you might just miss the mark on what it is that the client actually had as an objective.

Rob: 21:48

Yeah, that's a great point. And I think in your position as IBM consulting, when you're sort of piecing together, what that what that roadmap looks like. And you're thinking of partners like advanced, sometimes there's a clear advantage to partnering with one shop over another. So you know, if the product of the pattern that you're looking to follow is substantially higher quality from one vendor versus another, where the team is, is substantially more experienced, or some combination thereof, the decision is easy for that module of the journey, if you will, but of course, it's not always that clear cut. Rarely is it that clear cut, because that's just not how life works. And, you know, from our perspective, and, you know, we agree on this throughout our time together as partners, it's a good idea to start with a pilot or POC for this very reason. Not all scopes of work are even in the same neighbourhood of code coverage. And not all solutions produce equivalent results within the context that they're placed. You know, for example, we spend a great deal of, of our focus from a technology perspective in in our sort of superpower areas, if you will. So companies who work with us to move away from CA Gen are often surprised to find out that the way we handle the modernization process, on the technology level by refactoring the Encyclopaedia rather than the generated COBOL makes a massive difference in everything that comes after that from post modernization support and maintenance, to the broader project, within the scope of, of something that I've been consulting may be helping with. And, of course, one of our, one of the advantages of our relationship with you and the advantages of engaging with IBM consulting as a partner, is the holistic view with which you guys can bring to the solutioning approach. And with that, John, can you describe a little bit about your strategic approach from the IBM consulting perspective, when it comes to vendor selection for those modules for that journey? And what a customer might expect that to look like?

John: 24:05

Well, I think it all starts with skills, right? First and foremost, you know, when we're embarking on an opportunity with a client, right, and try and understand what they're looking to accomplish their skills that are going to align to whatever that that project entails. So that's first and foremost, I think, from their track record experience, you know, even just like with anything, right, when you put a team together, you know, how those individuals work together to be more than individuals into to drive to you know, that teaming effect and I think experience is a lot is a big part of that. And then also being able to call on you know, other projects or you know, or other team members, right depth of skill, not only in the people that are on the project, but you know, others that you can call on and, you know, be able to leverage and then then finally, you know anybody. They can do a project that that goes smoothly, it's the projects that hit, you know, bumps in the road, and most of them do. And then it's, it's how you handle those challenges, right? who steps up to the plate? Who's willing to stand by their work? Who's willing to, you know, to answer the hard questions, and, you know, in either, you know, to face the client, when things go, you know, go awry. And not to say that they will all the time, but I think, you know, that really is what, not every project that fails, fails, you know, for anybody's reason, any anybody's fault, right? Sometimes they just were projects that were challenging, and then it's figuring out how to move forward and then ultimately deliver to the customer. And I think, you know, those are the types of partners we want to work with him. And in, quite frankly, we've tried to really refine our partner model, you know, like I've mentioned earlier, in that vein, right, we want to work with the best, and we want to have, you know, we want to see repeated success with the best.

Rob

Definitely. And I think that it's funny, you're exactly right. And it is interesting, how when clients are sort of assessing, you know, what does it mean to modernise? What do we want to do? What is our what are our goals? Have we, as we've kind of discussed, the de risking conversation is a huge part of it. Like what are we facing potential good versus potential bad? And where's the risk in that process? And we often get asked, as I'm sure you do, you know, what piece what one piece of advice would you offer to a first time modernization prospect a team that's doing this for the first time, whether it's, you know, with us together with IBM consulting with advanced or even by themselves? Rebecca, you first what would your one piece of advice B,

Rebecca: 26:51

I think you do need to have careful consideration of what it is that you actually want to change what's what is the objective you're trying to reach. And I think you need to start off small, I think a lot of people think it's going to be a very trivial thing, to move things off. And I think you need to test those things and have a constant, let's just say backlog to steal things from agile type practices, where you're constantly going and looking for the next opportunity, and you've taken in chunks, and you've got a good way forward.

Rob: 27:30

Great advice. And teamwork really does make the dream work as they say, when you have when you have good communication, and a team is working well together. Through that process. It really enhances the experience to John, same question, what one piece of advice would you give to someone staring down the barrel of modernization for the first time?

John: 27:53

I think in this this, this answer is goes beyond monetization goes to life. But you know, there's really no right answer, right? There's no black and white. And I think we live in a world with where everybody has an opinion. Everybody has a perspective. And I think looking at whatever challenge that you're being faced with, and in this case, in monetization, and you know, in the scope of that, you know, break it into manageable pieces, and then, you know, figure out what meets your objective the best, right, and sometimes that's not 100%. So I think not having a perspective of it has to be this where it has to be this way, but really kind of being open to the possibility and really moving forward based on you know, what your goals are, you know, what your options are, and then what gets you the best result. And again, we talked about, you know, risk aversion, we talked about cost, we talked about skill, timing, you know, we didn't talk a lot about that, but in terms of, you know, what is your timeframe? And what are the patients of the business to kind of stay at standing there, you know, while you're trying to accomplish some of these things. So, I think, you know, just be open to the possibility and, and don't have a preconceived notion that it's going to be this or it's going to be that.

Rob: 29:05

It's great advice. It really is, as you said, in life as, as in modernization, all things, all things that appear black and white do end up becoming grey, and it's really important to retain that perspective. You know, I, I know we are coming to the end of our time today. And, and I don't want to keep everybody for longer than we have to, especially the two of you, who, you know, I do want to say again, thank you so much for joining us and for your insights, your experience and knowledge and the holistic view of the modernisation experience that the two of you bring is something that's incredibly valuable and unique. So, thank you.

And of course, thanks for everyone who joined us today for sticking around and hearing this out. Hopefully, you consider this time.

I'm well spent as well. If you'd like to learn more about application modernization at Advanced visit modern systems dot one advanced.com. And if you'd like to learn more about IBM consulting, check out ibm.com/consulting. Thanks again. Thank the two of you again, and until next time. Thank you.

Share Episode

Shownotes

Transcripts

Follow

Links

Chapters

Video

More from YouTube