Integration Tools: Click and stick

Low-level middleware isn't enough to cement your e-business systems to the rest of your organisation's IT. Philip Hunter offers a...

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.

  • Read more on E-commerce technology