1.4 Evolving Legacy Systems


System evolution covers a continuum of development activities, from adding a field in a database to completely reimplementing a system. System evolution activities can be divided into three categories: maintenance, modernization, and replacement [Weiderman 97]. Figure 1-3 illustrates how various evolution activities are applied at different phases of the system life cycle. The dotted line represents growing business needs. The solid lines represent the functionality provided by the information systems. Repeated system maintenance supports the business needs sufficiently for a time, but as the system ages, maintenance falls behind business needs. Eventually, a modernization effort that demands more time and effort than the maintenance activity is required. Finally, when the old system can no longer be evolved, it must be replaced .

Figure 1-3. Information system life cycle

graphics/01fig03.gif

Determining the evolutionary activity that is most appropriate at different points in the life cycle is a daunting challenge. Should we continue maintaining the system or modernize it? Should we completely replace the system? Enterprises that rely on legacy information systems, with limited budget, must obtain the best return on their investment. To make the correct decision, organizations must realistically assess their legacy systems, determine an appropriate evolution strategy, and analyze the implications of each action. The result of the initial assessment must be based on an assessment of the value of the system to the organization and the system itself [Warren 98].

The remainder of this section examines the differences among maintenance, modernization, and replacement.

Maintenance

Maintenance is an incremental and iterative process in which small changes are made to a system. These changes are often bug fixes or small functional enhancements that do not involve major structural changes. Maintenance is required to support the evolution of any system but has limitations. These limitations include the following.

  • The competitive advantage derived from adopting new technologies is seriously constrained because enhancements, such as implementing a distributed architecture or a graphical user interface, are not typically considered maintenance operations.

  • Maintenance costs for legacy systems can increase with time. Finding expertise in older technologies becomes increasingly difficult and expensive. Although it is relatively inexpensive to provide in-house training, engineers must be receptive to receiving this training.

  • Modifying a legacy system to adapt it to new business needs becomes increasingly difficult, as the impact of many small changes can be greater than their sum.

Modernization

Modernization involves more extensive changes than maintenance but conserves a significant portion of the existing system. These changes often include restructuring the system, enhancing functionality, or modifying software attributes. Modernization is used when a legacy system requires more pervasive changes than those possible during maintenance, but it still has business value that must be preserved. Reasons for modernization usually stem from legacy system brittleness, inflexibility, isolation, nonextensibility, and lack of openness [Bisbal 99].

System modernization can be distinguished by the level of system understanding required to support the modernization effort [Weiderman 97]. White-box modernization requires knowledge of the internals of a legacy system. Black-box modernization requires knowledge only of the external interfaces of a legacy system.

White-Box Modernization

White-box modernization requires an understanding of legacy system internals. If this knowledge is unavailable, an initial process called program understanding [Chikofsky 90] is required. Program understanding involves modeling the domain, extracting information from the code, and creating abstractions that describe the underlying system structure [Tilley 95]. Although some advances have been made in program understanding, it is still a risky and work- intensive task [von Mayrhauser 94, Haft 95]. We discuss program understanding at length in Chapter 5.

After the code is analyzed and understood , white-box modernization can often include system or code restructuring. Software restructuring can be defined as "the transformation from one representation form to another at the same relative abstraction level, while preserving the subject system's external behavior (functionality and semantics)" [Chikofsky 90, p. 15]. This transformation is typically used to augment a quality attribute of the system, such as maintainability or performance.

Black-Box Modernization

Black-box modernization involves examining the inputs and outputs of a legacy system, within an operating context, to understand the system interfaces. This is usually not as difficult as white-box modernization.

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].

Replacement

Replacement requires rebuilding the system from scratch and is resource intensive. Replacement is appropriate when legacy systems cannot keep pace with business needs and when modernization is not possible or cost-effective [Bisbal 97]. Replacement may be the only option when white-box and black-box modernization approaches cannot be cost justified.

Systems can be replaced either all at once by using a "big-bang" approach or incrementally. When replacing a system incrementally, it helps if the system has some degree of modularization or cohesion. Often, the legacy system is reengineered as a preparatory step before beginning an incremental replacement effort.

Replacement has the following risks that should be evaluated before selecting this technique.

  • IT personnel performing maintenance tasks may not be familiar with the new technologies.

  • Replacement requires extensive testing of the new system. Legacy systems are usually well tested and tuned and encapsulate considerable business expertise. There is no guarantee that the new system will be as robust or functional as the old one (shown in Figure 1-3). This may cause a period of degraded system functionality.



Modernizing Legacy Systems
Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices
ISBN: 0321118847
EAN: 2147483647
Year: 2003
Pages: 142

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net