As we move into a new era of computing, it is becoming increasingly clear that legacy systems will need to be replaced. Challenges such as cloud computing, mobility, and the advancement of analytics require fundamental changes in architecture that are not easily supported without a major rewrite or modernization. Yet many of the systems that must be replaced are large, critical and complex and vital to the operation of the enterprise. Code that has been patched and re-patched, accumulating technical debt at every step along the way becomes extremely costly to maintain and makes eventual replacement increasingly daunting.
Eventually, however, replacement must be considered. With maintenance taking up 70 percent or more of IT budgets, there is no real choice. When you do elect to replace your legacy system, however, it is important that you select the right option. There are a number of possibilities that may be considered, each of which has variants, but your choice will affect the cost of your replacement effort, its ROI, and its overall likelihood of success.
Here, we will look at some basic possibilities, and examine their potential cost. They are:
New Application Development. This is the total rewrite option, creating a project to replicate the legacy system with entirely new code. It involves manual development to rationalize the system, use of current coding practices, creation of modern interfaces, and support for current technologies. This is the most expensive option, and is generally only usable as a baseline. The replacement is likely to be at least as expensive as the original project, with a similar risk level to a typical “waterfall” project, and a high likelihood of time and budget overruns.
Extend/Surround. This is the option currently used in many facilities. The legacy system is encapsulated in coding that provided APIs and tack-on integration with other systems. This creates a growing patchwork of code, often in diverse languages, that gradually increases technical debt and incurs added maintenance costs. It defers replacement, but it can be a costly solution in the long run.
COTS/SaaS. Moving to a Common Off-the-Shelf (COTS) solution, or migrating to a Cloud-based SaaS system provide possibilities of moving to a less expensive and more modern architecture, but costs can easily escalate. The new system will require customization, and will entail ongoing costs. There may be ripple effects on other systems, and other costs in conforming to a completely new platform with unknown attributes.
Modernization. Modernization involves careful translation of code to create a new, modern, application based upon the logic and behavior of the original. This may be accomplished with varying degrees of automation, and the result is likely to be the least expensive and least risky of the possibilities described here. Modernization is by far the least disruptive option because it both preserves existing capabilities as well as extends the life of the software assets in which enterprises have made enormous investments.
The Business Process Reengineering manifesto of the early 90’s that called upon enterprises to toss out legacy systems and start over with a “clean slate” in order to reinvent business processes proved disastrous for the many organizations who undertook reengineering projects injudiciously. A series of highly esteemed papers, now known as Lehman’s Laws of Software Evolution, published by Laszlo Belady and Manny Lehman in IEEE and ACM from 1975 through 1996 demonstrated that as legacy systems are continuously adapted to varying requirements and circumstances in their environment they accumulated technical debt over their lifespans due to degradation brought about by unmanaged change. Now canonical research by Martin Fowler, William Griswold and William Opdyke catalogued techniques for remedying many forms of technical debt by means of refactoring.
OMG Series publications by William Ulrich and Philip Newcomb demonstrated that architecture driven modernization that coupled model-based and rule-driven assessment, transformation and refactoring was capable of rapidly evolve and modernize mission-critical legacy systems with high levels of automation, precision and quality. By means of modernization many kinds of technical debt and software weaknesses that make legacy systems vulnerable to cyber threats can be remedied. Establishing a cost comparison for replacing, updating or modernizing legacy applications can be difficult due to the wide variety of situations in which upgrades may be considered. Nonetheless, benchmarks can be developed. A simplified comparison of the three possibilities is provided in Figure 1.
Choice of replacement strategy can affect the length of the project, risk, skills needed for the project and for continued operation, additional customization, technical debt accumulation, maintenance, initial replacement cost (capital budget) and ongoing expense of the system. These items all incur cost that needs to be considered in the system replacement business case.
Modernization tends to be significantly less costly than other options across a variety of indicators. This is borne out by reports such as The Standish Group’s Modernization study , which concluded that, while 52% of modernization projects showed a high ROI, only 34% of package application projects (COTS) did, and only 11% of new application projects did. Overall, modernization had the lowest cost with the highest return.
Looking further at modernization, a more automated approach is likely to be less expensive than a manual approach—particularly if automation is backed with expertise and based on a modeling system that reduces risk. TSRI has developed a unique and trusted approach to modernization. It uses a bullet-proof process and intermediary models to extract logic and make it available to other languages. Once logic has been extracted, transformation to new languages, refactoring, and code optimization ensure that the final system is modern and bug free, but performs without risk according to the same logic as the replaced application.