COMMENT: Technology jobs in banks, and the legacy-code problem
If you're a technologist who doesn't want to work in an investment bank, I suspect I know why. You will have heard about the horrors of legacy code. Much has been written. Not all is true.
I've spent my entire career working in banking tech at large U.S. banks. Most of the code I see is unit tested, peer reviewed, part of a continuous integration mechanism and relatively easy to deploy. The quality of individual applications is improving. But the legacy code still lurks beneath.
Why is legacy code such an issue for banks?
To understand why banks have a legacy code problem, you first need to understand how they're structured.
The technology departments of banks are typically now the largest contributors to headcount. For example, 25% of people at Goldman Sachs are engineers and JP Morgan has 50,000 people working in its technology function.
This means that JPMorgan's technology team is larger than Facebook and Uber's combined. However, there's a huge difference between the problems technologists work on at Facebook/Uber and the problems technologists work on at investment banks.
At a Facebook or Uber you'll be working on problems that are simple functionally but hard technically. By comparison, at a bank, the problems are more likely to be simple technically but extremely hard functionally. Most banks have thousands of developers organised in silos, each trying to solve functionally hard problems. Historically, this was a recipe for disparate and brittle systems.
One way to think about the legacy system in issue in banks is to track a single trade booked by a big bank. The number of systems and applications it touches over the course of its lifecycle is astounding. That trade will be modelled innumerable times for different purposes, with feeds going all over the place. - If you tried to produce a diagram to represent it, it would look like a piece of abstract art. The interconnectedness, coupling and organisational complexity involved in these linkages and systems makes things brittle and very difficult to change. Therefore, if you have a legacy application you want to uplift, it can lead to a butterfly effect of changes across the bank.
The extent of the legacy systems problem in banks is illustrated by what happened when UK bank TSB tried to merge records and accounts from systems originating with Lloyds Bank Group with systems at their new owner Sabadell. - The resulting chaos led to a 4% fall in Sabadell's share price.
Not only is major change difficult, it’s financially and operationally risky.
Banks can't just close their legacy applications
Problems are worsened by the fact that banks can't just close these legacy applications.
Google recently made the decision to shut down Google+. An entire product and ecosystem just brushed under the carpet - the code no longer needing any maintenance. This is the sort of luxury that banking tech teams do not have. Most systems at banks are built to automate some internal business process, and that will usually be a long-lived thing. Ripping out and retiring systems is very costly and it’s often a case of if it isn’t broken, don’t fix it. This is why you see decades old systems, COBOL, and other ancient mainframe technologies lying around doing their thing.
It doesn't help that banks are frequently run by former traders and investment bankers, who aren’t going to invest in renewing technology over a number of years with no immediate return on that investment.
Legacy systems are a political issue
The legacy systems issue isn't helped by the endless churn of technologists at banks. I’ve seen large applications built out by front office teams (supporting traders or bankers) in London and New York, with a successful rollout, only for the team to then be reorganised or disbanded and the application is handed over to some other team in India, with little to no knowledge share.
It's a particular problem when senior technologists - technology MDs leave banks. The new replacement has their own ideas leading to the applications or platforms already developed being left out in the cold.
How banks are trying to reduce legacy systems (and make their tech jobs more interesting)
Believe me, banks know their legacy code is a big turn-off when it comes to hiring technologists. - No one wants to be staffed on a system with hundreds of baffling and dated dependencies.
JPMorgan is ahead of the curve on this. The bank has been through a relatively successful programme called "Kill the Tail." This was a technology division-wide effort to identify and remove old applications if they were no longer needed, or to re-engineer their functionality into newer strategic platforms and then remove them.
Deutsche Bank has done a similar thing on various parts of their plant and it is already paying dividends. It's proof that rationalising your suite of applications and infrastructure can save you lots of money in the long run.
Personally, I think that Conway’s law applies: "Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”. Bank CEOs might like to say they are technology companies, but until the way a bank is organised and operates is fundamentally changed then they are doomed to continue producing incredibly complex systems.
If I were a bank CEO, I would acquire one of the challenger digital banks to see how to model and organise a retail bank from the ground up and tailor it to the needs of a larger customer and product base....
Sam Garrett is the pseudonym of a developer working for a bank in London.
Have a confidential story, tip, or comment you’d like to share? Contact: sbutcher@efinancialcareers.com in the first instance. Whatsapp/Signal/Telegram also available.
Bear with us if you leave a comment at the bottom of this article: all our comments are moderated by human beings. Sometimes these humans might be asleep, or away from their desks, so it may take a while for your comment to appear. Eventually it will – unless it’s offensive or libelous (in which case it won’t.)
