Using the RUP to Evolve a Legacy System

Using the RUP to Evolve a Legacy System

by Philippe Kruchten

Rational FellowRational Software Canada

Some people claim that the Rational Unified Process (RUP) is only useful for "green field" development, that is, the development of a brand new system, from the ground up, in an empty green field. They contend that it cannot be used for further development or evolution of a "legacy" system. I strongly disagree: I know that large portions of the RUP can be used to evolve an existing system. Actually, about 80 percent of the sites where the RUP is used today include some form of legacy.

Assessing Your Legacy System

To determine whether a legacy evolution project is suitable for the RUP, I would pose three preliminary questions to the development organization:

1. What characterizes your legacy system?

2. How do you want to evolve your legacy system?

3. Is your plan a sound business decision?

We'll discuss these in detail below.

What Characterizes Your Legacy System?

A legacy system has been defined as a system that "significantly resists modification and evolution to meet new and constantly changing business requirements."1 It is usually implied that the system is large and old. And in this context, the person asking this question also means "a system whose original development was not done with the RUP."

If the original development was done with the Rational Unified Process, then most of the artifacts you need would exist already in some form or another. In this case, evolving the system could mean just adding one more complete development cycle (inception, elaboration, construction, and transition); inception and elaboration might be relatively small, depending on the complexity of the proposed evolution. This is the case, for example, if there are no significant architectural impacts. I would classify this as a maintenance cycle, which I will discuss in a separate article.

So let us assume that your legacy system was not developed with the RUP. This means that the development artifacts, when they exist, do not carry the usual RUP names, or are not in the form we expect them in the RUP. Very often, they are just missing or obsolete, or so old that nobody can trust them to still be relevant to the system. We can assume that other techniques were used: the design was not done using object-oriented technology, the requirements did not employ use cases, and so on.

We also assume that the legacy system represents a significant asset (a "legacy") that is really worth reusing in some form or another, as opposed to scrapping it altogether. So the value of the current asset must be assessed: Is its value in the code? The design? The requirements? Some of the algorithms or data? Or just the market share that the product commands? Unfortunately, the older the system, the harder it is to grasp and use the existing assets. The software documentation is very often obsolete, and the design must be reverse engineered (i.e., it requires "design recovery"), sometimes from the code itself.

Having to deal with a legacy system is usually considered a negative, but the existence of a "precedent" system to establish a point of comparison and use as a source of information is, in fact, very valuable. Unprecedented systems are much harder to define and develop.

In particular, your legacy system will enable you to easily identify:

Requirements and business rules

What is architecturally significant

Primary use cases

Users' priorities, wishes, and behaviors

The only danger is that the legacy system can be an anchor, stifling the examination and consideration of fresher approaches.

How Do You Want To Evolve Your Legacy System?

There is a broad range of evolutionary changes that we might want to undertake, from simple functionality extension, to a radical architectural change, to complete redesign and reimplementation. And for each, different technical solutions and levels of process formality will apply. Here are examples of legacy system evolutions:

Extension

Cosmetic makeover

Migration

Redevelopment

"All of the above"

Extension. In simple cases, you just need to add some functionality or feature. Drivers such as regulation changes, emerging business needs, or new features made available by the competition all require a corresponding evolution of the existing system. With many legacy systems, the older they are, the more difficult even simple additions become. The cumulative effect of years of extension leads to a degradation of the system's architectural integrity, thus increasing the difficulty of extending that system.

Cosmetic makeover. Often you do not need to scrap the whole system, but only to give it a new look, or perhaps take advantage of a new GUI technology or interface. A solution based on wrapping certain components of your system to give them a new interface or allow their re-implementation can lead to an acceptable result with minimal development. This is the case for many applications that need to be rapidly "Web-enabled," for example.

Migration. Often the system has exceeded the useful life of its underlying hardware, operating system, or middleware. It relies on technologies that are either no longer maintained or very costly to keep alive. The solution is to migrate the legacy system to a new platform (hardware or software), preserving much of the existing software. For example, an application developed for a DEC VAX VMS environment must rapidly be deployed on a wide range of Unix- and Linux-based platforms. This was the case when we migrated the Rational Environment (a product with two million lines of code) from our own proprietary platform to a range of Unix-based platforms, which led to the product known today as Rational Apex. Whereas extension means adding new domain-specific behavior, migration means adapting the legacy system to a different technology platform. Migration has less tangible domain-specific value, but failing to do it in a timely and efficient way can bring the whole show to a halt.

