Adopt and adapt better than rip and replace...

Developing with Legacy Systems – Part 1

Common Topics

If the internet has done nothing else, it has made the parochial world of proprietary systems appear outdated. Software architecture "A" now had better interoperate with software architecture "B", or risk rejection as now being unfit for purpose. And all of them need to interoperate with language "X" and application "Z". But in practice, this is also the case when the languages and applications are ancient and venerable, because they are still running tasks critical to the survival of the business.

The arrival of SOA has made this an imperative now, for "sweating the assets" is now a strong mantra amongst business and organisational users. But developers and business managers need to work together to decide what actually constitutes an "asset". It is easy to assume that the asset is just the data, which can then simply be ported to a new environment. In practice, however, the asset is more commonly both the data and the application that created it, with the pair often being inseparable (in part, because the application may represent the only detailed documentation of the underlying business requirements there is; as well as containing hardcoded “master data”).

Risk management

It is also the case that any change away from an existing asset carries risk as well as advantage: change can mean failure as well as success. So, integrating legacy assets that still perform a valuable task for the business remains a serious and important option for developers to consider in business terms, regardless of how much they might relish the technical challenge any change constitutes.

This does not mean legacy integration is the de rigueur option. The possibility of change, to redevelop an application as a service component designed for an SOA environment, has to be one of the developers’ options. This will become one of the developers’ more pressing options over time, if only because the staff with the knowledge and experience needed to maintain many legacy applications are part of the "baby boomer" generation and are now nearing retirement age.

Vendors are, therefore, now offering businesses with established legacy systems a growing range of options that can integrate and absorb those important applications into the newer world of SOA and the Internet, without forcing the risks associated with "rip and replace" approaches.

Legacy shift

One option has seen HP, because of its commitment to Intel’s Itanium processor as the heart of its high-end server hardware range, take an important step with two of its acquired legacy environments – DEC’s old OpenVMS and Tandem’s old NonStop (see the whitepapers here and HP NonStop evolution here). The company has invested in porting these environments to run native on Itanium, which at least gives existing applications a current, more maintainable server platform to run on. This will give both systems an extended lease of life; which is important as they both still run business critical applications. But as both also offer potential advantages for the management of complex business transactions across the Web, it will be interesting to see if HP also takes the further step of promoting them to new users with support and developer education programmes.