Changes: The changes I made in this deliverable
as a result of feedback I received from the professor
consisted of better documenting
this paper by only citing the author and date of the works to reference
citations within the
paper. In the previous deliverable, I cited the author, date, and page number
in all
reference citations. Look
at the following example from the previous paper: (Kridva, 1999, p. 224).
Table of Content
Topic
1
Unique
Title 1
Statement
of the Problem 1
Abstract 2
Final
Paper 2
Reference
List 10
Title: Enterprise Application
Integration: Managing Information and Processes across the
Enterprise
Statement
of the Problem:
The implementation of
enterprise application integration (EAI) has allowed companies to realize
increasingly complex business processes. Some of the popular include web-based
commerce, business-to-business commerce, customer self service, expanding or
integrating enterprise resource planning (ERP) systems, mergers or
acquisitions, compliance with major regulatory changes, business intelligence
initiatives, supply chain integration and mobile computing. Yet the costs of
implementing EAI can also be substantial, both from a financial standpoint and
in terms of the organizational disruptions that are often involved. According
to Paul Korzeniowski, “While EAI tools have many attractive features, there are
implementation challenges. For instance, moving from a fragmented to a
centralized buying system is difficult” (Korzeniowski, 2001). Cheryl Kridva
wrote in the EAI Journal : “For sites integrating custom-developed
applications, the benefits of implementing EAI are impressive. But, the
implementation process can be very time-consuming and costly up front ”
(Kridva, 1999).
Abstract:
Enterprise application
integration has always focused on a company’s IT department integrating new
software modules or applications with its existing systems. Before the advent
of EAI, companies handled such integration with a great deal of difficulty.
Often, systems were merged by bringing in teams of expensive consultants, with
little guarantee that they would deliver satisfactorily. Several years after
undertaking these projects, it was not uncommon for companies to throw up their
collective “corporate hands”, write off millions of dollars spent, and walk
away from the project. Enterprise computing has progressed enormously in just
the last few years. Especially with the advent of the Web, not only it is
possible for diverse organizations to automate and integrate their businesses
and computer operations, it is imperative that they do so. Suddenly, as more
and more corporations become Web-enabled and find themselves relying on a
myriad of applications, the ability to evolve and integrate existing
applications becomes significant. Furthermore, it is not a simple matter for an
enterprise to discard its existing applications, or even overhaul its
established business processes, to affect a change in its business model. These
kinds of changes are financially expensive to undertake and daunting in terms
of human resources. Many enterprises cannot afford to make such changes or
discard existing systems. Thus, it is critical for enterprises to be able to
leverage their investments in their existing enterprise infrastructure and
applications. In these situations, enterprise application integration assumes a
great importance. Enterprise application integration (EAI) enables an
enterprise to integrate its existing applications and systems and to add new
technologies and applications to the mix. EAI also helps an enterprise to model
and automate its business processes. However, EAI implementation does come with
a great deal of difficulties and challenges. The purpose of this paper is to
present an in depth study of EAI including the challenges of implementing it,
the solutions to those challenges, and the benefits of a successful
implementation.
Introduction:
Enterprise application
integration (EAI) entails integrating applications and enterprise data sources
so that they can easily share business processes and data. Integrating the
applications and data sources must be accomplished without requiring
significant changes to these applications and the data. EAI defines semantics
for application and data integration. That is, EAI defines a standard methodology
or approach for applications and data sources to communicate. The pieces in the integration
puzzle─such as an underlying database management system (DBMS)─can
change, but because of this common methodology, the replacement piece can be
plugged in and the communication can continue uninterrupted (Rao, 1999).
By focusing on integrating business processes and data, EAI
encompasses both the distribution of such processes and data and the concept of
reusing modules. Most importantly, EAI approaches this integration as a process
separate from the different applications. That is, someone can integrate
various applications with each other, and with underlying data resources,
without having to understand or know the details of applications themselves.
EAI is best suited for environments that are heterogeneous rather homogeneous.
Heterogeneous environments are those whose applications and data do not reside
within the same environment. A company may have reached this point because of
acquisitions or mergers with other companies, where they have been compelled to
absorb some other company’s systems into their own environment. They may have
been trying to increase their capacity─or avoiding replacing existing
systems─by patching
their own internally developed systems or other purchased systems onto their
core systems. Or, they may be supporting large numbers of users on distributed
systems with a multitude of platforms.
Why companies are
implementing EAI?
With the advent of the Web,
enterprise application integration has taken on a larger significance beyond
that of merging application systems solely within an enterprise. Enterprise
servers now handle and maintain huge amounts of data and business logic.
Furthermore, because the Web enables easy information and service access, it
has become a principal means of communication. An enterprise must be able to
make its business data accessible to other, from internal employees to external
partners, suppliers, and buyers. Employees require access to the enterprise data
to keep abreast of company policies and developments, and to carry on the
internal business of the company (Stokes, 1999). For example, employees file their expense reports through a Web
interface. Business partners may be communicating important technological
information. Buyers and suppliers need access to enterprise data to facilitate
the parts ordering and delivery process.
Providing services through the Web is rapidly becoming the
emerging trend. Enterprises are recognizing that it is important for them to
provide more of their services, such as customer support and product catalogs,
through the Web. Enterprises have come to see that having such services
available both in a traditional manner and over the Web enhances their
business. The technology scenario is evolving at a breath-taking pace, and EAI
is now increasingly being driven by Web-driven requirements and technologies.
As more and more businesses establish a presence on the Web, Web-driven EAI
becomes very essential. Enterprises need to integrate their existing
applications and enterprise systems to drive their business-to-consumer and
business-to-business interactions, plus their other Web services. In fact,
success in e-business is driven by an enterprise’s ability to integrate existing
applications and extend the reach of these applications to Web-based access
(Osborne, 2001).
Up to now, applications were classified as either front-office or
back-office applications. Front-office applications are considered to face the
customer or end user. Front-office applications include applications for
customer relationship management and marketing automation. Back-office
applications provide the information infrastructure for running the back-end
business processes of an enterprise. Applications provided by an enterprise
resource planning (ERP) system are good examples of back-office applications.
Traditional EAI focused on integrating the front and back office applications.
However, traditional EAI is becoming Web-driven EAI. Rather than being targeted
to the front end or the back end, most EAI applications are now integrated for
the front and back ends and Web enabled (Inmon, 1999).
The EAI Architecture (How is
EAI segmented?)
EAI is about building an
infrastructure that allows for business agility. And for an infrastructure we
need some king conceptual view, an architecture. Giving the all-encompassing
character of EAI, it is to give one that really addresses all aspects.
Especially now that EAI is extending its reach to include the e-business
paradigm, lots of technologies will have their place in an EAI exercise.
Therefore, we will limit ourselves here to an architecture description for
messaging oriented integration approaches (Allen, 2001).
The business process layer is the one where the
business modeling is done, where the flow of business processes and associated
business rules are defined. Today, reality is that this layer still is largely
undefined. On the other hand, there are a number of vendors that entered the
application integration space directly at this level, even without underlying
messaging based infrastructure. Their focus typically was on the integration of
packaged applications. Gradually, they are extending their space to lower
layers, seeking partnerships with some of the leading vendors of transformation
engines and hooking up their product to “standard” messaging environments such as MQSeries. In EAI architecture, the business layer
implements the “translation” of business flows and processes. The basic object that
it can manipulate is the business component. The business layer defines the
rules for the chaining and the interaction of the components. The normal
evolution will be that workflow-style solutions will play a major role here.
But workflow alone will not be sufficient. A complete solution will have to
incorporate process modeling facilities, simulation capabilities and support
for complex logic (Gold-Bernstein, 2000).
The component layer is the highest stack level that is
under control of IT. This layer provides all necessary building blocks that the
business people can manipulate in above layer. In any EAI messaging based EAI
approach, business components are logical objects that represent the execution
of one or more business functions. Being logical objects, they are instantiated
by one or more (physical) executables that perform the programming logic. These
instances receive requests for processing and send replies via well defined but
not necessarily uniform (messaging) interfaces (Linthicum, 2000).
The message services
layer provides generic services that can assist the functioning of above
layers. This includes services such as: reformatting of messages, routing, load
balancing, alternate path switching, message warehouse. This layer together with
the transport services layer is often referred to as a “message broker”.
The transport services layer is the world of the “basic”
middleware products. Message oriented middleware is one of the key players
there, but this layer will also incorporate other middleware products such as
object request brokers and transaction managers. This layer also has to provide
several of other supporting services such as audit, logging and security. From
a development point of view, this also includes aspects of API’s, message
formats and templates.
Challenges in implementing
EAI
First, we have the problem
of incompatible protocols. If the applications were built independently, it is
highly unlikely that they will use the same technology for interprocess communication.
An application enabled for DCOM cannot speak directly to another application
designed for HTTP. Some older applications may not be equipped for direct
interprocess communication at all – they may expect to find a data file on a
local disk. We also encounter the problem of incompatible data formats. This
may be a question of mismatched low-level data type representation between
dissimilar computers, or a higher-level issue of mismatched data structures.
Mismatched data types may arise because one computer uses a different binary
representation for some data type – numeric types are particularly troublesome
– from another computer. Structures that are logically identical will be
physically different at a low level of representation. Dissimilar data
structures involve two programming teams choosing different data structures to
represent the same body of data. For example, one program might use a
hierarchical structure well suited to programmatic use. Another might serialize
its data in fixed length fields, a system oriented to saving data to disk or
performing bulk data exchanges through files. Whatever the case, application
integration usually needs some facility for translating between data formats.
This facility must correctly map one item of data into another and back again
if two programs are to communicate.
Application integration is not complete when two programs are
made to communicate with one another. We have to deal with data flow and error
handling. Implementing a non-trivial process usually requires the connection of
multiple applications in an appropriate sequence. The architect of such a
system must also consider how the process can fail and provide for alternative
paths through the system (Garimella, 2001). Consider a simple retail purchase
at a web site:
1.
The site searches and displays a catalog
2.
The user selects purchase
3.
The site accesses an inventory control system to confirm availability and mark
the product for
selection
4.
An order price is calculated (this may involve shipping costs, sales taxes, and
promotional
discounts)
5.
An e-mail acknowledgement is formatted and sent
6.
A shipping invoice is generated so that warehouse fulfillment workers can
complete and check the
order
If you have the luxury of
starting this business from scratch and have to write custom systems to support
it you have little need for extra application integration. If, on the other hand,
you are enabling web solutions for an existing business, you will probably have
to coordinate the activities of several programs. Also, the path I
have just described is the path the process will take if everything works
correctly. If the site is to be robust, though, the architect will have to
consider various contingencies, such as:
1.
What if the product is back ordered, or perhaps discontinued?
2.
Is the product compatible with all forms of shipping?
3
What happens if the acknowledgement is bounced at the receiving domain?
Different applications may have to be invoked in
different sequences to account for all the contingencies that are possible in
the system. In other words, we need an integrated system that is flexible, and
has built-in error-handling.
Even when all the individual
applications have been stitched together to implement the desired workflow,
system administrators must be able to monitor the process during run-time, to
manually verify the status of any particular item of work and intervene if
necessary. They should also be able to adjust the parameters governing each
step in the workflow (Bushan, 2002). Considerations include:
1.
Should some steps be processed in batches, and if so, at what intervals?
2
How long should one process wait for a reply from another before raising an
error?
In other words, it is not enough to build an
integrated system. We must be able to monitor and control it, as well.
Enterprise Application Integration Approaches
Given the complex nature of
EAI implementation and development, it is important that organizations use
standardized integration approaches to achieving successful implementation.
Following are five approaches that can be used to integrate existing enterprise
information systems with enterprise applications.
1. Two-tier client-server approach: This
approach is based on the two tier client-server model, and
it is typical of applications that are not based on the Web.
It was a widely used approach to the
advent of Web-based applications. With this approach, an
EIS provides an adapter that defines an
API for accessing the data and functions of the EIS. A
typical client application accesses data and
functions exposed by an EIS through this adapter
interface. The client uses the programmatic API
exposed by the adapter to connect to and access the EIS.
The adapter implements the support for
communication with the EIS and provides access to EIS data
and functions (Caccia, 2002).
2. Synchronous adapters approach: Adapters designed for
this approach provide a synchronous
request-reply communication model for use between an application and an
EIS. A synchronous
adapter can be used to define an API that includes a remote function
callable by an application.
When an application wants to interact, it invokes this remote function
on the EIS. An interaction
such as this is considered synchronous because the execution of the
calling application waits
synchronously during the time the function executes on the EIS.
3. Asynchronous
adapters approach: With asynchronous communication, an application calls
the
the remote function to interact with the EIS. The
application makes the remote call, then
immediately returns and continues its own processing.
The remote function is sent to the EIS. The
EIS handles the function and returns some reply
information to the application as a separate
invocation. The application never suspends its own
processing while the remote function executes.
4. Message
broker approach: When applications and EISs use a message broker for
integration and
message delivery, the application and the EIS can act
as both message producers and consumers. A
message broker may provide additional services such
as: message routing, transaction
management, reliable message delivery, message
priority and ordering, and message
transformation (Courtey, 2002).
5. Application
server-based approach: An application server is a natural point for
application
integration, because it provides a platform for
development, deployment, and management of
Web-based enterprise applications. Application servers
are the platform of choice for application
that are developed using a multitier architecture.
Typically, an application server provides a set of
runtime services to its deployed components. These
runtime services are hidden from the
application components through a simplified
programming model (Seeley, 2002).
The Future Of Enterprise
Application Integration
Given the nascent state of
Web services, it’s reasonable to question the wisdom of derailing or
redirecting existing EAI projects in favor of a shift to web services. The
optimism reflects the excitement surrounding Web services, but the enthusiasm
should be tempered with a dose of reality grounded in sound business sense. By
now, most companies have elaborate infrastructures in place that tie their
applications together. If an EAI substructure is a rickety mess that falls to
pieces at slightest perturbation, replacing it makes good business sense. But
in most shops, existing integration technology is working (Ulrich, 2000).
Web services will eventually bring radical change to the EAI
landscape, but the revolution hasn’t happened yet. The old approach to EAI,
with all its limitations and costs, is still valid, and companies seem to have
integration down to a routine. Rather than pull the plug on integration
projects already in pipeline, CTOs should start steering their companies toward
Web services. IT leaders should query application vendors and consultants on
their Web services strategies and use their answers to determine their place in
integration plans. New projects should include preparation for Web services,
starting the identification of the services and data each application should
expose. If Web services will eventually wipe out traditional EAI software and
tools, it won’t happen quickly. For at least the next couple of years,
traditional integration technologies will evolve in parallel with Web services.
In the short term, CTOs will be able to blend the old and new approaches to
achieve cost benefits and to reduce project complexity. Looking farther ahead,
advanced tools will emerge to help IT departments transform cumbersome EAI
infrastructures into simpler, more streamlined collections of Web services
(Sifter, 2001).
Conclusion
There is a definite trend
among enterprises toward integrating their exiting enterprise applications and
information systems with Web-based applications and services. More and more,
enterprise must establish a Web presence and make their business services
available to Web clients. However, at the same time, an enterprise can not
afford to discard its existing systems and applications, but must leverage
these existing assets to be successful. This paper highlighted some of the
tasks and challenges that face enterprise’s compelled to integrate their
information systems and applications and then expose these applications and
systems to the Web. This Web-driven application integration is a process that
closes the gap between existing
applications and Web-based applications and services. Ultimately, Web service
and wireless clients, in a B2C or B2B context, will be able to initiate business
processes that act on critical information maintained in Enterprise Information
Systems (EIS).
Reference List
Courtney, E. P. (2002). Plain sailing to enterprise integration. EAI Journal, 4, 111 – 119.
Kridva, C. (1999). Enterprise application integration. EAI Journal, 1, 223 – 239.
Linthicum, D. (2000). Making application integration scale. EAI Journal, 2, 86 – 93.
Osborne, C. (2001). Integration is everything. EAI Journal, 3, 77 – 81.
Rao, N. (1999). Extreme application integration. EAI Journal, 1, 150 – 155.
Seeley, R. (2002). ECM: Transforming EAI. EAI Journal, 4, 22 – 29.
Sifter, C. (2001). Integration project management 101. EAI Journal, 3, 91 – 99.
Stokes, N. (1999). EAI and beyond: A multi-level flow model. EAI Journal, 1, 60 – 69
Ulrich, M. W. (2000). Project team integration: Halting a pattern of failure. EAI Journal, 2, 11 – 13.