Legacy issues and their resolution l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 27

Legacy issues and their resolution PowerPoint PPT Presentation


  • 317 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Legacy issues and their resolution

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


Legacy issues and their resolution l.jpg

Legacy issues and their resolution


Topics l.jpg

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

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

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

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

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

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

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


  • Login