"If you take the conventional approach, your failure and overrun rate will be no better than for other conventional projects, and it may well be worse."

Opening Statement

In my experience, the primary reason organizations wish to modernize their applications is technical debt, though it is rarely expressed that way. But this is not necessarily technical debt as described in the October 2010 issue (Vol. 23, No. 10) of this journal. I calculated it like this for three of our firm's clients in the last year:

• When it takes 25 programmers to maintain a system when five could do the job, the technical debt is an expense item: 20 x $100,000 per year.

• When it will take $5 million to modernize the system so that five could do the job, the technical debt can be reduced by an investment that will be paid back in two and a half years.

• When the enterprise loses a $100 million/year business opportunity because it will take 18 months to make the necessary software changes, the technical debt is an opportunity cost of $100 million/year, and the payback for a modernization investment that would allow the necessary software changes within the opportunity's time horizon would be about two and a half weeks.

• When the application is sited on a mainframe that costs $20 million/year and could reasonably be rehosted to a Linux/Unix/Windows platform that would cost $1 million/year, the technical debt is an operational expense of $19 million/year, and the payback for the investment would be about three months.

When incremental refactoring will not solve your problem or will cost too much, then you will have to contemplate a major investment in your application. If you choose a conventional redesign and rewrite approach, you will take a blank piece of paper, gather requirements just as for a wholly new system, and go build a completely new system from the requirements and detailed specifications. However, if you take this conventional approach, your failure and overrun rate will be no better than for other conventional projects, and it may well be worse. On the other hand, there are alternative paths to modernization that reduce that risk to near zero, usually saving money in the process. Alternatives to a top-down redesign/rewrite fall into three main areas:

1. Modernization by preservation of legacy code in some form (wrapping, rehosting, or code translation)

2. Modernization by preservation of legacy functionality in new code (package solutions, rearchitecting, or a pure rewrite)

3. Rationalization of legacy functionality with a bottom-up rebuild (either internal or external rationalization)

Cost control during a period of economic stress and fear of the risks of a conventional project are driving serious consideration of these alternatives.

THE SPECIFICATION PROBLEM

The essential complexity of legacy system functionality is almost universally underestimated, especially for medium to large applications, which are our primary focus. Hidden in all that spaghetti code are solutions to specific business cases that have been long forgotten but are still needed. It is not possible to create a waterfall specification or an agile storyboard if no one understands what the existing system does in sufficient detail.

The one spectacularly positive feature of legacy modernization projects is that -- at the beginning of the project -- we have a 100% complete and 100% correct specification of the old system functionality: the legacy system source code. All we have to do is to replicate that functionality precisely, and we cannot have a project failure.

This is an absolutely crucial point and one that needs to be made over and over again: replicate first, then enhance. If you take nothing else away from this issue of Cutter IT Journal, take this lesson to heart: allowing any business functionality changes is almost always the ultimate reason for failure and cost overruns in a modernization project. By and large, technicians hate this recommendation, but the technicians will usually still have a job after a project failure.

If you accept any changes in business functionality, then you have no way of knowing, once you start testing, whether the discrepancies you find are defects in the modernization or problems in the modified code and/ or modified requirements. How can you tell? This seems minor, but it is the rock upon which projects founder.

MODERNIZATION ALTERNATIVES

What are the alternative options for modernizing and rationalizing your applications? Our authors discuss different aspects of the following approaches:

Modernization

Code Preservation Strategies

• Do nothing is the most popular "strategy."

• Wrapping extends your otherwise untouched application with products to allow a new user interface and/or external access to legacy data.

• Rehosting entails changing platforms, primarily mainframe COBOL/CICS to open systems, focusing on use of emulation products to minimize or eliminate any changes in the code base.

• Code translation (aka conversion or migration) is an automated process of modifying the existing source code base into a new language and/or to fit a new database and/or transaction processing interface.

Functionality Preservation Strategies

• Rearchitecting is a tool-assisted, semiautomated process of extracting the data model, transactions, and business logic from a legacy system and reimplementing the business functionality in a modern framework.

• A rewrite is a manual version of rearchitecting without significant tool assistance. It may include methodological improvements that are not specifically tool-oriented.

• COTS/GOTS is a commercial or government off-the-shelf application that is configured and/or modified to provide a replacement solution.

Rationalization

• Internal rationalization rebuilds an existing application in a substantially simplified form but without changing the business functionality. The distinction between internal rationalization and rearchitecting/ rewrite approaches is that the formal complexity of the rationalized application is orders of magnitude lower than the result of either rearchitecting or rewrite projects, yet it has the same functionality.

• External rationalization merges the business functionality of two or more applications containing both overlapping and disjoint functionality.

The code preservation strategies do not fully solve the business problems that are the most frequent impetus for modernization: the ever-greater cost of maintenance and the lack of flexibility and agility. All four approaches are tactical and inevitably short-term in their outlook. They are not solutions -- they are postponements. Not that this is a criticism; sometimes one of these strategies is the right decision. It may be the full extent of your response, or it may be one step in a multistep solution. In some cases, code preservation approaches may be all that you can afford in money and time. They must be considered among the strategies, but we will not spend much time on them.

The functionality preservation strategies are more strategic solutions for legacy modernization. Rearchitecting may be a new term to many, but it is a more cost-effective way of performing a rewrite that applies tools to harvest as much of value as possible from the legacy system. My associates and I have seen increasing interest in this approach over the last few years. One of our authors, Tom Bragg, focuses on this strategy.

