Host Intro (Gene Kim)

Next up is an experience report from Legal & General, which is one of the UK's largest financial services and asset management companies. In this session, Bharghava Bhogireddy, Jennifer Pickard, and Tariq Surty will describe their initiative to overhaul the company's mainframe engineering and delivery systems.

I love this experience report because it is an amazing story that eventually and ultimately depicts mainframe developers as just another type of developers, which is very different than my perception, say in 2015, which is so upended by a longtime friend and community member, IBM Fellow Rosalind Radcliffe. So here to tell the story are Bharghava, Jennifer, and Tariq.

Tariq Surty

Thanks very much, Gene, for the generous introduction. It's very kind of you. I must say, it's a real pleasure and honor to have the privilege of sharing our story with you today in this fantastic forum.

Like you mentioned, I'm Tariq Surty. I'm the IT Director for the Retail Retirement business at Legal & General. I'm joined today by a couple of other members of my team: Jennifer Pickard, who's our Head of Engineering, and also from the architecture team, Bharghava Bhogireddy, also known as Vamsi. That might be a little bit easier for you, Gene. He's our Senior Operations Architect.

I'm going to go through quickly a quick background of the company and set out the context and the case for change that has led us to this project. Jennifer will then talk about our empathy-driven approach, and Vamsi is going to share the detail of the solution and results.

For those who haven't heard about Legal & General, here's a quick overview. Legal & General is one of the world's biggest asset managers. In the UK we have been recognized as the most admired company, not once, but two years in a row, a feat I am led to believe only achieved once before. Our 10,000 or so employees are aligned to core life protection, retirements, and pensions businesses, which are a major source of the over one trillion in assets that our asset management arm has to manage.

The way we invest these assets is underpinned by our purpose, which is summarized as inclusive capitalism. This for L&G means that we're using the assets to not only create value for shareholders, but also to do that in a way that benefits society and our responsibility to sustain the world we live in. That's a unique value proposition from L&G.

As I mentioned, the three of us are in the pensions business, which has undergone a huge amount of change over the last few years, largely driven by regulatory changes. The key milestone for this was in 2012, when the UK government mandated the need for all employers to offer a pension scheme and shifted from employees having to opt into pension schemes to having to opt out, because they would be automatically enrolled when joining a company.

This change was a catalyst for the growth in the number of customers we support and enabled us to grow from 250,000 in 2012 to approximately 5.2 or 5.3 million today. Due to other changes in the pension industry, we expect this number to continue to grow over the next few years.

To respond to this rate of growth and to drive better, more efficient customer experience, a couple of years ago we initiated an initiative for us to accelerate the adoption of digital transformation, drive much more straight-through processing, remove technical debt, and also adopt agile at scale.

Given the rate of change, the scale of growth, and the digital experience we wanted to create all impacted our core pension administration system. Given the fact that the core pension administration system at L&G was on the mainframe, to be able to support the business effectively from a technology perspective, we looked at the idea of moving away from the mainframe. For numerous reasons, we ended up asking ourselves: instead of mainframe modernization, why not just modernize the mainframe, especially the processes by which we deliver change?

So why not? We asked ourselves: why not join the IT revolution and bring all the great things that DevSecOps and modern software development practices and tools have to offer, such that we can drive not only the quantity of change, but also the quality and the quickness of change too?

To explore this question of why not, we initiated a project called iMpala. You may be thinking, why iMpala? Well, most of you, I'm guessing, will probably be too young to remember mainframe technology in the same way as you are probably too young to remember the Chevrolet Impala. But given we are working with heritage technology and wanted to drive for more agility, nimbleness, and speed, we thought iMpala was a fitting name.

As I mentioned earlier, Jen, Head of Engineering, is with us today and she'll share more details of our approach to achieve our vision for mainframe software development. Over to you, Jen.

Jennifer Pickard

We decided to use empathy-based thinking. We thought it was really important that we took the time to hear people who engage with the mainframe and make sure that we listened to those issues, and that we'd have to iterate through some of those solutions and options.

We had a number of empathy-based sessions that we ran. That was across a number of different groups, not just your developer and quality engineer community, but across a broad spectrum of the people that were engaged with the mainframe. We really took the time to run a number of sessions. It took one to two months, many thousands of post-it notes generated, really trying to understand the flow of work through the systems, the different teams, and the handoffs.

Actually, we found that the teams found that quite cathartic, that they could articulate their issues and their concerns. Equally, they started to come together in terms of their own view as to how they could improve things and things that they'd observed. But when it came to the tooling and what options were out there, people were just less aware. They were aware of current things, but the new world was slightly different.

