Continuing our recent theme of helping big complex companies to increase their agility, today I’m going to talk about some practical steps banks can take to simplify their technology architecture to make future change easier to manage. To be clear, I’m not talking about building a new bank in this post, I’m talking about simplifying the technology of the old bank. For those interested in some of the technical details, I’ve included an interview with Xavier Boileau one of our colleagues who has a lot of experience helping banks to transform and modernize their legacy infrastructure.

Digging up the road

Banks are not short on new and innovative ideas. They have visibility of all the cool stuff going on around them in their industry and they have no shortage of advisors and fintech companies coming to them with new ideas. The problem is that implementing these new ideas in their legacy systems is analogous to “digging up the road” which is very disruptive, costly and risky. Most ideas never get implemented as a result. This inability to implement new ideas is the main reason big banks lack agility.

Best not to touch it

But this road digging analogy doesn’t quite capture the complexity that one encounters when trying to implement change in a bank. Rather than seeing a couple of simple gas and water pipes that need to be navigated beneath the road, banks are confronted with a web of complexity which is mind boggling more akin to a poorly wired telecoms switch board:

Moreover, no one person knows what all the wires are there for. They know not whence they came nor where they lead. Many of the wires are probably no longer in use, but how can you be sure which ones are active and which ones are redundant? Many of the wires were probably connected 50 years ago by people who have since departed the bank taking this knowledge with them.

Help is at hand

One of the main insights we gained from our recent work designing and building new banks from scratch is that a microservices architecture with a common orchestration layer is the key to keeping inputs and outputs very transparent. Extending our wiring analogy, we are basically moving from the above web of spaghetti to something that looks more like the following:

In this model, each wire has a specific and narrow purpose (it supplies a “microservice”). It is also very easy to swap components in and out because all the connections are standardized. Implementing change no longer requires digging up the road. We can calmly open the door to the cable cupboard and move connections around, unplug the services we are no longer using and plug in cool new services as they come available. In other words, we can manage change quickly and in a very controlled and transparent manner. We have regained our agility.

What this looks like in reality

To be clear, the above wiring board was only an analogy for a modern technology architecture. The reality of implementing change under this new architecture is more complex than plugging and unplugging cables but the availability of API technology means the concept of "plug and play" is becoming more realistic.

The below is a much simplified view of how a bank works but gives a good illustration of the difference between the old and the new (target) architecture.

Old “Spaghetti” Architecture

New “Microservices” Architecture

Let’s describe the main differences between the two architectures:

Old Architecture

• Everything is connected to everything else in a web of complexity. As functionality grows, complexity expands exponentially.
• Each connection is a bespoke connection requiring a systems integrator with specialist knowledge of each system to make changes.
• Most of the data is stored in the underlying systems.

New Architecture

• Each service is connected to a common integration layer. As functionality grows, complexity expands linearly.
• Each connection is standardized (through the use of API technology) so it’s much more “plug and play”.
• All the data is stored centrally.

The advantages of the new system are hopefully obvious:

• It’s much easier to swap services in and out.
• Changes can be managed more rapidly and at lower cost and risk.
• Your data is held centrally so you won’t be “held to ransom” by any of the service providers.
• It’s easier to manage and optimize the load/traffic going through each component.
• It’s easier to isolate and fix failures across the system.
• Easier to assemble new propositions from existing components.
• Easier to deliver real-time services.

And by the way, this is how all the big tech companies are architected, Netflix being the most well-documented example.

An interview with Xavier Boileau

Xavier is Partner at Oliver Wyman who recently went through this experience of moving a large bank from the old architecture to the new microservices approach. It's an ambitious undertaking but Xavier has convinced me that it is possible to manage this transition in a controlled and piecewise fashion. More from Xavier below.

How difficult is it in practice to disentangle the complex web of legacy systems?

 Xavier:

“The art of  modernizing existing legacy systems comes from decomposing the old systems (often mainframe) into smaller components with some of these components being moved to the external cloud. Each of the services should be "Elastic, Resilient, Composable, Minimal and Complete" but the difficulties are not just technical. Progress towards the target architecture will initially be limited by a skills shortage, resistance to change, and the impact it may have on existing ways of working and organization. For example, leveraging API's implies a change in the way you design, build and govern applications which will require a big cultural shift. And, let's not forget, there are a lot of vested interests who stand to gain from maintaining the existing complexity…”

How do you manage the transition from the old architecture to the new one?

Xavier:

“It is usually better to pilot the new architecture with a narrow business scope that will prove the benefits of the new approach. You can then use the project to put in place the common elements, set up the infrastructure, establish a first set of services and train the team with the key skills. You will then be able to expand towards a more fully fledged "platform". An example pilot project could be the encapsulation of an existing product line to be sold on somebody else’s platform with a view to opening the bank up to the broader external ecosystem.”

How do you ensure that no data is lost or contaminated along the way?

Xavier:

“One of the problems you encounter when you setup microservices is the "real time" synchronization that you need to maintain between your "sets of services" and the underlying system of record in the legacy. Each time data is modified in the legacy you need to broadcast the change to the platform layer, and each time a request for modification is executed in a channel via an API,  you need to update both the platform layer and the legacy system of record. Fortunately, a modern message streaming platform such as Kakfa supports an "event driven" architecture, with messages being pushed to each system and application that needs to be updated each time an event occurs.”

So, in short, while Xavier admits that managing this transition is not going to be easy he thinks the chances of success are improving rapidly now that we have the modern toolkit available to make it happen. If I were a CTO of a large bank, I’d be diverting most of my change budget to making this transition happen as quickly as possible. And while the approach could be criticized for being “technology led” transformation, it will give the “customer led” transformation that follows a much greater chance of success.