Divide and Modernise
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