Within the IT industry we all know the danger word: Legacy systems. When this buzz words falls you are doomed.
Most of the time it means some project must be done that has little business value in itself. This since everyone is still happy with the functionality, except some always complaining software engineers who seem not to be able to solve simple incidents and always complain with when some simple new functionality is required.
Legacy systems and projects to turn legacy systems into new sexy systems again are often doomed before starting. Since software upgrades only is too costly, selling such life cycle management projects often requires some creativity towards business stakeholders. So for many years selling costly legacy projects, or simple upgrades of an ERP systems, means telling that the result of such a project is not only that real disasters for business continuity are mitigated, but also that latest new sexy technologies will be added. So in 2019 you sell these projects with block-chain, mobile responsive and machine learning as the real new business values.
Legacy system often face software rot. Software rot , also known as code rot, bit rot, software erosion, software decay or software entropy is either a slow deterioration of software performance over time or its diminishing responsiveness that will eventually lead to software becoming faulty, unusable, or otherwise called “legacy” and in need of upgrade. This is not a physical phenomenon: the software does not actually decay, but rather suffers from a lack of being responsive and updated with respect to the changing environment in which it resides. (https://en.wikipedia.org/wiki/Software_rot )
An issue with the rot metaphor is that it puts the blame for having legacy systems on the wrong piece of the puzzle. If software becomes unusable and hard to change over time, it’s not because of any alteration to that software that needs to be reversed. Rather, it’s the foundation on which the software has been built, ranging from the actual hardware via the operating system to programming languages and libraries, that has changed so much that the software is no longer compatible with it.
So a legacy system that must change has some unstable foundations. This can be hardware, used software frameworks, operating systems or a programming languages that every developer who likes developing really refuses to learn or do. Often a combination of these factors are seen with legacy systems that are build on some ERP system where the original vendor has been taken over by some very large software company who keep increasing license fees while minimizing maintenance and support.
A good way to prevent the legacy system danger is to use the earthquake metaphor. So what should you do in order to prevent a house being destroyed by an earthquake?
So instead of hiring very expensive consultants just think of strategies that are needed when facing the risk of earthquakes:
- Avoid risk at all cost. Build on stable foundations only. Don’t build a house in a zone with seismic activity, don’t accept software dependencies unless they have a very good track record for stability.
- Make your construction robust. Make your house solid enough to withstand typical seismic activity in your area, with a safety margin.
- When shaking foundations cause damage, do repair work before collapse happens.
- Accept that your construction is short-lived. In case of collapse, start from scratch.
Of course for enterprise architects the fourth strategy is unacceptable. And software developers that like innovation will not be happy with only using very stable frameworks which is a consequence of option one.
By using these simple principles when constructing large (new) systems the risk of a total collapse can be mitigated.
From a systems dynamics viewpoint: Second order effects are important when preventing software rot: E.g. the time scales of changes are themselves subject to change. And other second order effects are that the risk factor and probability of risks will differ in time.
