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.
Table of Contents
-
- Preface
-
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
-
Common Issues
- No Documentation
- Lost Knowledge
- Hidden Knowledge
- Unused Functionality
- No Coherent Design/Inconsistent Implementation
- Fragility (vs. Stability)
- Tight Coupling
- Loose Coupling
- Zombie Technologies
- Licensing
- Regulation
- Politics
- 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!
-
Strategies
- Ignore it
- Investigation
- Maintenance
- Upgrade
- Migration
- Incremental Improvement
- Replacement
- A special note on Decommissioning
- Conclusion
-
What is Legacy?
-
Part 2 - Investigation and System Review
- Architectural Description and Review
-
Stakeholders
- 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
-
Architectural Sketches
- Why Sketch?
- Context Diagram
- Container Diagram
- Component Diagram
- C4 - Classes
-
Further Analysis
- What else can be done?
- Further Static Analysis
- Further Dynamic Analysis
-
Security Considerations
- Passwords
- Account Maintenance and Lifecycle
- Cryptographic Keys
- Certificates
- 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
-
Preparation Issues
- 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
-
Stabilisation
- Why?
- 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?
- Documentation
- Tests
- Design Considerations
-
Safely Making Changes
-
Appendices
-
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
- Notes
Bundles that include this book
About the Author
Robert has been a developer since 1995 and worked in industries from energy management to investment banking. Much of this work has involved upgrading and migrating legacy systems with the occasional green-field project (with integration to legacy systems, of course). He has worked in the IT industry long enough to realize that ALL successful systems become legacy eventually.
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...