Two sets of coauthors -- Tom Love and John Wooten and Matthew Simons and Jonny LeRoy -- take a completely different position. Rather than apply tools, they adopt different methodological approaches to a rewrite that will improve the yield. This is extremely interesting, because an organization could adopt one of their methodologies and perform the modernization with internal resources, doing without an outside vendor.

The GOTS/COTS approach to functionality preservation must start with a legacy discovery phase, just as both rearchitecting and the rewrite methodologies. However, once the business logic has been derived -- a process frequently referred to as business rule extraction -- that business logic is used to configure and/or modify the package to provide equivalent functionality. There is no escaping the need to discover all the details of the legacy functionality -- unless you are willing to change your business processes to match the package.

Rationalization, particularly internal rationalization, will be a new term to most people, but it is where some of the most interesting and innovative work is being done. One could think of it as modeling the functionality of the legacy application, but with executable models. This is a crucial distinction from legacy discovery and documentation projects, such as UML modeling of an existing system, because the models can be tested against the functionality of the legacy system. If the functionality is identical, then you have proven your model to be correct. By using code coverage techniques on the legacy application in conjunction with the functionality testing, then you have proven your model to be both correct and complete.

The implications of this are extremely far-reaching insofar as legacy modernization is concerned, because the difference between being almost correct and actually correct is the difference between failure and success. The downstream potential for cost reduction and increases in flexibility are perhaps even more important. But these approaches are very new, and we have a lot to learn about them.

External rationalization is one of the most difficult projects to undertake using any methodology, but adopting some of the tools and methodologies of internal rationalization can bring an almost intractable problem under control.

IN THIS ISSUE

Since testing is where we discover that our projects are going wrong, it is fitting to start with testing to help avoid that fate. In the first article, Richard Bender discusses testing in a modernization project, providing real-world examples of why you must have a phase 0 that delivers only replicated functionality and then a phase 1 that delivers any desired enhancements.

If you are going to undertake a modernization project, you first need to get your arms around the problem. Corby James presents a methodology for sorting out a portfolio of applications and providing a prioritization of applications to be modernized or perhaps left in place.

Lawrence Fitzpatrick takes this analysis deeper, reminding us that we must understand systems to be modernized as part of an integrated whole, taking into account the complexities of the interdependencies between the business and IT. He then walks us through 10 best practices to drive success in legacy replacement projects.

Next, Tom Love and John Wooten present an agile approach to rewriting legacy applications that their firm has successfully applied to many projects. They discuss one 11 million LOC project in detail. What is particularly interesting is that some aspects of the target solution were highly rule-based. As a result, the complexity of the application was sharply reduced and its flexibility was markedly enhanced, so that the process was arguably closer to internal rationalization than to rearchitecting. A particularly nice example of the impact on flexibility is illustrated by an incident that could have had a major impact on a more conventional project but had zero impact on their project.

"Creaky platforms" are the subject of our next article, by Matthew Simons and Jonny LeRoy. The authors describe a number of metrics visualization methods that can help organizations determine exactly where their problems are, prompt management to take action, and drive the remediation efforts. They advocate an incremental approach to legacy system replacement, describing their use of Martin Fowler's "strangler application" in successful rewrite projects.

In our next article, Tom Bragg compares and contrasts code translation with rearchitecting and manual rewrites. Taking a procedural language, such as COBOL or C, and translating it to an object-oriented (OO) language, such as Java or C#, will give you programs that execute correctly, but they won't otherwise look much like OO programs. Code translation is relatively cheap and solves a short-term tactical problem, but it does little if anything to help the long-term strategic problems of application maintenance cost and flexibility -- in fact, it may make them worse. Rearchitecting, by contrast, is a semiautomated approach that will reproduce your business functionality, essentially creating the equivalent of a pure rewrite but better/faster/cheaper. Crucially, it produces properly implemented OO programs, so maintenance costs and application flexibility do improve significantly. While rearchitecting costs more than code translation, it is still less than a redesign/rewrite project -- arguably much less.

In our last and perhaps most thought-provoking article, Michel Vanden Bossche and Ian MacLarty introduce us to the Semantic Web and a completely different way of conceptualizing applications -- all applications, not just Web applications, and truly new applications as well as legacy applications. Indeed, the Semantic Web could be the paradigm that replaces the OO programming paradigm.

The authors discuss the limitations of UML in fully describing a system and the practical solution offered by the latest W3C standards OWL and SWRL, which in conjunction with RDF enable a 100% description of a system in a much, much more compact way than I could have imagined possible. A few thousand lines of OWL and SWRL can fully express a model that would require millions of lines of Java or C# to express and can be changed in a tiny fraction of the time it would take in a conventional language. These new concepts promise to carry us beyond OO languages and relational databases into a new world in which the complexity of implementation will never exceed the essential complexity of the business problem to be solved. This is internal application rationalization applied directly to the source of the issue that made "legacy" synonymous with "problem." Indeed, this rationalization solution should be -- knock wood -- the end of legacy as a problem.

So where does that leave us? Our goal has been to provide some exposure to the alternatives available to any enterprise seeking to modernize its legacy applications, even if those applications are only a few years old. We wanted to introduce rearchitecting, rewrite methodologies, and both types of rationalization into the vocabulary of legacy solutions, which usually limits the choices to code translation and redesign/rewrite.

You have options. Explore them before spending pots of money on something that may not work or may not be what you thought you were getting.

ABOUT THE AUTHOR