Information Age: News, analysis & insight for IT & business leaders

Since the recent business downturn, it has become fashionable to talk of legacy systems management as a strategic issue. After years of profligate spending on the latest IT systems, businesses have begun to realise that their existing systems represent much more than a maintenance liability, to be replaced as soon as possible. Rather, they are a reliable and vital asset.

But there is a problem: most legacy systems were not designed to interoperate with modern, open systems, let alone service-oriented systems.

That is the challenge of the modern service-oriented architecture (SOA). In many ways, the success or failure of SOA for the next several years will depend on the ability of organisations to manage and integrate their legacy software.

After all, it is a basic tenet of the SOA that new systems are no longer built from scratch, but constructed out of composites of existing systems.

In theory, this shift towards the repurposing of existing resources will increase the ability of systems architects to build systems that can respond to changing business requirements. But for the theory to work in practice, they must have ready access to a "toolbox" containing clearly labelled, pre-packaged software components (or services) - the Lego bricks of the SOA age.

To create these toolboxes, organisations face two key challenges. The first requires a change in attitude. Traditionally, organisations have viewed legacy systems as a series of discrete, monolithic applications whose value lies in the services they provide today, rather than in the potential they have to drive new services tomorrow. In the SOA world, legacy systems must be viewed more holistically, as treasure troves of valuable business logic and data structures whose real value is independent of any particular application.

The second challenge is a practical one. Having cast aside the "silo" approach to legacy systems, organisations must delve into the legacy treasure chest to identify what it contains and to then package these software assets ready for use.

This process of encapsulation has already been underway for several years at many companies. But for most, the process is still in its infancy - just as commercial packages have a long way to go before they become truly service-oriented.

Many tools are available to help users in this. Object programming began the process in the early 1990s, and the use of message-passing, enterprise service bus (ESB)-based integration tools from vendors such as Tibco and Sonic have enabled legacy systems to participate in the emerging architecture more fully. Many suppliers, such as WRQ and Micro Focus, are now providing tools which enable their users to repackage embedded functions as web services.

In general, though, often the integration is not fine-grained enough. In some cases, whole applications have been welded together into unwieldy composite systems; functional duplication is common and systems can be extremely difficult to configure.

For SOA to succeed, key business logic needs to be more clearly defined, wrapped with the standard interfaces which will make them universally compatible with one another. Critically, they must then be labelled in a way that makes them accessible not just to developers, but to the new breed of business aware systems architects.