Because enterprise architectures have been poorly planned for the last two decades and longer, it is time to return distributed enterprises into the realm of sanity. Many organizations built systems based on the "cool" technology of the day, suckered into the hype without properly considering how these systems would somehow, someday, share information. For example, there are organizations with dozens, if not hundreds, of different types of open and proprietary systems, each with its own development, database, networking, and operating system religion. The result is a heterogeneous mass (read, chaos) that only the bravest—or most foolhardy—enterprise architects are willing to sort out without gutting the entire enterprise just to get things back on a sane track.

Again, EAI as such is not new. However, the science behind linking varied types of information systems certainly is. EAI has become a sophisticated set of procedures with newly refined technologies, such as message brokers, that allow users to tie systems together using a common glue. The concept of EAI may not be new, but the power of the tools and technology, as well as the techniques available to solve the EAI problem, sure are. Middleware, for example, once clearly a programmer's toy, is now a business tool that allows enterprises to freely move information between any number of systems at will—in many cases, without having to change the source or the target systems. Cutting-edge technology has created the opportunity to solve a problem that has been becoming more intractable for years.

Another factor that is driving enterprises toward the promised land of EAI is the broad acceptance of Enterprise Resource Planning (ERP) applications as the new IT infrastructure for the post-millennium corporation. Packaged applications, such as those from SAP, PeopleSoft, and Baan, have revolutionized the way integrated information technology systems are built within most enterprises. Rather than creating new systems from scratch, the modern enterprise is able to leverage existing business rules and processes defined by a single, or several, vendors.

Companies such as SAP have become multibillion dollar entities thanks to the wide acceptance of ERP applications in larger enterprises. What's more, interest in packaged applications has increased in general, with sales automation packages, customer care packages, and vertical market-oriented packages making headlines in the trade publications.

As much as ERP applications can help the integration solution, however, they can also hurt. Organizations are discovering that ERP applications are difficult to install and configure and that, too often, once they are up and running, they turn out not to be all that they were cracked up to be. There is the "little problem" of extracting information from these beasts, information that may be vital to other information systems within the enterprise. For example, if SAP replaces five systems within an enterprise and those five systems supply information to any number of other systems that may also be in place, then the SAP systems must also communicate with these other systems in the enterprise. Making this happen demands an incredible degree of coordination, programming, and testing.

Although coordinating these systems may seem like a minor problem to those who have linked custom systems, it is important to remember that a packaged application typically does not allow for any modification to its source that would enable it to pump information out of a common middleware pipe. This requires interfaces that the ERP application vendor provides. While it would seem like an easy stretch to expect the vendor to have solid and easy-to-use interfaces already in place, the reality is much different. In fact, the major ERP application vendors are beginning to create these interfaces within their products. For the time being, the interfaces are immature and difficult to use.

This immaturity represents another aspect of EAI and its real value within many enterprises. EAI is able to link many disparate systems—including ERP applications. It is not unreasonable to suggest that the growing interest in ERP could very well be driving the interest in EAI as well.

If EAI has been around for a while in everything but name, why write a book on it now? As we've already suggested, the need for EAI is a result of many years of building distributed computing systems with poor architectural planning. The systems using traditional techniques and technology simply cannot communicate with one another without changing a significant portion of the application. In other words, a logical approach is necessary in order to integrate existing enterprise applications, as well as to address the new breed of technology.

This book is designed to provide the average computer-literate person with enough information to determine if his or her enterprise needs, or would benefit from, EAI—and, if so, how to approach enterprise information planning requirements using the concepts of EAI.

We will present approaches to implementing EAI within typical enterprises, or between two or more enterprises, using the supply chain integration scenarios. We will also discuss the enabling technologies of EAI, technologies such as middleware, system management layers, standards (such as XML), and application development tools that allow applications and databases to share information with one another. Interfaces into complex systems such as SAP and PeopleSoft will not be left out of the mix. We'll also take a look at the future of EAI technology and discuss how you can prepare for it now.

Ultimately, this book is designed to save you money. Because the lack of proper EAI means that many existing information systems cannot coordinate or share information—resulting in a tremendous loss of revenue—then the addition of EAI within most enterprises has the potential of saving that revenue. Much of those savings come either with the automation of processes that are currently being completed through mechanical mechanisms or through viewing all enterprise systems as a single virtual system and thus having access to all relevant data for decision support.

Of course, any number of other types of savings may be derived from EAI; they vary case by case, enterprise by enterprise. In most situations, the value of EAI is apparent.

In addition to the benefit of application integration within the enterprise, a tremendous benefit is also derived from sharing information with applications that exist outside of the enterprise. e-Business integration is a mechanism by which information systems are connected with information systems that are owned and maintained by a trading partner. The result is the ability to share information such as order inventory and sales data. Sharing such information speeds up all aspects of business, including production, sales, order processing, and invoice processing. Increased efficiency in any and all of these areas results in increased profitability.

e-Business is the next frontier of EAI. Analysts have already begun to double the estimates for business-to-business electronic commerce.

There are so many people to thank that it's difficult to know where to start. First of all, I want to thank Ursula Kappert, my executive assistant. Ursula diligently took on most of the heavy lifting in creating this book, including editing, gathering and sending chapters and graphics, and also putting up with a grumpy boss after yet another marathon writing session.

I want to thank Steve Johnson, my graphics guy, who was able to take my abstract, modern art-like chicken scratches and turn them into understandable and enjoyable images. Credit also needs to go to Mary O'Brien and Elizabeth Spainhour of Addison-Wesley, who had faith in this book and allowed me to bring it to market. Also, thanks to David Wolfe, who helped edit earlier drafts.

I would also like to thank Christine Sukhenko, my technology analyst, who assisted me in research for the book, and Andre Yee, my VP of R&D, who provided many ideas and felt the impact of mine.

Moreover, I can't leave out the SAGA Software executive team, including CEO Dan Gillis, for the encouragement to take on and complete this project. It's better to lead than to follow.

David S. Linthicum is Chief Technology Officer for SAGA Software (www.sagasoftware.com), and is an internationally known EAI and e-Business expert. He has consulted for hundreds of major corporations engaged in deploying complex distributed systems. In addition, he is the author of several regular columns, including "Middleman" in Enterprise Development, and "Site Builder" in Computer Shopper, as well as more than three hundred other articles on technology. David Linthicum is a frequent speaker at technical conferences, including E-Business Expo, Comdex, iEC, Comdex Enterprise, Software Development, and Application Integration and Apllication Architecture. He is also the author of David Linthicum's Guide to Client/Server and Intranet Development.