For years ‘legacy’ has been one of IT’s favourite euphemisms – a word marketing executives latched onto in the late 1980s when they found references to ‘old mainframe and minicomputer code’ were proving too negative.

While in its everyday meaning legacy has the positive connotation of a financial windfall, as it became parlance in an IT setting its association with ostensibly

outmoded software – Cobol, CICS, IMS, VSE, VMS – quickly made it something of a dirty word.

Of course, this was a subjective view from suppliers keen to sell organisations the next generation of software. Indeed, it was not so long ago that a Cobol/CICS application was regarded as leading edge, catapulting computing into the uncharted world of real-time transaction processing.

But even today, when Java and .Net are the most fashionable platforms for new applications, no organisation – with the possible exception of the newest of start-ups – could claim to have a portfolio of totally up-to-the-minute applications.

For everybody else, the problem is how to make the existing, tried and trusted systems work with the latest thing.

As iWay Software sales director Kevin Magee puts it: “The question is not whether to integrate your legacy applications; it is how easily and cost-effectively it can be done, and what tools to use.”

A good illustration of the perpetual nature of legacy integration is provided by one application that has touched almost every household in the UK – British Telecom’s CSS (Customer Service System). Since the mid-1980s, this multi-mainframe hosted application suite has kept track of telephone bills and services for all BT’s customers. It is a vast system, handling bills worth over £10 billion per year for 23 million customers. And 17 years after it went live, it is still going strong.

But large as it is, it is not standalone. Over the years, British Telecom has had the need to make CCS’s resources available to other applications. Fortunately, the system was originally based on very advanced design for its time, with its presentation logic (what appears on screens) separated from the business process logic. That allowed BT to develop a middleware layer between the two that would allow bridges to be built between new applications and CSS.

Like many large-scale applications, its middleware layer has now gone through several generations of integration technology. Initially the need was to integrate it with other IBM mainframe systems, which was done using the venerable LU6.2 protocol, while communications with the outside world relied on the X.25 packet-switching standard.

Later, in the early 1990s, the need to interface to client/server applications prompted a switch from X.25 to TCP/IP, and then from LU6.2 to MQSeries. And most recently with the advent of the web, the CSS system has been integrated with other systems via XML (Extensible Mark-up Language) and web services technologies. That evolution has created a matrix of integration to the point where, today, over 500 BT services use the middleware to access CSS.

Currently, says BT’s web services integration manager Jon Calladine, “the integration challenge is to take existing systems and use [parts of their functionality] in C# or Java applications – applications which are not easily able to deal with them natively.”

In many respects, the industry has risen to that kind of challenge, analysts believe. “Integration in general has become easier: and people now have proper products they can count on,” says Bloor Research analyst Peter Abrahams.

There have been two major infrastructure changes behind such developments. The first was the widespread adoption of ERP (enterprise resource planning) systems from companies such as SAP, Peoplesoft and Oracle; the second was the arrival of the web.

The take-up of ERP created a need for companies to make the resources in existing systems available to this new breed of applications. The business logic in the old standalone applications was still in many cases valid, if not mission-critical, and the data they used needed to be accessible to the ERP suites.

In most cases that meant hooking into Cobol applications. And even today, according to Tony Hill, CEO at Cobol tools specialist Micro Focus, “75% of the world’s transactions are still running on Cobol applications.”

Living with Cobol

On the surface, the simplest way of integrating applications is by building a point-to-point connection. Every application has APIs (application programming interfaces), which allow access to and from other applications, and programmers can use these to translate the requirements of a new system into a language the legacy system understands. In this way the new can interact with the old.

Of course, this is fine when there are only two systems that need to work with each other. But most users have tens or even hundreds of applications, and each one may need to interact with more than one other. The multiple interfaces required quickly become complicated and difficult to work with, precipitating the situation where programmers dare not touch a legacy system for fear that any changes may have unforeseen, disastrous effects.

EAI (enterprise application integration) packages emerged towards the end of the 1990s to act as integration hubs that were easier to manage and maintain. EAI recognises that in any large organisation, integration of applications is an ongoing fact of life that needs to be managed as much as any other part of the business, and requires specialised tools and methods to do so.

A prime example is Tibco Software’s BusinessWorks product range. It consists of an integration program, made up from a set of adaptors that provide connectivity to a wide range of business software products, and a base system or broker, which makes data available inside a business process. On top of this are built other products for task management, for business process analysis and for forecasting.

The ability to play a supra-applications role makes EAI a highly suitable candidate for the task of orchestrating business processes as they draw on various applications during their execution.

The Derbyshire Building Society wanted that level of abstraction. Says IT director Keith Pattison: “We made up our minds that we needed to remove the business processes from the core application. We felt that the architecture we had in place was starting to restrict what we wanted to do and we couldn’t

[extend the] organisation without developing end-to-end interfaces which would eventually become unwieldy and difficult to manage.”

The EAI package had a major impact on streamlining processes that were previously disjointed because of a lack of integration between applications. The building society reports a greater than 50% reduction in processing time since integrating three of its core systems, as well as the elimination of a departmental backlog. In addition, there are less tangible benefits stemming from the fact that the new architecture reduces the need for end user knowledge of the systems.

Critics of EAI systems argue that, historically, they have been expensive, proprietary and complex.

But the industry itself is addressing at least one of these problems: the cost element. A new form of EAI, known as the ESB (Enterprise Service Bus) has emerged, based on standards such as XML and JMS (Java Message Service). According to Steve Craggs, European chair of the EAI Industry Consortium, ESB “does 80% of what a proprietary solution does. But because you are using standards, the cost dynamics are completely different.”

It is possible to use less comprehensive and cheaper forms of integration. XML is one. The language is designed to allow developers to define data in a way that enables it to be transferred over the Internet (see box, ‘In practice: Deutsche Bank Luxembourg’).

Open interfaces

XML may be ideal for some applications, but it does not go far enough for others. Web services, the set of standards built on top of XML, provides arguably the most powerful and most flexible means of integrating new applications with legacy code.

Web services is defined by Paul Tarttelin, manager of distributed solutions at Intel’s Solutions Services IT consultancy division, as “an emerging architectural model for deploying software applications, and making applications interact with each other using web standards”.

Essentially, web services allows developers to transform point-to-point interfaces into open interfaces. Once one has been written for any application, it can be used by any other application that can use the web services standards. So web services does away with the need to write multiple interfaces for one application. “You only have to do it once – that’s the key – no matter how easy or difficult it happens to be,” says Tarttelin.

Micro Focus’ Tony Hill agrees, underscoring the fact that web services has become a major weapon in organisations’ fight against the cost of applications integration. “The current business climate emphasises reducing costs, becoming more agile and minimising risk. The whole web services story plays well to that.” It is important to remember, though, that web services only solves part of the integration problem. According to Bloor Research’s Peter Abrahams: “If you bring lots of web services together to execute one business process, you need to ensure they will complete concurrently, or be able to pull back to the position prior to execution.”

There is also, as yet, no standard for security, though one, known as WS-Sec and proposed by IBM and Microsoft, is currently under development. Some companies can make big gains using web services. British Telecom is among them, but the head of web services at BT Global Services, Peter Gandy, expresses some caution. “We see web services purely as an enabler. It allows you to [integrate] quicker and cheaper than other methods. But it’s just a new way of doing this. It does not suit every situation.”

EAI, XML, web services: Such technologies may be making the challenge of integrating newer applications with older systems easier. But given an ever-expanding base of ‘legacy’ applications, the drive for more efficient ways of bridging those incompatabilities will never cease.