Consulting

Understanding EAI
Bridging the gaps across the Enterprise

Get connected

. . . .
Audit Tax Consulting Corporate Finance
 Understanding EAI

Contents
1. Introduction 4
1.1. The extended enterprise 4
1.2. What is middleware? 5

2. Integration fundamentals 6

2.1. Integration approaches 7

2.1.1. Point to point 7
2.1.2. Application server based 7
2.1.3. Integration broker 8
2.1.4. Portals 9

2.2. Common architectures 11

2.2.1. Hub and spoke architecture 11
2.2.2. Bus architecture 12
2.2.3. Service oriented architecture 12

2.3. Web Services overview 14

2.4. Emerging technologies 15

2.4.1. Enterprise Service Bus 15
2.4.2. Business Process Management 16

2.5. Types of messaging 16

2.5.1. Synchronous vs. Asynchronous 16
2.5.2. Broadcast vs. Point-to-point 17
2.5.3. Queuing vs. Pub/sub 17
2.5.4. Request/response vs. Fire and forget 18

2.6. Types of integration 19

2.6.1. Application Programming Interfacing 19
2.6.2. Data-level integration 19
2.6.3. Message-level integration 20
2.6.4. Process-level integration 20

1
Understanding EAI

3. How to sell EAI to our clients 22

3.1. Integration requirements 22
3.2. The business case for integration 23
3.3. Establishing the ROI 24
3.4. Risks of integration 24
3.5. How to plan and build a Middleware solution 25
3.5.1. Business case and requirements analysis 26
3.5.2. Evaluation, proof of concept 26
3.5.3. Architecture 27
3.5.4. Analysis and design 27
3.5.5. Build 27
3.5.5.1. Messaging layer/infrastructure 28
3.5.5.2. Build/configure adapters 28
3.5.5.3. Transform/route messages (message broker) 28
3.5.5.4. Implement process flows and workflow 28
3.5.5.5. Implement business partner integration 28
3.5.5.6. Implement portal 28
3.5.5.7. Implement system management and monitoring components 29
3.5.6. Test & release 29
3.5.7. Operations & monitoring 29

4. Vendor overview 30
4.1. Market overview 30
4.2. Key vendors 30
4.2.1. IBM 30
4.2.2. BEA 32
4.2.3. Microsoft 34
4.2.4. Others 36

5. Glossary 37

2
 Understanding EAI

Scope
This document is intended as:

• A quick reference guide and primer on middleware solutions for Deloitte staff;

• An overview of our Integration & Portals capability within Development & Integration (D&I);

• A useful tool in high-level architectures and bid work.

Acknowledgments
This document has been written by Deloitte staff who are experts in the field, with contributions
made by:

• Trevor Allen;

• Paul Shaw;

• Steven Francis;

• Ian Shepherd.

Contacting us
Questions or feedback relating to Development & Integration or this document should be addressed
to Neil Allcock, UK D&I Lead (+44 207 007 8127, [email protected]).

3
Understanding EAI

1. Introduction
This book is an introduction to middleware, enterprise application integration (EAI) and business-to-
business integration (B2Bi). The aim of this guide is to provide an insight into integration technology
and issues for a wide readership, ranging from the wilfully non-technical to those who are just
getting started with application integration.

1.1. The extended enterprise

Today’s typical enterprises use best-of-breed packaged applications to perform specialised tasks such
as accounting, provisioning, billing, shop floor control, inventory management. Within these
applications there is data which is common to a few applications such as customer information,
product information, etc., creating a need to share information. While these applications are all
behind the firewall, today’s enterprises also need to communicate with suppliers, partners, public
marketplaces and customers to improve quality of service, increase efficiency, control costs, and
manage profitability. In other words, there is a need to integrate.

Typical mid-to-large enterprises have tens to hundreds of applications performing specialised tasks
and which need to share data. The number of interfaces can grow exponentially as new applications
are deployed.

4
 Understanding EAI

The main driver for enterprise application integration (EAI) is the relatively recent transition from
all-encompassing, monolithic, custom-built applications to a set of off-the-shelf, best-of-breed
specialised applications, running on a variety of hardware and software. This multitude of applications,
each with its own database, has created “islands of data” in an enterprise’s IT infrastructure.

• Each island has its own interpretation of enterprise-wide objects (i.e. customers, products,
shipments, sales).

• Each island has data that overlaps with data contained in other islands, creating an integrity
issue.

• None of the islands contains complete information about enterprise objects, making it necessary
to integrate data from multiple islands for a unified view of the enterprise objects.

These islands of data are also “islands of automation”. Each application, such as an ERP system
(e.g. SAP, Peoplesoft), is built for a single purpose and for a single set of users. It automates only a
limited set of functions within the overall required enterprise functionality:

• Each island automates only a limited set of activities within the enterprise.

• There is duplication between business processes contained within different islands, which
requires synchronisation of business rules between them.

• None of the islands contains enterprise-wide processing, making it necessary for multiple islands
to create unified enterprise processes. Some enterprises already have manual processes to
support enterprise-wide functionality, but the processes should be formal and automated.

ERP systems, originally intended to eliminate the need for a large portfolio of different applications,
have turned out only to add to the complexity. Estimates vary but it is commonly accepted that an
ERP system only addresses a small part of the total functionality required by an enterprise, typically
less than 25%-30% of an enterprise’s needs.

Middleware emerged as a technology aimed at solving the islands of information problem.

1.2. What is middleware?

Finding an analogy for middleware
Middleware is like a Babelfish. According to Douglas Adams in the book “The Hitchhiker's Guide to
the Galaxy” a Babelfish is a special sort of fish, when put in the ear it interprets between different
languages. In the same way, middleware solves the problem of disparate systems that can not
communicate with each other.

Ovum defines middleware more precisely as “The combination of technologies and processes that
enable custom-built and/or packaged business applications to exchange business-level information
in formats and contexts that each understands”.

While Gartner says it is “the software glue that helps programs and databases that may be on
different computers work together”, which is the most helpful analogy to remember.

5
Understanding EAI

2. Integration fundamentals
What you need to know about middleware
Whenever two application systems have to be integrated they are linked using middleware, typically
as point-to-point interfaces. The presence of many such point-to-point interfaces in an enterprise
creates a confusing maze of software pipes running in and out of application systems. Middleware
solutions have evolved from these point-to-point interfaces to a packaged middleware solution
which is able to link multiple applications together. This evolution has culminated in an enterprise-
level middleware platform that links multiple application systems within the enterprise while also
communicating with application systems in partner enterprises.

An enterprise application integration solution will need to address the following services.

6
 Understanding EAI

2.1. Integration approaches

2.1.1. Point to point
In this approach, there is a direct link between any two applications. Data is transformed by the
originating application into the format for the target application. This is fine when there are only
two applications; however as the number of applications increases the number of interfaces grows
exponentially. This becomes highly complex and expensive to maintain.

For N systems, there are potentially as many as N.(N-1)/2 links.

2.1.2. Application server based

