|
legacyasset or liability? |
> three
perspectives on legacy
> evolution
|
legacy systems as italian food
it takes two to tangleOnce 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. |
| 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?)
"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.
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.
| top |  |
|
Copyright © 1999 Veryard Projects Ltd http://www.veryard.com/sebpc/legacy.htm |