asset or liability?

on this page

> three perspectives on legacy
> legacy and alignment
> legacy and understanding
> packages as legacy
home page contact us
see also

> evolution
> maintenance
> Reusing Legacy: Models, Data and Systems (pdf) (SCIPIO white paper)
> Component-Based Development for Y2K and Euro

legacy systems as italian food

Spaghetti Many separate strands, tangled together.
Pizza You try to cut out a wedge of pizza, but it remains connected to the rest of the pizza by innumerable strands of elastic cheese.
Lasagne What were once separate layers (of cheese, pasta and other ingredients) have now been melted into a solid mass.

it takes two to tangle

Once upon a time, computer programmers could easily recognize spaghetti code by the presence of one word: GOTO. It was considered harmful; programming languages were developed in which GOTO was unnecessary or impossible; generations of programmers were trained to resist anything that resembled a GOTO. But the pattern or meme mutates, and reappears in a new form, designed to bypass our programmed resistances. Large complex computer systems are now being developed; each software component may be impeccably designed and coded, but these software components are wired together (using some form of scripting language) into something that we can only regard as a new manifestation of spaghetti.

The use of good patterns, and the avoidance of negative patterns or anti-patterns, can easily become trite or obsessional. An interesting pattern mutates, evolves, morphs. We must be alert to every new manifestation.

Three perspectives on legacy systems

There are three perspectives on legacy systems, which have different conceptual status.  We need to articulate all three perspectives, if we want to have a complete theoretical and practical account.
PAST Legacy as a sociotechnical artefact, the product of a past development process/project.  Or perhaps the product of a sequence of maintenance actions on such an artefact.  We must presume that such development or maintenance was carried out in terms of a set of intentions (business objectives, design priorities, etc.) then in force.
PRESENT Legacy as a sociotechnical system-in-use.  As I have pointed out elsewhere, there is often a large gap between a system-as-developed and a system-in-use.  In the users' hands, the system moves away from the development intentions.  The users often find ways to do things that were not anticipated by the developers, or even that the developers specifically sought to prevent. (I have some extreme examples of this.)
FUTURE Legacy as an asset with ongoing value, with the potential to survive and evolve, relative to emerging intentions.

(For OO fans, of course, inheritance is a Good Thing, while legacy is a Bad Thing. Got that?)

Legacy and alignment

Legacy Systems have been defined as follows:

"Socio-technical systems that are vitally important to the working of the organization, but which fail to meet the need for which they are now intended."

This definition brings to centre-stage the alignment between a sociotechnical artefact on the one hand, and a set of intentions (or requirements) on the other hand.  The intentions for this artefact have shifted, and the artefact is now out of alignment with these intentions.

Obviously alignment is not a simple Yes/No,  Few if any artefacts are perfectly matched to the users' intentions, even when first developed.  And all legacy systems, if they are still in use at all, can be presumed to satisfy some requirements.  A system is more-or-less aligned, adequately or inadequately, relative to a specific set of intentions.  But which intentions, and whose?

The judgement that a legacy system now fails to meet its needs, rests on a logically prior judgement about what its needs are - in other words, of all the requirements and desires of all the users, which ones naturally belong to this specific legacy system?

Here's an example.  In the finance sector, the launch of a new financial product usually generates some new requirements on IT systems.  These could either be regarded as additional requirements for existing (legacy) systems, or as requirements for new systems that would operate in parallel with the existing systems.

Another example: Many billing systems still in operation were designed and built before the advent of direct debit.  Instead of modifying the billing system itself to support direct debits, a separate direct debit system was built.

In practice, the judgement as to whether to extend/modify an existing system, or to build a new system, depends largely on a perception of the ability of the existing legacy system to accommodate some or all of the new requirements - or rather the ability of a given team of software engineers to make this accommodation.

This judgement also depends on how the legacy system is perceived - its identity.  When an organization tries to accommodate something new, there is a question where it is going to belong within the organization.  Which manager, or which department, is going to take responsibility for it?  Whose budget is going to pay for it?  Sometimes these questions are easy, or even trivial to answer, but sometimes there is a difference of opinion, resolved by debate between peers, or escalation to a higher level of management.

The evolution debate needs to include a discussion of the evolution of intentions, as well as the evolution of artefacts so that they better satisfy these intentions.

Legacy and understanding

In order to understand where things belong in an organization, one needs a model of the organization (which may be an implicit mental model or a formally notated model, and is not always complete or consistent).  In practice, each participant has his own slightly different model of the organization, and what happens in these debates is that differences between the different models are exposed and clarified.

Something similar happens with new IT requirements.  One has a mental model of the architecture of legacy system, and each participant in the discussion may have a slightly different mental model.  People are often influenced by the names of legacy systems - they interpret the name of a given system as a sign that this system ought to be the right place for a given requirement. Because this system is called the Billing System, it ought to handle everything that we regard as Billing.  (This is sometimes seen as a scoping question, to do with the boundaries between Billing and other systems.  By characterizing it as a question of identity, I am going further than the scoping question, problematizing the very integrity and survival of an entity called The Billing System.)

Users' mental models of legacy systems are important in another way as well.  The actual use of a system by actual users depends on their mental models of the system.  The users often don't use all the features of the legacy software, and it may sometimes turn out that a new requirement can be satisfied by switching on an existing feature and retraining the users, with no need to restructure the legacy code.  In other words, you are changing the socio- part of the legacy system, and leaving the technical part the same.

Regarding packages and components as legacy

Legacy thinking also applies to the use of COTS (commercial off-the-shelf) software as to in-house and bespoke applications.  The specific ways that we use Lotus Notes in a given organization, or the specific implementation of SAP - these also constitute legacies, with many of the same issues.  (There are also practical questions about whether and when to upgrade the package to the vendor's latest version, which also have to do with the legacy invested in the previous software version.)


home page

contact us

This page last updated on October 29th, 1999 
Copyright © 1999 Veryard Projects Ltd