Legacy issues and their resolution
1 / 27

- PowerPoint PPT Presentation

  • Updated On :

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about '' - spiro

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Topics l.jpg

  • 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 l.jpg
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 p rofile of legacy systems l.jpg
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 l.jpg
What causes a system to become legacy?

  • Lack of System suitability

  • Lack of Underlying platform suitability

  • Lack of Software quality

System suitability l.jpg
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 l.jpg
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 l.jpg


e.g. 16-bit to 32-bit

mainframe to PCs

Operating system

fast changing


lan, wan, differing c/s models

Development environment

major legacy hazard

Data management system

architecture, use and scale


Underlying platform

Software quality l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg

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

Underlying platform

Software Quality

Causal Dimensions of Legacy Status

Legacy effects l.jpg

Asset value goes down

Mission criticality


Ease of operation goes down

User satisfaction

Ease of testing and auditing

Ease of migration / evolution declines

Ease of use of new technology


Ease of maintenance declines

Cost of maintenance and resistance to it

Availability of resources

Program size and complexity

Dependence on individuals

Legacy Effects

Definition of legacy status l.jpg

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

Definition of legacy status

Finding a solution l.jpg
Finding a solution

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

Solution strategies l.jpg
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 l.jpg
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 l.jpg

  • 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 l.jpg
Data reuse

  • ODBC

    • Reuse of data over networks and the internet

  • Data warehousing

  • Data migration

Code reuse l.jpg
Code reuse

  • Vertical wrapping

  • Horizontal wrapping

  • Application wrapping

Redevelopment renewal l.jpg
Redevelopment / renewal

  • Redevelop

  • Renew iteratively

  • Restructure software

  • Re-host

References l.jpg

  • 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 l.jpg
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.