6.

Case Study 1: Evolution of a

Legacy System

Objectives
• To show how you can use Renaissance to develop an evolution strategy for a
legacy system.
• To demonstrate how to manage an evolution project using Renaissance.
• To show how you can customize Renaissance according to project and organiza-
tional needs.
• To show the impact of technical, organizational and business factors on system
evolution.
• To illustrate the guidelines presented in Chapters 3-5: evolution planning, system
modelling and migrating to distributed architectures.

:!, Contents : ~'; , ,

6.1 Background
6.2 Scenario 1: Evolution Strategy Development
6.3 Scenario 2: Evolution Strategy Implementation

In this chapter, we present a case study based on our experiences with reengineering
legacy systems. The system's technology typifies many data processing systems that
were developed in the 1970s and remain in service today. This case study provides
the foundation for two scenarios. Each scenario extends the case study with
additional technical, business and organizational characteristics. Table 6.1 summa-
rizes each scenario according to the characteristics oflegacy systems which we intro-
duced in Chapter 1.
The first scenario demonstrates the value of good software engineering. In this case,
the system has been maintained by a technically mature organization. The system
has been subjected to a preventative maintenance program as part of the agreement
between the development and operational organizations. Consequently, the system
is in good technical condition. From a business viewpoint, the system generally
supports the operational organization'S business process, and its business goals are
not radical. We demonstrate how you can use Renaissance to determine a suitable
evolution strategy for the system.

I. Warren, The Renaissance of Legacy Systems 107

© Springer-Verlag London Limited 1999
108 The Renaissance of Legacy Systems

Table 6.1 Scenario characteristics

Characteristic Scenario
2
High maintenance costs .t
Complex software .t
Obsolete support software
Obsolete hardware
Lacking technical expertise .t
Business critical .t
Backlog of change ,requests .t
Poor documentation .t
Embedded business knowledge .t
Poorly understood by maintainers .t

In contrast to Scenario 1, the second scenario is more negative. The system is in poor
technical condition since it has been maintained according to an ad hoc process.
Rather than invest in a quality maintenance program, the operational organization
has procured the services of many software houses to make changes to its system. Its
policy of reducing maintenance costs has, however, resulted in a system which is
difficult and expensive to maintain.
Scenario 2 also involves radical business goals. Furthermore, the operational organi-
zation mandates a particular target system. We show how you can use Renaissance to
manage the transition between the legacy and target systems. Table 6.2 summarizes
the parts of Renaissance we illustrate in this chapter.

Table 6.2 Demonstration of Renaissance

Renaissance Scenario 1 Scenario 2
Method Used to develop a suitable Used to manage an evolution
evolution strategy project with a mandated target
system
Process Phase 1 Phases 'I to 4
Customization Responsibilities Process model
Document repository Responsibilities
Document repository
Evolution planning Legacy system assessment Evolution project planning
Evolution strategy development Risk assessment
Cost estimation and risk
assessment
System modelling Context modelling Context modelling
Technical modelling
Migration to a Consideration of a distributed
distributed architecture architecture for the target
system