Migrating Legacy Systems to the Web

INTRODUCTION

Business Process Reengineering (BPR) is defined as “the fundamental rethinking and radical redesign of business processes to achieve significant improvements of the performances, such as cost, quality, service, and speed” (Hammer & Champy, 1993). Most BPR projects aim at converting business organisations from hierarchical centralised structures to networked decentralised business units cooperating with one another. This conversion is assuming a strategic relevance as the Internet is changing radically business processes, not only because they are purposely reengineered, but also because the Internet and the information and communication technology, offer more convenient means of fulfilling their requirement.
Current business processes have been profoundly fitted to the available software. The technologies involved in process execution impact the way businesses are conceived and conducted. Abstractly, BPR should entail discarding the existing and legacy systems to develop new software systems that meet the new business needs. This is superficially attractive and human appealing. However, legacy systems cannot be simply discarded because they are crucial systems to the business they support and encapsulate a great deal of knowledge and expertise of the application domain. This entails that even the development of a new replacement system may have to rely on knowledge which is encapsulated in the old system. In summary, existing systems are the result of large investments and represent a patrimony to be salvaged. Therefore, to satisfy the goals of a BPR project, it is necessary to work intensively to search a trade-off between the constraints of existing legacy systems and the opportune BPR strategy.
In this article, we discuss a strategy for migrating business processes and the supporting legacy systems to Web-centric architecture. The overall strategy comprises modelling the existing business processes and assessing the business and quality value of the supporting software systems. This is followed by the migration of the legacy systems, which can be in turn enacted with different strategies. The initial step consists of understanding and modelling the business processes together with the involved documents and software systems. The analysis of the existing processes is required to get an inventory of the activity performed, compare them with best practices, and redesign and/or reengineer them. Our overall approach is discussed in details in references (Aversano, Canfora, De Lucia, & Stefanucci, 2002a; Canfora, De Lucia, & Gallucci, 2002b), together with experience concerned with their applications. The final phase related to legacy system analysis and assessment is discussed in details in Aversano, Canfora, and De Lucia (2003) and briefly presented here.


BACKGROUND

Legacy systems are “large software systems that we don’t know how to cope with but that are vital to our organization” (Bennett, 1995). There are a number of options available in managing legacy systems. Typical solutions include: discarding the legacy system and building a replacement system; freezing the system and using it as a component of a new larger system; modifying the system to give it another lease of life. Modifications may range from a simplification ofthe system (reduction of size and complexity) to preventive maintenance (redocumentation, restructuring, and reengineering) or even to extraordinary processes of adaptive maintenance (interface modification, wrapping, and migration) (Pigoski, 1997; De Lucia, Fasolino, & Pompella, 2001).
Several authors have identified possible alternatives for dealing with legacy systems and have proposed decision frameworks to select among the alternatives. In general, decision frameworks require that a legacy system be assessed from two points of views: a business dimension and a technical dimension (Bennett, Ramage, & Munro, 1999; De Lucia et al., 2001; Sneed, 1995). This information measures the complexity of the business processes and administrative rules that a system, or system’s component, implements and their relevance to achieve business competitiveness. The technical value of a legacy system can be assessed through different quality attributes, such as the obsolescence of the hardware/ software platforms, the level of decomposability, the maintainability, and the deterioration (De Lucia et al.,2001).

Figure 1: A decisional framework

