Tariq Surty

Uh, good morning. Can you hear me? Okay? Great. Thank you very much for making the time to come along. And especially, I think this is the hardcore people in the room today, right?

Well, I was thinking about this actually the first thing this morning, and I was thinking, actually, I probably did a marketing mistake by putting the word "mainframe" in a title of a talk. And I was thinking that actually, you know what? As soon as people see that word, they'll run for the hills, right?

But also — there were a group of people, like probably yourselves, when you see a fire, when everyone is running away from the fire, you're probably the people who are actually running towards the fire. So in some ways, we're kindred spirits here together.

I'm Tariq Surty. I'm the IT Director of the Retail Retirement business at an organization, a company in the UK called Legal & General. I'm here with a couple of my team — Jennifer Pickard, who's the Head of Engineering, and Bharghava Bhogireddy, who's in the architecture team. And we're here to tell you a little bit about what we did, this project called iMpala.

I'm going to set a little bit of context about the background to L&G — Legal & General — I'm sure no one knows about that company over here. So I'm giving you a little bit of background about that, and also the context and the case for change, right? What drove this initiative that we are calling iMpala, that Gene was kind of so inspired by and wanted us to share with you today?

So you probably know — Legal & General not known in the US yet, but in the UK a very, very big name. And we were fortunate enough to be in the UK the most admired company for two years in a row. A feat — I'm told that actually it's only been repeated once before. So quite a big achievement. And the 10,000 employees that we have are aligned to three core areas of business. Our protection business, which is life protection; pensions business; and retirements business. And the flows of assets from these businesses come into our investment management arm. And that investment management arm has about 1.3 trillion now of assets — UK pounds worth of assets — to manage, and they manage it in a particular way and they manage it with a particular purpose.

That purpose is underpinned by what we call at Legal & General "inclusive capitalism." What that means really for L&G is that when we invest these assets, we're not only just looking for shareholder returns, but we're also looking for how we can make those assets work for the communities in the UK, but also how can we use those assets, invest those assets in such a way that also benefits the sustainability agenda that we have to protect the earth that we live in. And that drives our core purpose.

So, like I mentioned earlier on, the three of us are working in the pensions business. And this is an area that has gone through a huge amount of change in the UK over the last few years, largely driven by regulation. The biggest one of those was in 2012, where the UK government announced a regulation that meant that all employers had to offer a pension scheme to the employees, and employees would be automatically enrolled into that pension scheme — and had to opt out if they didn't want to be part of the pension scheme.

This was a game-changer for all pension providers in the UK, because what it meant was a significant amount of growth in number of members for each pension provider. And so we were impacted by that as well. In 2012, we had about 250,000 members in the pension schemes that we are managing on behalf of our clients, and today we're about 5.5 million. And given what's happening in this sector over the next few years, we expect that to grow.

So from a business perspective and a technology perspective, the question really was for us: how do you deal with this growth? How do you deal with this growth and ensure that we can maintain the customer experience they want, enhance the customer experience the way that we want, but also do that in a cost-effective and efficient way?

So a few years ago — a couple of years ago — we developed a strategy that focused on accelerating some of the work that was going on to be able to accelerate digital transformation within the organization, especially the pensions business, and drive much more straight-through processing, remove technical debt — and at the same time change the way that we operate. So we're doing agile at scale. So basically, in summary, we wanted our cake and eat it.

The core thing about this is that all of that change was underpinned or impacted our core pension administration platform. And guess what our core pension administration platform is running on? On the mainframe.

So we looked at this from a technology perspective and said to the business, well, how do we achieve this? We looked at the options with the business and said, look, do we want to actually move off the mainframe? And we looked at the options of moving off the mainframe. But then we actually looked a little bit more differently at the challenge that we had. And I suppose given the theory of constraints — you are only as fast as your slowest link within the chain — we focused on saying, actually, what is it about the mainframe that we want to go and change? So we flipped things around. So people were talking about mainframe modernization, mainframe modernization. We said, actually, let's flip it around and look at it slightly differently — why not modernize the mainframe?

Why not modernize the mainframe? Especially given the fact that within the wider — why not look at it from a perspective of joining the IT revolution, and bringing in all of those great practices that DevSecOps, modern software development lifecycle tools and processes can offer, to be able to drive not only the quantity of change that we're able to deliver, but also the quality and the speed and the quickness of that change too?

