Arcus Global
June 14, 2016
Does your organisation have a system, which while critical to some business function is proving nearly impossible to update and change? Does every upgrade cycle take months and require serious effort and testing? Is the application starting to creak at the seams and proving occasionally unstable? Are staff having to come up with creative workarounds to get their work done, because it’s just too hard to make the system do what it needs to do? Are talks of process change and transformation often blocked by what your technology will allow you to accomplish? Is it built on a technology platform that nobody has used to build anything new in the last decade?
If you can say yes to a good subset of these questions, you have a legacy system on your hands. Systems, by and large, don’t start out as legacies. They become legacies after having been instrumental to the business in achieving past goals. This is not a unitary process and not reducible to a single cause. Unfortunately, that means there is no simple answer to avoiding the problem either. There are, however, some common anti-patterns to look out for and try to avoid:
Death by excessive technical debt. A level of technical debt is almost inevitable with any larger software system. However, once you start stacking hotfix on hotfix and deciding to go for the immediate option to address the current issue every time, rather than taking the time to refactor and redesign poorly performing parts of the code-base you are entering a technical debt spiral. As with ordinary debt, the interests you pay on this technical debt will eventually overwhelm the resources you have available to pay it. At that point your system stagnates and becomes a legacy. Pro-active technical debt management is therefore a critical component in avoiding legacy systems syndrome.
Death by a thousand change requests. This often happens to successful systems. Because the system works well, it is extended simultaneously in a number of different directions at the same time without strong governance and the complexity of the requirements the system is meant to address grows beyond the ability of your team to manage. At that point, the coherence of the system is lost and because of the difficulty in understanding all the factors at play in any given direction of change, the evolution of the system grinds to a halt. Effective change governance and modularity of architecture are the key factors in trying to prevent this outcome.
Death by absence of expertise. Another classic. The system is built and remains relatively stable for a period of time. When significant change becomes necessary, no one who were part of the original team are around anymore and you’re back to trying to figure out how the whole thing works, something which is sometimes nearly impossible after the fact. Ensuring continuing ownership and accountability for the system goes some way towards mitigating this, as do strong support agreements with suppliers or structured knowledge transfer within an in-house team.
Death by obsolete technology. For long running systems, given the amount of change in technology we’re currently experiencing, it is inevitable that left to its own devices the system will eventually become obsolete. A process of guided architectural evolution that gradually modernises parts of the system as it matures, is critical to avoiding this. Picking a technology platform with a strong developer community and a supplier who is actively investing for the long term also helps.
