I know it might sound like the flaming obvious, but the overarching driver to re-engineering a legacy system, and most particularly one that is core to the business, is that the risk and cost of NOT doing it must be greater than the risk and cost of doing it.
Despite the power of modern development tools and methods, it will almost certainly take longer and cost more to develop the replacement system than it did to build the legacy one. There are many reasons for this – undocumented features, algorithms and exceptions, convoluted and arcane logic, architectural challenges (e.g. business logic embedded at every layer from the UI to the controller to the database or even the lack of any distinction between these layers), entrenched thinking amongst all the key stakeholders (including IT), and the engineer’s resolve to ‘do it right this time’.
Big Bang – re-engineer in peace
The big-bang might be purest and simplest from the engineer’s perspective, but offers challenges in terms of keeping pace with necessary changes to the legacy system, managing stakeholder expectations (they will wait a long time before being able to see much and even longer to use anything), and team motivation (nobody wants to work on the old mess, they want to make the new one). Those managing the budget will look at the cool new technology being built and demand that rather than waiting for the new system, the new features should be retrofitted into the old system ‘to gain immediate payback on the re-engineering investment’. This of course takes people and attention away from the work on the re-engineered system, which extends the timescale, adds pressure to enhance the old version, etc.
And when the new system is ready, parallel running will often be a massive challenge, involving staff levels, training, support and contingency costs (read ‘disaster recovery’) that are difficult to predict at the start of the project.
Hybrid – build out the old
A hybrid approach involves re-developing the existing application in modules, gradually replacing the old with the new. This inevitably means that there will be an integration effort, making old creaky components and data work smoothly with the shiny, slick and well-designed new bits and data. A hybrid approach carries the risk and cost related to maintaining the old system plus maintaining the new components being used to replace or wrapper parts of the old one whilst simultaneously developing the new system. If new components are run alongside the old ones, maintaining a new, almost certainly richer and better designed data model alongside the old one will add considerably to the effort, increasing the duration and/or resource requirements of the project.
It is also challenging to make it a fully Agile project when parts of the new system have become ‘set in stone’ or at least much harder to modify by being put into production. And you will almost inevitably find yourself having to resolve issues in the hybrid system that would not have occurred either in the old or the new systems operating separately. It might be wisest to apply a hybrid Agile approach to a hybrid re-engineering project. Creating user stories will be less about establishing what users want to do and more about what they want to change when moving to the new system. You might call them “iterations” but really they will be more about sprints focusing on one or more functional features. There are many ways in which the Agile approach will be applicable – self-organising teams, story cards, burn-down and the like. But because there should be less uncertainty about the overall functional requirements, the project is likely to feel rather more waterfall than Agile – it will take some experimentation and thinking about to arrive at the right set of methods.
All projects have risks, but re-engineering projects have some unique risks that will need to be carefully assessed and managed. And as I said at the beginning, an important consideration is the cost of doing it v. not doing it at all. Doing it will mean that a significant amount of effort/cost/time will go into doing something that, once finished, will put you exactly where you were when you started. OK, maybe cleaner, shinier and with a more maintainable undercarriage, but not really doing anything that wasn’t happening before. That takes some serious stakeholder management – again the flaming obvious but too often overlooked.