Context
a legacy system whose technology (e.g. database) is obsolete and soon to be unsupported. An identifiable area of functionality, relatively
well localised in the legacy system, of which a generalisation would be useful, but is not immediately mission critical.
Problem
Modification of a dying legacy system is undesirable. Wrapping the system, sometimes useful, is not a good solution here because it
perpetuates the use of unsupported technology. If a new system is developed ``from scratch'' to replace part of the old, the developers will
be expected to provide ideal functionality: it will be impossible to manage expectations and the project will become huge and
correspondingly risky.
Solution
Begin by mechanically translating the relevant part of the database to a modern format. Rewrite the relevant code without yet attempting to
change its structure, thus acquiring a new system providing part of the functionality of the old, but no more, and without substantially
different structure from the part of the old system. Remove the now redundant data and code from the rest of the legacy system, handling
the consistency and gateway issues. Then consider the reengineering of the now-separated, manageably sized system.
Consequences
Work proceeds in distinct manageable phases. Even if ``requirements explosion'' does overtake the final restructuring step, the main aim,
that of removing the dependency of the functionality on the obsolete technology, will have been achieved.
On the negative side, code and data is migrated before the new requirements on the system are analysed, which means that some of this
effort may turn out to have been wasted.
Major outstanding questions include: can the problem of data dependencies between the new and the old system be solved, and how? Will
the restructuring of the new system in fact be [politically? technically?] possible and/or desirable?
Contributors
Perdita Stevens, Rob Pooley
Related pages: ReengineeringPatterns
|