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