This approach contains a common application server which accepts requests from web users or
client applications and processes these using services and data from service applications. They
provide a mechanism to build applications that communicate with several back-end resources
(applications, databases, queues, objects) and deploy the applications to a Web platform.

Application server based integration suits highly trafficked, web-based applications, with relatively
simple integration flows. Application Servers provide a central location for application logic from
multiple packages and facilitate communications with multiple resources, applications, databases, etc.

7
Understanding EAI

If there were an application error while processing the requested service, the middleware is able to
rollback the updates made to all resources, such as databases and queues during the transaction,
returning the integrated systems to their previous consistent state. (Note it is not always possible to
perform a full rollback unless all end applications support 2-phase commit) Application Servers are a
Web-enabled evolution of traditional transaction-oriented middleware called Transaction Processing
Monitors (TP Monitors).

TP Monitors have traditionally been used to build mission-critical applications based on multi-tier
client/server architectures. Key features of TP Monitors are scalability, transaction support, resource
management, availability, database connection pooling, queuing and load-balancing. Examples are
BEA Tuxedo, Microsoft MTS and IBM CICS.

Most, if not all, present day application servers will either adhere to JavaSoft’s Enterprise Java Bean
(EJB) specifications and the J2EE component framework or alternatively they will be compliant with
the Microsoft .NET platform. Example application servers include BEA Weblogic & IBM Websphere.

2.1.3. Integration broker

This approach involves a common integration broker middleware linking many applications to many
other applications via software messages. This is a flexible and extensible model in which an event in
an application (e.g. new customer setup) triggers a message to the broker which will transmit
messages to multiple systems which need to know about the event (based on configurable business
rules). It also supports the automation of long running transactions using multi-stage message
flows. Integration Brokers represent a powerful mechanism for integrating multiple resources
(application systems, databases, queues, objects and middleware solutions).

8
 Understanding EAI

For N systems there are N links.

Integration Brokers support transformation of the data and intelligent routing of messages as it
flows between applications through the middleware. They enable quick connectivity to several
applications by providing off-the-shelf adapters – easily configurable products enabling connectivity
to proprietary applications. Integration brokers also provide:

• Workflow capabilities – for moving an item of work between systems and/or end users.

• Business process integration – to define and run business processes across applications.

• Monitoring mechanisms – to manage the status of processes and the performance of the
integrated system.

Leading vendors in this space are IBM, TIBCO, SeeBeyond, webMethods and Vitria.

2.1.4. Portals
Portals are one-stop user-interfaces that allow users to store content and access information from
several sources within and outside the enterprise. Portal user-interfaces are typically Web browsers
and wireless devices. The sources of portal information are application systems, databases, and
document and image repositories within the enterprise, and content aggregated from outside the
enterprise. The users of portals could be employees, customers or business partners.

Leading Portals include Microsoft, Plumtree, Obtree (now OpenText), Vignette, Broadvision,
Interwoven, Convera Documentum, and Hummingbird.

9
Understanding EAI

Integration brokers enable the development of portals by providing a tool to build the portal user-
interface and to manage the aggregation and display of portal content. The overall architecture of
an integration broker based portal is shown below.

Portals typically provide the following features:

Content Aggregation and Delivery – The process of accessing and aggregating content from
several different sources and rendering the content for different presentation media like Web
browsers, mobiles, PDAs, and pagers.

Personalisation – Enables portal users to customise their portal experience, tailoring the content
and appearance of their portal. Rules engines determine what content needs to be displayed, when
and for whom. Business intelligence engines monitor the user’s interaction (click stream analysis)
and accordingly send targeted ads/promotions and cross-sell/up-sell content.

Notification – Portal users can request notification of selected information based on a

time-schedule or a user-defined event e.g. fall in a certain stock price by 5%. Notifications can be
received on a Web browser or wireless device.

Security – Integration brokers typically provide end-user authentication services for portals. They can
also allow use of authentication services from the Web server or an external security system.

10
 Understanding EAI

2.2. Common architectures

2.2.1. Hub and spoke architecture
A hub-and-spoke architecture is the most common architecture design in a middleware
implementation. A centralized broker called the ‘Hub’ acts as the middleman in all transactions in a
hub and spoke architecture. The disparate systems (spokes) never exchange messages directly;
instead they send the messages to the hub. The hub processes all in bound messages and performs
various operations before sending a message to the downstream system. Some of the tasks that the
hub performs may include:
• Validating the incoming data.
• Transforming the data for consumption by the downstream systems.
• Enrichment of data to make it acceptable at the downstream system.
• Routing of the data to the appropriate downstream system.

The message broker, messaging layer and adapters are important components of a Hub & Spoke
architecture.

Message broker – The message broker transforms the data between the formats used in the
source and destination applications and supports intelligent routing of the messages at run-time
based on data values.

Messaging layer – The underlying mechanism that transports messages between the applications
in the enterprise.

Adapters – Adapters or connectors are components that connect the integration broker with the
external application systems.

11
Understanding EAI

2.2.2. Bus architecture

The concept of a Bus architecture is that it provide the enterprise with a messaging backbone that
ties all of the integrated systems together. Each of the integrated systems would be able to
interoperate through use of a standard message formats known to the other systems on the Bus.
Proprietary middleware solutions such as TIBCO and technologies such as CORBA have typically
been the implemented as a means of providing the messaging standards and controlling the usage
of the Bus.

However, with the Emergence of Web services and Service Oriented Architectures, the bus
architecture is becoming fashionable again in the shape of Enterprise Service Buses.

2.2.3. Service oriented architecture

A service-oriented architecture is a collection of services that communicate with each other to
provide a loose coupling of different software systems. It allows the implementation details to be
abstracted from the process definitions and patterns leading to an adaptable, flexible style of
architecture. Service based architecture is an aggregation of services satisfying a business process
such as for example a Trade Settlement or Home Loan Settlement. The model enables the reuse of
common functions in different business contexts. Interfaces should be available for all providers and
consumers (Web Services). The communication can involve either simple data passing or it could
involve two or more services coordinating some activity. Some means of connecting services to each
other is needed.

Service-oriented architectures are not a new thing. Early service-oriented architectures used DCOM
or Object Request Brokers (ORBs) based on the CORBA specification. A service is a function that is
well-defined, self-contained, and does not depend on the context or state of other services. The
technology of Web services is the most likely connection technology of service-oriented
architectures. Web services essentially use XML to create a robust connection.

12
 Understanding EAI

The following figure illustrates a basic service-oriented architecture. The request and subsequent
response connections are defined in some way that is understandable to both the service consumer
and service provider. A service provider can also be a service consumer.

The principle of service oriented architecture can also be applied to integration, and a flexible
integration architecture can be created using services. Some services are used for application
integration, some for process integration support and others for system management and
monitoring.

Application Integration Services – Enable communication/information flow between different

systems.

Application Support Services – Enable process integration.

System Management Services – Provide system support, monitoring and reporting.

The following table shows some example services that have been used in previous integration work.

