Integrate ToWhat?

Integrate To…What?

It is interesting to consider just what the targets of integration are. What kinds of systems do new applications need to link or tie into, and what kind of information is passed between integrated applications and between peers?

Accounting systems built in the 1970s might need to be WWW-enabled. New human resources (HR) or customer relationship management (CRM) applications written in Java might need to communicate with an insurance company's Oracle-based database systems. There is a wide range of hardware, operating systems, and programming languages out there, and each type might need to talk to another.

Legacy Systems (Run the World)

The term legacy systems is at the same time useful and a bit unfortunate. Many people associate the word "legacy" with old, slow, awkward, proprietary information systems held together with spit and rubber bands. There is perhaps some truth to this, but here's a secret legacy systems, including mainframe computers, run the world. In some ways there is no such thing as legacy systems, just older or newer information systems. The now ubiquitous PC-based Linux or Windows servers running Java application servers are a very recent addition to the computing world.

Many integration efforts focus on proprietary or custom computer systems. They might have difficult or unsupported programming interfaces actually, if a programming interface exists at all, that's a bonus, and if a network-programming interface exists, it's cause for celebration! Many might have been developed internally by the organization that uses them, or were perhaps cobbled together in COBOL or Fortran. Documentation may or may not exist. This is just as true for applications built yesterday as for systems built 20 years ago.

Building communication bridges or adapters to such systems is one of the more interesting parts of integration efforts. Communicating with legacy applications runs the spectrum from using the file system itself to pass information, to actually being able to use more recent, Internet-oriented transports like TCP sockets or HTTP, to using email to pass messages, or even using nice Java network APIs like JMS or RMI.

The Problem of Syntax and Semantics

A significant problem when linking disparate systems is that of data or interchange formats. As mentioned later in our discussion of EDI, there simply isn't a single standard. This means that integrating two applications might require not only building adapters or bridges for network protocols, but also building data translation or transformation components. The rapidly increasing use of XML will also help this situation, but syntax or format alone is unfortunately not the only problem.

When a native Language 1 speaker communicates with a native Language 2 speaker, each might be able to translate words literally so that the other can understand what is being said, but the meaning might not translate without some added contextual information. A concept in one language and culture might not even exist in the other. In other words, there might be a conceptual gap that syntax alone cannot bridge. This semantic gap is a more serious problem than, say, the problem of translating between nice human-readable XML and nasty machine-readable binary data.

In these situations, often the only way to solve the problem is to get enough information from experts in the different systems or applications to be able to bridge that gap in a reproducible manner. After all, the solution must be able to be carried out by a computer. This again is where integration can be a social engineering endeavor. Negotiation and compromise are integration tools.