Redevelopment. If the legacy system is a mission-critical system that has become extremely hard to evolve, that cannot scale up, and that relies on obsolete hardware or software technologies, then you may have to redevelop it. Usually you have to do this gradually, as you cannot afford to lose your existing customer base. This was the case for the Canadian Automated Air Traffic System, which was running on very old hardware and an operating system more than twenty years old. You may object that this option does not belong here; but even if you plan to rebuild a system from scratch, you should exploit your legacy system to understand key aspects of the new system. It contains a wealth of both positive and negative experience and knowledge.

"All of the above." Finally, there are circumstances under which a company may need to do a migration, cosmetic makeover, and redevelopment in succession. They may need to rapidly move a legacy system to a new platform and give the system a brand new look to satisfy market demands, then redesign the system and gradually replace the old code base, chunk-by-chunk, using new technology -- software components, new language, and middleware -- in order to be able to move forward. This is the most challenging and risky approach, but it can be done. I recall a customer with a large MIS application containing several million lines of RPG (Report Program Generator) code developed on an IBM AS/400 platform that had to be converted to Java and capable of running on the Web and a wide range of Windows and Unix systems. They successfully redesigned and implemented the application in Java over a period of two to three years, without too much disruption for the installed based.

Is Your Plan a Sound Business Decision?

You do not evolve a legacy system just because it is there. You have to ask whether changing the system makes sense. In general, it really is reasonable to keep legacy systems around: their development or acquisition is typically a sunk cost, and most likely there is no business justification for scrapping them. There is also an opportunity cost, however: given limited resources and infinite demand to build new things, to maintain a legacy system is a decision not to spend those scarce resources on new things. If you find that you are simply engaging in preservation -- injecting resources into a system for emotional or historical reasons rather than for meaningful business reasons, or because you have not examined any alternatives -- then it is probably unreasonable to continue maintaining the system.

Using the Rational Unified Process

If you do decide to pursue any of the legacy system evolutions we described above, then the first things you can apply from the RUP are its fundamental principles:

Early risk mitigation

Iterative development

Progress assessment based on concrete, measurable evidence

Organization around small, empowered teams

Verifying quality continuously

Scope management

Producing only the artifacts that are needed

These principles are not specific to "green field" development; they apply to any type of software development. This already makes the basic RUP lifecycle template, with its four phases of Inception, Elaboration, Construction, and Transition fully applicable to a legacy system project. This in turn makes most of the Project Management activities of the RUP fully applicable as well. Just because it is a legacy system, there is no reason not to have a Vision Document, describing what it is you want to achieve; a Project Plan, showing major milestones and what you want to accomplish; maybe iterations and their specific objectives; and a Risk List. You also need a Business Case, to be able to discuss the benefits of doing the project and the approach you will take. This Business Case will be based on an estimate of costs: staffing and other requirements (tools, middleware, training), which, in turn, will depend on the extent of the work to be accomplished. As you progress toward the Transition phase, you will need a Deployment Plan, showing how the new system will be deployed, replacing the old one.

Establishing a RUP-Friendly Baseline

To go beyond simply applying the RUP lifecycle and use other disciplines of the RUP going forward, you need to establish a starting point. You must identify a minimal set of essential artifacts describing the legacy system. Depending on the scope of the evolution, you may need more or less of:

Requirements

Architecture and design

Tests

User documentation

Once you have established this baseline of RUP artifacts, you can proceed with the legacy project as if it were a RUP Evolution cycle.

Establishing a minimal set of artifacts that will allow your project to proceed as per the RUP requires some reverse engineering on your legacy system. By reverse engineering, I mean trying to identify, extract, or recreate enough information to enable you to proceed almost as if the project had been originally developed using the RUP. This is the point at which many project managers are ready to scrap the RUP for their legacy project, as they perceive this reverse engineering effort to be a huge waste of time. It does not need to be such an immense effort, though, as the intent is not to recreate every single artifact, but to understand the key attributes of the current system, and determine what should be conserved and what should be replaced or upgraded.

Requirements. The most important value of the legacy system is to provide a minimum specification for the new system. For example, when we started Rational Apex, the first draft of our Vision Document stated "it has first to do everything that the Rational Environment (version Delta) does, and do it no slower." Then we specified deviations from the Rational Environment: features added, features dropped. A smart team never retrospectively documents the requirements of a legacy system, so you do not have to restart the requirements effort from scratch; you only need to identify your key use cases. You probably have them already, described in the current User's Manual. Just having an inventory of the use cases (a Use Case Survey) may be enough. You will only need to detail the use cases that need to change. Many of the nonfunctional requirements can be derived from your marketing or installation documentation: capabilities, size and performance characteristics, operating systems, memory, peripherals, other software, general constraints, and most of the "ilities." If you are not using a requirements management tool, then maybe now is the right time to start doing this inventory.