13
Understanding EAI

2.3. Web Services overview

Web Services are a set of technical standards that have gained prominence in recent years; they are
an enabling technology for service oriented architectures. Web Services standards are defined by
OASIS, a non-profit making organisation that drives the development and adoption of standards in
e-business. Because large IT firms like Microsoft and IBM contribute to the standards, they should in
principle promote interoperability.

The Web Services Description Language (WSDL) is the agreed standard used for describing Web
Services. The following figure illustrates the use of WSDL. The steps involved in providing and
consuming a service are:

1. A service provider describes its service using WSDL. This definition is published to a directory of
services. The directory could use Universal Description, Discovery, and Integration (UDDI).
Other forms of directories can also be used.

2. A service consumer issues one or more queries to the directory to locate a service and determine
how to communicate with that service.

3. The WSDL definition of the service is passed to the service consumer. This tells the consumer
what the requests and responses look like for the service.

4. The service consumer uses the WSDL defined format to send a request to the service provider.

5. The service provider provides the expected response to the service consumer.

14
 Understanding EAI

All the messages are sent using SOAP (Simple Object Access Protocol – the envelope format for
sending the Web Services messages). SOAP generally uses HTTP as a transport mechanism, but
other means of connection may be used. However, it is the pervasiveness of HTTP connections that
will help drive the adoption of Web Services.

There are many other standards that cover more specific functionality (many are still evolving and
have not been ratified as yet, covering areas such as transaction management, reliable messaging
and security). For example WS-Security is a web services standard that covers how web services can
be used securely across the internet between multiple business partners. One of these specific
standards that is currently emerging and will be of particular interest in integration is BPEL
(Business Process Execution Language). This defines a notation for specifying business process
behaviour. Business processes can be described in two ways:

• Executable business processes – actual behaviour of a participant in a business interaction.

• Business protocols – how the process conceptually works without revealing their internal
behaviour. The process descriptions for business protocols are called abstract processes.

The scope of the BPEL description includes:

• Sequencing of process activities, especially Web Service interactions.

• Correlating individual messages with the correct process instance.

• Recovery behaviour in case of failures and exceptional conditions.

• Bilateral Web Service based relationships between process roles.

2.4. Emerging technologies

2.4.1. Enterprise Service Bus

Enterprise Service Bus (ESB) combines features from several previous middleware approaches.
The key to its emergence is:

1. Its distributed architecture, wherein some services are executed near the application programs,
rather than in a central hub.

2. Open Standards-based infrastructure.

3. The value-added services it provides, beyond those found in basic communication middleware
e.g. load balancing, logging, failover etc.

In comparison to a Service Oriented Architecture where the entities are distributed and publish their
abilities, ESB’s support a centralised configuration and deployment of the entities allowing the
Enterprise to know where and how many instances of the entity exist while also being able to
redistribute services without affecting operations.

ESB is seen as a “lightweight” middleware option, and many of the suppliers are new or small
vendors (e.g. Fiorano’s ESB, IONA’s Artix, Sonic Software’s ESB).

15
Understanding EAI

2.4.2. Business Process Management

The Butler Group define BPM as “the software and tools required to model and execute an
organisation’s business processes, through the orchestration and integration of the necessary
people, systems, applications, and application components”.

BPM concerns the delivery of business processes and how to align the resources of the enterprise in
order to do so. From an EAI technology perspective this means going beyond a technical integration
of the enterprises technology stack (i.e. plugging all the boxes together) and providing process
integration enabling the core business processes at the heart of the enterprise (e.g. Manufacture
Product, Procure Supplies, Answer Customer Inquiry etc.).

BPM provides the necessary abstraction layer between the business and the IT implementation used
to support the processes. This lends itself nicely to a Service Oriented approach, allowing the
best-of-breed applications to collaborate seamlessly and efficiently to provide the individual tasks
that make up the business process.

2.5. Types of messaging

Middleware communications can be implemented using a number of different mechanisms.

2.5.1. Synchronous vs. Asynchronous

Synchronous – In synchronous mode, whenever the calling application wants to have a request
processed at a remote application, it passes the request to the middleware and waits for a response.
Once the remote application processes the request, it sends a response to the middleware which
forwards it to the calling application. The calling application stops processing until a response is
received, i.e. this middleware has a “blocking” nature.

Asynchronous – The calling application sends a message to the middleware and carries on with its
own processing, looking for a response from the remote application only at a later point in time.
Unlike the synchronous mode the middleware has a “non-blocking” nature, making the
asynchronous mode a popular choice for integration.

16
 Understanding EAI

2.5.2. Broadcast vs. Point-to-point

Broadcast – Some messaging technologies take advantage of network broadcast protocols to push
messages to multiple systems. Such an example would be TIBCO’s Rendezvous messages, that use
UDP broadcast to publish one message that is transmitted to all the nodes on a network. Broadcast
messaging is an efficient way of saving network bandwidth in a high traffic environment where
there are multiple consumers of information. However, since broadcast mechanisms usually do not
have control over who subscribes to messages at a network level, there are inherent security issues.

Point-to-point delivery – Point-to-point delivery on the other hand is built on point-to-point

network protocols such as TCP. As the name suggest, point-to-point is delivering messages from the
producer to the consumer. Point-to-point provides better control over where the messages are sent
thus providing better security. However, when there are multiple consumers of the same message,
point-to-point can become inefficient.

2.5.3. Queuing vs. Pub/sub

Queuing – In queued communications, the calling application sends the message to a queue in the
middleware and carries on with its own processing. The remote application retrieves the message
from the queue in the middleware and works on it. The remote application does not have to be
active for the calling application to send a message to it.

Publish/subscribe – In publish/subscribe, the middleware solution has a central pub/sub engine or

hub or broker. The calling application sends (publishes) the message with a certain topic to the
broker and carries on with its own processing. The broker, in turn, redistributes the message to all
applications (subscribers) that have subscribed to that topic. In this model, the publisher does not
need to know anything about the applications that are interested in the published message. This is a
typical model for middleware platforms that link a community of application systems.

17
Understanding EAI

2.5.4. Request/response vs. Fire and forget

Request/response – The calling application sends a message to the middleware, also indicating the
target remote application. The middleware then passes the message to the specified remote
application. The remote application passes a response message to the middleware which sends it
back to the calling application. The calling application expects a response but can collect the
response synchronously or asynchronously via the middleware. In addition, the middleware may
transform the data flowing through.

Fire and forget – In this model, the calling application sends a message to the middleware solution
without worrying about the recipient or even if the message is ever received e.g. latest stock quotes.
The middleware solution then broadcasts the message and interested applications can pick up the
message.

18
 Understanding EAI

2.6. Types of integration

Enterprise integration can be achieved at a number of levels, depending on which is most suitable
for the business, depending on the role middleware has in supporting the business.

2.6.1. Application Programming Interfacing

