A few years ago I was working in an environment where a number of systems collaborated to deliver a truly mission-critical application. One of the component systems – call it X – was hosted in a ClearPath platform. In a report, an independent consultant noted something to the effect of “X works well but it is a legacy system and therefore limited.”
To the best of my belief, beyond knowing very roughly what X did and that it worked well, the author of the report knew nothing more about X or the platform on which it ran. But somehow he felt constrained to conclude that X was limited because it was a legacy system. In fact, X was – and still is – very stable, meets all its business goals, including delivering a fast, even response time, is adaptable and open to a variety of external interfaces, and runs in an up-to-date platform.
So what does legacy mean? Is it a question of age, system type, or what? In real life, a legacy is regarded as a positive thing. Not in IT: legacy has become loaded with negative baggage. I think we can trace the problem to the so-called client/server revolution of the late 1980s and 1990s. Legacy systems became equated with mainframes, which, contrary to the evidence, the prevailing orthodoxy viewed as expensive and difficult to use. The client/server revolution conspicuously failed to deliver but a negative view of mainframes has partially stuck.
Seacord., Plakosh and Lewis of Carnegie Mellon SEI ( in ‘Modernizing Legacy Systems’, Addison-Wesley, 2003) provide a better definition: ‘Software systems become legacy systems when they begin to resist modification and evolution.’ There is no mention of system type or age, just that they resist modification and evolution.
But this definition begs the question: how do we quantify ‘resisting modification’? Here’s a possible answer.
IT systems have to deliver the services the business requires in a timescale and cost that meets business needs. For each set of new business requirements, we can determine a required combination of time and cost, which we may write as [time, cost] required. Setting it is a business decision and is likely to vary according the nature of the requirements. For example, there may be an elapsed time window of six months to launch a new product before competition catches up. Time is therefore a critical factor in that case.
However, what is possible will depend on the system to be modified. There will be a possible time and cost – what is achievable – associated with implementing each set of requirements in the system. We can write this as [time, cost] possible. possible.
Experience of earlier implementations, the state of the system, available skills and a number of other factors can be used to determine the possible values for different kinds of implementation.
We can now define a legacy system as one where, consistently and for most sets of requirements,
[time, cost] possible > [time, cost] required (A)
Some corrective action is required if A is true. I do not propose here to go into what should be done, other than to observe that it is almost always better to modernise an application, for example exposing it as services in a service-oriented architecture, than to discard it and start again. See my previous blog, What is SOA and why does it matter?, for more on SOA.’
But it’s high time to dump the word ‘legacy’ altogether, as it will remain loaded with baggage. We should simply consider whether or not A applies to the system concerned and act appropriately.