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 –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 System Suitability Software Quality Underlying platform

Legacy Effects –Asset value goes down Mission criticality reliability –Ease of operation goes down User satisfaction Ease of testing and auditing –Ease of migration / evolution declines Ease of use of new technology Scalability –Ease of maintenance declines Cost of maintenance and resistance to it Availability of resources Program size and complexity Dependence on individuals

Definition of legacy status Adversely effects –Asset value –Ease of operation –Ease of maintenance –Ease of migration / evolution Causes are lack of –System suitability –Underlying platform suitability –Software quality

Finding a solution Slee and Slovin (1997) proposed a 4R portfolio matrix: -

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. – 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.