First: what is technical debt? What is security debt?
The phrase “technical debt” has evolved since it was first described in software development thirty years ago. Initially, it referred to a shortcut or cut-corner to expedite a usable – but imperfect – product. The idea was that it was saving time and/or costs in the short-term, but would need to be overcome (“repaid”) before further upgrades could be made.
Now, its meaning has expanded to describe the situation of using continually depreciating legacy technology. Many financial organisations are currently using core platforms that rely on 30-40 year old architecture – being regularly updated and maintained, but never completely replaced. Now, they are no longer the best fit for the purpose; there is only so much patching and working around them that can be done without compromising the overall integrity of the software.
This is also where security debt comes in – the compromises to data security that come hand-in-hand with technical debt and legacy systems.
Why do financial institutions need to address their technical debt?
Overcoming technical debt – and the corresponding security debt – in a core platform is one of the most pressing challenges financial companies face. But why is this the case if legacy core banking platforms have been reliable enough to date?
In some ways, it is this in-built reliability of these platforms that produces this current demand. These financial systems were created to prioritise stability and security over speed – but today’s market demands real time processing, frequent feature launches and quick partnership with emerging fintech.
As technology evolves, we’re approaching a point where those legacy systems are no longer sustainable. We have to move away from some of those legacy architectures and remove that technical and security debt so you can have a sustainable platform moving into the future.
IBM Global CTO for Financial Services John Duigenan said, “It’s not that banks want to be stuck in the past. They clearly don’t – clients are demanding they offer modern services; competitors are disrupting them left and right.”
As for the developing urgency to upgrade? He said, “The reason banks often do nothing to address [the technical debt] is they convince themselves that they have to rewrite a 40-year-old program, and then they’re looking at a hundred-million-dollar price tag. So they kick the can down the road. But the longer the debt persists, the greater the consequences. Banks get less agile, less able to innovate code. They become more vulnerable to cybersecurity breaches. Addressing those breaches can drain the development budget, so that all the firm can afford to do is fix emergencies rather than deliver new capabilities, entrenching it in a vicious cycle…”
If your organisation is yet to begin a strategy to overcome the technical debts in your platform and safeguard for the future, now is most certainly the time – before you’re caught out with a platform with more debt than it can hold.
How to let go of technical debt and modernise your core banking platform
Modernising your core banking platform is no small task. It will not be a quick fix – we liken it to undertaking a total renovation on a house… without the tenants inside (i.e. your customers) noticing until they are in a refurbished home. To modernise without interrupting operation, plan for the initiative to span several years with a number of interim states along the way.
9Yards consultants are experienced in supporting financial institutions through major core platform upgrades. The process typically includes:
- Recording an accurate depiction of the current state of your organisation’s platform: The state of legacy platforms can be a point of contention amongst teams. Feelings of frustration or defensiveness can cloud internal views of the actual current reality. Having an external, objective perspective to determine what you’re working with is an important first step.
- Defining the target state and interim states: Knowing precisely what you are working towards keeps the initiative on track, in scope and scaffolds the direction of work. By also determining interim states, your organisation can not only begin benefitting from parts of the work sooner – it also keeps morale and therefore momentum buoyed. While there’s no such thing as a fully future-proof solution, we recommend composable platforms that will be more straightforward to update when the time next comes.
- Developing a roadmap: A roadmap is not only a guidebook outlining exactly how to execute the entire transformation, it also acts as a business case. It provides confidence to anybody reading it that this approach is appropriate, calculated and justified. There’s no unrealistic expectations on anybody, it’s very clear what will be delivered by whom, when, and at what cost.
To see this approach in action, read our case study: Moving forward from legacy software with HAMBS. If you’re ready to see how overcoming technical debt and modernising your core banking platform could look in your organisation, please get in touch with our team today.
