Legacy Systems

1. 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 incompatiblewith 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 • 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