Integration architecture variants

The fundamental integration architecture variants are:

• Point-to-point architecture: A collection of independent systems which are connected through a network.

• Hub-and-spoke architecture: A further stage in the evolution of application and system integration, in which a central hub takes over responsibility for communications.

• Pipeline architecture: In pipeline architecture, independent systems along the value-added chain are integrated using a message bus. The bus capability results in the distribution of the interfaces to the central bus throughout the communication network, which gives applications a local access to a bus interface.

• Service-oriented architecture: The integration of different applications to form a functioning whole by means of distributed and independent service calls, which are orchestrated through an ESB and, if necessary, a Process Engine.

Point-to-point architecture

A point-to-point architecture is a collection of independent systems which are connected through a network. All the systems have equal rights, and can both use and provide services (Lublinsky 2002). This architecture can be found in many organizations, where application islands that have grown through time have been connected directly to each other.

As shown in the above diagram, in this architecture, there is no central database—each system has its own data storage.

New systems are connected directly with the existing ones, which over time leads to a highly complex set of interfaces. A point-to-point architecture with n applications can in theory have n*(n-1)/2 interfaces.

It is easy to imagine how complex, error-prone, and difficult it can be to maintain such an architecture as more and more applications are added. Expanding the system is costly and, as the number of interfaces grows, operation becomes increasingly time consuming and expensive. A SWOT analysis is shown in the following table:

Strengths	Weaknesses
Low startup and infrastructure costs Autonomous systems	Only practical if there are a few systems and a few connections Replacing individual systems is a highly laborious and costly process Very inflexible, not the base for an SOA and, therefore, it is difficult to represent business processes No overview of data Limited reusability of components Time consuming and costly operation
Opportunities	Threats
Functions within the systems can be rapidly adapted to meet new requirements	High follow-up costs Lack of standardization

Hub-and-spoke architecture

Hub-and-spoke architecture represents a further stage in the evolution of application and system integration, as shown in the following diagram (Gilfix 2003):

Its objective is to minimize the growing interface complexity by using a central integration platform to exchange messages between the systems. The central integration platform can transform messages, route them from one application to the next, and change the content of the messages. This architecture is often used for complex data distribution mechanisms. A SWOT analysis is shown in the following table:

Strengths	Weaknesses
Reduction of the interface problem Low follow-up costs Compliance with standards Autonomous systems Simplified monitoring	High startup and infrastructure costs
Opportunities	Threats
Individual systems can be integrated/replaced easily	With high transfer volumes, the central hub could become a performance bottleneck Single point of failure

Pipeline architecture

In a pipeline architecture, independent systems along the value-added chain are integrated using a message bus, as in the following figure. The implementation of this architecture corresponds to that of the hub-and-spoke architecture, as the corresponding middleware products are normally installed and operated on central servers. The bus capability results in the distribution of the interfaces to the central bus throughout the communication network, which generally also gives applications local access to a bus interface (Ambriola, Tortora 1993).

Similarly to the hub-and-spoke architecture, this architecture also keeps interface problems to a minimum. The use of appropriate middleware components allows the communication between the systems to be standardized. The bus system is responsible for message distribution. The transformation and routing rules are stored in a central repository. Depending on the middleware product in use, business functions and rules can also be represented. A SWOT analysis is shown in the following table:

Strengths	Weaknesses
Low follow-up costs Very flexible architecture Compliance with standards Autonomous systems	High startup and infrastructure costs
Opportunities	Threats
Individual systems can be integrated/replaced easily	With high transfer volumes, there is the risk of a performance bottleneck, if it is not separated from normal traffic (for example, separate bulk channel)

This form of architecture is ideal for:

• Very high performance requirements (event-driven architecture)

• 1:N data distribution (for example, broadcasting)

• N:1 database (for example, data warehouse)

Service-oriented architecture

The core of a service-oriented architecture, and the main distinction between this form of architecture and those described earlier, is the fact that business processes and applications are no longer coded as complex program structures, but are orchestrated as independent, distributed service calls.

An ESB is used as the central integration component for service calls. It has similar properties to those of the integration platform in hub-and-spoke architecture, or of the bus in pipeline architecture. A SWOT analysis is shown in the following table

Strengths	Weaknesses
Low follow-up costs Very flexible architecture Compliance with standards Supported by all major software houses	High startup and infrastructure costs Requires a comprehensive SOA strategy and governance
Opportunities	Threats
Individual systems can be implemented and orchestrated easily	Lack of focus on relevant business processes