1 / 27

Legacy issues and their resolution

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.

spiro
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Legacy issues and their resolution

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

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

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

  5. What causes a system to become legacy? • Lack of System suitability • Lack of Underlying platform suitability • Lack of Software quality

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  22. Data reuse • ODBC • Reuse of data over networks and the internet • Data warehousing • Data migration

  23. Code reuse • Vertical wrapping • Horizontal wrapping • Application wrapping

  24. Redevelopment / renewal • Redevelop • Renew iteratively • Restructure software • Re-host

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

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

More Related