Architecture and Design. Your legacy system does not need to be completely redesigned using object-oriented (OO) techniques. You will, however, need a minimal amount of architectural information. You can create a minimal Software Architecture Document, starting from the Implementation View: What are the various subsystems or main bodies of code? And what are the critical interfaces? From this information you can identify your Deployment View and your Process View, if the legacy system is distributed. You will need a precise inventory of the existing software, clearly identifying each element and the relationships among them. If the software is not yet under configuration management, now is the right time to start controlling it.

Describing the interfaces and the scenarios of how these interfaces are exercised is crucial. Later on, you will identify the subsystems that are not affected by the evolution: the stable, core, reusable chunks of the legacy system. Do you need a detailed software design documentation as well as these interface descriptions? If you have it and can trust it, that is nice, but do not embark on a huge effort to produce it before you know what pieces need to be changed. And even then, proceed on a case-by-case basis. Tools can help you do this reverse engineering, which does not need to exceed a few days of work.

Tests. Whatever tests, test scripts, test cases, and test harnesses were developed for the legacy system will still be largely applicable for the new system.

User Documentation. Unless there is an incentive to completely revamp it, the user documentation for the legacy system can constitute a good baseline for the new system. The RUP templates for these artifacts can be used, as well as some of the associated guidelines and checkpoints. But you probably want to tailor the templates first, to avoid falling into the trap of documenting elements you do not need. In many cases, you can "fill in" the templates (in your first pass) by cross-referencing; that is, indicating in which existing document the corresponding information can be found. If the existing documentation is online in HTML, then use a URL.

Finally, a good additional artifact to create while doing this reverse engineering is a Glossary of terms used in the legacy system, collecting terms as you encounter them. It will prove invaluable when going forward.

Note that this step of establishing a baseline is not RUP specific. Whatever process or method you will use to go forward, you will need to do some reverse engineering of the existing system. The Web site for "Renaissance," an Esprit project on software reengineering, is a good source of information on reverse engineering.1 Evolution: Going Forward with the RUP

Once you have established your minimal RUP artifact baseline, much of it by reference to existing information, you can now proceed. Most of the activities of the RUP apply, just as they do in Construction and Transition iterations for a brand new development project. Yet, as always, try to keep things as light as possible as you choose what to adopt from RUP; do not execute activities or create artifacts that are unnecessary.

Requirements Management. Express new requirements using use cases. You may have to recreate a use case for existing functionality to better articulate what is being changed. If several use cases need to be added or changed, you may find it useful to derive a small Domain Model from your Glossary.

Architecture and Design. You might want to use object-oriented techniques and the UML (Unified Modeling Language) for your new development. A handy technique is to consider some of the least affected subsystems as big composite classes, especially when you are doing sequence diagrams. As you may have done for your use cases, you can create a Design Model, but only go into details for the classes that are architecturally important or that need to evolve. Proxies can be created for these classes, mapping their functionality to the existing code.

If your long-term goal is ambitious and aims at a complete, gradual replacement of the legacy system, you will have to do an architectural design for the new system, and then map it to the existing subsystems. You can create wrappers around some of the existing body of code to make it look like it was designed using OO techniques. Reassembling the complete system with the various wrappers can be an internal milestone in your elaboration phase. As you go into use-case design, your use-case realizations will show you the impact on various existing subsystems. Then you can decide which of these "wrapped subsystems" need be converted, ported, or rewritten.

In some limited cases, you might be able to use tools such as Rational Rose to reverse engineer elements of your existing code into the UML. But do not rely on using the results blindly; they will always require some enlightened human interpretation.

Deployment. Depending on the scope of the evolution, deployment of the new system may be more challenging than a green field development. If you migrated the system to a new architecture or redeveloped significant portions of it, you will have to choose a strategy: either to cut over "cold turkey" from the old system to the new one, or use a phased strategy and do the transition in small incremental steps. Or, you can even have both systems working in parallel until the new one can be fully trusted. In practice, deployment is often much more delicate with a legacy system than a new application, as you need to tackle issues of data conversion, continuity of operations, retraining of personnel, and so on.

