For most people, in most situations, being passed a legacy is a good thing. Perhaps their long-lost uncle has left them a stately home filled with antiques. Or a legacy might be a valuable art collection given to a museum or the work of a famous author. However, in Information Technology, it is a dirty word filled with innuendo and often used as an insult. This is a strange situation and we should define exactly what we mean by legacy before addressing how to deal with it – and even if we should deal with it!
When we refer to a system as being legacy what we're really saying is that the system is built in a way that differs from how we'd choose to do so today. Legacy systems may have been written well, using the best technologies and tools available at the time, but those technologies are now out-of-date. A system written in 2001 using Java 1.2 and Oracle 8i may have made perfect sense but if you wrote it now, you'd at least use the latest versions available or even something different entirely (Scala, MongoDB, and so on didn't exist then).
Like most developers, at the center of my working life is the software development process. This might initially involve a business analysis and some support afterward, but this takes up a relatively small percentage of my time.
A software-development-centric view of the world is as follows (this is the Software Development Life Cycle (SDLC) diagram and your own process may differ slightly). There are two parts that interact with the outside world – requirements and deployment (which may be lightweight and frequent) and external interactions are wrapped in those phases.
Figure 1.1: An example software development life cycle
For some businesses (for example, public-facing websites), software is the business and there is no significant period before or after software development – it occurs constantly. These businesses are very interesting to us developers for this very reason (and therefore, these projects are often discussed at conferences); these are the exception. For most organizations, their individual IT systems perform a function that constitutes only a small part of what the organization does.
Therefore, software users view the world differently. The software development phase is a very small part of their business processes, life cycle, and lifespan. They view the world a little more like this:
Figure 1.2: The life cycle in context
Most of the processes the software users execute will originally have been done manually (I include generic software tools such as spreadsheets) and may have been done this way for 6 months to 100 years. (If you think I'm exaggerating with "100 years" then you should speak to someone who's worked for an old insurance company.)
At the end it will be decided that it is cost-effective to develop bespoke software (or spend a lot of effort configuring BPM/CRM software, and so on). This process may be iterative and deliver value quickly but will be mostly complete after a relatively short period of time (compared to the organization's lifespan).
The software is now fully live, and a software team will consider it to now be in its maintenance phase. From the organization'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 is 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 be replaced when it is no longer fit for its purpose.
If we were going to scale the diagram to indicate time, then it might look like this:
Figure 1.3: The life cycle in context and scaled with time
These are typical life cycle times that I've experienced and yours may differ – this will depend largely on the industry you work within.
Therefore, legacy should be viewed as a phase in the life cycle 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 many years after being deployed.
Note
Line-of-Business Systems versus Others
It was pointed out to me (thanks to Robert Smallshire) that the life cycle I've described best fits line-of-business software development and other types of systems that may vary greatly (for example, the control systems for embedded devices). This is true and reflects my personal experience but the statements on differing perspectives still hold.
I wrote a blog post covering much of this and someone commented that they refer to legacy systems as mature, as this has a more positive connotation. I think it also accurately reflects legacy as being a stage of a life cycle rather than any indication of quality.
A system maintained by professional programmers would be periodically upgraded and migrated to new technology when required, so it may never be mature/legacy. However, this is rarely a decision for programmers – it's a management decision. To be fair to management, does it really make sense to spend large amounts of money continually upgrading a system if it works? If the programmers and systems team did a good job, then no changes may be needed for many years. This indicates a high return on investment and a good quality system – a legacy!
Of course, when you do have to make changes or additions, you have a very different set of issues compared to modifying a system that is being continually developed.
Giving an example in a publication is dangerous as, in five years, it might be hopelessly out of date. However, considering the subject matter, I shouldn't make this argument. Look at the following:
Figure 1.4: © Dave Ross sourced from Wikimedia
Is this a legacy system? It's a museum piece. This is an IBM360 and was once the most popular computer on the planet. However, there are no commercially working examples left and they can only be found in museums.
This shouldn't surprise us, given the example timeline and arguments from earlier. Systems will be end-of-life or modernized eventually and it's very rare for a working system to be this old. So, what are the types of legacy systems you're most likely to come across? This will obviously change with time (and depends on the organizational areas you work within), but they are most likely to be:
Between five and fifteen years old
Without maintenance for two years
Using out-of-date APIs or technologies
If they don't meet these criteria, then you are unlikely to consider them to be legacy. Some examples are:
Java 1.2/1.3/1.4 running under Solaris 8 on an Ultra Sparc III server using Oracle 8i
C# 1.0, Windows server 2000 using SQL Server 2000
Objective C on NeXT server
J++/J#, VB6, FoxPro, Brokat Twister
A combination of spreadsheets, macros, and shell scripts
I'll cover common issues in the next section, but the preceding examples have different problems even though they are technologies from between 10 and 15 years ago. The first two (Java/Oracle and the .net stack) are very out of date but are all supported technologies. These should be simple to upgrade and support but are likely to be challenging to modify. The next two involve hardware and software that are discontinued. This will be much more challenging. Lastly, we have the very common situation of a system being bolted together from 'office tools.' In this book, I'll be covering these kinds of legacy systems.