We took those learnings and consolidated those down to a number of key areas. One was the tooling. The other was around the time we took to create data and quality data, and to get it to the right position, and the amount of manual steps within those processes and handoffs within those teams.

There was also an issue of environment contention. When the production mainframe, during peak end-of-month processing times, has capacity allocated to that production system, you end up with less capacity being given to the lower environments, which in some cases would lead to those systems really slowing down or more or less being unusable for the development teams. Addressing that pain point, we really realized we wouldn't be able to get a big bang. We'd need to go slowly and incrementally introduce those changes and learn how that settled with the teams.

We also wanted to address the next generation and give them tooling capability that meant they could be the next generation that continues to support, maintain, and grow the mainframe capability. We addressed those influencers and detractors, making sure they're engaged and continue to see the value of the work that's being done.

From that, we then really started to look at the problem statement. What were we trying to do? We defined those key questions. One was, how do we get CI/CD onto the mainframe? How do we introduce those core capabilities? How do we bring cloud into the mainframe, in terms of a virtualized mainframe environment, and remove that contention on the main production workloads? How do we ensure it is adopted, it is used, people remain curious, and we engage that next generation?

We focused on the people again. Beyond the standard things that people will be doing in agile worlds around show-and-tells and open communication, it was really looking at bringing in a fresh pair of eyes. We brought in a new engineer who had not been with the company before, who had a fresh lens as to what options were there and what was workable. It also meant they could validate some of the initial tooling to say, does it even stand up? Is it worth showing it to anybody else?

We brought in a graduate engineer so that we could trial with them how easily they could engage with some of those processes. We did some silly things, like games and prizes. We had a prize for the first person to raise a bug. It wasn't very much, but it was the gesture, really trying to make sure that we wanted them to feedback and feel they could feedback, positive and negative. That built a really good community as we went through those latter sections, that they felt they could be vocal, again positive and negative, and could start to engage with their own teams as to things that they found and explored as they went through the interactions.

We also, as always, put things through Copilot, as I think everyone's doing today, and asked it what a modern engineer would look like. This was the image and the wording that it generated. We used that. It was the sort of thing we were doing, but it ended up being our term: Leslie was the future mainframe engineer. We used that icon and the wording to really keep us focused to make sure we were delivering against some of those main concepts.

I'll hand over to Vamsi, and he'll talk through the solutions.

Bharghava Bhogireddy

Thank you. It was very evident from the outset we had to adopt CI/CD processes for our mainframe development lifecycle, as the goal was to provide a uniform developer experience, whether it was for the seasoned mainframe, 25-year mainframe-experienced developer, or the young Leslie we recruited 18 months before.

During the empathy sessions, as Jen explained, it also became very evident that just providing the CI/CD capability on the mainframe is not going to provide the answer. Whatever change agents we are looking at, whether it's the developers or product owners, we had to provide much more than that.

One of the reasons Legal & General are the market leaders in the pensions industry is because we bespoke for the majority of our customers, 5.5 million customers across 14,000 schemes. Providing a representative test data set that represents that production quality is also very important for us to cater in the solution, along with providing immutable mainframe environments.

Just imagine bringing down a physical mainframe up and down, or spinning up and spinning down to achieve that immutability. Like every other organization, or a heritage application or product that has stood the test of time, our pension admin system is 25 years old. Somewhere along the line, key personal dependencies about the knowledge of how to configure these environments, how to make those changes, and that's by breeding the hero culture. In the new world, we envisioned that hero culture has to be avoided.

As this was empathy-driven, it was also very important for us to look at each of those aspects that caused our developer communities to spend more than 30 or 40 minutes on a daily basis. At first principles, we said, let's remove that toil in the new world: automate-first, automation-first mindset.

This would not be possible without bringing a lot of tools. As you can see in this slide, we had to bring in a lot of new tools provided by four to five technology partners and new ways of working as a technical solution.

We then embedded these tools and processes into our mainframe development lifecycle so that our Leslies can develop and deliver the change into production, which continues to stay on the physical mainframe, in less than two weeks. That was the dream. That was the aim we were going towards.

All our testing before the code moves to pre-prod and production will continue to happen on the virtual mainframe, immutable mainframe. We achieved that immutability using a partner called Pop-up Mainframe along with Microsoft. They provide zD&T environments on Microsoft Azure.

The test-data quality I was talking about was provided by creating a golden test data set that mimics production, and using Delphix with continuous data capability so that the environments are now solved. We solved the environment problem. We solved the data problem.

