Context |
A legacy system is to undergo reengineering to realise benefits for
the organisation. You wish to minimise the risk of: system outages during
cut-over; bugs in the target implementation; project cancellation; changing
requirements; and systems becoming unsupported. In addition, you need to
make best use of limited resources.
Although you expect reengineering to benefit the organisation, such
an activity will, itself, carry risks which are difficult to predict, quantify
and obviate. The scope of the project appears to be too large for the amount
of resources available to support the necessary effort. If the project's
timescales are stretched so as not to overload resources, requirement are
more likely to change. If extra resources are acquired (for instance staff
and equipment), project costs will rise and there will be an extra training
burden. Changing requirements threaten to undermine reengineering efforts,
yet you cannot ignore changing requirements since the credibility of the
project, and hence its future viability, depends on satisfying users and
business objectives. |
Consequences |
Decisions on how best to decompose the legacy could be based
on any existing hierarchy of interfaces, logical code and data or the likelihood
of certain hardware or software components becoming unsupported. Alternatively,
tackle mission-critical phases first to raise the profile of the project.
If databases are migrated early, redundancy can be identified which can
help rationalise subsequent phases. Stand alone applications are more straightforward
to migrate than those which are tightly coupled with other systems. This
approach may lead to a quick success which helps the project's credibility,
but could overlook more critical migration candidates.
When some application has its interface, logic and data too tightly
coupled for them to be individually excised, you may wish to wrap that
part of the legacy. However, this will perpetuate the use of potentially
unsuitable legacy components.
Since the system is operational after each phase, the benefits of the
project can be realised quicker than if the whole legacy were migrated
and deployed at once. Also, bugs are easier to find and correct in a small
component than in a large system. This reduces the project's risk and inconvenience
to users.
If, while balancing the resources and effort required for a phase, there
is a significant disparity, consider subdividing or combining phases. Additionally,
to make best use of different team skills, preparation for a later migration
may be able to take place in parallel with the deployment of an earlier
phase.
Requirements creep is always a risk while reengineering. However, with
each phase, new requirements can be accommodated throughout the project.
If you suspect change is likely, you may wish to reengineer early those
phases which are less likely to be affected. In addition, if each phase
is delivered quickly, users may have less time to think up changes.
Realising benefits early, reducing the impact of bugs and minimising
the disruption of new and changing requirements gives the project credibility
and will help secure its future funding. However, if circumstances change
and the project is not to be continued, the end of each phase leaves the
system operational and having prioritised the phases, the most important
issues will already have been addressed.
It is likely that there will be a number of dependencies between system
components. Using gateways, you will be able to let disparate parts of
the emerging architecture communicate. If you are ultimately aiming for
a distributed system, early adoption of a middleware product allows you
to provide consistent interfaces between components, so insulating the
system from changes that occur behind the interfaces.
Cutting over from the legacy to the target is risky. You may wish to
let the legacy and target components coexist until it is convenient to
change to the target. However, maintaining a legacy and target implementation
of the same function is costly. Therefore, plan to retire legacy components
as early as possible. For databases, this may be achieved by restricting
updates to the new database and only conducting queries on the legacy -
gradually the legacy will die. For a user interface, invest in training
as near to deployment of the new interface as possible and make users aware
that the old interface will cease to be operational beyond a certain date.
In this way, users are less likely to forget what they have learned and
revert back to the legacy interface. If they do revert back or are slow
to adopt, they know they have a limited to time to conform and will feel
encouraged to do so. |