So this became our focus. We initiated a program of work called iMpala — and you might be asking yourself why iMpala. There's a funny story here, but I'm not sure if you people are familiar with the Chevrolet Impala. Many of you probably never have, probably. So some of you in the room probably too young to remember or have interacted with the mainframe, and likewise, probably haven't interacted or been familiar with the Chevrolet Impala. But either way, both of which were a great piece of technology, a piece of engineering. So we looked at this and thought: it's heritage technology, which inherently is good, has great capabilities — how can we use that, and combine it with the things that we really wanted, which was agility, nimbleness, and speed? And we thought, therefore, iMpala was a fitting name.

Like I mentioned earlier on, Jennifer, our Head of Engineering, is here, and we'll talk through our approach into being able to deliver towards our vision of a new mainframe — reimagined mainframe software development lifecycle.

Jennifer Pickard

Thank you, Tariq. So we decided very early on, we thought it'd be really important that we focused really on the people part of the change — to really focus on that empathy-based design thinking, and really make sure we understood and took the time to fully understand those issues, and not just assume that we understood what those problems were.

So we went through and we ran a number of empathy-based design sessions. We did that with multiple different people — not just through traditional developers, testers, but all of the different teams that interacted with the mainframe — and really took that time to understand: what are their pain points, what are the metrics they're looking for, what is the frequency of change? And really that understanding of the ways of working that they have today.

So there were many thousands of post-it notes — rooms filled with post-its that people had put forward in terms of the hand-offs and the dependencies and their pain points. And they actually found that very cathartic. They found that really useful — that even within those groups, taking them away from their day-to-day, they were already starting to think about where they could see bottlenecks and issues. But where they were a little bit less sure is just the tooling — what's out there, what's available.

So the main lessons we learned from that was just the lack of tooling. They weren't using any kind of IDE; they were still on the green screens. And the time and effort it took to create not just data, but to find the right data, get it to the right point in the processes that it was usable — and then start again — all the efforts that took, as well as contentions generally with the physical mainframes. With the physical mainframe, when you are doing your production workloads, like peak times during that monthly processing, it will actually take CPU usage away from the developer environment. And it was practically useless for two days or so in the month.

And really we realized we wouldn't be able to do a big-bang rollout — that just wouldn't be possible. Too big a change, too many issues. And we really needed the time to settle in and work those through. And that we really wanted to focus on that next generation — so who was going to be the next generation of mainframe developer? How do we lower those barriers to entry and make it seem, you know, as any other existing sort of developer experience? And really understand those influences and detractors — who do we need to involve to make sure they're successful, and really include those within the delivery?

So the big questions we asked were: how do we get the CI/CD onto the mainframe? How do we look at the tooling, the data, the automation? How do we make it a cloud-based mainframe development? So to remove that restriction on the physical environments, how do we move to the cloud? And how do we adopt our ways of working? And make sure that once that is implemented, teams remain curious — how do they keep looking at those processes and keep being engaged into how to make those better each time, and really engage that next generation?

So we took two key things initially with the structure of the team. One was to bring in a graduate engineer so we could prove out our theory of: they have no mainframe experience — can they come in, start using the tools, get going, what's their feedback? The other was to bring in an external developer, many years of experience, fresh pair of eyes, wasn't ingrained in the current processes. And we could also use them to really work through the tooling and kind of give us initial first stab as to: were these tools workable before we then engaged with an initial early-adopter group? But that early-adopter group was also key in terms of providing both the feedback, but also that community message going out to the rest of the engineering teams in terms of what was being done on the mainframe.

We also had some fun games and prizes. So when we were engaging with those early adopters, making sure that whoever found the first defect won a prize. Sounds silly, but it was trying to encourage feedback. We wanted to hear what was good, but equally what was bad. And we'd try and resolve those as quickly as we could to get that momentum going, and do the normal kind of show-and-tells and engagements and senior leader engagement — all the things I'm sure of you do with your change programs.

So in terms of this exercise, we actually did this as a bit of — just playing around with Copilot, really. We put into Copilot, what does a modern mainframe developer look like? And this was the feedback. And actually we took this and used it as a persona to really bring in that personality around — they're called Leslie. We called them Leslie — to say, keep us kind of focused: where we meeting these goals? This is what we think a future developer should look like. It took away the term developer / tester — we just talked about, would Leslie be using this system? Would it be workable for them?

And so without further ado, I'll talk to — and Bharghava will talk through the solutions.

Bharghava Bhogireddy

Thank you, Jen. It all started when Tariq came to me on a cold afternoon in London. It's always cold in London, by the way. And the topic was, can we do CI/CD on the mainframe? I said, why not? Let's do this.