One of the earliest methods of integrating applications was through program functions that were
exposed outside the application as Application Programming Interfaces (APIs). This would allow
external applications to make use of the services provided by the application, however there were
typically limitations with respect to what services were exposed and what technology platform was
being used, which prevented communication across different platforms/networks. Nowadays APIs
are still exposed by most applications and with the emergence of open Internet standards such as
XML and TCP/IP, integration across different technology platforms has been made easier.

2.6.2. Data-level integration

Data-level integration is one of the simplest way of integration and the least complex to implement
(providing the data model is well understood). The basic concept is to support data exchange
between disparate applications by moving data directly between the databases that support
applications. Updates on one database are automatically propagated to other databases so that
applications accessing different data stores get the same view. This update process can be achieved
with the use of database triggers, or a batch process.

The approach is simple because databases can easily be accessed, and because it avoids the need to
modify the application sitting on top of it.

There are several disadvantages of data-level integration. Application logic is bypassed, which could
potentially result in data being used in the wrong context. Because the data structure of the
applications is tightly coupled, it becomes difficult to make changes to one application without
impacting the others and the data integration mechanism itself.

19
Understanding EAI

2.6.3. Message-level integration

Message-level integration uses the exchange of messages between multiple applications.
The approach differs from data-level integration in that the applications themselves trigger the
messaging. This provides more controlled information exchange. This approach also leverages
existing application logic, data transformations and validations.

Message-level EAI is more invasive then data-level EAI because it requires more modifications to
existing applications to create interfaces for sending and receiving messages. Disparate systems
publish messages to other systems, and messages are handled by processes within individual
systems. Each exchange of a message is a distinct transaction, and there is no simple way to tie
together messages that form part of a single business process.

2.6.4. Process-level integration

Process-level integration (also known as Business Process Management) is an extension of
message-level EAI. It allows the building of enterprise wide business processes and incorporating
existing applications into those processes. The actual data exchange still occurs via messaging, but
EAI middleware acts as a workflow engine – orchestrating message exchange. Because business
processes extend into multiple systems, a workflow is completed only after the different systems
have processed and acknowledged received messages.

20
 Understanding EAI

Process level EAI can fundamentally change the way traditional processes are managed within the
enterprise by:

• Minimising/eliminating Manual processing.

• Allowing better control of data transfer through real time and guaranteed delivery.

• Synchronizing workflow and ensuring completion of key tasks in processes that span multiple
areas of an organisation.

This is the ultimate EAI implementation because it transforms existing disparate applications into a
cohesive system of business processes, supporting all the functions the enterprise requires.
Arguably it offers the greatest business benefits and return on investment, though this can be
difficult to measure.

Integration brokers originally supported integration within the enterprise only, but integration with
business partners is now supported, enabling coordination of multi-step business processes that
span multiple enterprises.

Business Process Management (BPM) coordinates entire multi-step business processes, potentially
involving several applications and lasting several seconds, minutes, hours, days or even weeks.
The Business Process Manager tracks each instance of a business process (e.g a customer order)
through its entire life-cycle from receiving the initial message that triggers the process through to
completion of the process. Unlike simpler forms of flow automation, the Business Process Manager
maintains context information for the duration of a business process instance that spans many
individual events.

BPM is different to simple Workflow Management because workflow coordinates the movement of
an item of work across several persons in the enterprise to complete a process end-to-end.
Nowadays the workflow and process-level integration are being merged to support an integrated
process flow spanning across application systems and human users of the systems.

21
Understanding EAI

3. How to sell EAI to our clients

3.1. Integration requirements
“What we want is...”

These are some of the words regularly used by our clients to explain what it is they need from an
integrated solution that cover more specific functionality :

Functionality – The platform will typically support automated business processes based on the
exchange of information between systems independent of individual formats.

Data Integrity – The middleware platform will maintain data-consistency as it transfers data
between applications and components.

Availability – The platform will become an enterprise resource, required 24x7 with minimal
downtime during hardware or software maintenance.

Scalability – The middleware platform will easily accommodate additional loads by adding
computing resources without any software changes.

Flexibility and Extensibility – The platform will easily allow replacing or modifying components
and adding new functionality.

Reliability – The middleware platform will be reliable by ensuring that sufficient redundancy is
built-in.

Security – The platform will support security features such as authentication of users and other
systems, access control lists (ACL’s) to control authorisation levels for different user groups, digital
certificates, digital signatures and other internet security measures for interactions across the
firewall.

Stability and Robustness – If the middleware platform is used in a manner different from what is
normally expected, it will remain in a consistent state and respond in a user-friendly manner.

Monitoring – The platform will provide tools to track messages that flow through and monitor the
state of business processes and connected components.

Exception Handling – The middleware platform will facilitate exception handling by allowing
correction of data and re-submission of erroneous messages.

22
 Understanding EAI

3.2. The business case for integration

Today's corporate systems are a complex web of personal computers, midrange systems, and
mainframes that run a variety of operating systems, applications, database management systems,
software languages, and system tools. This type of environment leads to several problems, including:

• Complex/inefficient business processes and linkages.

• High process costs.

• Limited process flexibility.

• Limited scalability.

• High costs for interface development and support.

• Limited cross system information.

The foundation of e-business is the integration of behind-the-scenes systems. The market is

requiring back-office and B2B integration associated with supply chains, e-commerce, and internal
initiatives. This integration is becoming increasingly complex as a result of mergers and acquisitions,
as well as the global presence of many organisations. This environment has resulted in an increased
focus on enterprise and inter-enterprise integration, including middleware services such as
store-and-forward message delivery, application adaptors, data transformation, and rule-based
routing.

According to Gartner Group, approximately 40% of the average IT budget is spent on integrating
systems. An increasing proportion of IT budgets is being spent on “infrastructure” items, including
middleware, that are required to build an integrated enterprise. However, the business case for
infrastructure software is difficult to justify. Many of the benefits of infrastructure software are
qualitative, intangible, and don’t lend themselves to straightforward cost-benefit analysis.

If a business case cannot show a quantifiable profit or ROI in 2-3 years it will be likely to be thrown
out. Yet many enterprises are struggling with a complex web of interconnected legacy systems.

In addition to IT costs savings, Benefits can include:

• Reduced business process costs.

• Improved process and organisational flexibility.

• Faster decision-making ability.

• Organisational learning.

• Information availability and timeliness of information.

A quote from Gartner Group’s Roy Schulte: “Enterprises that thrive in the future will be those that
can rapidly assimilate packaged applications and re-use their existing applications in new ways.
They understand that systems built to change are ultimately more valuable than systems that are
built to last. The key to their success will be in how they modularise their application portfolio and
how they organize the connections among their systems.”

23
Understanding EAI

3.3. Establishing the ROI

Two commonly asked questions are:

• What will be the value of the benefits generated by more streamlined business processes?

• How much will it cost the organisation to implement these processes?

A common pitfall is to point to “time savings” and “increased revenue” as sources of ROI, but
neither of these deliver, by themselves, an improvement in profitability.

