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 lifetime using techniques like re engineering Socio Technical Systems Lagacy systems are more than just software systems Sommerville describes legacy systems as sociotechnical 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 Support software Runs on System hardware Uses Runs on Application software Uses Application data Embeds knowledge of Uses Business policies and rules Constrains Business processes 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 Program 1 File 1 Program 4 Program 2 File 2 File 3 Program 5 Program 3 File 4 Program 6 File 5 File 6 Program 7 Database Management System Program 1 Program 2 Program 3 Database management system Program 4 describes Logical and physical data models Transaction Processing Account queries and updates Teleprocessing monitor ATM s and terminals Serialised transactions Accounts database 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 objectoriented 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 Shared memory F1 F4 F2 F3 F5 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 objectoriented 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