Legacy issues and their resolution Topics • • • • • • What is a legacy system? How ‘legacy’ is the system? Dimensions of legacy status Evolution and avoidance of legacy status Legacy assessment through cause and effect Moving on from a legacy system Evolution of the legacy • Original systems were granted as favours from above • User involvement did not exist • Solutions were machine-friendly rather than user friendly • As systems revolved around smaller, isolated businesses, there was less change • Development and execution took time • Systems were tailored to solving a current problem Common profile of legacy systems • Applications that are up to 35 years old • Part of an application portfolio that is vital to the running of the business • No time to shut down and replace • Badly designed, not integrated, expensive to maintain • Prevalent in central government, transportation, energy and the financial sector What causes a system to become legacy? • Lack of System suitability • Lack of Underlying platform suitability • Lack of Software quality System suitability • doing what the organisation wants it to do – (suitability of system to business process) • doing what the organisation needs it to do – (suitability of business process to organisational mission), • being usable by the organisation – (suitability of the system to the organisational environment). Reasons for problems regarding System suitability • Unwillingness to face change for political financial and cultural reasons • Constant need to refocus organisation’s mission, processes and culture – requires research, benchmarking and training • Occurrence of events separate reality from the system’s focus Underlying platform • Hardware – e.g. 16-bit to 32-bit – mainframe to PCs • Operating system – fast changing • Networking – lan, wan, differing c/s models • Development environment – major legacy hazard • Data management system – architecture, use and scale – openness Software Quality • Component quality – Quality of the written software within the component • Design quality – Quality of the current design, in snapshot form • Change management quality – How quality is assured while evolving system to meet changing requirements Quality of written software • Originally may be written in a clear, legible and flexible way • Maintenance results in change in style, organisation and functionality of the system. Older systems – Style - e.g. introduction of structural programming in a program using GOTO’s, or change from structured to object-oriented, or change from crafted code to generated code. – Organisation - e.g. program written with input, processing and output sections - maintainer puts processing code into the input or output sections. – Functionality - e.g. adding code to make current obsolete, without removing obsolete code Object-oriented systems • Number of tiers • Maintainers leave their mark! – How many tiers? – What’s in the control tier? – How much responsibility is given to each class? • Most organisations have not yet introduced standards for such issues. Quality of design problems • Manual implementation of methodology – resulting in errors, inconsistency, failure to maintain over changes, loss of traceability, mountain of paper • Change of methodology during lifetime of system – changes not retrospective, original design lost • Automated life cycle – with insufficient traceability, value addition or consistency Quality of change management • Software Process Improvement or Assessment models – Not in widespread use – Extremely difficult and intensive to implement – When depending on external sources, iterative improvement may be beyond organisation’s control Causal Dimensions of Legacy Status • System suitability System Suitability Underlying platform Software Quality – Suitability to organisation’s mission – Suitability to organisation structure – Suitability to process • Underlying platform – Hardware, Operating system, Networking, Development environment and Data management • Software quality – Component quality – Design quality – Change management quality Legacy Effects – Asset value goes down •Mission criticality •reliability – Ease of operation goes down – Ease of maintenance declines • Cost of maintenance and resistance to it •User satisfaction • Availability of resources •Ease of testing and auditing • Program size and complexity – Ease of migration / evolution declines •Ease of use of new technology •Scalability • Dependence on individuals Definition of legacy status • Adversely effects • Causes are lack of – Asset value – System suitability – Ease of operation – Underlying platform suitability – Ease of maintenance – Ease of migration / evolution – Software quality Finding a solution • Slee and Slovin (1997) proposed a 4R portfolio matrix: L o w b u sin ess v alu e L o w tech n o lo g y co n d itio n R etire H ig h b u sin ess v alu e L o w tech n o lo g y co n d itio n R ed ev elo p L o w b u sin ess v alu e H ig h tech n o lo g y co n d itio n R eassess H ig h b u sin ess v alu e H ig h tech n o lo g y co n d itio n R en ew Solution strategies • • • • • Leave them alone Deal with them gradually Implement change as a ‘big bang’ Solve the problem In-house / outsource Open assessment or assessment towards a particular solution Solutions for legacy systems • Solutions offered come from a wide variety of sources. • Rather than look at individual solutions, look at characteristics of those solutions. • Evaluate the solutions superficially, based on their characteristics, to give an impression of what problems they may solve / cause. Architecture • Component based – Not necessarily object-oriented – Good software component and design quality • Object oriented – Good software component and design quality – Infrastructures may be too ‘leading edge’ • Layered architecture – Promotes flexibility in adapting applications – Requires sophisticated understanding of platforms • Bespoke – enables process excellence, but not quickly! Data reuse • ODBC – Reuse of data over networks and the internet • Data warehousing • Data migration Code reuse • Vertical wrapping • Horizontal wrapping • Application wrapping Redevelopment / renewal • • • • Redevelop Renew iteratively Restructure software Re-host References • What legacy systems are: – Arnold (1989), Sneed (1995), Gold (1998), Ransom et al.(1998,99), Slee & Slovin (1997), SABA/SEBPC website. – Http://www.dur.ac.uk/CSM/SABA/legacy-sig/report.html • Software Engineering paradigms – Pressman (2000) • Platform choices – Laudon & Laudon (1999) • SAP R/3 – Huge number available now. Further references • Gartner group conference proceedings – Excellent for showing what is being used, rather than theoretical ideas – References not used, so descriptions or references for original material must be got elsewhere – O’Byrne, Patricia, Wu, Bing “Lace Frameworks and Technique – Identifying the Legacy Status of an Information System from the Perspectives of its Causes and Effects” 2000 International Symposium on Principles of Software Evolution (ISPSE 2000), Kanazawa, Japan.