So we started — from the outset, it was very, very clear that during the empathy sessions, or during the initial days of thinking about the CI/CD processes on the mainframe, we had to adapt and adopt the mainframe DevOps processes that were so successful for the cloud colleagues, to bring them onto the mainframe.

So our solution was a five-part solution, the CI/CD process, and most importantly, the environments that they need to work on.

The dev and test environments that we have are on the physical mainframe. How do you bring immutability to it? Just imagine a Z15, Z16 box, and you're going to bring them up and down. And have any of you ever been near a mainframe when you shut it down physically? It makes a big sound — because Z mainframe, "Z" means zero downtime. It never shuts down. It only shuts down once, when you want to physically decommission it. We had to do that, to bring immutability onto the physical mainframe. That was the first part of our solution.

One reason Legal & General are market leaders in pensions: for our 15,000-odd schemes and 5.5 million customers, we bespoke — we bespoke for each of our schemes, whether it's handling their data and processing their payrolls, to take the money off every month for contributions. So we handhold them throughout the process. To provide a representative dataset of the solution — or a representative dataset that mimics production — our test team don't make our life easy. They were asking for time travel. That means to go forward and back so that they can mimic an annual benefit statement or a monthly contribution cycle. So they wanted the "back to the future" type on the data. So they were asking a representative production dataset with time travel capability.

And the third most important part was — if you all have seen the movie Shawshank Redemption, Morgan Freeman's character Red says, when Andy Dufresne comes in, he says: "These walls are funny — you will hate them initially, but then you will start getting used to those walls, and then you become institutionalized." Like every organization that stood the test of time — we have been here for 188 years. Our pension admin system has been around for 24 years. Invariably without knowing, a hero culture sets in. Only some people know how to configure these environments. Only some people know how to develop right code on these environments. In the new world we were envisaging, we wanted to remove that hero culture, and also we wanted to avoid creating key dependencies.

So we then partnered — we had to bring, to make this dream possible. The dream was: our Leslies, whether it was a 25-year-old experience Leslie or the 18-months-graduate young graduate whom we recruited fresh out of college, to be able to deliver code to production every two weeks. That's what you see here — our Leslie's devices.

We had to provide them with what was good in the cloud development practices. So we moved 80,000 of our modules from Endevor — which is a legacy or heritage source code management system — to GitHub. And to provide them with the endless list — don't want to work on black and green screens, you need to give them Java-type IDEs. So we partnered with BMC to get their Topaz IDE.

So the developers come in, they have to get the code from their IDE, and then they do the testing, or they do the development using IDE. And with one push of the button, the code goes all the way to pre-prod. And this is where the power of one was very, very helpful. When we had our young Leslie developing, compiling code, and with the push of a button, the code was going to pre-prod — that's when magic happened for us. The older Leslie saw that, and said: "Wow, this new generation of mainframe developers — that new generation of mainframe developers who are 25-year-old was able to push the code in one button click, why can't we do it?" That's when they started, they started converting into this modern mainframe CI/CD.

And important for us was the empathy-based design thinking approach for each of these solutions, whether it was using the continuous data capability from Delphix to provide those golden set of test data, or using GitHub Actions for moving mainframe code all the way from the virtual pop-up environments we have got to the physical mainframe environment in pre-prod and production. It took us two iterations.

And the mainframe environment problem that we solved — we partnered with an organization called Pop-up Mainframe, who provide IBM's zD&T pre-canned on Azure. So our physical environments, where we are decommissioning them — we moved our dev/test environments to cloud, without changing code or config. That gave us that immutability. These are immutable mainframe environments still doing mainframe development, but on cloud.

So if you see our pipeline: our Leslies come in, they do their editing on an IDE, compiling code, it goes all the way from the virtual mainframe to the physical mainframe using GitHub Actions. This is how we achieved the dream we set ourselves into go in — releasing mainframe code every two weeks, in an agile and DevOps manner, which is what the cloud colleagues have been doing for years. We brought that to the mainframe.

How did we go about doing this? One important tool that we use was service design blueprints. These are very important, because to take everyone on the journey, you need to tell them each of those transition states. We had three transition states and an end state. And we work for a business — we had to tell our sponsors at each transition state: what is the value they'll get? How many story points will get delivered faster here? What is the code quality that's going to happen at each transition state? And even to the people who are the developers who are with us at the same time, we were telling them: "Oh, we are not getting rid of Endevor fully — it'll be there for another 18 months. You are not going to go on to GitHub at the same time as everyone." So we gave them freedom to come when they are ready to come in. We were not enforcing this — we were making them part of the solution, part of the approach, part of the delivery. And these visual aids, the service design blueprint, really, really helped us.

