Force Fit

EAI also provides a simplified integration model that does not involve each application team developing in-house code to make systems work together. By offering a single platform for centralized integration, EAI vendors promise to reduce the amount of work each application team must do to retrieve data from other systems.

Most EAI products sell server software and one or more development tools to write interfaces between systems. Many of the products currently on the market are Java-based, using Java Application Servers to provide a solid base for EAI to build on.

And that base is pretty healthy. In researching this article, we heard over and over that integration is one area of IT still being funded. Gartner research supports that, estimating that by 2005, more than 90 percent of large enterprises will have integration technology in place.

Mixing It Up

Integration is critical to keeping systems synchronized. Today, the vast majority of IT shops come down on the "buy" side of the "build versus buy" debate, meaning your corporation is likely full of systems you didn't build and for which you have no source code. Making them communicate is a tall and expensive order, often requiring that your network and server administrators have intimate knowledge of the assumptions made when the integration code was written.Take, for example, a simple case of a customer information system purchased several years ago and an order-fulfillment system just put into place. How do you relate orders to customers? Can you easily connect a failed delivery back to a customer?

Without EAI, the typical process to resolve these problems is:

1. A businessperson determines the process that occurs and defines what needs to be done.

2. These business requirements are then turned over to an analyst, who determines the best way to achieve the business goal.

3. A programmer implements the solution.4. The network and server staffs are charged with keeping the new process running and monitoring its health--even if the monitoring tools are not built in.

Now add two more systems to the mix, each needing to interface with existing apps. That gives you a total of 12 interfaces for four systems, each requiring maintenance by two separate project teams (see "Without EAI" in the illustration).

Now let's see how you'd resolve this problem if you had EAI in your toolbox: The businessperson would still need to determine what process is necessary. But he or she would have a graphical tool--a business process modeler--to draw out the interaction, probably with help from the systems analyst; and a developer or EAI specialist would implement the bottom layer of the system, where data is transferred between the customer-information and order-fulfillment systems. While a developer would still need to write code to accomplish complex integration goals, where systems interact without any human intervention, most simple data transfer or validation would be achievable through a GUI, ultimately saving time and money.

If each system in our typical organization interfaces only with the EAI server, we're down to eight interfaces for four systems--one each to get data from the EAI server and one to send data to the EAI server (see "With EAI" in the illustration below).

Not only is this much more manageable, but you get the added benefit of centralized management to enforce error-reporting and log-generation rules.

Granted, the real world is more complex than this scenario, both in number of systems and number of interfaces per system, but look at how much you stand to gain.The Business

If your organization is like most, each project team independently creates the systems needed for integration. Every team must spend time addressing integration management issues--time that could be better spent maintaining and enhancing the systems that keep your business running.

The EAI business case follows three basic lines:

1. Centralized management with automated error reporting provides a single place to discover all the system interactions in the organization and a way to help eliminate redundancy.

2. EAI technology allows you to change from interactions between multiple systems to interactions with the EAI server--when a system performs an update, it reports that update to the EAI server, which then propagates changes out to all the systems dependent on this transaction.3. A dedicated integration staff offloads the time-consuming task of system integration from each project team, allowing teams to focus on making their systems solve business problems, and building teams that specialize in the quality and stability of your integration code.

Level Truths

Like any technology that streamlines a complex process, EAI is far from simple. To be generic enough to work with disparate databases, programming languages, operating systems and even hardware architectures, most EAI products are layered on top of Java, which offers independence from hardware and operating system issues, allowing vendors to focus

on their core apps. IMany vendors use JDBC as aprimary database connectivity tool (see "Typical EAI Application" for an overview of an EAI product).

There are now two levels of EAI: conventional, low-level EAI and BPM (business process modeling).

BPM EAI is used to design high-level overviews of system interactions, making broad statements such as, "When an order is fulfilled by the order fulfillment system, that order should be marked as filled in the CIS system." Each statement is then given a specific definition to use with low-level EAI--for example, field names or stored procedures that map from the affected fields in the order-fulfillment system to the target fields in the CIS system.

For conventional EAI, there are two basic architectures--queue-based and message-based. In a queue-based system, changes in one system are placed into a queue by that system and pulled off the queue by any system interested in the changes. In a message-based system, changes in the source system immediately trigger a message that is propagated to the target systems by the EAI server.

