Low-level middleware isn't enough to cement your e-business systems
to the rest of your organisation's IT. Philip Hunter offers a user
guide to enterprise application integration
Since the very dawn of distributed computing in the 1970s,
companies have been integrating the different applications and
systems they use. But with the rush to e-commerce and
e-marketplaces, a new tier of integration is needed between Web
servers and a whole range of processes such as supply chain
management, CRM (Customer Relationship Management), and content
management, as well as more traditional ERP (Enterprise Resource
Planning) systems.
Older approaches to integration required significant coding
every time there was a change to any of the systems involved. This
may have been acceptable in the days of static batch processes that
only rarely needed modification, but is totally useless in the
e-word where overall business processes require a number of major
systems to be integrated.
The challenges are considerable, from consistency of customer
records at the database level right down to basic protocol and
formatting issues. It is only recently that EAI (Enterprise
Application Integration) tools have become available that tackle
all the issues including high-level data consistency. However,
considerable human intervention is still needed. For this reason,
the quality of an EAI supplier's consultancy is at least as
important as the technology it is selling, according to Robert
Wilson, vice-president of products for online marketplace
eCredible, which outsourced its data centre to IBM, and its
enterprise application integration to WebMethods. "If you're
outsourcing your whole EAI worldwide, you want a supplier with
high-quality consultants globally," says Wilson.
Although everyone agrees that application integration is more
important than ever, much confusion arises from the variety of
acronyms and terms used to describe it. EAI has emerged over the
last two years as a more solid entity from the mists of middleware,
which could be used to describe almost any form of software
involved in linking systems, platforms or processes. According to
James Robertson, European director of marketing and business
development at EAI supplier Crossroads, EAI should provide a
consistent hub interconnecting all the systems involved in an
overall process, rather than just tools that facilitate various
aspects of the integration.
Such distinctions may not be particularly helpful to users,
though. Far better, according to Russell Francis, CTO of e-business
systems integrator Infogain, is to consider the functions you need,
and assess various contending solutions, whatever they are called,
according to how well they perform with what is most important to
you. There are five principal functions:
- Messaging. This refers to the transmission of messages between
different applications or software components. IBM's MQ Series is
the best-known messaging product around
- Transactions. This refers to the ability to transmit many
messages reliably, robustly and repeatably
- Workflow. This refers to the ability to control the whole
sequence of interactions between applications or
processes
- Adapters. These enable applications to communicate, so that
messages can flow between them
- Monitoring. This involves keeping abreast of all the message
flows and interacting processes so they can be tuned to improve
performance and avoid congestion
As Francis points out, a set of EAI tools may excel in one or
two of these sectors, but be no more than adequate in the rest.
"Typically where a product is best of breed will be determined by
what it was renowned for before its supplier decided to enter the
EAI market,"he says. For example, eLink is promoted as an overall
EAI tool by BEA Systems, but is strongest at transactions because
the product emerged from BEA's acquisition of Tuxedo, a specialist
in transaction monitoring.
This begs the question of whether it is better to seek an EAI
solution from a single supplier, even though it may be weak in some
areas, or adopt best-of-breed tools for each key area. The problem
with the latter strategy has been that while EAI tools may be good
at integrating applications, they are not so good at working with
other suppliers' EAI tools.
The realities of the enterprise IT scene favour the
best-of-breed approach simply because no single solution can cover
all eventualities. But if companies have to live with multiple EAI
suppliers, they can at least exploit the best features of each one.
Some EAI suppliers have now recognised this, and are making it
easier for their products to interoperate with those from other
suppliers. Tibco, for example, now has a number of customers using
IBM's MQ Series for messaging, and makes little attempt to lure
them away, instead helping to ensure that the integration operates
as smoothly as possible.
There are some interoperability standards that EAI tools should
adhere to, in particular Corba and J2EE. Although these standards
have not yet been widely adopted, they are likely to become more
important, and also serve as an indication that a supplier is
committed to interoperability. This is important in the emerging
world of e-marketplaces, which are creating greatly increased need
for application integration. "Instead of integrating tens of
applications, you'll have to start thinking of hundreds or maybe
thousands," says Francis.
But before companies start worrying about integrating with
others enterprises, they would be wise to put their own house in
order. It is best to perform a comprehensive consolidation of
applications, processes and data behind the firewall before opening
up your back-office systems to significant external access by, say,
fellow members of an e-business exchange.
In selecting the tools for such consolidation, product features
are not the only technical consideration. It is also worth looking
at the design philosophy of the tools and how well they fit with
your requirements.
For example, some suppliers favour a top-down approach in which
integration is defined by high-level processes. Others have adopted
a bottom-up strategy in which the plumbing comes first, providing
an integrated platform for building the higher-level processes.
The top-down approach is more elegant and pleasing conceptually,
but unless it generates the correct connections at lower levels, it
won't be workable. In practice, therefore, a bottom-up strategy may
provide a shorter route to fully integrated systems including the
higher-level business processes, at least until top-down tools are
more mature.
Whichever approach you take, the fundamental goal of EAI is the
same: to greatly reduce the ongoing cost of IT projects by cutting
down on the 70% that typically goes on integration. The only way of
achieving this is by commoditising the integration process, making
the functionality repeatable to minimise the amount of new code
that needs to be written every time a process is changed.
Case Study: Healthcare
User: eHospital
What's the business strategy?
eHospital aims to be the e-marketplace of choice for the European
healthcare market, enabling hospitals to improve the efficiency of
their procurement. eHospital isn't just providing a basic online
procurement service, but also integrating with hospitals' internal
materials management systems to streamline the process of ordering
healthcare products, particularly consumables. At the same time
eHospital is helping healthcare product suppliers improve their
level of service by integrating their stock control and
availability systems with the order management processes of the
hospitals.
How are systems being integrated?
eHospital recently announced a partnership with three key IT
suppliers: i2 Technologies for the marketplace and supply chain
management, Ariba for procurement systems, and IBM for hosting the
service and integrating the various components. The EAI part is
therefore provided by IBM's WebSphere infrastructure software,
chosen, according to eHospital's financial director Geoff Rayner,
because it was best placed of all the EAI solutions to tackle the
wide range of integration problems in the hospital market.
"Hospitals are, quite frankly, an IT nightmare," says Rayner.
"There are so many systems from so many suppliers, and lots of
small participants in the market."
Although Rayner believes IBM is far from having a polished
portfolio of EAI tools, the company is devoting substantial
resources to the field, and already has the industry's most robust
and widely support messaging protocol with MQ Series.
What lies in the future?
The company has noticed that the vast majority of items purchased
by hospitals are items such as bandages and standard medicines that
need replenishing constantly but not always at predictable times.
To simplify this process, eHospital is improving the front-end
materials management systems so that doctors, senior nurses and
other relevant healthcare professionals, can reorder goods via
pocket scanners as they walk in and out of the hospital wards,
rather than, as at present, having to visit a terminal that may be
some distance away. "Nurses and doctors shouldn't be spending their
time on procurement," says Rayner.
Case Study: Telecoms
User: Telenet
What's the business strategy?
Belgian telco Telenet is one of the new generation of carriers,
offering cable-based communication services and competing on price,
value-added services and flexibility. The role of IT systems is
crucial because it allows telcos to develop and make new services
available before competitors and thereby win mindshare in key
markets. The current catchphrase is service provisioning. All new
services involve interaction between multiple systems, so the key
to success lies in the quality of the integration.
How are systems being integrated?
Telenet recently completed its second round of system integration.
The company needed a quick fix to get off the ground a few years
ago by integrating key systems, such as its CRM application from
Clarify, billing software from Keenan, and a package to facilitate
the provisioning of new services. A systems integrator provided
what turned out to be a stop-gap solution. "It didn't do everything
for everyone, but was a good start," says Telenet's IT supplier
manager Werner de Rouck.
As other functions were added, such as support for number
portability within Belgium, further integration was required. It
became clear that the existing solution couldn't be extended
effectively to embrace the new systems and processes, because it
wouldn't allow changes to be made across the whole environment
quickly enough. "Whenever we want to sell a new product, multiple
systems are involved," says de Rouck.
"Time to market is crucial for us, so we needed a solution that
enables us to make changes across all the systems quickly."
Two options were identified, one being to migrate to a single
supplier for all critical applications so that the integration came
out of the box, and the other to go for multiple suppliers and
tying their applications together with EAI software. The latter
option was chosen because, as de Rouck points out, it is impossible
in practice to escape integration anyway, given that no single
supplier can supply everything. The company decided it might as
well tackle integration square on and establish a sound strategy
from the start, with a single interface to each subsystem.
The supplier chosen was Active Software (recently acquired by
WebMethods) for its ActiveWorks e-business integration software, in
preference to better-known contenders such as IBM. "WebMethods had
the most intelligent adapters," says de Rouck, "and good references
in the telecoms area."
What lies in the future?
Now that the EAI solution is in place, Telenet intends to exploit
it by stepping up the pace of development. Number portability will
lie at the heart of a range of services - for example, in unified
messaging, allowing customers to combine e-mail, voicemail and
fax.
Case Study: Manufacturing
User: Philips
What's the business strategy?
Consumer electronics giant Philips has a business group
manufacturing cathode ray tubes for TVs and monitors. The group is
under constant pressure to cut costs and improve quality. There are
various logistic problems, one of which is that because the
products are relatively large and expensive to distribute, a
strategy of distributed manufacturing is required, so Philips has
established a factory in each of its 10 main regions. Supporting
the 10 factories that assemble the final picture tubes is a second
tier of factories making glass units such as electron guns, with a
third tier making the constituent parts of the electron guns. These
second- and third-tier factories are all owned by Philips, but it
also has a number of external suppliers that furnish the raw
materials such as glass.
The resulting complex network of relationships was proving
increasingly hard to administer with the existing IT structure
based on EDI (Electronic Data Interchange). A new solution to
support better scheduling of orders and deliveries was needed.
How are systems being integrated?
The EDI system for delivering messages between factories had become
so unwieldy that some had gone back to faxes, according to Hans
Trump, Philips' IT and logistics manager for display components.
"We felt we needed to define a way of scheduling based on Web
communications and Internet technologies such as XML," he says.
A two-pronged solution was chosen. IBM's MQ Series software was
used for basic messaging, mostly between legacy systems, but with
WebMethods' B2B enterprise software implemented where possible.
"All our main IT suppliers work with WebMethods, so we can
standardise the messages," says Trump. "We use MQ Series for some
systems not in the supply chain for guaranteed message delivery,
and it has the advantage that it doesn't require a separate server
from the application, which WebMethods does."
What lies in the future?
The plan is to deploy WebMethods wherever possible, and standardise
on XML throughout the whole supply chain, including non-Philips
factories. The same applies to other systems within Philips'
domain, such as forecasting, that currently require older, less
reliable protocols like FTP for access.
Case study: Financial
User: Bank of Bermuda
What's the business strategy?
Founded in 1889, Bank of Bermuda is very much a bricks-and-clicks
business. It seeks to maintain its traditional reputation and
customers in fields like fund administration and global custody
services, while stepping into the e-world with online banking and
credit card transaction processing for e-commerce.
A key part of this strategy is the roll-out of a new global
banking service called Bankline II to corporate customers, which
began two years ago and now extends to insurance and fund managers
in Bermuda plus some overseas offices. Bankline II gives customers
a consolidated up-to-the-minute view of their position in the
currency of their choice, as well as access to basic balance and
transaction information. It can also be used to make cross-currency
domestic and international payments via a variety of mechanisms
with the option of postdating.
For all this to work on a global basis, the ability to access a
multitude of systems from a single front-end was imperative.
How are systems being integrated?
The bank chose middleware called Architect from eFunds for the
integration. According to the bank's senior project manager Judy
Readwin, Architect met the principal specification for a system
that would provide a globally consistent view of all applications,
irrespective of location or time zone. "We also required maximum
flexibility, as Bankline II had to be able to draw data from
multiple host systems, the combination of which can change," says
Readwin. "Now we only need to learn one system and it tells you at
a glance what you're worth. Previously you'd have needed to log
onto each host separately to find that out."
The middleware runs on a series of IBM RS/6000 servers, acting
as a middle tier connecting Windows clients to multiple hosts, some
new but others decidedly legacy such as a Digital Equipment Vax
cluster. The ability to access a mixture of legacy and new age
systems was therefore also a prerequisite.
What lies in the future?
The ability to reuse existing middleware code reduces the cost, and
most importantly time taken, to deploy new services. The first
priority, though, is to continue the roll-out beyond Bermuda to
other overseas offices, and to embrace areas of the bank's business
not yet served by Bankline II.