But how do you bring that uniform developer experience for the young Leslie who was recruited as a Java developer, to the senior-most mainframe, 25-year-experienced developers?

What is new to the mainframe developers has already been used by cloud developers: accessing the code via GitHub using an Eclipse-based IDE. We achieved that by using Broadcom's Git Bridge, where we migrated all our heritage code into GitHub, and then we provided access to that code using an IDE by BMC.

Then the magic happened when the senior-most developers saw what young Leslie could achieve. They spoke to each other like the early adopter Jennifer was describing, and they could see pushing the code to pre-prod as a click of a button, not the 25 or 30 commands you need to type on black and green screens.

This didn't come just like that. All those circles you're seeing showed that empathy-driven approach. We had three or four iterations before we arrived at what Leslie's device should have, or using GitHub Actions for pipeline management. We had two iterations at it. Empathy is very key for how we continue to deliver our developer experience platform.

We had the solution blueprint. We had the tools that we needed to bring in. We designed the solution blueprint. But how do you take everyone on the journey? Just imagine when you are remodeling your house: you'll have an architect and builder come and say, this is how the end looks like. We exactly did that with the help of the tool called service design blueprint. But it was not going to be a big-bang story. That was the end state where we wanted the developers to go to. But there are transition states. All our Leslies are now in different transition states, and each of these transition states has business value.

At the end of the day we work for business, and we had to show our sponsor at each state what is the business value provided. Drawing these service design blueprints and taking everyone, inclusive of the sponsor, got that buy-in in a continuous manner.

We can have the best intentions, we can have the best technology solutions, but without the team who are very important, without them being bought in, it is not possible. The attitude the teams have got, whether it's the extended partner ecosystem of partners we have got or our senior management, the two magical words are: why not?

We were blessed to have the team with that attitude, whether it was moving our mainframe environments to Azure without changing the code, or moving our 80,000 modules from Endevor to GitHub, or building those CI/CD pipelines using GitHub Actions, not the traditional Jenkins, because it is easy to maintain. We were blessed with having the why-not attitude across the six to seven partners we have got and our senior management, and the team who said: why not? We will do it. It is not rocket science. We can get it done once and it is possible.

With all of that, the success came to us. We achieved the success we wanted to achieve. We can now deliver our change in less than four hours into pre-prod. We can create environments in minutes. Code scanning and vulnerability detection can happen for mainframe COBOL code using SonarQube very early in the pipeline. We have achieved the highest quality using automated unit tests, which can visually show which part of the code has been tested or not tested. This is mainframe COBOL code, which has 2,000 lines per program.

With success comes the desire to achieve more, and feedback is very important for that. We went out externally and internally and sought feedback. We are proud to say that we have won the prestigious CMG Impact Innovation Award. While we were getting that external recognition, the heartwarming thing for us was our young Leslie telling us: what is this fuss about mainframe development? I'm a cloud-based developer, but I don't find any difference between the DevOps pipelines we have created.

Our senior-most mainframe engineer who was reluctant to come on the journey has now converted. To top it off, because of the approach we have chosen and because of consolidating our environment, we have also received the prestigious Environment Impact Award, both for the methodology and for reducing the carbon emissions by SustainableIT.org.

What are the key takeaways in our journey? Having that empathy throughout any project initiative, transformational initiative, to whom we are doing this project for and who we are doing this project with, is very, very important. And that why-not attitude from the teams, leaders, and partners. If you're equipped with the right tool, like a design-thinking approach, or the success mantra test and learn, keep testing, keep learning, the continuous cycle, the senior executive buy-in will come. Definitely lots of pizza helps to bring people into the sessions and keep them engaged throughout the sessions as well. That's something we have found as a key takeaway or key salient points of our approach.

What we are looking for from all of you is that we have started this journey thinking it may be possible, it may not be possible. If you're on a similar journey like us, you don't have to reinvent the wheel. Please feel free to reach out to us. We also want to exchange notes with you on what you did yourself to transition to an automation-first mindset, or changing the focus away from the pound symbols or dollar symbols to the throughput- and value-driven approach, and how did you measure cost of your change? What are the models you have used? Please feel free to reach out to us.

Thank you, Gene, for giving us this opportunity to present our empathy-one story. Thanks a lot to all of the audience who are listening to us. Thank you.

Host Close (Gene Kim)

Fantastic. Thank you so much, Vamsi, Jennifer, and Tariq. It was amazing to see how you helped four generations of developers, and I loved the testimonials. Thank you so much.