Introduction

The mission-critical systems, frequently called "legacy systems," of many large companies are often buried within large, monolithic applications with no industry-standard interfaces and developed with older computer languages, such as COBOL. Many of these companies wish to exploit internet, intranet, e-commerce, and other new technologies in order to remain competitive. However, rewriting these key "legacy systems" may not be a viable option from a financial (too expensive) or technical (initial programmers no more in the company) or timing (can't afford to wait) point of view. The alternative chosen by many companies is to modernize their "legacy systems" by integrating them with new applications.

The most popular way to make such integration is commonly called Enterprise Application Integration or EAI and consists in implementing a communication infrastructure between the various enterprise applications, both new and legacy.

Legacy Integration Strategies

Legacy integration can be divided into two main categories :

• Non-invasive
• Invasive

Non-invasive

Non-invasive strategies are those that don't modify the legacy application or perform only minor modifications. This strategy is the less expensive one but is also the less flexible. This approach is usually used when EAI integration is done at user interface level, at data level, or sometimes at application interface level.

When integration is done at the user interface level, the existing text-based screens are replaced by browser-based ones integrated in an enterprise business portal. Even if this kind of integration is usually considered somewhat unstable and archaic, it is sometimes the most practical way to integrate legacy systems that do not provide database- or business process-level access.

Data level integration can be done by either reusing the existing legacy database or by extracting the data from the existing database and updating a new database using an ETL (Extract, Transform, Load) solution. Even if this approach seems attractive, it is sometimes difficult to implement because data transformation, constraints, and controls are often implemented in the business logic of the legacy applications.

Non-invasive application interface-level integration, called also "legacy wrapping," can offer a little more flexibility. In this approach, you build callable Application Programming Interfaces (API) around legacy transactions. Since this approach leverages existing legacy transactions, it is not very expensive and avoids the inconveniences of data-level integration. By transforming the transactions in APIs, it gives more flexibility than user-level integration. However, to remain non-invasive, this approach cannot be used to modify and enhance business features. For that, you need to use an invasive approach.

Invasive

An invasive strategy supposes that you need to modify functional legacy code. Obviously, there is more risk and cost with this kind of approach because usually legacy code is old, not well documented, and the programmers who wrote it are rarely available. But this type of approach is also the one that gives more flexibility and allows you to modify and enhance existing business processes and features. This approach is usually used with EAI application interface level integration when you need APIs that do not correspond to existing legacy transactions. This approach could be also used with EAI method-level integration, but refactoring the existing code to provide sharable methods is often too expensive.

One invasive application interface level integration approach is called "legacy e-Components." This approach consists of partitioning the legacy application into a collection of autonomous business components. Each component publishes a clearly defined set of APIs that facilitates the move from rigid program-to-program connectivity toward a more loosely connected message-based approach that can be deployed in multiple platforms and integrated into the overall architecture using appropriate component models. This approach can be refined to define each "legacy e-Component" as one or more services in a Service-Oriented Architecture (SOA), using XML web services. See Concept: Introduction to Service-Oriented Architecture.

Because invasive approaches are typically more expensive and architecturally risky than non-invasive approaches, you should consider adopting an iterative approach that drives down risks and proves architecture feasibility in the early iterations.