What is "legacy"? It's worth remembering that a lot of systems were written in RAD (Rapid Application Development) tools such as PowerBuilder and Visual Basic in the nineties and this is now often undocumented legacy in small companies (and some not-so-small ones) - just as COBOL systems are in large enterprises.

In fact, although I'm all in favour of RAD done properly (using a process such as DSDM, or JAD (Joint Application Design), some of this sort of "rapidly produced" legacy was produced with little process and less business input (often the person who can be spared to talk to IT is the person who can't do the business). So, it is often undocumented and possibly even dysfunctional in part. But it may still be in use, often in companies that have now made a strategic decision to run J2EE or .NET web services.

Ian Diaper, principle consultant with Northdoor, says this stuff can often be reclaimed – after applying some sort of a legacy decision matrix to decide whether it will be worthwhile. Essentially, if legacy isn't offering value, retire it; if it is both useful and maintainable, keep it; if it is useful and unmaintainable, transform it (Northdoor's Matrix, in the illustration provided by Northdoor, is a little more sophisticated than this; there's a link to a bigger version of this here).

But beware of transforming legacy without a good business reason, just because new technologies are more fashionable – the pointy haired boss may not realise this, but most developers can turn their hand to any language, given a little training and encouragement.

For transformation, Diaper recommends technology from Canadian company Metex, a long-term partner of Northdoor. Northdoor, in fact, supplies transformation consultancy as much as the technology, and Metex can transform legacy written in Powerbuilder, Oracle Forms, RPG, Delphi, and Centura.

According to David Ballard (consultancy director, at Northdoor): "It isn't just a case of 'translating' legacy 4GL syntax to run under J2EE or .NET using conversion tools or compilers. These are totally different architectures and such literal translation will just deliver the old logic in a new language, bringing none of the benefits of the new architecture. Logic must be coded in a completely new structure. This coding involves an understanding of the business logic in the old application&."

Well, that's true of any legacy reclamation: the code tells you what the legacy does, but you need a domain expert (and, if you're lucky, the documentation) to tell you why it does it; and a technologist to make sure you get the best out of what you're moving to.

But with the sort of 4GL legacy we're talking about (and, to my mind, including Visual Basic makes for a fairly loose definition of 4GL), elucidating the business requirements may be an even worse problem. At least legacy COBOL developments followed some sort of recognised process; with Visual Basic, for example, the process may have been in the head of the coder. And, a system which made sense in the London Office where it was prototyped may have been rolled out worldwide – and may now be causing horrendous problems in, say, Shanghai. If you are to reclaim legacy effectively, you can't simply reproduce the status quo together with any problems it has.

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. ®

Related stories

• Working in the COBOL mine (5 January 2007)

  https://www.theregister.com/2007/01/05/developing_legacy_systems_part2/

• Adopt and adapt better than rip and replace... (3 January 2007)

  https://www.theregister.com/2007/01/03/developing_legacy_systems_part1/

• Firing up the Erudine engine (16 November 2006)

  https://www.theregister.com/2006/11/16/erudine_behaviour_engine/