Reclaiming a different legacy

Ballard recommends Northdoor's five step approach to addressing this issue: Planning; Architectural Design; Code transformation (using automation); Refinement; Testing and Implementation.

Here's my take on this:

1. Planning. Always a good idea – and make sure you include checkpoints so you can take action (possibly even abandon the project) if you find that things aren't going as expected: perhaps the quality of your legacy is worse than you thought or the business more complicated.
2. Architecture Design. This is where Northdoor expects to get some income but, to be honest, outside help with experience of legacy transformation, will be invaluable here – unless you really do have suitable experience inhouse.
3. Code transformation. Automation is probably essential to making reclamation cost effective – without it, you might well be as well off using the legacy as a guide to requirements but rewriting the code from scratch using modern tools. Ballard describes this process: "Use software tools to map out the functions of the legacy code and translate them into an object-oriented structure to run under your target platform. Map out the inheritances and relationships within the business framework. The code is then converted to a universal layer and finally migrated to .NET or Java. This stage will use native functions and datatypes alongside code reassembled using an object generator."
4. Refinement. As I've already said, you won't want just to reproduce the behaviour of the existing system, warts and all. This is another area where external consultancy, with a different point of view to that available inhouse, may be useful.
5. Testing and implementation. As for any development, you must ensure that the transformed application will perform efficiently and accurately, without affecting the business service adversely. And don't forget training and the need to ensure that business users trust the new application.

So, it is good to be reminded that legacy doesn't just mean COBOL. A lot of work was done in the nineties with tools which made writing code very efficient, although whether they all helped with testing and resilience, in practice, is moot.

For every mature 4GL team using tools like Uniface, or the Progress 4GL, there were dozens of individual developers who believed that prototyping infallibly delivers fit-for-purpose systems (if it does, it is only for those involved in the prototyping and their clones) - and reclaiming this sort of legacy may be hard work.

Nevertheless, such legacy represents intellectual property that you won't want to discard if it can be reclaimed cost-effectively, and Northdoor appears to offer a mature approach to deciding whether this is the case and then doing it.

Its Metex technology is a vital part of this, as it should free developers up from the problems of code translation to the harder, and more important, problem of assessing and modernising the essential business requirements model behind the legacy being reclaimed.

Unfortunately, Metex only deals with a subset of the 4GL-type technologies you'll meet, albeit a reasonably important subset. But, of course, if you're using something still supported like Uniface, moving off that platform, without a very good business reason, often wouldn't make business sense anyway. ®