Project Management

Enterprise Application Integration

Author: David S. Linthicum

ISBN: 0201615835

Buy this book at

Integrating Enterprise Applications
By Alan Zeichick

It's a nasty problem-one of the nastiest, many would agree. Creating and implementing a strategy for enterprise application integration, or EAI, requires a big budget, a talented team, a big budget, hands-on support from systems vendors and consultants, expensive integration products and a lot of time and patience. Oh, did I mention a big budget?

One particularly vexing challenge facing any planned EAI project is that there isn't a single thing called EAI, because that newly popular buzzword implies that EAI is a tangible problem with a definable process and a clear set of goals that determine a solution set. It's none of these; there's no one-size-fits-all EAI solution-and don't let an EAI vendor or consultant tell you differently. Is your goal to breathe new life into stovepipe applications by adding messaging interfaces? Are you trying to integrate packaged applications? Is the end result supposed to be data mining? EAI can be all of those to your organization, or none of them.

Imagine my distaste with vendors who try to tell me that they've got the "best of breed" EAI solution. Imagine my delight when I found an excellent book from David S. Linthicum that describes all of the various aspects that might be considered part of an EAI problem, process and solution. If you're trying to get a handle on what EAI might mean for you and your organization, his aptly named "Enterprise Application Integration" covers all the bases. Although Linthicum is employed as CTO of Sega Software, his book-as with all his writing, such as his column in Enterprise Developer-is remarkably free of perceptible bias. 

The book begins with a discussion of EAI, plus the presentation of various ways of defining the concept. My favorite, and the one I use most frequently, is to combine multiple disparate applications into a single virtual application. But there's more to EAI than a clever concept: Because it's expensive, there must be a business reason to integrate those stovepipes, enterprise resource planning systems or even external apps. Linthicum doesn't spend a lot of time on that issue, and it would be nice if he spent more, perhaps with a case study or two, but he does a fair job of framing EAI in business terms.

Plan on spending a lot of time with chapters two through five-not because they're difficult to read, but because their meaning is essential to conceptualizing the essence of EAI. In those chapters, Linthicum describes in very definite terms four broad categories of EIA: data-level, application-interface-level, method-level and user-interface-level. Those four levels describe the basics of how information is pulled out of one existing application and fed into another one.

Do you want to go right to the data store by writing to the back-end database? Does each application offer published and documented APIs for which you can write external unidirectional or bidirectional access programs or scripts? Can you create methods, or business logic, using distributed objects or an application server? Or must you resort to simulating a legacy app's user interface, perhaps scraping 3270 or 5250 screens or encapsulating them with objects?

Until you understand the distinctions (and perhaps have a handle on which of your applications can be accessed with which types of EAI), you can't develop a strategy for truly integrating them. Fortunately, the author's explanations make the distinctions crystal clear.

Once over the hump, move forward to chapter six, which introduces processes for tackling EAI problems. That feeds nicely into middleware-the technological glue that binds all the applications together.

Linthicum serves his audience well by holding his in-depth, six-chapter discussion of middleware until this point. Too many companies choose middleware based on flavor-of-the-month without regard for the fact that each of those technologies solves a different problem, and many solutions will require multiple types (or layers) of middleware, not a slavish devotion to the latest fad.

It would have been nice if the book went deeper into competing technology implementations, such as DCOM vs. CORBA, which does have some coverage, or Microsoft's MSMQ vs. IBM's MQSeries. In those cases Linthicum is breezy, with throwaway lines like "MQSeries is the 600-pound gorillait can do just about anything it pleases," contrasting with "MSMQ provides the best tool support 'out of the gate,' simply because it has been developed by Microsoft." Harumph.

The next section of "Enterprise Application Integration" discusses general issues surrounding packaged applications-in this case, Linthicum focuses on SAP and PeopleSoft. It's an overview, nothing more: Fourteen pages on integrating R/3 using EIA and middleware can't be anything but.

As the book winds toward a close, there's another breezy chapter on Extensible Markup Language and related standards; you won't gain much depth on XML from here (read "XML: A Manager's Guide," reviewed last issue, for a solid nonprogrammer's education), but the author does tie XML in with EAI, which is typically not one of the uses being touted by XML's major proponents, although it's a natural fit for messaging. And indeed, the next chapter touts messaging brokering, which Linthicum calls "the preferred EAI engine."

Message brokers, in case you're not familiar with the concept, are servers that use a hub-and-spoke model to bridge multiple systems together, translating messages, distributed objects or business logic as appropriate. I like the definition "message brokers are middleware's middleware." Although Sega Software, Linthicum's employer, makes and sells a message-brokering product, he gives equal ink to other players in that market.

Bottom line: EAI is important, whether you're running mainframes, ERP or other systems. It can also be confusing. If you'd like to find a single book that makes it less confusing, this is the one to read.

Reprinted with permission of SDTimes.  Originally appeared in Issue 2, March 15, 2000.


"Of course the music is a great difficulty. You see, if one plays good music, people don't listen, and if one plays bad music, people don't talk."

- Oscar Wilde