Working in the COBOL mine

Summary

Legacy modernisation, then, is just one more example of where developers must learn to step out of the "technology" silo and consider `business’; they must be able to make fact-based modernisation choices driven by business imperatives. They must also avoid being driven by technology or, worse, vendor marketing agendas. The choices facing them are:

1. Full “Rip and replace” – throw away legacy systems and redevelop them from scratch. Expensive and wasteful; but can deliver a high quality system reflecting modern business practice (if the development is run properly and legacy domain experts are still available) and gets rid of expensive old-fashioned platforms. This may be the only option if legacy is undocumented and automated legacy analysis tools aren’t available.
2. Use of advanced replacement technology – similar to “rip and replace” in effect but with lower risk through the use of modern technology (such as Erudine, for example; or 4 GL frameworks such as Uniface from Compuware) to generate new systems efficiently. This assumes that domain experts are available; and/or that the legacy is well-structured enough to act as a “requirements spec”.
3. The “SOA approach” – extract services from legacy and make them available to more modern applications. Assumes a degree of legacy quality (modular design and a “good practice” approach) – and there’s a chance that the legacy doesn’t work in an SOA environment.
4. “Object Wrapping” – similar to the “SOA Approach” but at a lower level – wraps legacy as reusable objects. Assumes legacy quality and there’s an even bigger risk that the legacy wasn’t built to be used this way.
5. Cross platform development - basically, migrate legacy to a more cost-effective platform using advanced tools and either transfer production to the new platform; or maintain on the new platform and transfer updated systems back to the original platform. Assumes legacy quality and doesn’t work on (isn’t available for) every platform.

And, in practice, developers may have to adopt aspects of all these approaches, depending on circumstances. It is now fashionable to recognise the quality of much of our IT legacy (if it is still in use after all these years it must be doing something right) but it is also possible to waste a lot of time trying to reclaim poorly documented and architected systems that just happen to work (as far as the business can tell).

So, the bottom line is that you should plan for legacy reclamation, considering all the options; but make sure that you have a contingency option for bailing out if reclamation really gets bogged down in bad legacy. And there’s another contingency to consider: if you find that your legacy has been getting the wrong answers for all these years, how will you manage the politics of suddenly getting the numbers right? Especially, if you’ve been reporting the wrong numbers to the regulators.

So, perhaps the real bottom line is that legacy reclamation isn’t a second-class project for tired developers. It is an important part of your IT process and needs access to your best, brightest and most flexible brains.