Reclaiming a different legacy

It isn't just COBOL you know...

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.

Shows a Legacy Decision Matrix.

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.

Sponsored: Today’s most dangerous security threats