Working with Legacy Systems
This book is 100% complete
Completed on 2016-10-17
About the Book
There comes a point in everyones I.T. career when they become responsible for a legacy system. This is inevitable and I call it the Penelope Principle. Like the Peter Principle (where people are promoted to their level of incompetence) and the Dilbert Principle (incompetent workers are promoted to where they can do least damage - management) this should be accepted and worked with rather than being fought against. It is stated thus:
All I.T. workers will be promoted into a position where they become responsible for a Legacy System
However the I.T. industry is obsessed with new technologies and new projects. University courses, books, magazines and conferences focus on what is new and assume you always start with a clean slate. This isn't what actually occurs in the real world and I hope what follows fills some of this gap. This book is NOT intended to present a formal methodology but is aimed at all the Penelopes out there who need a guidebook to help them with their first legacy system.
Part 1 - Definition, Issues and Strategy
What is Legacy?
- An IT centric view of the world
- Systems Development in Context
- Systems Development Scaled with Time
- Examples of Real Legacy Systems
- No Documentation
- Lost Knowledge
- Hidden Knowledge
- Unused Functionality
- No Coherent Design/Inconsistent Implementation
- Fragility (vs. Stability)
- Tight Coupling
- Loose Coupling
- Zombie Technologies
- Organisation Constraints and Change are reflected in the System
- External Processes have evolved to Fit around the System
- External Systems have evolved to Fit around the System
- Decaying data
- Now What?
Reasons to be Cheerful
- A legacy system is a successful system
- You have real users you can talk to
- You can learn a lot about the business
- You can have a large impact quickly
- It’s important, but not trendy, so you’ll get paid well!
- Ignore it
- Incremental Improvement
- A special note on Decommissioning
- What is Legacy?
Part 2 - Investigation and System Review
- Architectural Description and Review
- Locate the stakeholders
- End Users
- Support Staff
- System’s Infrastructure Staff
- Audit and Compliance
- Budget Holders
- Third Party Suppliers
- Developers/Software Engineers/Database Analysts
- Document the Stakeholders
- Why Sketch?
- Context Diagram
- Container Diagram
- Component Diagram
- C4 - Classes
- What else can be done?
- Further Static Analysis
- Further Dynamic Analysis
- Account Maintenance and Lifecycle
- Cryptographic Keys
- Third Party Passwords and Keys
- Lack of Patching
- Moving from Closed to Open Networks
- Modernising Data Formats
- New Development and Copied Data
- Server and Infrastructure Consolidation
- Improved Backup Processes
- Checklist of Questions and Actions
Part 3 - Making Changes
Safely Making Changes
- Virtualisation is your Friend
- 50,000 Foot view of the virtualisation process
- Actions to make a system safe to change
- External Dependencies Required for Testing
- Duplicate Test System Data Becomes Stale Quickly
- Internal Coupling Stops You Swapping Components
- Changes Cause Unexpected Errors
- Licensing and Regulation Issues Running Multiple Copies
- Structural Changes for Disaster Recovery/High Availability
- What have we Achieved Already?
- Bad Data
- Removing Unwanted Data
- Data Cleansing
- Removing Unneeded Components
- Removing Unneeded Tasks
- Process Cleansing
- Removing Unused User Options
- Don’t Underestimate a Resource Boost
- Re-Examine your Application Settings
- Optimise the User’s Actions
Leaving a Good Legacy
- Why Bother Leaving a Good Legacy?
- Design Considerations
- Safely Making Changes
Appendix 1 - Example Legacy Scenario
- Very Brief Overview
- Why this example?
Appendix 2 - Legacy Project Questions
- Why a List?
- References and Bibliography
- Version History
- Acknowledgements and Thanks to:
- Appendix 1 - Example Legacy Scenario
The Leanpub 45-day 100% Happiness Guarantee
Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms...