Up!

Risks of keeping legacy systems in use

Sep 24, 2014

Despite continuous progress in software, legacy systems remain in use all over the world. This is true for individual consumers as well as companies, and has various – and obvious – reasons, such as end user familiarity, satisfaction, force of habit or cost control. In case of financial institutions and banks in particular, these legacy systems are often homebrew platforms that may or may not be linked with various third-party platforms.


A Rube Goldberg machine

For large banks in particular, this organically grown software can be a side-effect of continuous acquisitions and mergers that often required ad hoc solutions from IT departments, because each new entity in the ‘mother bank’ brought on board its own software.

While these bridging solutions were undoubtedly creative, years of this approach has made some core banking software systems look like the digital equivalent of a Rube Goldberg machine: a deeply impressive framework that makes a number of relatively mundane tasks incredibly complex. The continued use of legacy systems causes three major challenges that relate to the common ‘sunk cost fallacy’, i.e. the belief “I can’t stop now, otherwise what I’ve invested so far will be lost.” – which is true regardless of whether the investment is stopped or not.

Risks of keeping legacy systems in use


Major challenges in legacy systems

Deep specialization is required to maintain the system. The IT pioneers who originally designed the bank’s core banking system may have already left or are about to leave the company, resulting in a loss of knowledge (which is a risk), or mandating the bank to invest in training employees in a very narrow skill set (which essentially perpetuates the cycle).

Maintaining and updating the system is costly. Apart from the human cost, non-standardized solutions take more time and money to maintain. Adding new modules, product features or simply keeping up with innovations consumer technology (e.g. mobile banking, digital wallets or microcredits) will sometimes consume an exponential amount of resources, putting the bank at a disadvantage vis à vis leaner competitors.

Internal IT logic conflicts with business logic. Things that make sense from an IT point of view may not always jive well with the business logic. For instance, there may be three types of savings accounts that were carried over from acquired banks and that each have their own distinct IT platform. To the business and the consumer, this often causes mystifying issues at the front-end in terms of speed and ease of use.


Transformation, one step at a time

Entirely switching to a new, standardized core banking platform from a third-party specialist is not without risk. Many banks are hesitant to cause disruptions in their regular workflow, making a radical ‘rip and replace’ approach not ideal. That is why a careful, step-by-step approach is the more prudent way forward.

The cross-sector Banking Industry Architecture Network is well aware of these issues, and has put forward a number of ideas that help banks ease their way into such a process. These include mapping out both business and IT needs, filling in functional gaps, decoupling processes that don’t belong together as well as grouping functionalities that should belong together (e.g. a loan cycle). According to business vertical or technology horizontal, the core banking system can then be set up piece by piece, causing minimal risk and minimal disruption, with the end benefit of having a more agile IT system with a lower TCO.

 

David Andrieux, PhD, Sopra Banking Software

Related Events

No related event