“Spaghetti systems” is a catchy name for a terrible problem. Go backstage at most banks and the tech scenario is usually a tangled mess. Thousands of applications are patched together, with some of the most critical platforms dating back to the 1980s. Cash machines still run Cobol, written in 1959.
This spaghetti leads to disasters. IT teams are terrified of updating ancient applications. Systems go down. Errors creep in. On one occasion the Financial Conduct Authority identified 750,000 customers paying the wrong amount in mortgages – a disaster for those involved. The cost of bank systems is mind-blowing. Bank of America allocated $10bn in a single year to modernise its IT, while JP Morgan spent $11.4bn.
But why are banks stuck with out-of-date software? It’s not down to desire. Banks talk a great game about the need to modernise.
It enables banks to innovate at a much faster pace and respond much more quickly to rapidly changing customer needs
There’s even an agreed methodology to upgrade. Instead of running applications with a monolithic code base, banks should chop them up into pieces, called microservices. Each microservice can run autonomously, operated by a team focused exclusively on their own sub-domain. It means upgrades can be done much faster.
And then there’s Continuous Integration and Continuous Deployment (CI/CD). This means code is updated regularly in a blizzard of tiny improvements, rather than a big bang upgrade every year or six months. Amazon, for example, updates its code every 11 seconds. The advantage is that each tweak can be tested individually. If it works, it’s retained. If not, the version is rolled back.
Cutting-edge software
If banks embraced CI/CD, the software would always be cutting edge, as it would always be improving. “It’s a much quicker and more efficient way of rolling out products and services,” says Prema Varadhan, deputy chief product officer at Temenos, one of the world’s largest providers of banking software. “The benefits are numerous and vast. It enables banks to innovate at a much faster pace and respond much more quickly to rapidly changing customer needs. This in turn gives customers a much better experience and makes them much stickier, which clearly has financial benefits.”
Varadhan says CI/CD can end the crippling financial burden of software. “Banks can make changes in this manner at a fraction of the cost of trying to achieve the same results on legacy systems. And as the innovation becomes frequent, banks can fail fast, fix, improve and this in turn will reduce accumulating technical debt and costs in the longer run.”
And the downsides of CI/CD? “Benefits far outweighs any costs or complications of adopting this methodology,” says Varadhan.
So why is CI/CD so under-used? Regulations are restrictive. Whereas a retail business can experiment with the stack, risking downtime in a worst-case scenario, bank regulators forbid any cavalier behaviour. This means even fintech companies, who promote CI/CD as a practice, are ultra-cautious about its usage.
Mark Holt, chief product and engineering officer at 10x Future Technologies and former CTO at Trainline, says this caution is well founded. “It’s important to recognise that, in business, context is everything,” says Holt. “While in some businesses, continuous production releases – and roll backs where features don’t work – is the best approach, a failing feature in banking just isn’t appropriate. A failing feature being in production for just 30 seconds may be the difference between a customer’s payment success and payment failure, which could mean the difference between them safely getting home that evening or not.”
The answer for 10X is to retain a philosophy of CI/CD, but to delay the release pattern until testing is over and partners are prepared. “Because of this, we balance risk by releasing and testing continuously within our development and test environments, and then perform monthly releases into client banking environments to ensure they have the robustness to deliver for end-customers,” Holt explains.
Human element
Then there’s the human element. The archaic nature of bank software means IT teams may struggle to understand newer practices. Gaetano Ziri, software engineer at Auriga, an Italian provider of bank software, says the human issue is the main reason banks are slow to move to CI/CD. The skills required are so broad. Ziri says a professional will need the ability to manage cloud providers such as Amazon Web Services and Google Cloud: familiarity with software packing tools (.exe, .deb, .rpm, Docker); familiarity with version control tools (Git, Subversion, Mercurial), plus expertise in security tools, code coverage analytical tools and monitoring tools. And that’s before an organisation’s culture is taken into account.
“Many businesses still prefer traditional methodologies when it comes to software development,” says Ziri. “Implementing Continuous Integration means that they would have to retrain their staff and also change existing operations. Most companies want to meet their objectives quickly and may be resistant to change.”
Sometimes banks are just too old to implement effective CI/CD. Varadhan says automated testing may not be possible in spaghetti system tech environments. “Testing modernisation requires access to consistent and quality data to be able to replicate real production-like scenarios,” she says. “Yet in many organisations, data provisioning remains a very manual process, which is both slow and unreliable, and results in out-of-date data.”
Where does that leave banks? CI/CD is clearly the future. Just like Google, Amazon, Uber, Spotify and other tech pioneers, banks will be able to upgrade software bit by bit, element by element. It will make them agile, able to implement even small improvements with the minimum of fuss. Neobanks already enjoy the benefits of CI/CD. Starling Bank, for example, is a major beneficiary.
But larger banks remain behind the curve. They may not have the staff for CI/CD, nor the culture. Regulation precludes rapid adoption or deployment. And the prospect of ripping out spaghetti systems is intimidating.
It’s a valuable issue to understand. Banks want to move on from the era of spaghetti systems. They want to modernise. The desire is never in doubt.
But when customers, partners, and commentators scratch their heads and wonder why banks don’t adopt CI/CD immediately, it’s worth remembering there are good reasons for the gap.
“Spaghetti systems” is a catchy name for a terrible problem. Go backstage at most banks and the tech scenario is usually a tangled mess. Thousands of applications are patched together, with some of the most critical platforms dating back to the 1980s. Cash machines still run Cobol, written in 1959.
This spaghetti leads to disasters. IT teams are terrified of updating ancient applications. Systems go down. Errors creep in. On one occasion the Financial Conduct Authority identified 750,000 customers paying the wrong amount in mortgages – a disaster for those involved. The cost of bank systems is mind-blowing. Bank of America allocated $10bn in a single year to modernise its IT, while JP Morgan spent $11.4bn.
But why are banks stuck with out-of-date software? It's not down to desire. Banks talk a great game about the need to modernise.