First estimate the number of point to point interfaces which would need to be developed and
maintained on an ongoing basis as a baseline for IT costs without a separate integration
programme. Then calculate the one off EAI implementation costs and the costs for building one
adapter for each application within the new integration broker architecture. This should provide a
basis for assessing potential IT costs savings.

Next conduct an analysis of all costs, revenues and profits associated with the business process as
supported by current technology. Then analyse how those metrics will change once the business
process is streamlined by using an integration solution.

Once you have analysed the benefits of the new business process, you need to analyse costs of
implementing the new business process, including a calculation of the cost of integrating
applications and the organisational costs.

3.4. Risks of integration

Integration projects are very complex and there are many examples where things have gone wrong.
The following risks are commonly seen in integration work:

Underestimating application integration – A middleware infrastructure is a key enabler of many

new e-business initiatives, whether in CRM, SCM or B2B. All of these require significant integration.
Underestimating integration effort may lead to longer time-to-market and higher costs of deploying
such new systems. EAI and B2Bi estimates are typically based on one-off costs for implementing the
EAI or B2Bi infrastructure, with an on cost for each package or system which needs to be connected
via an adapter, and then a cost per business process to support the integration across multiple
packages and system. It is particularly important not to underestimate the cost of developing
package or system adapters – as these will be very dependant on the complexity of the package or
system involved.

Middleware vendor and product related risks – Choosing the right vendor and product is key.
The right product from the wrong vendor is as bad as the right vendor with the wrong product.
Many enterprises which embark on an integration programme by themselves may quickly find
themselves out of their depth and in need of vendor assistance, which may not be available – some
vendors simply don’t provide the resources to support the initiative. Reduce this risk by running a
pilot and conducting a thorough evaluation process. In a large organisation, integration
requirements can vary widely between business units. It is likely that multiple products from multiple
vendors will be required.

24
 Understanding EAI

Size and scale – Integration solutions are part of a strategic “city planning” infrastructure, but
building a comprehensive infrastructure from scratch is practically impossible; by the time the overall
integration requirements have been gathered the business will have moved on and the technology
will have evolved two generations. This risk can be managed by building the integration solution as
functionally complete as it can get but on a smaller scale and scope. Later the scale, scope and
functionality can be expanded through project-driven incremental choices.

Single point of failure – Point-to-point connections between applications, whilst difficult to

manage, tend to be highly resilient. An integrated architecture, e.g. hub-and-spoke, increases the
manageability but introduces the risk of a single point of failure if there is a major software or
hardware failure in the integration broker. The risk can be countered by adopting an integration
broker that supports clustered configurations (one broker automatically takes over from another on
detecting a failure) and base it on a high-availability infrastructure.

Composite applications – Integration increases dependencies between applications. When two

applications are integrated simply through an overnight batch process the receiving application, and
the business process it supports, is engineered to deal with this delay. When middleware is
introduced the exchange is done in real-time and the business process it supports is re-engineered to
make use of this. This creates a dependency that can have a major impact on business operations
and continuity. When more than two applications are involved, i.e. as a “composite” application; in
addition to delivering benefits this can increase the impact of failure. Business processes must be
engineered to deal with these circumstances, e.g. how to handle order confirmations if the
application is using out-of-date information.

Data pollution – Middleware can move data around very quickly, which has the effect of migrating
any data pollution very quickly too.

Staff turnover – Middleware-skilled staff are very scarce and highly valuable in the market
(we would say that!). The effect of key staff leaving can be profound, but can be reduced by
insisting on high documentation standards and a knowledge management strategy (and by an
effective retention strategy).

3.5. How to plan and build a Middleware solution

A typical plan to build a middleware solution would be as follows:

25
Understanding EAI

3.5.1. Business case and requirements analysis

A formal business case setting out the quantitative and qualitative benefits of a middleware solution
is often required. Once this has been agreed with the business sponsors, a specification of
integration requirements can be developed.

• Build the business case, using readily available tools and methods.

• Confirm the scope of the integration requirements in a business context, e.g. integration
requirements may be confined to a bank’s retail operations but not include its capital markets
operations, which provides a rough delineation of the problem domain and the systems
concerned (which applications need to be integrated).

• The bulk of a middleware solution’s ROI is usually reflected in business areas other than the IT
organisation of a business, so middleware may be seen as a “cost” programme initially.

• Reduced cost-to-serve per customer and reduced transaction times (e.g. enabling straight-
through-processing in financial markets environments) are examples of the tangible ways in
which the ROI can be measured.

• Develop a detailed requirements specification, which covers functional requirements but also
integration-specific ones, i.e. which applications and systems will need to “talk” to each other,
and how.

3.5.2. Evaluation, proof of concept

Once requirements have been established, select the right technology to implement the middleware
solution. Rather than conducting a .beauty parade. of vendors and their products, or running a
scoring exercise of technical solutions, added value can be derived by kick-starting the Architecture
and Analysis & Design work in a cost-effective manner . vendors will usually agree to perform a
Proof of Concept for a nominal fee, or sometimes even for free. While the PoC system will not be
re-usable, design deliverables produced during this work may be to a sufficiently high standard so
that they can be taken forward.

• In the selection and evaluation, focus on vendor industry credentials, the availability of adapters,
and the quality of vendor support.

• There are not too many big/key vendors in this space, fewer than a dozen, although the market
is a confusing mix of technologies.

• You may wish to run a PoC exercise to test the technology as well as the vendor’s claimed
characteristics. This also provides a cost-effective way of kick-starting the architecture and
analysis & design stages.

26
 Understanding EAI

3.5.3. Architecture
Developing an architecture for a middleware solution involves making some key decisions on the
nature of the integration that is being sought.

• Type of architecture e.g. hub-and-spoke vs. a bus (publish/subscribe) architecture.

• The final architecture may be strongly influenced by the choice of vendor technology, e.g. TIBCO-
based solutions are by default based on an open publish/subscribe architecture, whereas IBM’s
WebSphere MQ is typically deployed as a hub-and-spoke architecture (or even involving several
connected hubs).

• When building a solution that involves integrating customers and/or suppliers, through portals
and B2B integration, security becomes a key consideration.

3.5.4. Analysis and design

The Analysis and Design work involves developing:

• Interface specifications.

• Process definitions (UML definitions/Use Cases can be taken as a starting point).

• Workflows.

• Routing and transformation rules (the .translation engine. that determines how messages
between applications should be translated).

• Enterprise message format standards.

3.5.5. Build
The Build phase relies heavily on outputs produced in the preceding phases. During the Build phase,
a number of solution components need to be installed and then configured. Installation is often a
straightforward wizard-driven process, requiring only minor customisation to suit the specific
situation. The subsequent configuration work is more complex and challenging. The diagram
highlights the key components that need to be deployed.

27
Understanding EAI

3.5.5.1. Messaging layer/infrastructure

This provides the underlying transport mechanism for the overall integration solution.
Many organisations currently using middleware only make use of this layer to provide them with a
guaranteed delivery mechanism, which still leaves them with point-to-point solutions (the
“spaghetti” of interfaces between systems).

