Despite the rapid advancement of technology over the last few decades, many businesses and institutions continue to run on legacy systems developed thirty, forty or even fifty years ago. Due to the size, complexity and importance of these systems, the costs and risks involved in replacing them are huge. While they continue to do their jobs, the potential benefits of updating them may not outweigh the potential costs and risks.
A big issue with these aging systems, however, is that experts that understand them and the languages they run on are becoming increasingly rare. While in many cases legacy systems are still the best tool for the job, they require updates and maintenance when issues occur. The number of people able to do this is shrinking as the developers who built and ran these systems retire and fewer younger developers learn the languages they were built on, leaving a significant skills gap.
One example of a language that is heavily relied upon by legacy systems is COBOL (Common Business-Oriented Language). Although it is over fifty years old, 43% of banking systems currently in use were built on COBOL and it remains crucial to businesses and institutions around the world. 80% of in-person transactions and 95% of ATM swipes use COBOL and it is used for 70-80% of all UK business transactions. With 220 billion lines of COBOL code running well internationally, the incentive to change systems is low.
The challenge of finding people who can still use these systems, or are willing to learn how, is an important one. Many banks are hiring contractors or keeping networks of ex-employees who are often paid large amounts by the hour to upgrade or troubleshoot these systems. They are willing to pay because these costs are nothing compared to what would be needed for an upgrade. Although this may work for now, it is not a sustainable solution.
There are other ways that institutions can manage this:
1. Training new developers on old languages.
IBM, who supply the mainframe computers that run on COBOL, have been proactive in training young developers on the language. However, this may not be enough as systems can vary wildly and most of the early developers did not write user guides or handbooks. Having older developers teach their successors how to manage legacy systems and creating a handbook for the future could help to make this more sustainable.
2. Planning ahead.
One day the costs and risks involved in maintaining legacy systems will outweigh the risks and costs of a replacement. Predicting when that time will come and preparing for it is essential for enterprises that don't want to be taken by surprise. Budgets can be an issue here as IT budgets are usually split between keeping everything running and investments in new innovations. Big spending on an infrastructure overhaul could mean less discretionary spending elsewhere, but it will become necessary sooner or later.
Banks are increasingly working with startups and emerging technology companies to deliver parts of their value chains. With the ability to move to more loosely coupled architectures this becomes more and more attractive.
If it is not possible to move off of legacy platforms entirely in the near future, enterprises will need to focus on retaining people who can use them for longer and encouraging young developers to learn these older languages. These systems are not going away immediately but businesses need to be ready for a time when the risks of keeping them will outweigh the benefits.
Share this post:
Operational resilience /
Maintaining Operational Resilience at pace white paper