"Organisations must use legacy functionality as the foundation for ebusiness killer applications - not as software to be discarded," says Massimo Pezzini, research director at analyst Gartner.
"Not only will the ebusiness environment require new applications that will use legacy functionality, the infrastructure to support more responsive ebusiness functionality will have to evolve and use portions of legacy infrastructure as well."
By 2004, more than 70 per cent of application development budgets will be devoted to enhancing and maintaining applications that have been in service for more than five years, according to Gartner. Meanwhile, analysts at Giga estimate the demand for allegedly 'old-fashioned' Cobol skills will still create employment for 1.13 million programmers worldwide in 2005.
Value of legacy applications
There are two possible approaches for building a well-structured combination of legacy and ebusiness applications that organisations should evaluate.
"The role of back-office systems is to be integrated; critical data is held in legacy applications, and customer-facing systems have to refer to this data. The two trends that we will see over the next three to five years to deliver this are integration and reuse," says Pezzini.
At British Airways (BA), there was no alternative but to reuse in-house applications - some date back to the late 1970s - in an ecommerce environment.
"The real business value is in your legacy applications. In the online era, a lot of companies' assets are in their information base, all of which exists in legacy systems," says Pat Gaffey, the airline's head of ecommerce.
"We have a massive dependency on legacy applications. There isn't a packaged enterprise system in existence that could replace them. If our critical systems fail, BA shuts down within minutes. Those are all legacy applications," adds Gaffey.
BA invested £12m in an ecommerce system that would link its legacy systems to a customer-facing front-end with multi-channel capability. Using an internet application server from BEA Systems to web-enable its old programs, it can now support multiple customer touch points, such as telephone, travel agents, the internet and Wap phones.
"We used a three-layer structure," says John Mornement, head of operations and design at the airline. "The first layer provided mainframe connectivity to the legacy systems. The second is a business logic server that connects the legacy data to the third, channel layer that manages the multiple sources of information."
The project proved how vital the 'old-fashioned' legacy applications are to BA. "Why not enable systems to operate at internet speed but retain the workhorses? The benefit of legacy systems is that you know that they work," says Gaffey.
For organisations with many non-integrated legacy systems, the challenge is not only how to integrate what they already have, but also how to integrate future requirements.
This is the task facing the Post Office as it prepares for deregulation in 2003. It needs to link modern, customer-facing applications as well as multiple, non-integrated legacy applications in its existing environment.
"Our new ebusiness systems need to use data supplied from applications running on IBM mainframes written in Cobol, Unix systems with Ingres databases, and Windows NT-based SQL Server systems," says John Greenlees, data exchange services manager at Post Office Business Systems. "We wanted to insulate our legacy systems from change, but integrate them into a common architecture."
The Post Office is building an infrastructure based upon a hub-and-spoke architecture using software from application integration specialist Constellar, combined with messaging using IBM's MQSeries products.
Data from legacy systems undergoes a two-stage transformation as it passes through the Constellar hub. First, data in legacy format is mapped into a standard Post Office data model, which is then mapped into the format required by the target system.
"The hub approach gives us the capability to deploy a common data architecture across the group. The central hub interprets information moving around the business, which provides better visibility of data and faster development of interfaces to systems. It reduces the risk of failure by reusing components we have developed previously," says Greenlees.
This technique of using middleware to link disparate systems together in this way is known as enterprise application integration (EAI).
"The market for EAI tools is growing at 80 per cent to 100 per cent per year in Europe. Leading-edge organisations are building an integration infrastructure to provide interoperability between systems," says Pezzini.
EAI tools are particularly useful if you are trying to connect existing, non-integrated systems into an ebusiness infrastructure.
Extracting the knowledge
Another approach that analysts believe will become increasingly popular among organisations with a large customer base is componentisation. This uses a technique called 'knowledge mining' to extract business rules from an existing legacy system. Business rules are self-encapsulated components of the software that are more open to external integration than complete transactions in an application.
"The idea of encapsulating legacy applications into components is not yet mainstream," says Pezzini. "Creating reusable business components from existing applications means you can use existing business logic. A componentised back-office system allows easier integration of new channels in a multi-channel ebusiness environment. Industry sectors with large consumer populations such as banking or insurance will follow this route."
Although the use of components is still in its early days, it is already coming in for some praise from business users.
"The componentised approach is the only way to evolve legacy systems into a web environment," says Tom Fothergill, ecommerce general manager at mail order catalogue company JD Williams (see box below). "By taking your key business rules and componentising them, you're creating something with long-term value and maintaining the investment you have already made over the years."
The viability of legacy applications in the ebusiness era has a lot to do with year 2000 compliance. The threat of the millennium bug forced companies to refocus on the role of its older systems - and their value.
"The year 2000 has been beneficial. The really rotten applications have gone," says Pezzini. "Organisations have spent a fortune fixing legacy applications. These applications are the business; they have been for 10 to 15 years, and are proven and functional. In 80 per cent of organisations the applications which survived year 2000 will remain for at least three to five years."
Insurer Pearl Assurance used its year 2000 project to review and improve its legacy applications, most of which were developed in Cobol and SQL. Pearl found that its use of certain applications had declined significantly as its business had changed.
For example, an ageing system to collect premiums was still in use despite not supporting the use of direct debits, which was handled by a separate policy management system. The first stage of the project was to perform an inventory of the existing applications to identify who used them, how they interacted with each other and which reports were produced.
"So much of our business is dependent on legacy applications. We need to be sure that they underpinned our main life insurance and pensions business, so we evaluated each application and decided whether to bin it or fix it," says Pete Kitson, IT programme manager at the company.
The project revealed that much of the system was redundant; many reports were never read, and parts of the system were no longer used, meaning that Pearl could streamline its applications while retaining mission-critical functionality.
The message seems to be: if you didn't carry out a full application audit for year 2000, then now is the time.
The benefit, say experts, will be reduced support and maintenance needs, and a better understanding of how to move the applications into the web environment.
Deciding what to bin and what to keep can be tricky. Try and concentrate on the business benefits and the real use of the program.
"The important legacy applications are those that are mission-critical and deliver competitive advantage to an organisation," says Len Erlikh, chief technology officer of US software supplier Relativity. "If the application is not mission-critical, leave it alone, or phase it out. If it's mission-critical but not a competitive advantage, organisations should migrate it to a package."
There is also the added problem of knowing what the legacy application of the future will actually be.
"I expect that client/server development tools from high-end 4GL vendors will become considered legacy soon," says Meta's Barnes. "Products such as Coolgen, Gupta, and Powerbuilder served a purpose to deploy departmental applications, but because the industry is shifting towards the web, with n-tier, application server-centric models, these tools are not a good fit. Organisations are looking to migrate from these applications, and the tools are generally becoming obsolete."
Analyst IDC believes that Visual Basic applications in particular are in danger, and that the language will be overtaken by HTML by 2002. Even some web software may be branded with a legacy tag.
"The first generation of web applications will become legacy very quickly," warns Kevin Prouty, research director at AMR Research. "Any web application has a lifecycle of two years. Old web applications will become legacy through new shifts in technology. It's going to be a rude awakening."
Beyond that, who knows? The pace of internet change means that the term 'legacy' itself may soon be legacy.
Do you agree?
Have your say on this article