Last time we were interested in understanding a bit more about the state of our IT systems, and whether we were being held back by what we could loosely term ‘legacy’. Perhaps a trickier question to answer however, is how we decide whether a system is legacy or not.
In the ideal world, when we built IT systems, we’d do so with a good understanding of requirements, and quickly enough that it would deliver a useful service on day one. Even if we had such an IT Shangri-La however, it would only remain so for a short while. Things change, and so therefore does the relevance of any given system. All systems follow some kind of decay curve, where consecutive events impact on a system’s effectiveness such that after a point, the benefits of having the system in place no longer outweigh its costs.
To further complicate things, we need to keep in mind that we’re not thinking about monolithic and isolated application stacks any more. Modern systems are more likely to be integrated with each other, and have dependencies with off the shelf components such as workflow engines and content management tools. Perhaps we should even throw virtualisation into the pot – is a legacy application running on a legacy OS still legacy, if the whole lot is packaged up into a virtual image running on a blade server?
An interesting article, of the top of my head, I’d define a legacy system from these three statements:
- That the operating system/layered components are no longer supported
- That the hardware is ‘out of support’ – we have to be careful here, you can support any server at cost
- That the server has been fully depreciated and therefore has no value
But then isn’t this linked to they way your buy capital equipment and say it’s four years, isn’t this too long from a support, energy efficiency and return on investment point of view? Who wants to keep a server for that long in terms of performance per watt and energy efficiency, the rate of change can be dramatic.