Legacy Systems

CIS 376

Bruce R. Maxim

UM-Dearborn

What are legacy systems?

• Systems developed for a specific client that have been in service for a long-time

• Many of these systems were developed years ago using obsolete technologies

• They are likely to be business critical systems required for normal operation of a business

• These are the systems that everyone worried about when the Y2K concerns became public

Legacy System Replacement

• The business risks associated with the strategy of scrapping a legacy system and replacing it with a new one are not insignificant– legacy systems rarely have complete specifications

– changes are not likely to be documented well at all

– business processes are reliant on the system

– the legacy system may contain embedded business rules that are not formally documented elsewhere

– software development is risky and not is always successful

Changing Legacy Systems• All systems must change to remain useful

• Changes to legacy systems can be very expensive– components may be implemented with different programming

styles as changes are implemented

– system may be written in an obsolete language

– system documents often out-of-date

– system structure may be corrupted by years of maintenance activities

– techniques used to save space or increase speed may have obscured understandability

– file structures used may be incompatible with each other

Legacy System Risks

• Replacing a legacy system is both expensive and risky

• Maintaining a legacy system is also expensive and risky

• Sometimes a the decision is made (based on the costs and risks involved) to extend system life-time using techniques like re-engineering

Socio-Technical Systems

• Lagacy systems are more than just software systems

• Sommerville describes legacy systems as socio-technical systems

• Socio-Technical System Layers– business processes

– application software

– support software

– hardware

Legacy System Structures• System Hardware

– could be a mainframe

• System Software

• Application Software

• Application Data– business critical data often used by several programs

• Business Processes– processes that support a business objective and rely on the legacy

systems hardware and software

• Business Policies and Rules– business operation constraints

Legacy System Components

Systemhardware

Businessprocesses

Applicationsoftware

Business policiesand rules

Supportsoftware

Application data

ConstrainsUsesUsesRuns-onRuns-on

Embedsknowledge of

Uses

System Change

• In theory– it should be possible to replace one layer in a socio-technical

system without making any changes to the other layers

• In practice– changing one layer introduces new facilities that must be used in

higher level layers

– changing the software may require hardware changes to maintain system performance

– it may be impossible to maintain hardware interfaces because of the huge differences between mainframe and client-server architectures

Here are some architecture examples from Sommerville that indicate some

of the types coupling that may be involved in among legacy systems.

Legacy Application System

File 1 File 2 File 3 File 4 File 5 File 6

Program 2Program 1 Program 3

Program 4 Program 5 Program 6 Program 7

Database Management System

Program1

Program2

Program3

Program4

Databasemanagement

system

Logical andphysical

data models

describes

Transaction Processing

Serialisedtransactions

Teleprocessingmonitor

Accountsdatabase

ATMs and terminals

Account queriesand updates

Legacy Data Concerns

• File-based systems may have several programs accessing and modifying incompatible data files

• It would be common to move from a file-based system to a database management system (DBMS)

• It is possible that the DBMS itself has become obsolete and needs to be replaced

• The DBMS may be incompatible with other database systems used in the business

• The teleprocessing monitor used in a transaction processing system may only work with a particular DBMS and mainframe environment

Legacy System Design

• Most legacy systems were designed without using object-oriented techniques

• A legacy system is not likely to have been designed as a set of interacting objects

• A legacy system is more likely to be designed using a function-oriented design strategy

• Many software engineering methods and CASE tools support function-oriented design

• Function-oriented design is common in MIS applications

A Function-Oriented View of Design

F2F1 F3

F4 F5

Shared memory

Functional Design Process

• Dataflow Design– used to model information flow

• Structural Decomposition– decomposition of functions into sub-functions shown

using graphical structure chart that makes use of the input-process-output model

• Detailed Design– the entities and their interfaces are recorded in the data

dictionary and the processing detail is represented using a program design language (PDL)

Input-Process-Output Model

System

Input Process Output

Input-Process-Output

• Input Components– read and validate data received file or device

• Processing Components– carry out transformations on the input data

• Output Components– format and display results of the data transformations

• Input, process, and output can be represented as functions with data flowing between them and as a bubble in the dataflow diagram

Using Function-Oriented Design

• For some systems (e.g. transaction processing systems) a function-oriented approach may be more natural than an object-oriented approach

• Companies with a heavy investment in CASE tools that support function-oriented design may not want to pay the price of moving to an object-oriented approach

Legacy System Assessment

• Companies that rely on legacy systems must have a strategy for evolving these systems– scrap the system and modify business practices so it is

not needed

– continue maintaining the old system

– re-engineer the old system to improve maintainability

– replace the old system with a new system

• The strategy chosen depends on the quality of the system and its business value

Business Value Assessment

• Need to take different viewpoints into account– system end-users

– business customers

– business managers

– IT managers

– senior management

• Process is similar to system feasibility assessment– Interview stakeholders and collate the results

System Quality Assessment

• Business Process Assessment– How well does the business process support the current

goals of the business?

• Environment Assessment– How effective is the system environment?

– How costly is it to maintain?

• Application Assessment– What is the quality of the application software system?

Business Process Assessment

• Interview representatives from each group of stakeholders and ask– Is there a defined process model and is it followed?

– Does everyone in the company use the same processes to achieve the same function?

– How has the process been adapted to meet local needs?

– What are the relationships between this process and other business processes?

– Is the process supported effectively by the legacy system?

Environment Assessment

• System software or hardware supplier stability • Hardware failure rate• Age of hardware and software• Performance of system• Support requirements for hardware and software• Maintenance costs• Interoperability with other business systems

Application Assessment Factors

• Understandability of source code• Documentation quality• Data model (existence and duplication)• Performance• Programming language used• Configuration management controls• Test data existence and regression test results• Team members capable of maintaining application

System Measurement

• Collecting quantitative data can help assess the quality of the application– number of system change requests made– number of user interfaces in the system– volume of data used by system– reliability measures– defect detection or removal rates

System quality and business value

12

3 45

67

89

10

System quality

Business valueHigh business valueLow quality High business value

High quality

Low business valueLow quality

Low business valueHigh quality

Legacy System Categories

• Low quality, Low business value– scrap the system

• Low quality, High business value– should be re-engineered or replaced if a suitable system

is available

• High-quality, Low business value– replace with COTS, scrap system, or maintain

• High-quality, High business value– continue operation using normal maintenance practices