We had good empathy design thinking, we had the right solutions in place, we had partnered with the right organizations. But most important, the secret sauce of our success was the "why not" culture we had. When we asked partners like IBM, Pop-up Mainframe, Microsoft: can we move physical mainframe environments without changing the code? Generally you'll find market solutions where you have to rewrite the code to Java to go to cloud. But we asked them: can we do it? And the partners said: why not? Let's do it. And without changing code, config, we moved all our 14 physical mainframe environments into Microsoft Azure.

And then, because ours was an empathy-based approach, we never were forcing all the devs by 31st December, you are going to be on the cloud. We didn't do that. We are going into the new world — we said, you can continue to use Endevor here, and whoever wants to come onto the GitHub, COBOL code on GitHub, they can come there. That means we were creating — we didn't make our life easy — we had two source code management systems and syncing them. That was made possible by our partner Broadcom, with a tool called Bridge for Good. Again, our engineering team and our partner said, "why not."

And the most important part was — Tariq doesn't make our life easy as well. So we chose our enterprise strategy as GitHub Actions to be our CI/CD orchestration tool. Generally for mainframe CI/CD, whoever has experimented so far, Jenkins is their preferred tool. But we said: let's do GitHub Actions. And there was a learning curve for our engineering team, but they were happy to come along, and they said, "why not." So we really thank all our partners — Kyndryl, Microsoft, IBM, Pop-up, TCS, Delphix, Broadcom, BMC. That was the complexity — we had to talk to eight different partners to arrive at this solution. This is where we slightly deviate from the cloud devs, because not many solutions are out there, but it is still complicated, and there is a huge learning curve. Just imagine going and telling a 20-years-experienced dev who has not heard the word "Git" or "branching" — tell them, "this is your branching strategy" — "what, which tree is it?" would be the first reaction you'll hear from them. They've never heard branching, not strategy, not Git. But that power of one, having that young graduate come over who is good at doing the Python things, sitting them with the developer community, helped us.

And with the help of a lot of authors here at IT Revolution who couldn't join us on here, we read all those books and we got inspired from them, and we implemented this. And then we believed: happy developers means happy business, happy IT organization.

You can see these are the numbers we are very proud of. We can deliver the mainframe change in less than four hours into pre-prod, non-critical changes. Our environment creation — generally physical mainframe environments take months to create. We can now create it in 15 minutes to 30 minutes. And most importantly, what helped our sponsors believe in us is we are now able to deliver every two weeks. What used to be three months to deliver a release, we are able to do every two weeks. There's an interesting talk on DOES UK if you're in the UK, to hear our colleagues talk about how we achieve 10 to 60.

And this was the differentiator. When you look at the cloud-based colleagues — one of our AWS cloud community of practice told us they can't predict the — they can't give you a code coverage in unit test. But with the tools we are using, we can search with certainty in detail which part of the code is being tested. That's the beauty of the COBOL language as well — which part of the code is being tested, which part is not tested, which decision flows are being tested, which are not. So we can with certainty give that in our automated unit tests.

And to those who don't believe mainframe projects can really innovate to awards — we have the testament to that. We won the CMG Impact Innovation Award. And also during the journey, we found out this is not only good for the planet — the methodology, with the people, it's also good for the planet, because we have decommissioned 14 environments, which is 550,000 MIPS a year and 42 terabytes of data. So we were facilitated with the Environment Impact Award for our DevOps journey, in SustainableIT.org. We recently won our DASA award for DevOps and Sustainable IT Impact.

But most heartwarming was when our young Leslie, 25-year-old Java/Python developer, telling me: "I'm not finding a difference between mainframe CI/CD and the Python CI/CD pipelines." That was the biggest win — the words are still good.

What are the key takeaways? Having that empathy for whom you are doing the project, and with whom you are doing the project, is very, very important — at the start of the journey, during the journey, even after delivery. And design thinking tools like service design blueprint — it helps you get everyone on the journey, from the sponsors. And the "why not" attitude of all the partners, senior leadership, is very, very important. Test and learn, keep learning. And definitely lots of pi — pizza — helps to bring people into the design thinking sessions we had.

And it'll be good to connect with the limited audience here, or whoever is interested in our journey, who have done a similar journey. A lot of us have still the mainframe — whether you're coming off or staying back on the mainframe, some of the concepts we have used are good for everyone, and happy to exchange notes on those. What is the approach you take? We believed in happiness of the developers rather than the pound value. If you're taking a similar approach, or any different approaches, that will also be helpful. This is the support we are after. And thank you for your time.