NEWS AT SEI
This article was originally published in News at SEI on: December 1, 2002
The knowledge embodied in legacy systems represents a significant corporate asset. Managing long-term software evolution is critical, because systems cannot be easily replaced.
The concept of software evolution has existed for some time, as the following transcript of a talk by J.I. Schwartz at the second NATO Software Engineering Conference held in 1969 indicates:
Managers must be willing to adapt as situations arise requiring changes in scope or technique. The basic system must, through such means as data description divorced from procedures, centralized data maintenance, and data-independent programming languages, be flexible enough to permit change and evolution without reprogramming. People must be flexible enough to tolerate rather drastic changes in direction [Buxton 70].
Developing evolvable systems adds costs to the initial development cycle [Sommerville 00]. Managers, already constrained by unrealistic budgets and schedules, are forced to cut time and budget by de-emphasizing evolvability. Re-engineering existing systems to improve evolvability uses time and resources without repairing specific defects or deploying new functionality, making it a hard idea to sell to management. The cumulative consequences of near-term management decisions have had a debilitating effect on multinational companies, all levels of government organizations, and even a sizable part of smaller organizations [Brodie 95].
For large enterprise systems, a strategy of design for evolvability is a necessity. This approach does not distinguish between development and maintenance; maintenance is simply continued product development. A common practice has been to engage a large development team for several years, followed by years of maintenance by an inadequately small team, followed by a major effort to replace the system. An alternative and potentially more practical approach is to keep an adequately sized development team in place to constantly evolve and maintain the software in a sustainable manner.
Before systems can be evolved, they must be evolvable. Transforming legacy systems to the point where evolvable software development again makes sense is accomplished through legacy system modernization.
COTS and Legacy Systems
Systems are made up of many different types of components:
- commercial components: commercial off-the-shelf (COTS) products
- open-source components: community-developed and maintained software
- reuse libraries: corporate assets developed by other groups
- legacy components: recovered, reusable assets
- custom code: components developed for the current system
Similar to commercial components, legacy components may be treated as “black-box” components because the source code is not available or because of the inscrutability of the legacy source code. Black-box modernization involves examining the inputs and outputs of a legacy system, within an operating context, to understand the system interfaces.
Black-box modernization is often based on wrapping—surrounding the legacy system with a software layer that hides the unwanted complexity of the old system and exports a modern interface. Wrapping removes mismatches between the interface exported by a software artifact and the interfaces required by current integration practices [Wallnau 97, Shaw 95]. Ideally, wrapping is a black-box reengineering task, because only the legacy interface is analyzed and the legacy system internals are ignored. Unfortunately, this solution is not always practical, and often requires understanding the software module’s internals using white-box techniques [Plakosh 99].
Software modernization efforts may also replace existing legacy code with COTS components. While replacing code that you own with code that you must license may seem counter-intuitive, there are numerous reasons to attempt it. Replacing legacy code with commercial components typically reduces the amount of source code that must be maintained. When building a business case for this type of modernization effort, it is important to consider not only the savings of not having to maintain code, but also the cost of extracting the legacy code, the amount of glue code that must be developed (and maintained), and any additional licensing and training costs.
The COTS-Based Systems initiative at the SEI has long followed a spiral model of customer engagements, where we work with customers to solve problems related to their COTS products. From these engagements, in which we apply known techniques, we discover new techniques and practices and expand and perfect existing ones. Recently, customer engagements have been formalized in the SEI’s strategic approach to achieving its mission to “create, apply, and amplify”).
Many, if not all, CBS initiative engagements over the past several years have been with customers that are modernizing or replacing legacy systems. Through these customer engagements we have developed and refined a risk-managed modernization (RMM) approach to modernizing legacy systems. This approach is documented in a new book in the SEI Series in Software Engineering, Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices [Seacord 03].
Risk management is a software engineering practice that continuously assesses what can go wrong (risks), determines what risks are important, and implements strategies to deal with those risks. Risk management is not a new idea; it is an integral element of the spiral development process developed by Barry Boehm [Boehm 88] and is documented in the SEI’s Continuous Risk Management Guidebook and a large body of related work [Boehm 91, Karolak 96, Higuera 96].
The objective of the RMM approach is effective risk management and mitigation leading to the development of a modernization plan that minimizes the risk of the modernization effort. The creation of this plan requires the application of a wide range of software engineering methods and techniques, as well as detailed understanding of legacy and modern technologies.
Figure 1 illustrates a UMLactivity diagram of the RMM approach. Ovals in the diagram represent activities. Arrows represent transition between activities. The horizontal synchronization bars require completion of the previous activities before starting new ones. The process starts with a project for modernization that has been selected using portfolio analysis. The end state for the process is an integrated modernization plan.
Figure 1 Risk-managed modernization approach
Software modernization requires carefully analyzing candidate modernization options and strategies that affect the interests of many stakeholders. As a result, software modernization requires making non-trivial and non-obvious tradeoffs. These tradeoffs are multi-faceted and include technical, programmatic, and organizational considerations that may strain an organization’s decision-making abilities.
Boehm, B. “A Spiral Model of Software Development and Enhancement.” Computer (May 1988): 61-72
Boehm, B. W. “Software Risk Management: Principles and Practices.” IEEE Software 8, 1 (January 1991): 32-41
Brodie, M. L. and Stonebraker, M. Migrating Legacy Systems: Gateways, Interfaces and the Incremental Approach (Morgan Kaufmann Series in Data Management Systems) (ISBN: 1558603301). Morgan Kaufmann Publishers, March 1995
Buxton, J. N. & Randell, B. “Software Engineering Techniques.” Proceedings of the NATO Software Engineering Conference. Rome, Italy, April 1970.
Higuera, Ronald P. and Haimes, Yacov Y. Software Risk Management(CMU/SEI-96-TR-012). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, June 1996.
Karolak, D. W. Software Engineering Risk Management. Los Alamitos, CA: IEEE Computer Society Press, 1996.
Plakosh, Daniel; Hissam, Scott; and Wallnau, Kurt. Into the Black Box: A Case Study in Obtaining Visibility into Commercial Software (CMU/SEI-99-TN-010). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1999.
Seacord, Robert; Plakosh, Daniel; and Lewis, Grace. Modernizing Legacy Systems: Software Technologies, Engineering Processes and Business Practices.
New York, NY: Addison-Wesley, 2003.
Shaw, Mary. “Architecture Issues in Software Reuse: It’s Not Just the Functionality, It’s the Packaging.” Proceedings of the IEEE Symposium on Software Reusability, April 1995.
Sommerville, I. Software Engineering, 6th Edition. 2000.
Wallnau, Kurt; Morris, Edwin; Feiler, Peter; Earl, Anthony; and Litvak, Emile. “Engineering Component-Based Systems with Distributed Object Technology” (Lecture Notes in Computer Science). Proceedings of the International Conference on Worldwide Computing and its Applications (WWCA’97). Tsukuba, Japan. March 1997.
About the Author
Robert C. Seacord is a senior member of the technical staff at the SEI and an eclectic technologist. He is coauthor of the book Building Systems from Commercial Components as well as more than 40 papers on component-based software engineering, Web-based system design, legacy system modernization, component repositories, search engines, security, and user interface design and development.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.