1. CIS 376 Bruce R. Maxim UM-Dearborn
Legacy Systems
CIS 376
Bruce R. Maxim
UM-Dearborn

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

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

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

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

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

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

8. Legacy System Components

9. System Change In theory In practice
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

10. Here are some architecture examples from Sommerville that indicate some of the types coupling that may be involved in among legacy systems.

11. Legacy Application System

12. Database Management System

13. Transaction Processing

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

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

16. A Function-Oriented View of Design

17. 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)

18. Input-Process-Output Model

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

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

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

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

23. 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?

24. 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?

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

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

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

28. System quality and business value

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