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: Low business value
Low technology condition
Retire
High business value
Low technology condition
Redevelop
Low business value
High technology condition
Reassess
High business value
High technology condition
Renew
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.