Enterprise Application Integration (EAI)

This article talks about several concepts related to Enterprise Application Integrations (EAI). Harnessing the experience gained in integrating applications, we will explain what and how an enterprise architecture looks like, what is an integration architecture, when and why this concept appeared, what are the benefits it brings and what options we have in implementing integration solutions.

What do we mean by the term “enterprise”?

Many of us associate the term “Enterprise” with a large or very large company, that has slow or inefficient processes. But if we look at how literature defines this term, we will notice that it is slightly different from our understanding.

The term “Enterprise” is usually defined as any human effort to undertake something. Consequently, an enterprise or a business is a group of people who work together to achieve a well-defined purpose and who perform an activity, having a certain platform as support.

A standard in Enterprise architecture domain, developed by The Open Group, defines the term “enterprise” as any organization or group of organizations that have a common purpose.

For example, an enterprise can be:

• A corporation or a department of a corporation
• A chain of geographically distributed organizations, with the same owner
• Partnerships or business ventures organized as a consortium
• Governmental agencies or governmental departments

Therefore, any organization, regardless of its size, composition or scope, has an enterprise architecture.

Enterprise architecture

Considering how the term “enterprise” is defined, we can say that any organization consists of more components that allow an organization to exist, and, in the same time, to facilitate the fulfillment of its strategies and objectives.

This type of architecture makes it possible to optimize processes of any kind, manual or automated, and their integration in an environment that is change responsive and offers support in developing the company. Besides, it facilitates the transformation of the business, keeping a balance between development, innovation and operational efficiency.

When and why did the need for integration appear?

Enterprise architectures, by nature, contain many systems and software applications, which provide different functionalities that the company relies upon to develop its daily activities.

In early 90s, many companies adopted the idea of software packaging. Which meant a product that will solve one or many business needs identified at that time. A common example is the ERP system, a software module that was a single point of contact between all the applications that managed the company resources.

Because this approach did not work as expected, companies started to add complementary solutions to be able to manage other areas of interest of the company. In the figure below, we can identify the different modules that may exist in the software infrastructure of a company.

While conducting business activities, companies must evolve to stay competitive through continuous adaption to market needs and requirements. In this ever-changing scenario, both software and hardware infrastructures are in the spotlight.

Once the business, the number of software components and quantity of information grew, companies had to find solutions to cope with the challenges of optimizing such an applications infrastructure.

How does an integration architecture look like?

Usually, a company’s application infrastructure can be very complex, made of many different applications and based on different technologies and architectures.

Initially, to facilitate their interconnection, a point-to-point integration model was used.

Point-to-point integration

Point-to-point model implies the implementation of a contact point between any pair of applications or systems that communicate. This contact point manages all data transformations, integrations and other messaging services needed for integrating the two components.

In an infrastructure with less components, this model works well enough, offering an easy integration solution and not very complex, so that any system changes are easy and quick to install.

Yet, as we add new components to this infrastructure, the number of point-to-point connections increases to get a full integration. So, the maintenance cost of such solutions increases exponentially.

As noticed in the image above, the number of connectors needed to integrate eight systems exceeds the value of thirty.

Considering that every connector will have to be developed and managed separately, applying this integration model into complex architectures gets extremely difficult if not unmanageable.

EAI Integration

The Enterprise Application Integration term was first mentioned in 1996, in a Gartner publication (USA). The study provided an analysis of several big companies’ custom approaches to handling different integration issues.

EAI can be defined as the process through which data in a software application is brought together with data coming from another application or system.

Most of the times, EAI is associated with middleware technologies and is known for having an essential role in interconnecting existent apps in the enterprise architecture by simplifying and automating business processes.

As an alternative to the P2P integration model, where the possibility of failing in connecting a complex infrastructure increases as the number of integrated systems grows, the EAI solutions rely on the middleware concept used in centralizing and standardizing integration models applicable to the entire enterprise infrastructure.

The EAI systems incorporate connection adaptors for protocol transformation, data transformation processes for converting data from the system-source format in a format that can be understood by the destination system, orchestration and routing services, as well as other components.

The model proposed by EAI loosens the connections tightly hooked with the point-to-point model. An application can send a message without having to know the user’s location, what information it needs, or the utility of the message sent. All this information can be handled by the EAI implementation.

To conclude, this architectural type is much more flexible, the components can be eliminated or added according to needs, whilst offering a simplified environment for development, where a service can be reused by several applications.

EAI implementation models

There are two main implementation typologies for EAI architecture, each with its own advantages and disadvantages.

Hub-and-spoke — the traditional Enterprise Application Integration

The first EAI implementation on the market incorporated all the necessary integration functionalities in a central component, the broker.

The central component, known by the name of Hub, will use Spokes adaptors to connect and transform data in a format they will understand.

Among the tasks of the hub component there is also the transformation of the input message in a format known by the destination system and routing it towards the end user.

Some of the advantages of this model:

• As any EAI implementation, it allows loose coupling between the applications
• Applications can communicate asynchronously, transmitting a message and then continuing its activity

Some of the disadvantages we could identify:

• Single point of failure, by having one central component
• In case of an overload in the central hub, the overall performance of the system will be affected
• Difficult to use in long-distance communication (different geographical regions)

According to statistics in the field, this architectural model was successfully implemented in some companies, but most of the integration projects based on the hub-and-spoke architecture failed.

The ESB model

Several attempts to overcome the issues that had appeared by using the hub-and-spoke model evolved into a new way of implementing EAI, called the bus. While it still uses a central component for the distribution of messages, this one succeeds in splitting the other integration tasks of components distributed in the network.

As this new architectural model emerged, new components were added that offer functionalities such as: security, logging and exception handling mechanisms, message tracking etc.

Finally, a new architecture was defined, one that allows the development of simple integration solutions, reliable and personalized, with a high degree of abstraction compared to the level of application, which follow a consistent model, and which can be implemented and configured with minimum effort, independent of the applications or the systems they connect. This architectural model is known as the Enterprise Service Bus.

The ESB integrating model is based on the SOA architecture offering an environment constituted by distributed services that communicate with one another in the network.

In the EAI domain, there is a series of providers of ESB solutions and, despite the differences between them, the majority offers the following basic functionalities:

• Location transparency — handling the message receivers in such a way that a consumer does not have to know details about a specific provider to receive messages from it.
• Transformation — the ability to convert messages in a format that can be easily understood and used by the receiver.
• Protocol conversion — the capacity to accept messages transmitted through different known protocols;
• Routing — functionality through which, based on predefined rules, the messages can be transmitted only to certain consumers.
• Message enrichment — the ability to add extra information to an existent message.
• Monitoring / Administration — an ESB solution that can offer both methods for monitoring the system performance, as well as methods for administering the infrastructure’s resources and components.
• Security — manipulating data within ESB and connecting systems and applications to the integrating solution, must be done in a secure way.

Given the capabilities offered by such a solution, we can identify the following advantages:

• Lightweight — being an architecture which is based on interconnected services, it is easily adaptable to the specific needs of each enterprise architecture, no matter how complex it is.
• Extensibility — facilitates adding systems or new applications to an already existent infrastructure.
• Scalable and distributed — having the functionalities split between components and services, these can easily be distributed in the network and scaled depending on the system’s needs.
• Adopts SOA principles — ensures a solid base for adopting architectures based on Microservices, in the process of digital transformation.

All the details presented in this article are a strong starting point for choosing an integration solution that is fit for any specific architectural needs.

For any further details regarding the enterprise integration area, you can find us here:

https://www.meetup.com/Business-Integration-Community-Cluj-Napoca/