EAI-Application Integration Exposed

Software Magazine, Feb, 2000 by David S. Linthicum

EAI, plus the new generation of middleware that supports EAI concepts, are emerging as the "missing links" in the quest for success in B2B integration.

ENTERPRISE APPLICATION INTEGRATION (EAI) is really nothing more than putting science, methodology, and technology behind the integration of information systems. As we move into a more connected world, application integration in support of mission-critical concepts such as business-to-business (B2B) integration, drives EAI, as does the availability of modish and more effective middleware technology for use with the Internet.

However, EAI remains a difficult concept to grasp for most organizations, and an even more difficult concept to successfully implement. The barriers to application integration still exist, including incompatible application interfaces or lack thereof; limitations of current middleware technology, and the expense of adapting your entire enterprise to EAI.

While there are clear challenges to application integration, the need to bind applications together both within and between enterprises is driving the interest in EAI as well as the new technology offerings to support it. Message brokers, unheard of just a few years ago, are now dominating most EAI solution sets, as are Java-enabled application servers, and even traditional middleware such as message-queuing software.

Clearly, the essence of EAI is something we've been trying to achieve for years. Now that B2B integration and the exposure of existing enterprise systems to the Web have become imperative, EAI can no longer wait. Considering this, it's time to better understand the ins and outs of application integration, finding the sweet spot in approach and technology for your particular organizanon. As always, to better understand a problem and its solutions, we need to break it down into its components.

We can break application integration into macro problem domains: intra-enterprise, or application integration that occurs within the firewall (traditional EAI); and inter-enterprise, or application integration that occurs between two or more distinct organizational entities (e.g., companies, agencies, etc.). We can further break each macro problem domain into application integration types, which include data level, application interface level) method level, user interface level, and information portals.

Intra-Enterprise Integration

Intra-enterprise application integration is the joining of systems that serve a single enterprise. Typically, this means linking the older mainframe-based inventory system, written in DB2 and Cobol, with the SAP R/3 system just installed, or perhaps linking both systems with the sales automation systems of a company just acquired.

In the past, companies addressed most intra-enterprise application integration requirements through whatever means they could find. This included nightly or weekly batch updates, FTP file transfers, and rekeying data. Later, they learned to join systems together using traditional point-to-point middle ware products such as the Open Software Foundation's DCE (Distributed Computing Environment) or IBM's MQSeries message queuing software.

The point-to-point nature of these products, while providing the ability to share information between a single source and a single target system, quickly became difficult to manage and constantly required expensive changes to all participating systems. In short, leveraging traditional point-to-point middleware could not scale to the massive application integration needs today's businesses are encountering.

Today the answer is leaning toward more solutions-oriented and strategic approaches and technology, including creating a common infrastructure for enterprises to share information in one-to-one, one-to-many, and many-to-many configurations (see "Integration Infrastructure," p. 50). Newer, but less proven technology, such as message brokers and application servers, are replacing more traditional point-to-point middleware products and ad hoc integration solutions. Albeit, hyperbole seems to be leading reality as we once again consider the latest magic bullets. As time pushes on, we have a clearer view of what these new products will and won't do for us.

Types of EAI

When contemplating intra-EAT, an organization must first understand the sum and content of the business processes and data in the organization. IT also needs to understand how these business processes are automated (or not), and the importance of all business processes. Depending on the enterprise, this may demand a significant amount of time and energy. In brief, organizations must understand both business processes and data. They must select which processes and data elements require integration. The types of EAT solution sets can take on several dimensions (see "Types of EAT," p. 51).

Data-level EAI is the process -- and the techniques and technology -- of moving data between data stores. This can be described as extracting information from one database, perhaps processing that information as needed, and updating it in another database. While this sounds direct and straightforward, in a typical EAT-enabled enterprise it might mean drawing from as many as TOO databases and several thousands of tables. It may also include the transformation and application of business logic to the data that is being extracted and loaded.