Creating a component based bank (getting rid of the spaghetti)

One question that crops up regularly is how do we open source the bank, Chris?  The reason is that the bank has built itself over decades through thousands of programmes across hundreds of servers into this massively complex technological spaghetti that cannot be unravelled.  That spaghetti has to be serviced by thousands of programmers and developers because it’s all mission critical.  Then there are layers of suppliers on top of the internal spaghetti who have also built their legacies upon the bank’s legacies.  These suppliers are on versions 7, 8, 9 or 10 of their core platforms, and their customers are either on version 7 or 8 or 9 or 10 such that they have to maintain them all for a cost.

Now consultants and protagonists are all asking the bank to open source itself, convert to APIs and move data to the cloud and it’s no wonder the CIOs are going WTF?  It cannot be done.

However, I think it can.  I’m simplifying things, but if I were a CIO given the challenge of dismantling an elephant made of spaghetti, I’d start one strand at a time.  So let’s take one strand of spaghetti and see what it does.  Maybe it’s a strand that deals with payments processing for the mortgage product the bank sold in the 1990s.  The mortgage product was shelved in 2002, but no one has bothered to migrate the product or its regular payments to a new platform.  So it’s sitting there as one of the 100s of systems that fragment and cement data into niche parts of the banks underground network.

There are three parts to this strand of spaghetti – the processing of payments for an obsolete product; the mortgage product details itself; and the data about the customers who have that product. It always comes back to product, processing and customer.

Payments processing is moving to an API set, so let’s modularise the mortgage payment processing into an API that can be plugged into any mortgage product the bank operates now and for the future, whether obsolete or not.  The API is our first move towards modularisation.

Product information is part of the back office and, along with the customer profile, will be positioned into the enterprise data structures we build in the private cloud to allow product and customer details to be integrated through APIs into any front-end service we want to deploy.  In other words, the product and customer data – the content – are now architected into the cloud to be independent of the processing, which is the modularisation components of the banks’ operations based upon APIs.

Finally, we have to provide internal and external access to the content via APIs as a great user experience, so we now start designing apps based upon a single customer view of all the products they hold, accessed via APIs based upon the front-end view we want to deliver.  Those apps may be delivered as a base single platform, with bolt-ons and add-ons that the user can design to suit.  So for some they may hold one or two products, and purely use the base app platform with a couple of options.  Others, like large corporates, may use several base app platforms with multiple add-ons, as per the Deutsche Bank Autobahn Appstore.

So we have converted our obsolete mortgage product strand to a set of APIs, private cloud data and apps for access.  At this point, assuming the migration is working well, the old platform can be shut down as the processing is no longer on the obsolete platform but in our new data architecture.

Module 1 complete.

Now move onto Module 2: the mortgage products we sold from 2002-2009.

Module 3: the mortgage products sold from 2009 to today.

Then move on to the pension product we sold from 1979-1986, etc, etc, etc.

Strand by strand, we snap away at the spaghetti until it starts to unravel, strand by strand.  This is by no means a short term project – it might take years – but is important to attack as the bank cannot become digital if its products and processes are locked away in a cemented network of old spaghetti.  In fact, it’s doubly important if Oliver Wyman’s report that I blogged about yesterday comes true, as the banks locked into legacy spaghetti cannot compete with the modular services of the Fintech start-ups and innovative banks.

Meantime, I’ll leave you with one last thought, as I write this from a technologist’s viewpoint.  Accenture yesterday tweeted this picture:

If a bank doesn’t have the technology vision and leadership to make the conversion of spaghetti happen, then the bank doesn’t have the right leadership.  After all, along with changing the culture, managing competitiveness and implementing regulations, technology is one of the big four key buckets of challenge for the leadership, as blogged again earlier this week.  If the bank’s leadership is missing a person who is critical to dealing with one its big four challenges, then the bank’s leadership is at fault. Fix it.