A decisional framework
We assess the technical quality of a legacy system by considering the obsolescence and the decomposability level. In particular, we focus on making decisions on the actions to perform as a consequence of a BPR project aimed at taking advantage of the Internet. We assume that the obsolescence of the system is high, and therefore, extraordinary maintenance is required. Accordingly, the decision about the particular type of intervention to take will be made based on the decomposability and business value of the system.
Two different kinds of decomposability can be considered:
• vertical decomposability, which refers to the possibility of decomposing a system into major architectural layers;
• horizontal decomposability, which accounts for the possibility of decomposing a legacy system into independent and cooperating business components.
In particular, concerning the vertical decomposabil-ity, Brodie and Stonebaker (1995) refer that a software system can be considered as having three types of components: interface components, application logic components, and database components. Depending on how separated and well identified are these components, the architecture of a legacy system can be decomposable, semidecomposable, or nondecomposable. In a decomposable system, the application logic components are independent of each other and interact with the database components and system interfaces. In a semidecomposable system, only interfaces are separate modules, while application logic components and database services are not separated. A nondecomposable system is a black box with no separated components.
Figure 1 shows a decisional framework that takes into account the considerations described previously. The decision about the intervention to take on the legacy system with a high business value is mainly driven by the vertical decomposability of the system. If the vertical decomposability value is sufficiently high, that is, the system is decomposable or semidecomposable in the Brodie and Stonebaker terminology, the best strategy is a short term migration of the system, achieved through wrapping the application logic and/or data management functions (that define the server tier) and reengineering/ redeveloping the user interface to a Web-centric style. This strategy represents a good alternative also in the case of a nondecomposable system, provided that the costs and risks of its decomposition are affordable (Canfora, De Lucia, & Di Lucca, 1999; Sneed, 1995). Ifthe decomposability level of a system with high business value is too low, the complete reengineering / redevelopment alternative has to be preferred, as the legacy system can still be used.
For legacy systems with a low business value, the decision about the intervention to take is mainly driven by the horizontal decomposability. In particular, if the horizontal decomposability value is high, it is possible to use again the framework in Figure 1 to make different decisions for the different business components. This provides the basis for a component based incremental migration of the legacy system. Whenever both the business value and the decomposability of a legacy system are low, the only possible option is elimination/replacement. Indeed, in this case, there are no adequate business preconditions to evolve the existing system.
The migration of a legacy system entails the reuse of the system components while moving the system toward newer and more modern technology infrastructure. Brodie and Stonebraker (1995) propose an incremental approach, named Chicken Little, to migrate a legacy information system using gateways. A different approach proposed by Wu et al. (1997) is the Butterfly methodology, which eliminates the needs of accessing both the legacy and new database during the migration process, thus avoiding the complexity induced by the introduction of gateways to maintain the consistency of the data. Both the methodologies aim at migrating a legacy system mainly based on its vertical decomposability.
Migration strategies have also been proposed that take into account the horizontal decomposability. Canfora et al. (1999) and Serrano, Montes de Oca, and Carter (1999) present two strategies for incrementally migrating legacy systems to object-oriented platforms. The main difference is in the method adopted for identifying objects in procedural code. Both strategies use wrapping technologies to enable the coexistence of legacy and newly developed components. According to Mowbray and Zahari (1994), wrapping is the practice for implementing a software architecture using pre-existing components. Using object wrappers, the legacy code is encapsulated in a controllable way. The wrapper implements the interface through which newly developed objects access legacy resources; it is in charge of mapping incoming messages onto calls to the programs that implement the object methods. In the literature different approaches for wrapping have been presented (Arranga & Coyle, 1996; Canfora et al., 1999). The Web offers several other powerful mechanisms for wrapping legacy systems in a distributed environment. For example, XML is widely used by developers as a standard for data representation of the component’s interfaces, message exchanging, and for defining scripting languages (Sneed, 2000).

MIGRATION STRATEGY

In this section, we present a Web-centric short term migration strategy based on vertical decomposability and on the use of wrappers. Full details of this migration strategy can be found in Aversano et al. (2003). This strategy applies to legacy systems with high business value and a high vertical decomposability level. Figure 2 shows the main phases of the migration process.

Figure 2: Short-term migration strategy