3.5.5.2. Build/configure adapters

Adapters are the software components which connect an application to the middleware solution.
Developing custom adapters can become a massive time-sink, especially when dealing with
applications which have no APIs (Application Programming Interfaces, a way of interacting with an
application) of their own. Opt for pre-built, off-the-shelf, adapters wherever possible. Alternatively,
you can always opt for adapters that access the underlying database directly, or even file-based
adapters.

3.5.5.3. Transform/route messages (message broker)

The message broker is the key component that allows you to move away from the point-to-point
architecture. Implementing the message broker is in many products closely tied to the
implementation of the process automation software. Some vendors are currently consolidating their
product ranges to combine the message broker and process automation software as one single
product. Implementation is usually a combination of visual configuration using drag-and-drop tools
and programming in Java. Message broker functionality can only be tested once the underlying
messaging layer has been implemented successfully.

3.5.5.4. Implement process flows and workflow

Processes are short-lived and automated, whereas workflow is the description for longer-lasting
transactions (hours, days or sometimes even weeks), typically requiring human intervention such as
approvals. As with the message broker, implementing and configuring the process automation
software involves a combination of drag-and-drop techniques and some programming. Commonly,
process flows invoke routing and transformation functionality which has been built in the message
broker layer, and successfully testing processes can only be done once the underlying message
broker is in place.

3.5.5.5. Implement business partner integration

Consider standards, your own as well as those of your business partners. Are you going for an open
or a closed business partner environment? Make it simple for your business partners to integrate
(e.g. built-in TIBCO adapters in Ariba) with your environment.

3.5.5.6. Implement portal

During portal implementation it is important to consider the integration that may be required with
other web-based services (e.g. credit card checks). Particular attention should go to the
personalisation element, e.g. inclusion of news feeds, customisation of screen elements by the user.

28
 Understanding EAI

3.5.5.7. Implement system management and monitoring components

Systems management and monitoring components could be implemented independently of the
other components. The software provided by vendors in this space varies greatly in quality and
sophistication. Some provide fully-fledged systems management software suites, whereas others
provide a basic monitoring tool which can report to other packages (e.g. HP OpenView, Tivoli, etc.)
on the performance of the middleware components. Consider whether you want to have the facility
for automated failover – processes and applications which fail can be automatically restarted by the
monitoring software.

3.5.6. Test & release

Initial testing of the middleware solution is usually done with dummy applications, as the final
integration testing can only take place once all applications have been deployed. The final test for
the integration solution itself therefore tends to be at the end of the “funnel”. The approach
typically is to perform a System test for each system individually and then perform an End-to-End
(or Integration) test involving all the systems and the middleware. It is important to subject the
middleware to all the other tests in the overall integrated system – Performance test, Stress test,
Security test, User Acceptance test and Regression test.

3.5.7. Operations & monitoring

A key task that needs to be carried out in operating a middleware solution is the ongoing
monitoring of transactions. Depending on the thoroughness of the testing that was conducted, fixes
to transactions will need to be applied and re-submitted.

29
Understanding EAI

4. Vendor Overview
This section provides a brief overview of the key vendors operating in the integration broker space,
and their product offerings.

4.1. Market overview

The range of vendors and products is bewildering. Recent reports have identified at least 23 vendors
in the EAI space. Strong vendors continue to grow and extend their products and strategies and,
unlike two years ago, most leading vendors offer fairly similar functionality. However, the way in
which that functionality is exposed to the user continues to differ according to the vendor’s vision of
the most effective way to present the specific functional capabilities.

Direct comparison between vendor products is difficult. Different products are designed for different
purposes and their relative strengths and weaknesses can be hard to assess – it is often possible to
achieve the same end result by using different approaches. However, the leading vendors have one
thing in common in that they all offer comprehensive suites of technically strong products in all of
the key EAI areas (e.g. messaging, integration broker, business process automation).

4.2. Key vendors

In Deloitte we have alliances with all of the leading vendors. We have established very strong
partnerships with three vendors in particular – IBM, BEA and Microsoft, but we also have alliances
with TIBCO, webMethods, SeeBeyond and Vitria, the other “Leader” vendors. A more detailed
overview of the products offered by these vendors is provided below.

4.2.1. IBM
IBM has been the biggest player in EAI market for several years. Initial success was based on its
traditional corporate strengths, and in particular the widespread deployment of MQSeries in
enterprises using applications running on S/390 (mainframes). IBM is ranked as a leader in the
application integration market place. IBM provides several integration products that can be used to
suite an individual company’s requirements. The main components are:

• IBM WebSphere Application Server is a high-performance, scalable transaction engine, which has
evolved over the years into a Web services-enabled, J2EE application server and development
environment. The Open Services Infrastructure allows companies to deploy a core operating
environment that works as a reliable foundation capable of handling high volume secure
transactions and Web services.

• IBM WebSphere MQ is an asynchronous message-oriented middleware technology that can be

used to reliably exchange information across different platforms. Comprehensive security options
ensure that data is delivered free from errors and safe from unauthorized access. Java support
means that MQ can also be used as a Java Messaging Service (JMS) provider.

30
 Understanding EAI

• IBM WebSphere Business Integration Server is a bundle of three integration packages that can be
used to connect applications and manage business processes. These packages are particularly
important to integration practitioners, and are described in more detail below.

IBM market WebSphere Business Integration in the following way:

“To accelerate the transformation into an on-demand business, IBM WebSphere Business
Integration product family delivers five key integration capabilities:

• Model

• Integrate

• Connect

• Monitor

• Manage

These capabilities are all supported by a Common Framework, which consists of tooling,
business objects, and adapter framework, a services oriented architecture, and a browser-
based GUI. Depending on your business integration requirements, you can deploy the
family of capabilities, or you can pick and choose the mix of capabilities for your business
needs. This flexible group of business integration capabilities can transform your company
into an on demand e-business that can grow without the need to constantly change the
infrastructure.”

The following diagram shows the different functionality provided by some of IBM’s integration
products.

31
Understanding EAI

The three components of the WBI are:

• IBM WebSphere InterChange Server is a process automation application that allows companies to
manage multiple discrete business applications as one. InterChange Server is shipped with pre-
built “collaborations” which provide standard business processes like Customer Synchronisation
and Purchase Order. Collaborations operate on generic business objects (GBO’s) and the end-
points of the processes are configured to interface with external applications via application
specific business objects (ASBO’s). The transformation between message formats and routing of
messages is therefore provided as well as the higher level business process functionality.

• IBM WebSphere Business Integration Message Broker (formerly WebSphere MQ Integrator

Broker) transforms and enriches in-flight information to provide a level of intermediation
between applications that use different message structures and formats. In addition to
transformation functionality, the broker integrates with databases to perform message logging,
data merge, and database update functions. It also simplifies the integration of existing
applications with web services, by transforming and routing SOAP messages, as well as logging
of Web Services transactions.

