CIS 376 Bruce R. Maxim UM-Dearborn 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

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

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

Database Management System

Transaction Processing

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

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

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

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