Legacy application renewal: Unlocking the value in your systems

No longer satisfied with a ‘rip and replace’ approach to legacy-application management, organisations are breathing new life into their mission-critical assets with web services and service-orientated architecture. By Jessica Twentyman.

For many companies, legacy applications – those written in languages such as Cobol and PL/1 and residing on data-centre mainframes – are an unfortunate but necessary reminder of their past. These applications represent years of maintenance and financial investment, which few firms are inclined to abandon, and enable them to perform mission-critical transactions that are vital to business performance. At the same time, however, legacy applications can be difficult and costly to integrate with newer systems and, for many, the role they will play in the technology architectures of the future is far from clear.

“They may be ‘legacy systems’ but they are also vital systems,” says Sean Baker, chief technologist at integration tools supplier Iona. “The companies that have these applications in place are not necessarily happy with the technology that underpins them, but at the same time they recognise that these applications are intrinsic in what they do for the business and, as a result, are extremely reluctant to take out a ‘rip and replace’ approach to dealing with them.”

Industry estimates indicate that most organisations face this problem to some extent. Some 70 per cent of the world’s mission-critical applications reside on legacy systems, according to market-research company Gartner. Around the world, there are upwards of 20,000 mainframes in use, and more than 700,000 IBM iSeries (formerly AS/400) proprietary midrange computers. These systems support more than 100 million users accessing both packaged applications and bespoke software written in programming languages such as Cobol, PL/I and RPG. IT giant IBM estimates that its mainframe transaction processing monitor CICS, first introduced in 1969, still handles more than 30 billion transactions each and every day.

That, says Forrester Research analyst Jost Hopperman, creates an environment of discrete and isolated applications – some new, some old – that find it difficult to ‘talk’ to each other. This often results in a ‘patchwork’ environment that creates overly high operational or maintenance costs. “Over time, companies will no longer be able to maintain these complex environments; this will cause, for example, an unacceptably long time-to-market for new products and severely limited responsiveness to the need to change business processes,” he says.

Some get round the problem by migrating older applications wholesaleto a newer platform, such as Unix , Linux or Windows – but such projects have a reputation for being difficult, costly and highly prone to failure. They also fail to take into account the shift in skillset that will need to accompany such a migration. Often, it will involve laying-off Cobol programmers and recruiting programmers with more up-to-date (but more costly) Java and Microsoft .Net skills.

Others tackle the problem using enterprise-application integration (EAI) toolsets from companies like IBM and WebMethods. These provide proprietary-adapter development kits that enable programmers to build adapters that will link custom and legacy applications to newer systems. But that approach, too, is time-consuming and expensive. Not only that, but every time an application is modified or upgraded the adapters also need re-engineering. It is hardly surprising, then, that EAI tools have become “too expensive and too difficult to have made more than a dent in system-to-system connections”, according to analysts at market research company Forrester Research.

That, for many, is where the concept of web services comes in. Web services are software components that use a universal set of standards to send data and instructions to each other, using the internet as a common backbone, with no translation required. And just because a software component resides within millions of lines of legacy-application code, that need not be any bar in transforming it into a web service. The web-services standards are:

The XML tagging language;
Simple object-access protocol (SOAP) for transferring data;
The web services description language (WSDL), a machine-readable description of the attributes and abilities of a web service;
Universal description, discovery and integration (UDDI), for listing the range of web services available.

By building new applications – and re-engineering old ones – around the web-services concept, organisations can create a dynamic IT environment comprising many loosely coupled software components that share data seamlessly with each other – an architecture increasingly referred to as a service-oriented architecture or SOA. And because the SOA uses the internet as its backbone, web services can share data with other web services outside of the enterprise, such as those residing on the systems of key trading partners.

Join the SOA
“The SOA and web services represent a new lease of life for legacy applications and a way of truly unlocking their value, as well as the skills and business knowledge of the employees that maintain and develop them,” says Julian Dobbins, senior marketing-development manager at Microfocus, a company that provides tools for legacy renewal.

Such tools – also available from IT suppliers such as IBM, Computer Associates and Iona – effectively interrogate legacy applications, scanning millions of lines of PL/1 or Cobol code, to identify sections that represent chunks of business logic.

From there, they automate much of the process of ‘wrapping’ these chunks in web-services standards, which will allow them to link to other web services-wrapped components to exchange data.