Short-term migration strategy
The first phase is the decomposition and restructuring of the legacy system to a client server style, where the user interface (client side) controls the execution of the application logic and database components (server side). The complexity of this phase depends on the decompos-ability of the system. Nondecomposable systems are the most difficult to be restructured, because decoupling the user interface from the application logic and database components can be very challenging and risky. Canfora, Cimitile, De Lucia, and Di Lucca (2000) present a method to identify the code implementing the user interface of these types of legacy systems. However, even migrating semidecomposable or decomposable systems might not be trivial. For semidecomposable or decomposable systems, the restructuring actions to be taken depend on the coupling between the user interface components and the other components. If all the data are exchanged through the calls between the client side and the application logic components, there is no need for restructuring. However, if the client and server components exchange some data through global data areas, data flow analysis and restructuring techniques are required to transform the global data into parameters to be exchanged across calls.
Once the legacy system has been restructured to a client server style, if needed, two phases can be conducted in parallel, namely the user interface reengineering and the wrapping of the server tier. The first phase aims at reengineering/redeveloping the user interface of the system by exploiting Web technologies. User interface reengineering entails using reverse engineering (Chikofsky & Cross, 1990) to abstract a user interface conceptual model and forward engineering to re-implement the user interface using Web technologies (Merlo et al., 1995; Moore & Rugaber, 1997). In particularMORPH (Moore & Rugaber, 1997) is a knowledge based approach that exploits transformation rules to restructure and transform the abstract model of the user interface into a new abstract model used to generate the target graphical user interface. We have used the MORPH guidelines to reengineer graphical user interfaces to Web interfaces (Aversano et al., 2003).
The transformation of the legacy user interface into the new Web interface should also be driven by the business needs. For example, if the new interface has to be used by the old users, a goal could be minimising the needs for re-training: in this case, in addition to establishing a one-to-one correspondence between the legacy and the new interaction objects, the mapping should be built maintaining a correspondence between the legacy panels and the new Web pages and forms (Aversano et al., 2003). However, in many cases the BPR process introduces new roles (for example, a legacy system in the reengineered process might be required to be accessed directly by a customer); in this case, the new interface must be radically redesigned to meet the new user needs (Sneed, 2000).
Wrapping the server tier is the key to reuse a legacy system with a high business value. In the last few years, the diffusion of the wrapping technology has had a significant impulse as a consequence of the use of Internet as a means of communication between remote programs. The final step of the migration strategy is the integration and testing of the new Web-based application. It is worth noting that once the Web-based migration of the legacy system is completed, the management of the new system will be based on a more general decision framework than the one in Figure 1 (see, e.g., De Lucia et al., 2001). In particular, the main factor to consider will be the business value, at least until the technical value of the system will be adequate to the evolving business needs. In other words, the migrated system will undergo periodical phases of evolution, to keep its functionality in line with the evolving business goals, interleaved with the ordinary maintenance of the system. Of course, a major shift in the technological business needs will entail a rapid increase of the obsolescence of the system, thus moving the management of the system to the decision framework of Figure 1.
The migration strategy has been applied in an industrial pilot project (Aversano et al., 2003). The project aimed at integrating into a Web-enabled architecture an existing online analytical processing COBOL system used by many banks for querying large archives of data for decision support through statistical and explorative analyses. The system has evolved over the past 15 years from a centralised mainframe version with a character-based user interface to a semi-decomposable client-server multi-version system composed of a graphical user interface running on a PC and several server components running on different platforms and accessed from the PC through a PC-host connection layer. In addition, a stand-alone version of the system working on the PC was available.
The need for migrating the system was imposed by the changes in the underlying business processes. The first and most important reason was the fact that the system was used by several banks to make decisions both at central and peripheral levels. In the old architecture, the PC-host connection layer had to be replicated on each client installation and this increased the application ownership costs. Most banks nowadays use Internet/intranet technologies for their information system infrastructure and this caused a push in the direction of Web migration. In addition, the new architecture adds flexibility; in particular, it opens the way to the migration of the stand alone
PC version towards a distributed version which federates several archives/database host sources, thus eliminating the need for maintaining the different versions of the querying and analysis software.
After assessing the system, we opted for a short-term migration strategy with the aim of reducing, at a minimum, the time needed to have a working version of the Web-enabled system. Besides the graphical user interface component, the migrated part of the system consisted of 218 COBOL programs and more than 130 KLOC. The migration was achieved essentially through an extensive use of reverse engineering, to design the new user-interface, and wrapping, to implement the server side. In particular, the presentation layer of the original system was separated from the application logic and database components and re-implemented.

FUTURE TRENDS

Currently, highly dynamic and agile organisations models are emerging in order to compete in global marketplace. This poses significantly new problems for software development and maintenance, and software services are being promoted as the next big step forward in software engineering. A key issue is that services are something that the organizations use, not own. As a consequence, maintainability is not primarily a technical problem. Nonfunctional properties need to be incorporated into service models so that business drivers, as well as technical issues, can be addressed in maintaining and evolving software systems. Two key issues must be considered. The first is the nature of the service supply chain, enterprises tend to express their needs in models in which consumers and suppliers define requirements together. Real situations are more complex: consumers influence the type and method of supply and the supplier influences a consumer’s business processes in order to adapt to their product.
The second issue is that the use of Web services requires a service-level agreement defining terms and conditions for use and maintenance. A critical success factor is the need for a negotiated and agreed architecture by which services can be used and maintained with minimum change.

CONCLUSION

This article has discussed a strategy for migrating business processes and the supporting legacy systems toward Web-centric architecture. The initial step consists of modelling the existing business processes and assessing the business and technical value of the supporting software systems. The analysis of the processes is required to get an inventory of the activity performed, and redesign and/or reengineer them. Based of the assessment, a decisional framework assists software managers to make informed decisions. This is followed by the migration of the legacy system, which can be in turn enacted with different approaches. In particular, the short-term system migration strategy decomposes and reengineers the system into its client and server components and uses wrappers to encapsulate the server components. Reverse engineering is used to abstract a model of the client components, and in particular the user interface, and redevelop them.
The short-term strategy was successful in reducing the time and the costs of migrating the system to adapt it to the new business scenario, however it did not change the quality of the server programs, which remain essentially unchanged, and therefore no benefits are expected in the future maintenance and evolution of the system. This is in contrast with other approaches that reverse engineer meaningful objects from the legacy code and wrap each of them separately. While more costly, such approaches offer more benefits on the long term as they enable incremental replacement strategies.

KEY TERMS

Business Process Reengineering (BPR): The fundamental rethinking and radical redesign of business processes to achieve significant improvements of the performances, such as cost, quality, service, and speed.
Legacy System: A software system which continues to be used because of the cost of replacing or redesigning it, despite its poor competitiveness and compatibility with modern equivalents.
Reengineering: The examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form.

Next post:

Previous post: