EAI - Enterprise Application Integration
" EAI is the ongoing process of putting an infrastructure in place, so that a logical environment is created that allows business people to easily deploy new or changing business processes that rely on IT."

The aim of EAI consulting is to integrate every piece of relevant information pertaining to internal processes and customer/partner facing processes. Today more and more organizations are implementing "best-of-the-breed" solutions. To leverage the true potential of these solutions, it is imperative that we "talk to one another seamlessly". Hence EAI consulting helps organizations with developing integration plans and integrating various "islands of information" using leading tools from Web methods, TIBCO etc.

Process
First of all, to eliminate (or create?) already some of the confusion: EAI is not something you can buy. EAI is not a product. It is not some kind of development tool. It is even not a category of middleware. EAI is something you do. It is a way of increasing the business value of your IT environment. However, it is also true that it is an IT approach that typically will make use of various middleware products and technologies.

Ongoing
EAI is not a one-time exercise. In the initial phase, where the company evolves from its current IT application environment to an EAI-enabled infrastructure, many one-time changes will occur. But even when arriving at the "final" stage of integration, it will be mandatory that, whatever further changes in the IT environment occur (new systems, new technology, changes to applications…), these are deployed in accordance to the EAI principles.

Infrastructure
The EAI process will result in the deployment of an infrastructure that implements (imposes) the principles of good application integration. Many organizations have implemented EAI-style solutions as a tactical approach to solve a specific problem. Such implementations will often be IT-driven and there is no harm to that. However, if your ambition is to work towards an EAI implementation such as the one discussed here, then "infrastructure" is a keyword. Consequently, such project must be business driven.
Some pieces of this infrastructure will be very low-level technical, far away from the abstraction layer used by the business people. However, this abstraction layer will not be able to provide its functionality and business services if the underlying groundwork is not done correctly. Message queuing is one of these parts of the underlying infrastructure that we see as being an essential element.

Logical environment
The final deliverable of an EAI exercise is a high degree of abstraction, automation and flexibility. If feasible, this environment should only reflect the image of business processes. At such abstraction level, the notion of an individual system, application, etc. does no longer exist. The technical infrastructure is not visible. Changes in this underlying infrastructure are completely transparent, without having a visible effect on the business logic layer. On the other hand, the business logic layer must have a clear view on the components that it can manipulate and the way that they interact.

This is another difficult point. An absolute requirement is a complete understanding of the behavior of the underlying components. Especially while integrating packaged applications, this really requires specialist knowledge of the internals of the package. Also, since you have no control of the package, it introduces the risk that changes occur in some of the packaged components, without you noticing.

Business People
Yes, IT people will probably not like this, but the business people are the ones who understand the business and they must be the ones that "build" business processes. No longer the complex exercises of translating business requirements into functional specifications, prototyping, RAD, etc. No, business people will simply do the "programming", be it that this programming will be quite a bit different from the one that is being used by the IT people who build the infrastructure.

Again, this underscores our requirement that EAI must be a business driven exercise. Business people have to be involved from the beginning. This also implies that top-management must drive the exercise.

New or Changing
EAI is not the thing you want to do if you have a very stable business environment (unless somewhere as a tactical solution). EAI is difficult, complex, and expensive. Therefore, you only want to start such an exercise if the potential gains are in balance with the guaranteed pains. However, in today's business climate only very few companies will have the luxury of stability. In most industries, "change" is the name of the game. EAI brings the promise of being able to handle "change".
Again, be realistic and know your business objectives. Not all companies will have the need to work towards an all-encompassing EAI implementation. For many companies, a more limited or even tactical approach will be the perfect fit. Therefore, it is necessary that you can clearly differentiate the different offerings in order to make the right decisions.

Business processes
Business process is the final keyword of our EAI definition: the things you want to do so that your company can grow; the translation of business objectives into action. This is the world of business services. These services will be built as an assembly of business components. A component being the piece of business logic that can be freely (re-) used anywhere to change, complement or enhance a specific business process.

This assembly of new or changing business processes should only have to deal with this manipulation of well-defined business components, the definition of the flow of interaction and the association of business rules to it. All underlying infrastructure, including complete ERP solutions, should be masked. Very few solutions today already provide support for such level of abstraction. As business processes are key in EAI implementations, do have a serious look at your current business operations. Some integration exercises will be a lot easier if first some level of process re-engineering takes place.

Architecture
As said above, EAI is about building an infrastructure that allows for business agility. And for an infrastructure we need some kind of conceptual view, architecture. Giving the all-encompassing character of EAI it is difficult to give one that really addresses all aspects. Especially now that EAI is extending its reach to include the e-business paradigm, lots of technologies will have their place in an EAI exercise. Therefore we will limit ourselves here to an architecture description for messaging oriented integration approaches.

