What’s behind the Bank of Ireland’s mainframe simplification agenda?

By Ronan Hughes

Note: This is a guest-contributed article by Ronan Hughes. He is the Core Banking Principal Architect for the Bank of Ireland which this year celebrates its 240-year anniversary.

Discussions about mainframe simplification at the Bank of Ireland may sound familiar to IT leaders at other banks and financial institutions.

The business is increasing investment in digital experiences that will enhance our relationships with customers. Cloud and generative AI have won everyone’s attention. There’s a desire to move workloads to the cloud for the speed and agility advantages it would offer. But there’s also a lack of understanding about why we can’t just move right away.

Beneath all this, we have a sprawling IT estate that needs attention, because it’s built on aging infrastructure. Some of it is at, or even past, what would be considered end-of-life.

To move forward and support the Bank of Ireland’s strategic growth pillars, we’re pursuing what can be described as a mainframe simplification agenda. The approach is characterized by three ways of working that I believe any bank technology leader would want to keep in mind:

1. Protect the crown jewels
2. Find and assemble your brain trust
3. Insist on collaboration

Protect the crown jewels

The essence of banking is the ledger—the balances, the book of record that for the Bank of Ireland goes back 240 years. That’s what holds the truth. It’s the crown jewels.

The purist view of our mainframe simplification is to restore a core system of record that is reliable, sustainable, hugely efficient, and easily maintained going forward.

We have decades of development that have seen fraud detection, customer authentication, payment initiation and more added to the platform. If we remove those and run them more efficiently in middleware services, that leaves us with a system of record that is exactly what the bank needs as a general ledger. And that’s what it should be.

When we have a system of record that is known, trusted, understood, and efficient, we then have the option to replace it or put that code base into a new, secure, sustainable and future-proof platform that does what the mainframe did. The platform functions in a way that we can handle moving forward--without limitations of skill set, knowledge, age or retention.

However, for example, if we were to force what we have today onto another platform without fully understanding all the underlying security measures, massive throughput and retro-fits, it would be doomed to fail. It wouldn’t work. You can’t debug anything. You can’t change anything. You can’t amend it in any way. You’d be stuck.

Find and assemble your brain trust

It’s clear that if we made a change to the mainframe in an area that had been running for 45 years, and broke it, we’d have big problems.

Thankfully we have internal expertise, knowledge, and insight that has been in the organization literally since the mainframe was installed. Many of those people don’t work on the mainframe anymore, but we know they invested a part of their soul in what’s actually running on that platform. There are decades of history in what was done, and what maybe didn’t succeed.

So, I suggested that we bring them back in as advisors on our mainframe simplification work to help us understand how decisions made 20 years ago could have great significance to what we want to achieve in the next three to four years—and it’s been useful.

For instance, we needed to understand why our mainframe had 30 clusters, and why the scalability varied so much among the clusters. Some of those clusters are very small and light. Some are massive and complex. Could we balance out the clusters to even demand on the machine?

We brought the question to the brain trust. The quick answer was yes. We could do that, but we’d need to be very careful because of the history of how the clusters were formed—which was based on batch processing and geography.

If we were to change the order of batch processing without knowing all of the upstream dependencies and downstream effects, we might unknowingly create a problem. We were aware of this because it had been tried and failed in the past. Without the brain trust, that knowledge might have been lost to history.

I find it hugely helpful in this process to say to people: I want to listen to you; tell me the things that everybody else has ignored, and I’ll take them forward and try and shape them into a way that others will understand. Just by being heard, people are empowered and motivated to contribute and share knowledge.

Insist on collaboration

We have four parties working side-by-side: The Bank of Ireland, Kyndryl, IBM, and NTT Data.

Coordination and collaboration are big parts of my job—much more so than code-based knowledge or even understanding the platforms. It’s like the difference between being a solo musician and being in a band where all parties must feel their contribution is heard and valued.

In the past, work here was done in a very waterfall kind of way. But we’ve found that agile methodology works better for us—delivering in small increments. That way we achieve a milestone every two to three weeks. At the end of the year, instead of having one delivery that may or may not work well, we have as many as 24 different deliveries, each of which has delivered benefits and created opportunities for contribution.

This method also de-risks each delivery and allows for learning on-the-job skills that had been forgotten or rarely used over the past few years.

Some deliveries have much greater benefits than others. Some might be positioning changes to facilitate more tangible benefits in the future. Maybe one or two fail, but the shared sense of achievement and accomplishment is much better, and of course, we make improvements based on smaller, less consequential failures.

The agile approach also helps our testing and change capabilities, as many other programs rely on core banking. Having the refreshed expertise, environments and skills available can fuel smoother operation of other programs.

The agile approach also enables us to incorporate institutional knowledge from the brain trust with new skills and capabilities, helping to lay the groundwork for ongoing change. The era of banks being able to run and deliver standalone change on their own internal platforms in isolation is gone. Our partnerships are vital for us to improve delivery and confidence in the platform.

We’re educating a new generation of technical experts for the Bank of Ireland, which helps address capability and skills gaps. Operational risk also decreases as the breadth and depth of knowledge expand among our bank employees, 3rd party support vendors and suppliers.

The evolution of core banking

If you were to start a new bank today, you probably wouldn’t use the mainframe. It’s very hard to maintain. There’s an element of dedication required in terms of a steep learning curve and skills that take years to hone. It’s not something you can easily pick up.

People talk about the evolution of core banking. And when they do, the focus is often on moving away from the mainframe onto newer platforms. But we have to keep in mind that core banking hasn’t really changed at all—it’s still the system of record and your central ledger.

My point is that in order to fully look at an evolution of the core system—and to ensure trust and delivery along the way—you have to understand where it came from. How did it come to be? What lessons have already been learned?

That’s what we’re doing at the Bank of Ireland, and how we’ll make sure we drive our business growth and strengthen relationships with our customers.

Ronan Hughes is Core Banking Principal Architect for the Bank of Ireland