Software must evolve to remain useful. According to the first law of M.M. Lehman, a renowned software evolution researcher, “A large program that is used undergoes continuing change or becomes progressively less useful.”¹ Lehman states in his second law that “As a large program is continuously changed, its complexity, which reflects deteriorating structure, increases unless work is done to maintain or reduce it.”² Years of accumulated code changes lead to less maintainable code. Many organizations that depend on legacy systems are struggling with how to modernize those systems, but are unable to adequately address the potential risks. A new book on risk-managed modernization provides the needed guidance.

Modernizing Legacy Systems: Software Technology, Engineering Processes and Business Practices, to be published in February by Addison-Wesley, was written by Robert Seacord, Dan Plakosh, and Grace Lewis, members of the SEI technical staff. The book introduces a legacy-system modernization approach that accounts for both software technology and business objectives. The book describes engineering processes and business efforts that can be used in planning, justifying, and executing the modernization effort.

 

The Legacy Crisis

The book meets the need for an effective modernization approach. The Standish Group reported that 23% of software and information-technology projects were cancelled before completion, while only 28% finished on time and budget with expected functionality.³ Because of the huge growth in computers for business process support, an estimated 250 billion lines of source code are being maintained, and that number is increasing.⁴ The relative cost for maintaining software and managing its evolution now represents more than 90% of its total cost. If trends continue, eventually no resources will be left to develop new systems. Seacord and his co-authors refer to this as the legacy crisis.

Legacy systems evolve through maintenance, replacement, or modernization. Maintenance can effect only limited change. Modernization can be a cost-effective option to replacement. However, modernizing software is daunting in that it requires careful analysis of options, stakeholder interests, and multi-faceted tradeoffs, including technical, programmatic, and organizational considerations.

Risk-Managed Modernization

Typically, development teams approach large modernization efforts either with trepidation and misgivings or with unwarranted self-confidence. “The former group is usually the one with the most experience,” says Seacord. “Fortunately, there is a middle road, which is to approach the modernization with respect for the magnitude of the effort and a plan.” This plan must incorporate an understanding of the legacy-system technologies, engineering processes, and business requirements. Finally, this plan must manage risk throughout the modernization effort.

This approach is introduced in the book as risk-managed modernization (RMM). RMM integrates software engineering concepts with an organized understanding of the information- systems technologies that define the range of possible solutions. The approach integrates risk management at every step—continuously assessing what can go wrong, determining what risks are important, and implementing strategies to deal with those risks.

The book shows how legacy systems can be incrementally modernized. It uses and extends the methods and techniques described in the book Building Systems from Commercial Components⁵ to draw upon engineering expertise early in the conceptual phase to ensure realistic and comprehensive planning. The book features an extensive case study involving a major modernization effort. The legacy system in the case study consists of nearly 2 million lines of COBOL code developed over 30 years. The system is being replaced with a modern system based on the Java 2 Enterprise Edition (J2EE) architecture. Additional challenges include a requirement to incrementally develop and deploy the system.

 

Finding a Better Way

The authors also emphasize the importance of creativity and innovation in addition to process. It is crucial, they write, to find a better way of doing things rather than trying to improve the way things have been done in the past. Many modernization efforts simply replace old legacy code with new legacy code. While this approach extends the useful lifetime of the legacy systems, it often results in re-codifying existing, outdated business practices. When deciding how aggressively to approach a modernization effort, consider when the next opportunity to modernize will come along, the authors suggest. On the other hand, being too aggressive in modernization plans means increasing risks that could lead to project failure. Therefore, plans must be well considered and plausible. “In our experience,” the authors state, “the best ideas actually reduce overall risk while providing needed capabilities.” Finding a “better way” may mean ignoring the existing system and processes and considering the underlying principles instead. This may provide a clearer vision of goals and allow streamlining of system and processes to this vision.

In his review of Modernizing Legacy Systems, M. M. Lehman asserted that the book provides needed guidance where very little exists. “I recommend it as a must for people directly involved in legacy system modernization, whether as customers and resource providers or as implementers. . . [It] should also be of significant interest to those who seek a better understanding of the evolution and legacy phenomena, and given the current. . . reliance on computers, that means all of us.”

For more information, contact—

Robert Seacord

Phone
412-268-7608

Email
rcs@sei.cmu.edu

World Wide Web
http://www.sei.cmu.edu/cbs/mls/