“When systems architects consider the functionality needed to support an SOA, they usually see that most of what they need to create it is already in place. By leveraging what is already bought and paid for, most of the work to create an SOA is already complete,” says Sean Baker of Iona.

One of the major advantages of this is that, once wrapped in web services, components can be used in a variety of cross-system applications. In essence, that means that companies can combine anything from a handful to hundreds, or even thousands, of ‘services’ into new combinations, or ‘composite applications’. That gives organisations the ability to customise their processes, even components derived from packaged applications, as never before.

“Reuse is a key advantage of legacy renewal,” agrees Paul Allen, principal consultant at Computer Associates (CA). Many companies, he adds, use legacy-renewal tools to expose chunks of legacy applications through numerous channels. “Take an airline booking system, for example. Once the component that processes a booking has been wrapped in web services, it can be accessed by the public via a website; by travel agents through their company’s booking systems; or by a specific traveller who is checking in for a flight, using a kiosk at the airport. All those processes use the same underlying business logic, but the user doesn’t need to know that in order to perform the task in hand,” he says.

Another key advantage, adds Allen, is replaceability. “In a composite application, different pieces of business logic can be plugged in or unplugged according to business need,” he says. “Sometimes, a brand new piece of business logic may need to be written but, quite often, that logic probably already exists somewhere in the architecture and it’s just a matter of using it to replace a redundant or outdated component. Even when a component must be written from scratch, it’s only a small part of the application – the rest of that application can remain as it stands.”

Examples of these more advanced composite applications are still rare, largely because most existing applications have yet to be fully opened up. But once this is done, composite applications should prove easier to build than completely new applications, because they use services provided by existing, stable, underlying applications.

Caution required
However, there is actually a lot more to building an enterprise SOA platform than top and tailing one or two legacy applications with web-services interfaces and plugging them together, argues

Butler Group principal analyst, Michael Thompson. He advises that companies need to think carefully about the future prospects for deriving value from legacy applications.

“As confidence in the practical viability of code and process re-use grows, there may be a tendency for companies to regard all legacy systems as a treasure trove of software assets. This could hold true, but users will only really be able to tell how true by making a concerted effort to sort through this treasure trove and separate the wheat from the chaff,” he says. “You will have to do an in-depth discovery process to find out what functional assets you really have.”

Then, there may be some tough decisions to be made about what to keep and what to throw away, since code that is kept will form the foundation of a functional repository that will be used for years to come.

Although some tool vendors, notably those with a mainframe lineage, like to give the impression that (under SOA) no old code is bad old code, the truth is rather different. “Some legacy systems have been around for 40 years or more and even though they may still be working and doing something useful, I don’t think all of it will really be worth keeping,” says Thompson. And eventually, he says, SOA adopters will be forced to modernise and transform much of their legacy-code.

In addition, the SOA as a means to tie-in legacy applications requires fundamental internal change at any company – and presents considerable hurdles. There is, for example, a considerable shortage of in-house IT developers who are experienced in architecting web services. These employees need, for example, business knowledge that will enable them to understand what components of logic are needed to complete a composite application, while also possessing programming skills that will enable them to model and re-engineer components to transform them into web services.

Many suppliers will claim that their products, to some extent, automate the process of applying web-services standards to existing code, this could still mean a hefty bill for systems-integration services from third-party IT services companies. “It is a job that requires some considerable architectural skill,” says Allen of CA.

But there can be little doubt that many companies will set out down an SOA path in the next few years – indeed, many larger organisations already have. “SOA is evolving from being a ‘best practice’ for the few to being the common practice for the mainstream,” says Tom McCoy, an analyst at Gartner.

That is borne out by a 2005 survey conducted by Forrester Research, which also shows that legacy-application renewal is a major driver of the SOA. “SOA provides a strong model for leveraging the value of legacy applications,” says Randy Heffner of Forrester. “Enterprises that currently have COBOL applications are more likely to have adopted SOA at some level (project, department, or enterprise level). Of those with COBOL, 44 per cent use SOA, versus 27 per cent for those who don’t have COBOL applications. Of the COBOL users, those who are actively extending or working to replace their COBOL applications have the highest use of SOA (47 per cent and 50 per cent respectively),” he says.

The message is clear: if legacy applications can play any part in the momentous strategic journey towards the SOA, those companies embarking on that journey will want to ‘leave and leverage’ their legacy applications – albeit in the short to mid-term, rather than jettison them completely.