| Context |
Your company is part of a group of companies. The group has a strategic
IT policy, part of which prescribes the standard packages which business
units should adopt. Your business unit has one or more legacy systems that
do not conform to the group's strategic preferences. It is difficult to
migrate to the target systems due the legacies' data and/or functionality
being incompatible with the target. |
| (Forces) |
You need to conform, but conformity will have associated risks,
costs and will take some time. Conforming provides the opportunity to make
improvements to the system. However, users may expect, or suggest, too
many improvements that will delay and add cost to the project. Users may
also be resistant to change. |
| Problem |
How do you move towards the corporate preferred packages? |
| Solution |
Migrate to an interim package that is readily compatible with the
legacy and target systems (see Figure 1). First identify such an interim
product, then migrate data and functionality. Finally, migrate to the target
system. Throughout the project, minimise changes to the system's external
views, for example do not radically alter screen and print-out formats.
Also, explain to users that the migration is like for like. Train
development personnel in the interim and target packages. Take the opportunity
to make improvements to the system whilst you are migrating, for example
clean up the data or improve the user interface. |
Figure 1 - Moving to Corporate Preferred Packages via an Interim
Package
|
|
Consequences
(aka Resulting
Context) |
By providing an interim package, work can proceed in manageable, stable
phases and so project risk is reduced. However, having to purchase it,
as well as the target system, will increase overall costs.
Since it is likely that the interim solution will have to exist for
a period until funding is available for the next phase, extra time will
be added to the overall project schedule. However, if funding does not
become available to move to the target, you are left with a working, stable
solution. Group can see you are moving towards their goal, nevertheless
the extra cost and time involved may not satisfy them. Unfortunately, the
longer the interim solution exists, the more time users have to become
comfortable with it and suggest new requirements.
The system's external views are similar to those in the legacy and
disruption to users and extra training is minimised, however you may have
to expend a great deal of effort in adapting the interim and target systems
to make them consistent.
Despite having explained that this a like for like migration in an
effort to reduce requirements creep, it is unlikely that system enhancements
can cease during the project. Fortunately, development personnel have had
suitable training to incorporate changes, but such extra training will
add cost to the project.
By carrying out housekeeping during the migration you improve the quality
of the system. However, too many, or too radical, changes may cause disruption
to users and could add to the burden of cost, time and risk. |
| (Related
Patterns) |
You could adopt Divide & Modernise and Middleware
to rationalise the responsibilities of the legacy before migration and
so reduce project risks. However you may add cost and time. In addition,
these other patterns include their own elements of risk.
When no interim solution exists, Live & Let Die provides
an alternative where the legacy and target can coexist. |
| Known
Uses |
This pattern has been seen in a small business unit of a large manufacturing
group. Their existing main business system was a highly customised database
product on an ageing mainframe. Its software and hardware were no longer
supported since the original vendor had gone out of business. The target
system was an MRP II package specified by group. It would have been difficult
and risky to convert the legacy's code and data to the target directly
and so an interim package was purchased. This package was supported and
would easily accept the functionality and data from the legacy. In addition,
its database was ODBC which would make the eventual migration to the target
MRP II package more straightforward. The final migration step is still
difficult since the MRP II package would necessitate changes to existing
business processes and product structures, but the overhead of having to
deal with data extraction and consistency has been reduced. |
Related pages: ReengineeringPatterns
|