• IBM WebSphere MQ Workflow (formerly MQSeries Workflow) supports long-running business

process workflows as they interact with systems and people. The focus of the product is the
management of processes requiring a high proportion of human interactions, and it allows you
to bring systems and people into a managed process integration environment.

IBM also provides a complete toolset, compatible with the Eclipse framework. Eclipse is an open
source development environment, created by IBM, and now managed by a not-for-profit
corporation. The Eclipse platform is highly customisable platform, and the majority of IBM’s tools are
now provided as plug-ins to Eclipse, WebSphere Application Developer (the main Java development
tool offered by IBM) being the first.

There are tools provided with each of the integration packages mentioned above, but one is
provided as a standalone product and is worth mentioning in it’s own right. WebSphere Business
Integration Modeller allows you to design, test, and communicate complex business processes. The
tool allows you to import collaborations from the WebSphere Business Integration Server as process
models and simulates the operational efficiency of processes and analyzes potential business results.

4.2.2. BEA
BEA Systems Inc. is one of the world’s leading application infrastructure companies, providing
enterprise software to over 15000 customers – including the majority of the Fortune Global 500.

BEA’s main differentiator is the ability for customers to go beyond simply standardising horizontally
on platforms that address similar requirements, such as application servers, portal software,
integration platforms, and so on. The BEA product suite allows both horizontal and vertical
standardisation – over the entire enterprise technology stack. This allows for unified development,
training, security and deployment across all of these areas.

BEA’s goal is to provide the world’s leading application software foundation for building, integrating,
extending, deploying and managing enterprise applications. Their offering in this rather broad
space, BEA WebLogic Enterprise Platform, includes the following products: BEA WebLogic Server,
WebLogic Integration, WebLogic Portal, Liquid data for WebLogic, and WebLogic Workshop.
32
 Understanding EAI

BEA bases its offering in the application platform market around three key tenets:

Unified – A single, unified architecture based on a common programming model and code-base
increases productivity, reduces costs and accelerates time to value for enterprise IT projects.

Simplified – Simplified application development, deployment, integration and management for all
enterprise applications and business processes increases IT productivity and shortens project cycles.

Extensible – Enables extensible IT infrastructure and ensures interoperability, flexibility and choice,
including incremental adoption of all or parts of the platform, integration with point solutions or
existing infrastructure standards, and extensibility through ISV applications and solutions.

These principles apply across the full spectrum of the BEA product suite, as depicted below.

• BEA WebLogic Server – the world’s leading, industrial strength application server underlying the
BEA WebLogic Platform enables IT organizations to deliver enterprise class applications in less
time with reduced costs while simplifying infrastructure complexity. WebLogic Server also
includes WebLogic JRockit – the first JVM specifically optimised for the Intel platform enabling
Java applications to run with increased reliability and performance on lower cost, standard-based
platforms.

• BEA WebLogic Integration – delivers a robust, unified application integration framework that
enables IT operations to fit business goals by delivering rapid, open integration in half the time,
at half the cost of any other approach. WLI is a drag and drop, tool-box development
environment that allows for faster development time to value. J2EE development can be
employed if and when necessary in business operations that complement the tool-box
development.

Business process management – Boosts efficiency with an environment for defining, executing,
and managing business processes that are optimized from end to end.

Enterprise resource access – Improves organizational responsiveness by opening up siloed and

proprietary data; and by supplying secure, rapid and consistent access to information,
applications, partners and users.

Dynamic integration services – Enhances business adaptability by dramatically reducing the

time needed by IT to reliably and securely meet changing business requirements.

33
Understanding EAI

• BEA WebLogic Portal delivers the industry’s first enterprise portal infrastructure for streamlined
portal development and assembly. BEA WebLogic Portal is the only enterprise portal platform
that also simplifies the production and management of custom fit portals.

• BEA WebLogic Workshop is a unified, simplified, and extensible development environment that
enables all developers to build standards-based, enterprise-class applications on the BEA
WebLogic Enterprise Platform—thus empowering development organizations to deliver
unprecedented IT productivity and accelerate time-to-value.

• Liquid Data for WebLogic provides the most cost-effective way to rapidly aggregate critical
business information in real time from disparate sources, increasing visibility and accelerating
business results.

In addition to the WebLogic product suite, BEA has a wealth of utilities, tools and add-on products
that complement the suite and have all of the advantages of the suite in terms of interoperability
and standardisation. A few of the more relevant products are as follows:

• BEA Tuxedo – a mature, industry leading distributed transaction processing platform.

• BEA WebLogic Adapters – a comprehensive list of technology, utility and application adapters,
built to the JCA standard. These include SAP, Oracle, JDE, Siebel and PeopleSoft. There is also a
generous portfolio of IWay software adapters for WebLogic.

• BEA MessageQ –fast, reliable message queuing software, allowing applications to communicate
across heterogeneous platforms with purported guaranteed message delivery.

4.2.3. Microsoft
Microsoft’s first foray into the true middleware space was with BizTalk Server 2000. Being a first
version it was considered functionally lacking in a number of ways as compared to the experienced
players such as IBM, and there were also stability concerns expressed. The follow up release BizTalk
Server 2002 remedied the majority of the performance and stability concerns, but there was still a
functional void in terms of true business process management. The new release, however, BizTalk
Server 2004 however (beta released 2003) has thus far seemed to be a big leap forward compared
to its predecessors. So much so that Microsoft is viewed by analysts as a visionary/leading
Application Integration vendor.

BizTalk Server and Visual Studio .NET have been tightly integrated to provide Microsoft’s Enterprise
Integration (EI), Business Process Management (BPM), and Trading Partner Interaction (TPI)
development and run-time platform. They employ XML and Web Services technologies to
implement integration and business process automation solutions.

Visual Studio .NET provides an extensive range of development tools for both application integration
as well as workflow development. The BizTalk Server architecture, by contrast, functions as the
process execution and activity monitoring engine for the solutions developed in the Visual Studio.

In BizTalk Server 2004, the Orchestration Designer module found in previous versions is now fully
integrated with Visual Studio .NET. The Orchestration Designer module provides a new integration
or process assembly workspace that graphically represents the design logic that is bound to
implementation objects like messaging pipelines, ports, and schemas.

34
 Understanding EAI

The following list shows the key BizTalk Server development components found in Visual Studio
.NET:

• An XML editing tool to define document semantics.

• An XSLT-based mapping tool and interpreter.

• A publish and subscribe messaging infrastructure that provides the logical processing facilities to
validate, authenticate, encrypt, transform, and route document exchanges. The infrastructure
also supports correlation and persistence of messages.

• A graphical drag-and-drop development tool for rapid development of complex business

processes.

Components found in the BizTalk Server environment:

• A process execution engine that uses the XML-based XLANG and allows for import and export of
Business Process Execution Language (BPEL) documents.

• A Business Rules Composer engine that allows for modular reuse of components to quickly and
efficiently create complex business rule sets.

