The Cult of the Legacy Core Banking System Migration
A banker keen to stay under the radar has written us an insider’s perspective on the TSB scandal. Going by the topical pseudonym of ‘The Stigcumbent’, who you may remember from this piece, they’ve written about the ups and downs of legacy banking and why TSB had to make its move.
Read on to learn the full glory of legacy banking and where the future lies…
The very public problems which TSB have faced this week with their long awaited untethering from decades old Lloyds Bank I.T. systems have focussed the Fintech world’s attention on the divisive topic of legacy core banking system migration. Why divisive you ask?
Well, there are few areas of Banking I.T. that generate such impassioned arguments both for and against something. Many commentators with strong opinions on the need to replace these systems cannot always clearly define why this is the case. It's often all a bit "just because" or "it's the COBOL innit?". Arguing very strongly for something without necessarily being able to provide clear, structured and proven benefits would in other walks of life have all the hallmarks of a cult - Brexit being the obvious comparison here.
The TSB use case, to be fair, is a fairly specific one. They have had more incentives than most financial institutions to bite the bullet and perform this work. Due to the European Commission enforcing their separation from Lloyds Bank amid accusations of the UK Government's stake, post global banking crisis, being equivalent to state aid. That said, TSB had been continuing to squat on Lloyds Banks' I.T. systems since then without incident albeit at a rumoured cost of £200m a year. Hence is this ultimately a migration driven by operational cost savings rather than any unavoidable legal and practical factors? In an article by Karl Finders in Computer Weekly he quotes an unnamed "I.T. Professional" employed by Lloyds Bank as stating "I would rate the legacy systems as the lowest risk and safest place to be as they have generally been proven over many years, if not decades" and "The level of care required to migrate a bank onto different systems is perhaps almost uneconomic to perform in a way that keeps the risk small enough". These comments may well ring true in the context of TSB's problems this week but they are arguably very against the grain within the more fashionable areas of Fintech who largely believe only an idiot would not be aggressively migrating at high speed away from these systems in order to secure the future of the bank. So who is right here? Let's examine some of the most commonly stated justifications for legacy banking system migrations. Clear your minds everyone and conjure up an image of Alan "Fluff" Freeman in your head for the next few minutes......
Just pipped off the top spot at #2 we have "Burning Platform" by "Jah Enterprise" So these computer systems are really really old right? Stuck together with sticky tape and memory boards sourced from Lithuanian Ebay yes? Obsolete and unsupported by the vendor since Norwich City F.C. last won the league cup? The most recent model addition to the IBM Mainframe family was in April THIS YEAR. I'll just leave that fact for you to ponder.
Why Did They Migrate?
The TSB use case, to be fair, is a fairly specific one. They have had more incentives than most financial institutions to bite the bullet and perform this work. Due to the European Commission enforcing their separation from Lloyds Bank amid accusations of the UK Government's stake, post global banking crisis, being equivalent to state aid. That said, TSB had been continuing to squat on Lloyds Banks' I.T. systems since then without incident albeit at a rumoured cost of £200m a year. Hence is this ultimately a migration driven by operational cost savings rather than any unavoidable legal and practical factors? In an article by Karl Finders in Computer Weekly he quotes an unnamed "I.T. Professional" employed by Lloyds Bank as stating "I would rate the legacy systems as the lowest risk and safest place to be as they have generally been proven over many years, if not decades" and "The level of care required to migrate a bank onto different systems is perhaps almost uneconomic to perform in a way that keeps the risk small enough". These comments may well ring true in the context of TSB's problems this week but they are arguably very against the grain within the more fashionable areas of Fintech who largely believe only an idiot would not be aggressively migrating at high speed away from these systems in order to secure the future of the bank. So who is right here? Let's examine some of the most commonly stated justifications for legacy banking system migrations. Clear your minds everyone and conjure up an image of Alan "Fluff" Freeman in your head for the next few minutes......
Old Things Are Useless?
Are all old programming languages bad?A non-mover at #5 is "They're Just Old" by the Shoreditch based power-funk trio "No Further Explanation Required" Old? Like the Rolling Stones? Don't they still regularly fill stadiums? Is a thing being old undeniably bad full stop? Is all old computer software bad? Are all old programming languages bad? It’s worth remembering that even Java is no spring chicken anymore, it turned 21 years old last year. So did its weakly typed cousin JavaScript (spits onto floor) which shows no sign of being toppled from the top spot amongst web developers. That means that an awful lot of current software engineers are working in a programming language launched before they were born, just like all those mainframe developers. Ouch.
Simplicity is Best
Stuff goes in, it gets operated on, stuff comes out. Repeat.Down one place to #4 is "COBOL Sucks" by "REACT and the Natives" The funny thing about being in the computing business for a long time is that sometimes the most blatantly obvious things don't dawn on you until quite late in your career. For example, the basic truth that all computer software executes in order to take a given input, do something to it and produce an output. Yes, even space rocket software, stuff goes in, it gets operated on, stuff comes out. Repeat. There's an awful lot of that going on in banking by the way. Oh look here's your monthly salary credit coming in from BACS. Shall we add the amount of the credit to your account balance? Great idea! Oh look you have a new balance! During my time in banking I.T. I've worked with most of the languages out there and the one most optimised for exactly this kind of simple flow is, you guessed it, COBOL. Using modern IDEs and DevOps practices, development in COBOL can be dragged into the modern software engineering world and made sustainable - if the effort and investment to support it is made.
What Batch?
There is no enforced outage to other system processes whilst this 'batch' is being performedUp two places to #3 we have "It's Not Real(time)" by "Overnight Bitch" Several recent entrants into the banking scene have made a lot of fuss about their I.T. systems having 'no batch'. Hmm this is interesting. So you have no standing orders, no direct debit processing, no application of credit and debit interest, no application of fees and charges, no statement generation right? All these things are fundamentally enabled by scheduled events triggering a process, in other words what we in the trade call 'a batch'. What is more likely meant by the 'no batch' assertion of the Digital Banks is that there is no enforced outage to other system processes whilst this 'batch' is being performed. Unfortunately this is not the revolutionary leap forward that the neo-banks are selling. Any bank whose existing mainframe platforms have been reasonably well evergreened since the 1980's already has exactly this capability. When was the last time your bank refused to let you have money out of an ATM because it was 'busy printing statements" or "calculating mortgage interest"?
Ice Cold
Just pipped off the top spot at #2 we have "Burning Platform" by "Jah Enterprise" So these computer systems are really really old right? Stuck together with sticky tape and memory boards sourced from Lithuanian Ebay yes? Obsolete and unsupported by the vendor since Norwich City F.C. last won the league cup? The most recent model addition to the IBM Mainframe family was in April THIS YEAR. I'll just leave that fact for you to ponder.
Too Many Clouds in the Sky
The degree of continuous improvement of those elastic computing platforms is astoundingAnd now - the moment you have all been waiting for - the coveted #1 spot this week goes to...... "I Wanna Be Elastic" by "Clouds do it Better" Hmmmmmm. Darn it. You got me. Yes - truthfully - this really is the killer blow that makes all the other justifications for legacy system transformation look, well, a little lazy frankly. Why is this a big deal? To understand this we need to take a look at mainframe platforms and how they manage workloads. They are, essentially, a vast array of fungible computing resources which can be dynamically deployed to whichever application needs it the most at that point in time. A fair degree of effort from the owning organisation has to be spent planning when and where those computing resources will be most required and even arrange for non time-critical workloads to be moved around the clock to better the utilise the 'whitespace' of quieter times of day. Run-time containers called "CICS Regions" need to be configured and managed on the mainframe which can then be cloned and deployed as part of the process of scaling individual services running on the platform. I am by no means the first person to make this claim - but the mainframe truly is the "original cloud". That makes it great right? That means we don't need AWS, GCP or Azure right? We've got our own cloud - yippee! Wrong, the problem is, what makes Azure et al such an attractive proposition for the hosting of any technology service is they do all the hard work for you. They build and manage the data centres. They treat you like a real customer, not just one of many cost centres within your own organisation bound up in some pretence of a genuine supplier/customer relationship. They document EVERYTHING you need to know about how to build and manage services on their platforms and you can actually understand it. The degree of continuous improvement of those elastic computing platforms is astounding, just look at how often AWS are tweaking and optimising services and updating all of their customer resources to reflect it. The mainframe is not dead, but the bank data centre it is sitting in is.
Out of the Competition
Bank shareholders simply have no interest in the increasingly expensive business of competing as technology service providers with the likes of Microsoft, Google, and AmazonThe sad truth of the matter is that despite banks being way ahead of the curve by building some of the world’s first scalable, reliable and relatively elastic computing and data storage platforms it just simply isn't their game any more, the era of the bank's data centre and operations staff being best in class is slipping away. That crown has been undeniably stolen from them by Amazon, with Google and Microsoft snapping at their heels. Cloud hosting of financial services still has a long way to go, it is imperfect but it is the future. So, why do we need to do something about those old IT systems? It's not the systems per se nor the increasing number of grey hairs on the heads of the people that originally built them. It's the data centre they are running in and the self hosting philosophy built around it that is on borrowed time. Bank shareholders simply have no interest in the increasingly expensive business of competing as technology service providers with the likes of Microsoft, Google, and Amazon. That means that the degree of reliability and professionalism with which these players can offer technology hosting services will only increase whilst the equivalent skills of incumbents are set to decline further. To loop this back to the TSB debacle where we started off, yes they probably did need to move away from their alleged £200m a year renting of Lloyds Bank's infrastructure for the reasons stated above but anyone attempting such a high risk manoeuvre needs to remember two things: #1. Don't Screw It Up #2. See #1 - Stigcumbent
