SOA and EAI

In my last post, I discussed the difference between an application and a service. As such, we have now set the groundwork for differentiating between SOA and Enterprise Application Integration (EAI).

This is a point of confusion for most customers I speak to about SOA. On the surface, they seem to serve a similar purpose. They both result in the integration of systems across an enterprise in support of business processes such that processes can be automated for the purpose of increasing operational efficiency and bringing down the cost of doing business.

In fact, I have heard many times that SOA is just EAI rebadged. This is not at all the case. The two solution offerings have very different concerns, involve different principals and should have very different objectives.

EAI concerns itself with finding ways and means of connecting existing applications together in an automated way. Without this "glue" connecting our applications, we must rely on human beings to be the point of interaction between applications, which is costly and error prone.

The first thing to note is that EAI is about connecting existing applications. EAI does not address the design of the applications themselves. Many applications were not designed with integration in mind. Integration in this case is an afterthought. As such it is very likely we will have sub-optimal distribution of functionality and data between these applications, making it a challenge to make them all work together in support of business processes that span multiple applications.

The second thing to note is that EAI is concerned with integrating applications (as opposed to services). As I have previously pointed out, applications are an orthogonal concern to services. Applications are designed primarily to meet the needs of a user, rather than support a specific business function.

SOA on the other hand is concerned primarily with the definition and design of services, more so than how it is they should be connected; other than restricting the means of communication between services to messages. We have a strong focus on defining and enforcing service boundaries as a means of controlling coupling between services.

With EAI, we resort to any means necessary in order to connect applications. This includes sharing databases, remote procedure calls, file transfers, as well as messaging. Where messaging is not employed as the means of integration, we have coupling between application implementations. If we upgrade or replace an application, then it is extremely likely we will greatly upset all applications with which the application interacts. If we attempt to consolidate applications, that will have broad reaching effects on IT systems across the organisation.

In order to compensate for sub-optimal distribution of functionality and data across applications, EAI relies very heavily on middleware to coordinate the activities and flow of data between applications. We tend to end up with extensive process orchestrations defined and executed within the middleware.

This is in part due to the fact that most applications today expose data centric rather than process centric integration points. Where no integration points are explicitly defined by the application, we rely on direct database access and manipulation in order to achieve our objective. By definition, this approach is completely data centric. As such, the process aspects of the integration effort fall completely in the domain of the middleware.

SOA can be applied in an organisation as a means of integrating applications, but integration should not be the primary objective. The primary objective should be to achieve loose coupling in order to attain business agility, with integration as a by-product of that effort.