In my last blog on legacy systems I talked about what they were and weren't. In this one I'm going to expand on this and how they fit into the business process lifecycle.
Like most developers the centre of my work life is the software development process. This might involve a business analysis phase before and some support afterwards but this is a relatively small percentage of my time.
The 'software development centric' view of the world is below (this is the 'SDLC diagram' and your own process may differ but will share elements). There are two parts that interact with the outside world - requirements and deploy (which may be lightweight and frequent) and the external interactions are wrapped in that.
For some businesses (e.g. public facing web sites) the software IS the business and there is no significant period before or after the software development - it occurs constantly. These businesses are very interesting to us developers for this very reason (and therefore the projects often discussed at conferences) but are actually the exception. For the majority of organisations their individual IT systems perform a function that constitute only a small part of what they do.
Therefore users of our software view the world differently. The software development phase is a very small part of their business processes lifecycle and lifespan. They view the world a little more like this:
Most of the processes they execute will originally have been done ‘manually’ (I include generic software tools such as spreadsheets) and may been done this way from 6 months to 100 years. (If you think I'm exaggerating with '100 years' then you should speak to someone who's worked with an old insurance company!)
Eventually it will be decided that it is cost effective to develop bespoke software (or spend a lot of effort configuring BPM/CRM etc software). This process may be iterative and deliver value quickly but will be mostly complete after a relatively short period of time (compared to the organisation’s lifespan).
It is now fully live and a software team will consider it to now be in its maintenance phase. From the organisation's point-of-view this is where the real value is extracted from the system. Very little money is being spent on it but it is being used and either helping to generate revenue or increasing the efficiency of a process.
As time goes on there will be a decreasing number of changes made to it. Eventually it will be considered ‘legacy’. Ultimately the system will reach end-of-life and replaced when no longer fit for purpose.
If we were going to scale the diagram to indicate time then it might look like this:
These are kind of lifecycle times that I've experienced and yours may differ - this will depend largely on the industries you work within.
Therefore 'legacy' should be viewed as a phase in the lifecycle of the process. Note that I have a small arrow going back to Software Development from the maintenance/legacy phase as it may have upgrades or additions made many years after being deployed.
A comment on my previous blog post said that they refer to 'legacy' systems as 'mature' as this has more positive connotations. I think it also accurately reflects legacy as being a stage of a lifecycle rather than any particular indication of quality.
Lastly I'm just going to quickly plug my talk at QCon again (Modern Legacy Systems) which explores some legacy issues, makes suggestions about approaching them and how to leave a good legacy rather than a bad one. If you haven't booked your place at QCon yet then you can use code ANNE100 to get £100 off.