| |
||
Enterprise Application Integration (EAI) is defined as the uses of software and computer systems architectural principles to integrate a set of enterprise computer applications.
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 workflow 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.
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.
EAI can be used for different purposes:
There are two patterns that EAI systems implement:
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).
EAI supports both asynchronous and synchronous access patterns, the former being typical in the mediation case and the latter in the federation case.
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 workflow application for approval of a loan that takes hours or days to complete).
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).
Multiple technologies are used in implementing each of the components of the EAI system:
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.
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]
Other potential problems may arise in these areas:
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.
Web Design & Development Guide, Powered by Usefulref