Why isn't Banking more Boring? Part Four

In the third instalment we examined the shape of the technology architecture required to support a fundamentally less complex and more cost-effective operating model. However, engineering a target platform (or buying one someone else has engineered) that enables different economics is solving only half of the problem. It counts for nothing unless we can move an existing bank - customers, products and transactions - on to it.

Historically this has been a long and costly endeavour. As we described in Part One the rewards are significant, but so are the risks. For a major retail bank of 10 million customers or more this would likely involve upwards of a billion pounds of investment and three years or more to complete. Executed poorly it can cause significant issues for customers and destroy significant market value. Together with core systems replacements (which have many similarities) it represents the most significant and difficult change a bank can undertake.

So is this a dead end? I don't think it has to be.

In the TED interview Musk says he has an ambition for his new tunnelling machines and it involves Gary. For those that don't know, Gary is the snail from Spongebob Squarepants and Musk and his team have a real-life pet version. Musk explains that currently Gary is capable of moving 14 times faster than the tunnelling machines. Success would be for the machines to beat Gary.

So let's suppose Gary is the person who says that doing a major bank migration will take one and half billion pounds and three years to complete. Can we find a way to beat him?

How it works today

Let's look at how we move the existing customers, products and transactions from one bank’s operating model (people, process, technology) to a new target bank. To date the most successful examples have adopted the following pattern

1. Prepare the target
2. Prepare the data and cutover plans
3. Manage away differences
4. Practice the migration and cutover
5. Execute the migration and cutover.

The very fastest have probably completed in eighteen months, but the average is more like two and half years. Here is why it takes so long.

Prepare the target

• Declare a change freeze on the target bank for, say, 3 years. It will take that long to plan and execute the migration and the target (processes or IT systems) cannot change radically during that period
• Incrementally make capacity changes (locations, systems) that are required to accommodate the volumes of the other bank – assume 2 years to achieve this across hundreds or thousands of IT systems and multiple locations
• Incrementally analyse and implement into the target bank's IT systems, procedures, processes and policies the changes required to support the minimal set of changes required to support the customer and products being migrated – let's also assume 2 years for this.

Prepare the data and cutover plans

• In parallel plan the data migration from the source bank’s systems to the target banks systems and build and test the migration software required to move all of the data across. This includes all financial data, customer demographics, transaction histories, credit histories, financial reconciliations, operational reconciliations, etc. – again let's say 2 years
• In parallel to this design, plan and train everybody required for the operational cutover from their original set of locations, processes and procedures to the target set of locations, processes and procedure – again assume 2 years

Manage away differences

• Because changes to the target bank are being minimised, customers will experience material differences between their “old” bank and their “new” bank, unless something is done. To avoid this we have to change the old bank to “mimic” as much of the “new” bank as necessary from the customer’s point of view. For example, we may have to change statements to have the same look and feel, or be issued on the same days as they will in the new bank, or change how existing online banking looks to mimic the look and feel of the target online banking platform.

When these three steps are done, we will have the following in place

• A running bank (the target) that has all the changes required to run the additional bank, provided we can get all of the data across and ensure that all of the cutover happens correctly
• Software that can move the data, and people who are trained in the new bank’s processes and procedures.

Practice the migration and cutover

• Everyone (Customers, Regulators, Media) will be extremely interested in a migration of this size and we will likely need the remaining 12 months (of the original 3 years) to practice the cutover and migration and evidence that we are prepared to execute successfully it before actually doing it.

Execute the migration and cutover

• At the end of 3 years execute the migration and cutover to start realising the benefits. This makes cutting over hundreds of locations, thousands of systems, tens of thousands of people, millions of transactions, and billions of pounds in value – all over a weekend – much simpler than it actually is, but that is why it takes 3 years to do it.

Why it works this way

There are three inherent reasons migrations take this approach

• The benefit comes from adopting the operating model, processes and product structure of the target bank (because that is the more efficient one) and therefore adopting it as-is is the path of least resistance and the fastest one to benefit
• The target IT architecture and processes are likely no more able to accommodate product or service variations at near-zero marginal (operational) cost than those from the bank being migrated. Therefore minimising variations is essential in order to minimise benefit loss. Every variation introduced into the target, whether to accommodate a product or process difference, is a variation that is likely to replicate the inefficiency of the operating model that is being left behind
• It is operationally and technically too difficult to execute the migration incrementally and cutover products, customers or areas of the business piece by piece when they are ready, rather than “big bang” when they are all ready. This is because there is significant overhead (money & time) associated with testing and proving everything works ahead of a migration event. Therefore undertaking one “big bang” is actually faster and cheaper than undertaking lots of incremental migrations.

Finding a way to beat Gary

Everything we know about banking migrations assumes that the target is based on a platform architecture that has today’s characteristics. But what if the target platform architecture had the following characteristics

• The ability to recreate source products quickly in days of development time, rather than weeks or months
• The ability to enable (down to per customer, per instance) product variation with near-zero marginal cost
• The ability to run, update and release products independently of others with zero regression and near-zero release costs.

These are precisely the characteristics that we should expect from the essential architecture underpinning our target bank if it is realised as a genuine cloud-native, micro-service based implementation

• Where products are independently deployable and releasable micro-services that encapsulate only the essential features of the product
• Where each product can be developed, deployed and released without downtime and without any impact to other services
• Where new bank instances can be quickly stood up and torn down to support trial migrations and cutovers.

If this is the case then the migration can be conceived and executed quite differently

• Prepare the target – No change freeze required, scaling is trivial and faster development times mean changes can be implemented quicker (days/ weeks vs. months)
• Prepare the data and cutover plans – Incremental cutovers can be designed, with products, processes and services being trained in and cutover when ready. Data is loaded through APIs (that scale capacity as required) making source to target mapping materially simpler.
• Manage away differences – Less of this is required as changing the target is straightforward and doesn’t undermine the benefits case (provided the “essence” is replicated and not the accidental complexity)
• Practice and Execute the migration and cutover – This becomes a simpler, continuous activity with incremental migrations rather than one “big bang” after 3 years.

All of this is not to say that that acquiring the customers, products and transactions of an existing bank will not be significant undertaking, but to come back to the question “Can we beat Gary?” the answer is

“A defining characteristic of the target platform is that it will make migrations a lot less difficult than they have ever been before. If it doesn’t allow us to beat Gary, then it isn’t a target worth landing on"

In Part Five we will come back to the question of how likely this is to happen in the next 3 to 5 years and then finally in Part Six discuss the alternatives approaches that could be adopted for achieving the same end of a dramatically more cost efficient operating model.