Other Disciplines. Other software development disciplines, with all their activities, guidelines, techniques, and tools, also apply: test and implementation, for example. Configuration management may be more relevant and required earlier in the project than for a new development, as you start from day one with many existing artifacts, sometimes with complex dependencies between them. In a legacy system upgrade, change management becomes a dominant activity.

Often, the decision to redevelop a legacy system also represents an opportunity to reengineer business processes, using business modeling, which could lead to a different set of requirements for the new system.

Completing the RUP. When creating the development case for a legacy system evolution project, you will notice that the RUP does not contain activities or guidelines for reverse engineering, design recovery, database conversion, or the technique of using "wrappers." These techniques are very dependent on the state of the legacy system and the technologies it uses, and it is hard to generalize them. See References 1, 2, and 4 below for pointers to various approaches and techniques.

A RUP-Based Evolution Cycle

The RUP's Inception phase specifies that you produce a Vision Document and Business Case, as well as an Initial Development Case specifying which artifacts you need to recreate. In this phase you will also start the process of reverse engineering for some of the artifacts: requirements and architecture, mainly, in order to be able to choose the appropriate evolution strategy and estimate its cost.

In the Elaboration phase, you will complete your RUP baseline, the minimal set of artifacts that you need to go forward, including the conversion of some older artifacts to the new tool set. For simple extensions, this can be done in one short iteration. But if there are a large number of architectural changes to go through, as in a migration strategy or redevelopment, then you will have several iterations in this elaboration phase to implement a new architectural baseline. It may even be that this Elaboration phase is the dominant phase, and that there will be little to do in Construction and Transition. Testing is put in place in the new environment, and regression testing can start early. Unlike Elaboration for a green-field development, there is from the beginning a large number of artifacts -- code in particular -- to manage, and activities from the Change and Configuration Management discipline have to be stressed earlier.

The Construction phase is not significantly different from any other RUP project. Additional elements are reverse-engineered, redesigned, and documented as necessary. Or they are just ported or translated into another language.

The Transition phase may be more delicate, depending on the deployment strategy to go from the old system to the new one; see the section on Deployment above.

Clearly, the RUP is helpful in staging legacy evolutions, with very concrete and measurable objectives for each iteration. Joe Marasco, the manager for the Rational Apex project wrote:

We decided which bits of functionality needed to be moved first, which parts will be moved without touching them at all, which will be moved in later iterations. The version on Sun OS was postponed to a later iteration, once the version on AIX was stable. Instead of seeing the butterfly emerge in one day from the cocoon, you plan its metamorphosis and track its evolution iteration by iteration. I cannot imagine managing the evolution of a complex legacy system by any other means.

Limit the Changes

How do you apply the RUP to a legacy system?

First, by understanding what you are trying to do.

Second, by intelligently exploiting what you already have.

Third, by focusing on the principles, and not necessarily the details, of the RUP.

Large portions of the RUP can be used for the evolution of a legacy system, with more or less tailoring and formality, depending on the type of evolution you envisage and how much information on the legacy system is at hand. How many of the RUP artifacts you need to actually develop by extracting from, or reverse engineering, the existing system depends on the complexity of the evolution and the degree of risk you can tolerate.

One caution: We have seen projects fail when too many changes were attempted at the same time: A major evolution of a legacy system (e.g., a migration to a new platform), at the same time as a change of process (e.g., going to the RUP), and a change of tool set (e.g., going to Rational Suites). It is preferable to introduce a new process and new tools during an earlier project, before you undertake a major legacy evolution, so that developers can become familiar with the RUP, its philosophy, and its contents, as well as the tools that support it. Avoid multiplying risk for the project by introducing too many unknowns and changes simultaneously.

Acknowledgments

Many thanks to my friends and colleagues for their help in assembling the information this article, which is based on their own blood-and-sweat experiences: Dean Leffingwell, Bruce MacIsaac, Joe Marasco, Walker Royce, John Smith, Grady Booch, Craig Larman, as well as the many participants in Rational's internal process discussion forum. They posed the question, again and again, whether RUP can be used effectively for legacy evolutions and provided valuable elements of the answer in this article. Thanks also to Catherine Southwood for ironing out my Frenglish.

About Author

Philippe Kruchten

Philippe Kruchten joined Rational Software in 1987 and is currently a Rational Fellow, based in Vancouver, B.C. Formerly the Director and General Manager of the Process Business Unit, he has led development of the Rational Unified Process. In addition to focusing on software architecture and design, he is keenly interested in software engineering practices and the development process. He holds degrees in mechanical engineering and a doctorate in computer science from French institutions.

Using the RUP to Evolve a Legacy System Page 9/ 9