Most of the press, vendors and consultants only distinguish two forms of integration. One is named Enterprise Application Integration (EAI) and the second is named Business-to-Business Integration (B2Bi).

In essence:

• Enterprise Application Integration adresses the level of applications with their environment, i.e. of the applications inside the enterprise, and
• Business-to-Business Integration adresses the level of the enterprise with its business environment, i.e. with a market place, between suppliers and customers, within a trading community, and so on.

This is good as a starting point, and sufficient for drawing the Onion models of integration functions. However:

• we put very different integration issues in the same bag
• and fail to recognise different project profiles that call for quite different integration approaches.

We speak here about artifacts, so we can formally define as many levels as we wish*. Personally, I found the following four levels most useful: ( *: so feel free to adapt the definitions of levels to your context)

1. Component to component; in other words, at the software level:

where the integration is between elements inside an application, possibly an application distributed over multiple servers. This level is typically supported by application servers (J2EE), transaction monitors (CICS, TUXEDO), object brokers (CORBA), component based development environments (COM+,.NET), publish/subscribe technologies and message queuing (MQ, JMS, MSMQ), Web services, as well as more classical tools like RPC middleware. The integration is driven by the component interfaces.

2. Application to local application, or simply, at the application level:

where the integration is for instance between a Logistics Order Management System and the Warehouse Management application, else a personalization engine in a portal and the content management sub-system, else a production planning application and the production monitoring application. In all cases, we mean specialized applications, complementing each other in a tight integration mode so that they altogether can be seen as a larger application by users. Yet, each application could be working "standalone". There, integration is supported by multiple forms of middleware, much of it already cited for the previous level: transaction monitors, Message Oriented Middleware, Data Oriented Middleware, RPC tools, application buses (publish/subscribe), web services, as well as classical file transfer/sharing (e.g. FTP, NFS, SMB...), data sharing (remote SQL), and protocol/conversation engines (e.g. SNA LU6.2, TCP/IP, UDP, HTTP, ...). The success of Web Services reinforces the support of this level by EAI vendor platforms. The integration is driven by the application rules, data consistency concerns, else short-lived processes that encapsulate application logic .

3. Application to foreign application; precisely, at the organisation level:

where integration spans over several departments and link applications that are managed independently and used by different departments or subsidiaries of the same company. There, integration can be supported by middleware as above but is the original playground of EAI vendors, providing added functionality over middleware under the form of message brokers, rules engines, data transformation, process engines, workflow systems, and so on. The integration is driven by the (internal) business processes to support.

4. Company to Company, or say, at a trading community * level:

where integration spans over distinct companies and link applications within these companies through gateways, clearing systems, market places, or value added network operators. The integration is driven by Trading Partner Agreements and associated commerce processes (also called business processes) to support.( *: suppliers and customers form natural communities, the term is not limited to formalised communities like a Trading Association for instance )

As you may have noticed, identical technologies are found at multiple integration levels. Web services are a peculiar case because they can be used over the four levels. What a simplification! A single technology fits all. It may explain a part of their success, but it is also a big source of miss-implementations because a proper understanding of the integration level shall influence the way to use them: the grain of messages, security features, intermediation through proxies or brokers, composition, handling of faults, discovery, and so forth.

Business segmentation definitions make full sense at the integration level 3. Level 2 can be re-defined as integration intra-segment whereas level 3 is inter-segments.

[www.artofe.biz] © 2005 bernard Hauzeur • All rights reserved.