Code modernization is essential in transitioning to digital business. Ancient code will have numerous liabilities in integration and in remaining secure. Fundamental to the problem is the fact that languages, programming approaches, and the surrounding IT are all evolving even as the business environment is evolving. This means that programs accumulate technical debt, leading to growing inefficiencies and maintenance costs over time. Continued accumulation of technical debt complicates any conversion effort. Yet, as we move into a future of newly designed smart processes and omnipresent digital interactions, it is certain that radical change and more invasive modernization will be necessary.
It is clear that a general approach is needed that leads both to effective conversion and to meeting the unknown requirements of the future. So, companies that wish to change need to centralize the modernization effort and discover the technologies which will be specifically applicable to the firm. In this context, it is important to consider the ROI of change efforts. Modernization must provide both for the current situation and for the unknown environment of the future.
One of the most persistent problems in modernization is migration of COBOL which exists in millions of lines across critical applications in high accuracy/high-volume areas such as finance and healthcare. These systems are particularly vulnerable as industry evolves to meet complex new requirements from clients and partners. While these systems have often operated for many years, as “black boxes” around which code might be wrapped, this approach eventually must break down. It entails a growing maintenance burden and serious security issues when pathways are built into the code to enable API access to obscure routines. Familiarity with the code base disappears as employees retire, and there is a growing lack of talent and experience in working with older programs.
To make essential changes and build for a digital and interconnected future, there is a range of possible remedies. These include:
- Continuing the black box. Since the software has continued to operate for many years and performed its functions, you can hope that nothing bad will happen and simply continue the maintenance cycle. You will be faced with increasingly expensive maintenance, and potentially serious security flaws as the years drag on. There will also be an opportunity cost as new technologies are increasingly unavailable due to the lack of malleability in access to critical code.
- Off-the-shelf replacement. It is sometimes possible to replace critical programs originally built in-house with commercial software or SaaS solutions. This often requires considerable customization, and will be less flexible. Processes may need to be changed, licensing costs will be incurred and there may be integration issues and unforeseen consequences.
- Greenfield replacement. Starting from scratch demands creating a project of at least the size of the original one. All of the lessons learned in the original coding will be lost, and there are likely to be huge over-runs in time and cost in both adding new features and making certain that critical functions continue to operate as expected.
- Manual conversion. Manual conversion or refactoring of the original system can be a massive project, potentially larger and more expensive than the original system. It is possible to introduce the modernized COBOL languages or move to later generation code. Without the specific knowledge of the original code and access to the programmer’s logic, much of the original functionality can be compromised. Such projects have very poor rates of completion on time and with adequate success. This will also be true of many “lift and shift” efforts which convert and bring the application to the cloud.
- Incremental conversion. Large programs could be split up, with only critical “must change” code subject to conversion. This provides short term benefits, but it also potentially adds to technical debt in the interfaces, and the original code that persists will continue as a potential source of future problems.
- Automated model-based conversion. For some situations, an automated conversion based on modeling can provide a cost effective outcome, depending upon the technology in use. Here, the original code is converted to a semantic model which is then optimized and used to generate code in another language.
Each situation is likely to have different needs, and demand a different solution. This is part of the reason that conversion has become such an intractable problem.
There are numerous companies involved with modernization of code and with bringing older programs into the digital environment—and huge differences, depending upon whether you are looking at a change of platform, a coding conversion, an update, a refactoring, or a rewrite of ancient routines. The most important issue is to determine what the overall modernization requirements are: what is absolutely critical, and what could be reserved for later. Modernization can be very expensive; but it also needs to be correct.