Legacy
I frequently hear "legacy application" used to describe old and poorly working systems, understandably these draw attention but consider all the systems in a modern enterprise and their technical age and it becomes obvious that the majority of business happens on "legacy" systems.
For any enterprise older than a decade the question should not only be about removing legacy. Any work done to day will be legacy in a year or two anyway, how much of the system landscape can and should be constantly rebuilt? Clearly most of our systems must and should be legacy systems, they should just be the kind of legacy, well working applications that don't require much attention. The principle must be to build things that can work unattended and be further improved and modernized easily.
Key legacy issues:
For any enterprise older than a decade the question should not only be about removing legacy. Any work done to day will be legacy in a year or two anyway, how much of the system landscape can and should be constantly rebuilt? Clearly most of our systems must and should be legacy systems, they should just be the kind of legacy, well working applications that don't require much attention. The principle must be to build things that can work unattended and be further improved and modernized easily.
The bad part
Assuming the legacy that is bad and needs removal the focus should be how to build replacements that are either vastly simpler to replace (small micro services comes to mind) if obsolescense is planned or less susceptible to cause problems in the first place.Key legacy issues:
- Competence, finding somebody competent (or willing) to deal with it
- Vendor lock in, costs for upgrades or replacement
- Dependencies, costs to change other applications depending on the legacy application
Comments
Post a Comment