Definitions of architectures are always a fun piece. Nobody agrees on the classifications and definitions, and often they are defined based upon their ability of being graphically represented in an interesting way.
Do not expect something fancy from our side. We simply needed a way to classify a bit the various pieces that make the EAI puzzle and we have based this classification upon the definition that we gave earlier. This is of course a very generic model and you can argue upon the terminology used. However, we want to use a classification that is as simple as possible, but highlights the major steps that are needed to get to a full EAI implementation. From top to bottom the layers are:

The Business Process layer
This is the layer where the business modeling is done, where the flow of business processes and associated business rules are defined. According to our definition, business people should be able to handle and control this layer. Of course, installation of the required software pieces that support this layer remains an IT task. Today, reality is that this layer still is largely undefined. None of the vendors that favor a bottom-up approach (starting at the messaging middleware layer and gradually adding functionality on top of it) already address this layer in a suitable way.

On the other hand, there are a number of vendors that entered the application integration space directly at this level, even without underlying messaging based infrastructure. Their focus typically was on the integration of packaged applications. Gradually they are extending their space to the lower layers, seeking partnerships with some of the leading vendors of transformation engines and hooking up their product to "standard" messaging environments such as MQSeries. Examples of such approach are Oberon and CrossWorlds.

In our architecture, the business layer implements the "translation" of business flows and processes. The basic object that it can manipulate is the business component. The business layer defines the rules for the chaining and the interaction of the components. The normal evolution will be that workflow-style solutions will play a major role here. But workflow alone will not be sufficient. A complete solution will have to incorporate process modeling facilities, simulation capabilities and support for complex logic.

The Component layer
The component layer is the highest stack level that is under control of IT. This layer provides all necessary building blocks that the business people can manipulate in above layer. In our messaging based EAI approach, business components are logical objects that represent the execution of one or more business functions. Being a logical object, they are instantiated by one or more (physical) executables that perform the programming logic. These instances receive requests for processing and send replies via well defined but not necessarily uniform (messaging) interfaces.

Business components are fully logical elements, without an understanding of the underlying technical infrastructure. Components manipulate "logical data" (meta-data). Therefore, any business component is free to interact directly with any other business component.

Component logic will be executed by the means of an underlying application or program. These are of course physical elements that all have their own internal representation and capabilities. Therefore, these underlying instances have to resolve their technical incompatibilities. Typically, this is handled by techniques such as data transformation, bridging, connectors, etc.

The Message Services layer
The message services layer provides generic services that can assist the functioning of above layers. This includes services such as: reformatting of messages, routing, load balancing, alternate path switching, message warehouse, etc. This layer together with the Transport Services layer discussed further on is often referred to as a "message broker".

Message broker is one of these often (mis-) used terms in the EAI literature. Since there is no clear definition of what a message broker must be, vendors will use this "label" for very different functionality. Therefore, look at the individual capabilities and not at the generic label.

The Transport Services layer
The transport services layer is the world of the "basic" middleware products. Message oriented middleware is one of the key players there, but this layer will also incorporate other middleware products such as object request brokers and transaction managers. This layer also has to provide several of other supporting services such as audit, logging and security. From a development point of view, this also includes aspects of API's, message formats and templates.

Conclusion
Even with such a simple architecture, it is obvious that the challenge is enormous. As said, no single vendor does address this today. Currently we are living a period that traditional EAI technology is merging with e-business oriented solutions such as application servers. Also ERP vendors are increasingly moving into this space. Given the anticipated importance of e-business the stakes are enormous but as yet no clear leaders do exist.

Does this mean that you have to wait? No. The potential business benefits of EAI approaches, even in today's context, are too important. Nevertheless, your first implementation will most likely be a tactical one: selecting the appropriate vendor for a specific business requirement or even a technical need. For a real all-encompassing EAI approach things are still a bit too early.

However, even when not yet going for the full 4-layer implementation model, you still can deploy your "tactical" solution with respect for the principles behind the model. Whatever vendor product will become the "leading" EAI solution of the future, the basic principles of EAI will remain the same: isolation of functionality, deployments that reflect the business process flow, clean interfaces, independence of technology, etc.

EAI does implement an infrastructure that can allow for the "seamless" replacement of business components or even complete applications. Make sure that the same principle is also respected for the EAI components themselves.

Dibon's areas of Expertise

 Scope, Consulting, Implementation, Customization and Training for EAI solutions

 Integration across multiple technologies including ERP, Web, Telephony, Mobile and Palm devices, legacy
   systems etc