Minimizing problems in legacy software
The financial services industry is evolving at an exponential rate in this age of digital transformation. Shifting customer expectations, disruptive technology and demanding regulatory requirements are constantly reshaping the sector. Many banks are finding that their current infrastructure and platforms are simply not capable of supporting the proliferation of user-centric, omnichannel and omnipresent capabilities that customers have come to expect from interacting with consumer-friendly software and applications from internet giants like Apple and Google.
Banks know that they have to evolve their software platforms if they are going to survive in a sector where consumers want to seamlessly manage their money and other financial services from any device, especially when challenger banks are offering consumer-friendly platforms that are disrupting established ways of thinking. However, one often overlooked and hidden cost of this platform modernization agenda is that of “technical debt.” This debt is the additional and often hidden cost of enhancement or maintenance of software platforms attributable to structural problems that have been introduced into the software over time.
Technical debt generally relates to how the software has been designed and built, rather than to functional or performance defects, and it typically crystallizes at the point where software needs to be updated. Technical debt can be a significant cost component, sometimes more than the cost of any functional changes required, and it can explain why what seems like a relatively simple functional change can become so expensive.
Many banks and other financial institutions allow technical debt to accrue because they are reluctant to fully upgrade legacy systems and risk introducing defects; they would rather just leave things running as they always have done and make limited changes to address specific needs. But at some point, they will need to address accrued technical debt and its associated costs when contemplating digital enhancements aimed at driving growth and achieving business objectives. The longer they avoid doing so, the larger the cost of this technical debt becomes.
In order to help banking and financial services teams understand technical debt and minimize the total cost of ownership of software, it’s worth looking at three distinct stages of technical debt occurrence:
New software development. New software development often takes place in a commercially-demanding environment, where quality can take third place after cost and time. Software is often created as a minimum viable product (MVP) to serve as a pilot system to deliver baseline capabilities. During development, many options are usually explored and the code may be written in haste.
MVPs can be a very productive approach, as they encourage innovation to flourish. However, sometimes they are developed in a manner that doesn’t comply with development standards, such as going through a design review or adhering to naming conventions, and this isn’t best practice. There is often some work still to be done to refactor the code, tidy it up and make it the foundation for subsequent development. It is also important to capture all the design decisions that were made, so as to aid subsequent development.
At this stage, the technical debt is the difference between the cost incurred to deliver the project such that the functionality works and the additional cost required to complete the project so that subsequent enhancements can easily be made at a later date. Normally, a lack of budget prevents the technical debt from being addressed, which leads to problems in the future.
While later stages of debt are more likely to be encountered, this explains the creation of the original debt.
Ongoing software maintenance. Once software has been deployed to production, it usually needs to be maintained to keep track of evolving third-party interfaces, protocols, standards and other dependencies. Some of these updates are mandatory, such as changes due to regulatory compliance. This can require parts of the software to be enhanced, extended, refactored or rewritten. But often, the people charged with making these changes may not be that familiar with the code they are changing. Frequently, the original code (or most probably a subsequent iteration) incorporates functionality that has likely been subsequently replicated (normally through a “cut-and-paste” type copy) rather than re-used and adjusted based on the current context.
All of this leads to complications when upgrading software. Subsequent updates may be made without an understanding of the original design, which can add unnecessary complexity that itself needs to be maintained. In addition, inappropriate customizations are often made to the code that then makes it harder to upgrade at a later date. This increases the cost and time to maintain and enhance the code.
Legacy software maintenance. These days, most enterprise software is created by large teams, with sharing of knowledge acquisition and transfer spread across a team. Decades previously, when legacy systems were being designed, the nature of software engineering was very different. Software was created in now-antiquated languages by very small teams and sometimes even by individuals. These people were responsible for designing, developing, testing and releasing their code and were familiar with all aspects of the development lifecycle. This included an innate knowledge of the build process, build tools and scripts, deployment environments and supplementary information. Many of the original team members may have left an organization – taking with them their knowledge – or simply forgotten how software they created 20 years ago actually worked and was built.
This is a common problem that results in the software having to be treated as a “black box,” viewed and analyzed as a closed system in terms of its inputs and outputs. This means that when updates do need to be made, they can be expensive, both in terms of finding people with the requisite skills and in making and testing changes to avoid causing issues in other parts of the software.
Another challenge with legacy code is that while processes and tools have been created for more modern software languages to analyze non-compliance or bad practice at the source code level, the tools simply do not exist for many legacy programming languages. These processes were not deemed important at the time and so associated tools were never created.
So, how should banking and financial institutions tackle the issue of technical debt? Established software engineering metrics can be used to analyze it, including the “Maintainability Index,” normally calculated from lines of code measures, and “Cyclomatic Complexity,” which looks at the number of linearly independent paths through the source code, as well as statistical measures.
While technical debt may not seem, on the surface, to be a major problem, it accrues and compounds over time so that maintenance and updates to software become vastly more complex and costly than they need to be. Technical debt can end up as the major cost component in any modernization initiative, and without it being addressed, can impact each subsequent modernization program. Technical debt should be minimized throughout the software lifecycle as the nature of technical debt changes over the lifetime of a software platform. Putting strategies in place to remediate this debt can also help ensure that the cost remains low in the future as well.