Over time, most vendors have implemented hybrids that support both of these models. The queue-based system is often called the "publish/subscribe" model--a misnomer because most message-based systems also allow for publishing and subscribing. The real difference is in the time needed to deliver the message and reliability if any part of the system goes down.

In a queue-based system, messages placed in the queue are retained until the receiver can deal with them. In a pure message-based system, if the receiver is not available, the message is lost; not surprisingly, pure systems are rarely implemented.

In "Smooth Integrators", we tell you how to determine the right EAI platform for your organization. But no matter which product you choose, your staff won't likely run the software right out of the box because of EAI's inherent complexity.

If you have people familiar with Java application servers, they should be able to configure and use any of the systems we tested, but the learning curve is steep enough that training is still in order. Most EAI vendors offer both training and professional services.An EAI implementation is not something to be undertaken lightly. You will touch every major system--possibly every system, period--in your organization. Businesspeople, technical staffers and managers will need to work together.

Done right, EAI can save you thousands of lines of code and many labor hours of management. It can also give you new insight into your business processes and enable you to quickly connect systems that might otherwise be unable to communicate. Done wrong, it can cost you hundreds of thousands of dollars and produce no benefits.

If you want to implement EAI, inventory all the system interactions in your company--you'll be surprised at how many there are--and identify the most likely EAI candidates. Perhaps you have systems that are not communicating reliably, or systems for which "the guru" is no longer with the company. Then there are systems so critical that to lose them would cost big bucks every hour they're down. These are all good candidates for the first phase of an EAI deployment.

Now pick a couple of low-threat interfaces and use them as learning experiences. Choose test systems where you have in-house experts in the source and target systems, so mistakes can be patched easily. Run a sample implementation with these low-risk interactions, and then start Phase 1 of the rollout.

Getting high-risk integrations into Phase 1 is a tactical choice: The biggest business benefit is going to come from stabilizing unreliable interfaces or replacing homegrown integration code that no longer has an owner. The process of integrating your enterprise will take an investment of many labor hours, so showing a positive result early on is important.Finally, dedicate staff to your EAI system long-term. It will function as the switch in your application network, handling all your app interactions. If it goes south, your apps will be without connectivity.

Also, have some trained EAI developers at the ready. Upgrades and system replacements will generate plenty of work for them. By using such EAI professionals, you're in effect not adding staff, but merely shifting responsibilities to ease the project teams' workload.

Don MacVittie is an application engineer at WPS Resources. Write to him at [email protected].

Post a comment or question on this story.

EAI Applications

Getting all those finicky applications you bought in the '90s to play nice with your shiny new Web-enabled software is tough enough, but throw in custom code written by long-departed COBOL connoisseurs, and the dreamof getting your applications to work as a team in support of business goals can seem hopelessly out of reach.

Enter EAI. Enterprise application integration apps work like a switch to which you hardwire all your disparate systems, thus ensuring that each application can interface with all others. Implementing simple business processes that once took days, even weeks, can be accomplished via a GUI. Magic.But like most magic, EAI requires hard work behind the scenes. We tested software from BEA Systems, IBM Corp., Sybase, Tibco Software and Vitria Technology, and found that all five products did a good job centralizing integration, and all let us define business processes, with varying degrees of ease.

The downside: Byzantine configuration and setup, and prices that may induce sticker shock. But training is available, and cost will be less of a factor if you go with our Editor's Choice: Sybase's Integration Orchestrator, priced at 25 percent less than the nearest competitor. IO also features an intuitive interface and the best Web services implementation, built on technology that has been proven over years of use.67% of the 300 enterprise readers we surveyed (from organizations averaging 29,000 employees) said they do legacy-to-legacy EAI

57% said Web services are OK for simple transactions behind the firewall, when asked if Web services are sufficient to replace conventional EAI for app-to-app transactions

76%said 18 months from now, Web services will be OK for simple partner transactions

57% said 18 months from now, Web services will be OK for simple partner transactions

FYI

EAI is the second highest-paying skill area among IT managers, followed by wireless infrastructure, ERP and Web infrastructure, according to InformationWeek Research's 2003 National IT Salary Survey. Web security ranks first. All pay $100,000 or more with bonuses. See "Sliver Of The Pie".