Enterprise Application Integration (EAI) is defined as the uses of software
and computer systems architectural principles to integrate a set of enterprise computer applications.
Rationale for EAI
In today’s competitive and dynamic business environment, applications such as Supply
Chain Management, Customer Relationship Management,
Business Intelligence and Integrated Collaboration environments have become
imperative for organizations that need to maintain their competitive advantage. Enterprise Application Integration (EAI) is the
process of linking these applications and others in order to realize financial and operational competitive advantages.
When different systems can’t share their data effectively, they create information bottlenecks that require human intervention
in the form of decision making or data entry. With a properly deployed EAI architecture, organizations are able to focus most of
their efforts on their value-creating core competencies instead of focusing on work flow management.
For generations, systems have been built that have served a single purpose for a single set of users without sufficient
thought to integrating these systems into larger systems and multiple applications. EAI is the solution to the unanticipated
outcome of generations of development undertaken without a central vision or strategy. The demand of the enterprise is to share
data and processes without having to make sweeping changes to the applications or data structures. Only by creating a method of
accomplishing this integration can EAI be both functional and cost-effective.
One of the challenges facing modern organizations is giving all their workers complete, transparent and real-time access to
information. Many of the legacy applications still in use today were developed using arcane and proprietary technologies, thus
creating information silos across departmental lines within organizations. These
systems hampered seamless movement of information from one application to the other. EAI, as a discipline, aims to alleviate many
of these problems, as well as create new paradigms for truly lean proactive organizations. EAI intends to transcend the simple
goal of linking applications, and attempts to enable new and innovative ways of leveraging organizational knowledge to create
further competitive advantages for the enterprise.
EAI is a response to decades of creating distributed monolithic, single purpose applications leveraging a hodgepodge of
platforms and development approaches. EAI represents the solution to a problem that has existed since applications first moved
from central processors. Put briefly, EAI is the “unrestricted sharing of data and business processes among any connected
application or data sources in the enterprise.” [1]
Undoubtedly, there are a number of instances of stovepipe systems in an enterprise,
such as inventory control systems, sales automation systems, general ledger systems, and human resource systems. These systems
typically were custom-built with specific needs in mind, utilizing the technology-of-the-day. Many used non-standard data storage
and application development technology.
Improving connectivity
Enterprise Application Integration has increased in importance because enterprise computing often takes the form of
islands of automation. This occurs when the value of individual systems are not
maximized due to partial or full isolation. If integration is applied without following a structured EAI approach,
point-to-point connections grow across an organization. Dependencies are added
on an impromptu basis, resulting in a tangled mess that is difficult to maintain. This is commonly referred to as spaghetti, an
allusion to the programming equivalent of spaghetti code. For example:
The number of n connections needed to have a fully meshed point-to-point connections is given by 
. Thus, for 10 applications to be fully
integrated point-to-point, 
, or 45 point-to-point connections are needed.
However, EAI is not just about sharing data between applications; it focuses on sharing both business data and business
process. Attending to EAI involves looking at the system of systems, which involves
large scale inter-disciplinary problems with multiple, heterogeneous, distributed systems that are embedded in
networks at multiple levels.
Purposes of EAI
EAI can be used for different purposes:
- Data (information) integration: ensuring that information in multiple systems is kept consistent. This is also known as EII
(Enterprise Information Integration).
- Process integration: linking business processes across applications.
- Vendor independence: extracting business policies or rules from applications and implementing them in the EAI system, so that
even if one of the business applications is replaced with a different vendor's application, the business rules do not have to be
re-implemented.
- Common facade: An EAI system could front-end a cluster of applications, providing a single consistent access interface to
these applications and shielding users from having to learn to interact with different applications.
EAI Patterns
Integration Patterns
There are two patterns that EAI systems implement:
- Mediation: Here, the EAI system acts as the go_between or broker between multiple applications. Whenever an
interesting event occurs in an application (e.g., new information created, new transaction completed, etc.) an integration module
in the EAI system is notified. The module then propagates the changes to other relevant applications.
- Federation: In this case, the EAI system acts as the overarching facade across multiple applications. All accesses
from the 'outside world' to any of the applications are front-ended by the EAI system. The EAI system is configured to expose
only the relevant information and interfaces of the underlying applications to the outside world, and performs all interactions
with the underlying applications on behalf of the requester.
Both patterns are often used concurrently. The same EAI system could be keeping multiple applications in sync (mediation),
while servicing requests from external users against these applications (federation).
Access Patterns
EAI supports both asynchronous and synchronous access patterns, the former being typical in the mediation case and the latter
in the federation case.
Lifetime Patterns
An integration operation could be short-lived (e.g., keeping data in sync across two applications could be completed within a
second) or long-lived (e.g., one of the steps could involve the EAI system interacting with a human work flow application for
approval of a loan that takes hours or days to complete).
EAI Topologies
There are two major topologies: hub-and-spoke, and bus. Each has its own advantages and disadvantages. In the hub-and-spoke model, the EAI system is
at the center (the hub), and interacts with the applications via the spokes. In the bus model, the EAI system is the bus (or is
implemented as a resident module in an already existing message bus or message-oriented middleware).
Technologies
Multiple technologies are used in implementing each of the components of the EAI system:
- Bus/hub:This is usually implemented by enhancing standard middleware products (application server, message bus) or
implemented as a stand-alone program (i.e., does not use any middleware), acting as its own middleware.
- Application connectivity: The bus/hub connects to applications through a set of adapters (also referred to as
connectors). These are programs that know how to interact with an underlying business application. The adapter performs
two-way communication, performing requests from the hub against the application, and notifying the hub when an event of interest
occurs in the application (a new record inserted, a transaction completed, etc.). Adapters can be specific to an application
(e.g., built against the application vendor's client libraries) or specific to a class of applications (e.g., can interact with
any application through a standard communication protocol, such as SOAP or
SMTP). The adapter could reside in the same process space as the bus/hub
or execute in a remote location and interact with the hub/bus through industry standard protocols such as message queues, web
services, or even use a proprietary protocol. In the Java world, standards such as JCA allow adapters to be created in a vendor-neutral manner.
- Data format and transformation: To avoid every adapter having to convert data to/from every other applications'
formats, EAI systems usually stipulate an application-independent (or common) data format. The EAI system usually provides a data
transformation service as well to help convert between application-specific and common formats. This is done in two steps: the
adapter converts information from the application's format to the bus's common format. Then, semantic transformations are applied
on this (converting zip codes to city names, splitting/merging objects from one application into objects in the other
applications, and so on).
- Integration modules: An EAI system could be participating in multiple concurrent integration operations at any given
time, each type of integration being processed by a different integration module. Integration modules subscribe to events of
specific types and process notifications that they receive when these events occur. These modules could be implemented in
different ways: on Java-based EAI systems, these could be web applications or EJBs or even POJOs that conform to the EAI system's specifications.
- Support for transactions: When used for process integration, the EAI system also provides transactional consistency
across applications by executing all integration operations across all applications in a single overarching distributed
transaction (using two-phase commit protocols or compensating transactions).
Communication architectures
Currently, there is a lot of variation of thought on what constitutes the best infrastructure, component model, and standards
structure for Enterprise application integration. There seems to be consensus that four things are essential for a modern
enterprise application architecture:
1. There needs to be a centralized broker that handles security, access, and communication. This can be accomplished through
integration servers (like the School Interoperability Framework (SIF)
Zone Integration Servers) or through similar software like the Enterprise service
bus (ESB) model which acts as a SOAP-oriented services manager.
2. The use of an independent data model based on a standard data structure. It appears that XML and the use of XML style sheets
has become the de facto and in some cases de jure standard.
3. A connector, or agent, model where each vendor, application , or interface can build a single component that can speak
natively to that application and communicate with the centralized broker.
4. A system model that defines the APIs, data flow and rules of engagement to the system such that components can be built to
interface with it in a standardized way.
Although other approaches like connecting at the database or user-interface level have been explored, they have not been found
to scale or be able to adjust. Individual applications can publish messages to the centralized broker and subscribe to receive
certain messages from that broker. Each application only requires one connection to the broker. This central control approach can
be extremely scalable and highly evolvable.
Enterprise Application Integration is related to middleware technologies such as
message-oriented middleware (MOM), and data representation technologies such
as XML. Other EAI technologies involve using web services as
part of service-oriented architecture as a means of integration.
Enterprise Application Integration tends to be data centric. In the near future, it will come to include content integration and business processes.
EAI implementation pitfalls
In 2003 it was reported that 70% of all EAI projects fail. Most of these failures are not due to the software itself or
technical difficulties, but due to management issues. EAIIC European Chairman Steve Craggs has outlined the seven main pitfalls
undertaken by companies using EAI systems and explains solutions to these problems.[2]
- The very nature of EAI is dynamic and requires dynamic project managers to manage their implementation.
- EAI requires knowledge of many issues and technical aspects.
- Within the EAI field, the paradox is that EAI standards themselves are not universal.
- EAI is not a tool, but rather a system and should be implemented as such.
- Building interfaces is an art
- Engineering the solution is not sufficient. Solutions need to be negotiated with user departments to reach a common consensus
on the final outcome. A lack of consensus on interface designs leads to excessive effort to map between various systems data
requirements.
- Information that seemed unimportant at an earlier stage may become crucial later.
- Since so many departments have many conflicting requirements, there should be clear accountability for the system's final
structure.
Other potential problems may arise in these areas:
- EAI implementations should be extensible and modular to allow for future changes.
- The applications whose data is being integrated often belong to different departments which have technical, cultural, and
political reasons for not wanting to share their data with other departments.
Advantages and Disadvantages
- Advantages
- Real time information access among systems
- Streamlines business processes and helps raise organizational efficiency.
- Maintains information integrity across multiple systems
- Disadvantages
- Prohibitively high development costs, especially for small and mid-sized businesses (SMBs).
- EAI implementations are very time consuming, and need a lot of resources.
- Require a fair amount of up front design, which many managers are not able to envision or not willing to invest in. Most EAI
projects usually start off as point-to-point efforts, very soon becoming unmanageable as the number of applications
increase.
The Future of EAI
EAI technologies are still being developed and there still isn’t a consensus on the ideal approach or the correct group of
technologies a company should use. A common pitfall is to use other proprietary technologies that claim to be open and extensible
but create vendor lock-in.
See also
Open Source Projects
External links
References
- ^ In its April 2001 report for AIIM International, "Enterprise Applications:
Adoption of E-Business and Document Technologies, 2000-2001: Worldwide Industry Study," Gartner defines EAI as "the unrestricted
sharing of data and business processes among any connected applications and data sources in the enterprise."(http://findarticles.com/p/articles/mi_qa3937/is_200203/ai_n9019202)
- ^ Trotta, Gian (2003-12-15). Dancing Around EAI 'Bear
Traps'. Retrieved on 2006-06-27.
This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)