• Health and Activity (HAT) management tools for monitoring the status of active messages and
process activities, in a real-time fashion, as well as logging of historical performance data.

• A Business Activity Management (BAM) module for real-time reporting on performance data for
business processes. These reports can be built as an output from, or a component within, a
distinct business process allowing for flexible granularity of reporting.

One of the key features of the BizTalk Server 2004 is the adoption of XML Schema definitions for
defining all internal BizTalk Server documents. An XML Schema is a set of specifications for defining
the structure, content, and semantics of XML documents.

BizTalk Server uses the XML Schema to create an internal structural and semantic model (a
document definition) of the proprietary information formats produced by the applications between
which it will manage communications. BizTalk Server uses a shared repository to store and publish
these definitions. A mapping tool maps the conversion of one application’s information format
(based on its internal BizTalk Server document definition) to any other format (also based on an
internal document definition) to create a transformation map. The transformation maps are also
stored and published in a repository. These maps can be reused for any number of data exchanges
without additional configuration. A data exchange takes place when BizTalk Server receives
information from one application that it identifies as input for another and executes the format
conversion through its mapping facility. BizTalk Server then delivers the information to the receiving
application or process step in the format required.

35
Understanding EAI

The technologies underlying this transformation engine are also based on XML standards – SOAP,
XSLT, and XPATH. The implementation of these transformations requires no procedural
programming. The BizTalk Server development environment abstracts the complexities of XSLT,
XPATH and XML Schema by use of its graphical drag-and-drop interface. This simplifies the
integration development process from a specialized procedural programming function to a non-
specialised assembly function.

While there are concerns around the ability for Microsoft products to work in non-Microsoft
environments, the counter argument proposed by Microsoft is that the seamlessness with which
they do run on, and interact with other components within, Microsoft environments more than
makes up for it for its breadth of compatibility.

4.2.4. Others

TIBCO – started as a middleware software company and now has positioned itself as an e-business
integration software and services vendor. In e-business integration, the core offerings are
ActiveEnterprise, ActivePortal and ActiveExchange. TIBCO ActiveEnterprise is a suite of software
products for application integration within an enterprise with the TIB/Rendezvous messaging system
the foundation. Other applications in the suite offer message brokering, process management,
workflow management, etc. The ActivePortal and ActiveExchange suites in TIBCO's e-business
integration offerings provide portal (B2C) and B2B commerce capabilities respectively.

webMethods – started in 1996 as a B2B software vendor. webMethods offers a comprehensive

e-business integration solution and has more than 750 customers worldwide. As part of its
comprehensive integration solution, webMethods enables companies to integrate both within and
across enterprises to application systems, databases and resources in heterogeneous platforms.

SeeBeyond – a global e-business integration solutions provider. With more than 1,400 customers
and 1,600 sites worldwide, SeeBeyond has a successful track record helping organisations to
connect every type of data and application software to optimise their businesses. SeeBeyond's
product, the ICANN suite, is a comprehensive solution available for uniting systems within and
among companies. At the highest level, it provides JAVA-based graphical interfaces for centralized
management, monitoring and configuration of the distributed design-time and run-time integration
components from anywhere on the network. SeeBeyond can be configured as a hub & spoke or as
distributed bus architecture.

Vitria – a leading integration server provider. Vitria BusinessWare's Business Process Management
component models and automates simple to complex business processes within and between
companies. BusinessWare's primary component for process management, called Automator,
provides the process modelling environment and the process execution engine for handling high
volumes of business transactions. Automator enables a company to graphically define mission-
critical business processes through the creation of visual models. The process modelling tool can also
handle processes requiring human interaction.
36
 Understanding EAI

5. Glossary
A2A Application-to-application, the integration of applications in an enterprise.

Adapter A software component to connect an application to middleware.

API Application programming interface.

application server A mechanism to deploy applications to a web-based platform.

B2B Business-to-business.

B2Bi Business-to-business integration, the integration of applications and systems

with business partners.

BPEL Business Process Execution Language, Web Services notation language for
defining business processes.

COM+ Component Object Model, a Microsoft standard for distributed software

objects.

CORBA Common Object Request Broker Architecture, a standard developed by the

OMG for distributed software objects.

CRM Customer Relationship Management.

DCOM Distributed COM, a Microsoft standard for communication between objects

on Windows and non-Windows platforms.

EAI Enterprise Application Integration, the integration of applications within an

enterprise.

EJB Enterprise Java Beans.

GUI Graphical user interface.

Integration broker A powerful mechanism for integration between multiple applications within
and across enterprises.

J2EE Java 2 Enterprise Edition.

Java An object-oriented programming language which allows developers to

develop platform-independent software (i.e. which can run on different
platforms without requiring modification).

Many-to-many A model of linking many applications together using middleware.

37
Understanding EAI

Message broker Software that transforms and routes messages.

Message queue A low-level form of middleware.

Middleware Software “glue”.

MOM Message-oriented middleware.

OMG Object Management Group, an independent software standards

organisation.

Point-to-point Direct connection between two applications.

Portal One-stop web-based user interfaces to access multiple information sources.

Publish/subscribe A middleware communication model whereby messages are published to a

central engine which distributes to subscribing applications.

Real-Time A Deloitte solution for the integration of business processes across different
systems.

Request/response A middleware communication model whereby messages are sent out with a
request for a response.

RPC Remote procedure call.

SCM Supply Chain Management.

SOAP Simple Object Access Protocol, XML enveloping standard for Web Services.

TP monitor Transaction-processing monitor, a form of middleware.

UDDI Universal Description, Discovery and Integration, Web Services directory

service.

UML Unified Modelling Language.

WSDL Web Services Description Language, notation language for describing Web-
enabled Services.

WS-Security Web Services security standard.

XML eXtensible Mark-up Language.

XRM eXtended Relationship Management.

38
 Understanding EAI

Notes

39
Understanding EAI

Notes

40
For further information, visit our website at www.deloitte.co.uk
In this publication references to Deloitte are references to Deloitte MCS Limited.
This publication contains general information only and is not intended to be
comprehensive nor to provide specific accounting, business, financial, investment,
legal, tax or other professional advice or services. This publication is not a substitute
for such professional advice or services, and it should not be acted on or relied upon
or used as a basis for any decision or action that may affect you or your business.
Before making any decision or taking any action that may affect you or your
business, you should consult a qualified professional advisor.
Whilst every effort has been made to ensure the accuracy of the information
contained in this publication, this cannot be guaranteed and neither Deloitte MCS
Limited nor any related entity shall have any liability to any person or entity who
relies on the information contained in this publication. Any such reliance is solely at
the user’s risk.
© Deloitte MCS Limited 2004. All rights reserved.
Deloitte Touche Tohmatsu is a Swiss Verein, and each of its national practices is a
separate and independent legal entity.
Registered in England and Wales number 3311052. Registered office: Hill House,
1 Little New Street, London EC4A 3TR, United Kingdom.
Member of
Designed and produced by The Creative Studio at Deloitte, London. Deloitte Touche Tohmatsu