SwayingPalmsAndShiftingSand

PublicReengineering Wiki

Context

At some time in the future, you will replace your legacy system. The circumstances under which this will happen cannot be predicted and the nature of that change process is unclear, but it will happen and it will cause problems. Your organisation has Business Processes (BPs) which are constantly changing to meet market demands (the swaying palms). The IT legacy (the shifting sand) is based on a widely used generic, domain specific package, but this is being constantly customised to accommodate the changing BPs. When the legacy system is replaced, another domain specific package will take its place. This package will have to have (or be given) similar company specific functionality as the legacy. The organisation would resist developing their own package. Because of it fluid state, the current legacy is poorly documented and knowledge about it resides in the minds and notebooks of the programmers. The customisation is complex and maintenance is expensive.

Problem

How can the upheaval of the inevitable change in IT systems be minimised?

Solution

Develop separate applications in lieu of adding complexity to the legacy. Model the domain to capture business objects. Introduce a translation layer between the BPs and the legacy, communicating through the business objects as much as possible.

Consequences

This pattern offers a proactive strategy to help prepare for the unknown circumstances under which the legacy is to be replaced. By having new and distinct applications separate, the growth in the legacy's size and complexity can be kept to a minimum. The translation layer can protect the BPs from changes in the IT infrastructure to a certain extent and vice versa. Change will still introduce problems but the effects will not be as great.

Figure 1 shows the legacy system supporting the organisation's BPs. The communication between the business and the legacy is conducted through the generic, unchanging business objects - when such objects exist. Since circumstances are constantly changing and the business objects only reflect part of the organisational artefact, the BPs need to communicate directly with the legacy as well. In other words, the legacy is partially wrapped.

Figure 1 - Swaying Palms & Shifting Sand

You may wish to consider rationalising the responsibilities of the legacy in which case Divide & Modernise and Middleware may be of interest.

When modelling the domain, bear in mind that any resulting model will soon be out of date and that only certain entities (for instance invoice or customer) may be all that is of use.

Known uses

A project in a UK bank is employing just such a strategy. Their legacy system is expensive to maintain and will be replaced at some time in the future. Traders in the bank are constantly creating new types of deals as markets and opportunities appear and evolve. These deals are difficult to reconcile with the legacy system until the code has been amended to accommodate them. Their business constants are concepts such as price.

• Start Here in this Web
• Categories
• Index
• Recent Changes
• FAQ