People often confuse connectivity with integration.
Connectivity is a straightforward idea. It just means connecting two applications, letting them communicate directly.

For example, suppose a firm wishes to let its customer relationship management (CRM) application submit new orders directly to its manufacturing application. The goal might be to move orders more quickly from the salespeople to manufacturing or to reduce the number of errors in submission or something else. Whatever the reason, the solution requires nothing more than a direct connection between two applications. Figure 1 shows a simple picture of this scenario.


Figure 1: Connectivity means directly connecting two applications.

Solving a connectivity challenge like this typically requires addressing two problems:

The applications must be able to interact in some way. They might communicate via SOAP, for example, or maybe they can be connected using a message queuing technology. The solution might even use a simple approach like writing to and reading from a shared file.

The data exchanged must be translated between the different formats used by the two applications. In the example shown in Figure 1, for instance, the CRM application probably represents an order’s information differently than the manufacturing application. This problem might be addressed by translating data into and out of a common XML representation or in some other way.

Make the scenario a bit more complex, though, and the story changes. Suppose, for example, that the interaction shown in Figure 1 is part of a larger business process, and that the firm has decided to automate this entire process. The result might look something like Figure 2.


Figure 2: Integration relies on an intermediary to connect multiple applications, such as when a complete business process is automated.

In this example, the goal is to automate a multi-step business process spanning two organizations. To begin, the CRM application submits a new order to the manufacturing application (step 1), much like the previous example. Rather than being sent directly to the manufacturing application, however, the order first goes to an integration server. This specialized integration software then sends the order to the manufacturing application. Once the order is complete, the manufacturing application interacts with the integration server again, which notifies the billing application of the order’s completion (step 2). The billing application can then send an invoice to a payment application in the customer’s organization (step 3). Once again, this interaction relies on the integration server—the two applications don’t communicate directly.

Automating this kind of multi-step business process, one that involves several applications across two organizations, is a common example of integration. Automated processes are typically faster, more accurate, and less expensive to operate, and so making this kind of investment can certainly be worthwhile. The technical challenge is more complex, however—this is integration, not just connectivity—and so are the problems to be solved.

Those problems include the following: Data must now be transferred between multiple applications, each of which might support a different communication mechanism. < br> The format of that data must be translated across several applications, not just two. If automating the process requires communicating between different companies, as with step 3 in Figure 2, this business-to-business (B2B) communication likely requires conforming to a standard (and potentially complex) data format such as electronic data interchange (EDI).

There must be a way to create and execute the logic that drives the entire business process. Because this logic isn’t part of any of the applications, it needs a server to run in. And because automating all (or even a large share of) a business process is likely to make the integration software mission critical, this server must be reliable and scale well.