Legacy issues and their
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
• User involvement did not exist
• Solutions were machine-friendly rather than user
• 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
• Prevalent in central government, transportation,
energy and the financial sector
What causes a system to become
• 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
• being usable by the organisation
– (suitability of the system to the organisational
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
• Development
– major legacy hazard
• Data management
– architecture, use and
– openness
Software Quality
• Component quality
– Quality of the written software within the
• 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
– 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
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
Causal Dimensions of Legacy Status
• System suitability
– Suitability to organisation’s
– Suitability to organisation
– Suitability to process
• Underlying platform
– Hardware, Operating system,
Networking, Development
environment and Data
• Software quality
– Component quality
– Design quality
– Change management quality
Legacy Effects
– Asset value goes down
•Mission criticality
– Ease of operation goes down
– Ease of maintenance
• Cost of maintenance and
resistance to it
•User satisfaction
• Availability of resources
•Ease of testing and auditing
• Program size and
– Ease of migration / evolution
•Ease of use of new technology
• Dependence on individuals
Definition of legacy status
• Adversely effects
• Causes are lack of
– Asset value
– System suitability
– Ease of operation
– Underlying platform
– Ease of maintenance
– Ease of migration /
– 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.
• 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
– Reuse of data over networks and the internet
• Data warehousing
• Data migration
Code reuse
• Vertical wrapping
• Horizontal wrapping
• Application wrapping
Redevelopment / renewal
Renew iteratively
Restructure software
• 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.

Legacy issues and their resolution