E. A. I. (Enterprise Application Integration)
EAI is a business computing term for plans, methods, and tools aimed at modernizing, consolidating, and coordinating the computer applications in an enterprise. Typically, an enterprise has existing legacy applications and databases and wants to continue to use them while adding to or migrating to a new set of applications that exploit the Internet, e-commerce, extranets, or other new technologies.
(Click here for "The EAI Journal" - a Web site focused on EAI.)
EAI is big business. Information Week recently did a survey of 300 technology managers in which 75% of the respondents said that EAI is a planned project in their IT departments in the coming year. This finding is consistent with similar research conducted by AMR Research that predicts that sales of EAI software products were about $600 million in 1999, up from $450 million the year prior. A growth rate in the range of 50% annually is predicted for the next several years.
It has also been reported that ERP market growth is currently in somewhat of a slump. That being the case, it is not surprising that some of the traditional ERP vendors (e.g., Baan and Oracle) are seeking opportunities in the EAI arena. Oracle recently introduced a set of application-integration tools designed to let Oracle ERP applications talk with legacy systems and software from competitors such as SAP. The package includes an application adapter development kit, a messaging server, and a business-process workflow engine. Baan Open World Integration Framework, unveiled in Nov. of '99, includes application adapters and a messaging server that transforms data into standard formats such as Extensible Markup Language (XML). Baan EAI is available as a separate product as of the first quarter of this year, as was BaanERP 5.0c, an upgrade of its ERP suite that uses the messaging system to tie in its customer-relationship management and supply-chain management suites.
However, other ERP providers are taking a different strategic approach. SAP, PeopleSoft, and J. D. Edwards' have decided to attempt to improve the routes in and out of its applications rather than introducing new middleware tools to the market. Robert Res, director of E-business technology at SAP says, "...We have no intention of selling EAI tools ...it's partnering we're interested in, because the EAI market is already well established." So these companies are working to make their systems interoperate more easily with third-party software by adding more API's and building support for standard messaging formats, such as CORBA and XML, into their software.
Whatever the strategy, many analysts say that ERP vendors simply can't afford to ignore integration if they want to remain relevant in an Internet-driven, E-commerce world, which by its nature requires that data flow easily across a variety of computing environments. The future is in building links between companies, not just integrating applications inside companies.
Application integration can be broken down into two macro problem domains: 1) intra-enterprise, or application integration that occurs within the firewall (traditional EAI); and 2) inter-enterprise, or application integration that occurs between two or more distinct organizational entities.
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 (for example), written maybe in Cobol, with the SAP R/3 system just installed.
In the past, companies addressed most intra-enterprise application integration requirements through whatever means they could find. This included weekly or nightly batch updates, FTP file transfers, and rekeying data. Later, they learned to join systems together using traditional point-to-point middleware. 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 that 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. Newer, but less-proven technology, such as message brokers and application servers, are replacing more traditional point-to-point middleware products.
When contemplating intra-EAI, an organization must first understand the sum and content of the business processes and data in the organization. In brief, organizations must understand both the business processes and the data. They must select which processes and data elements require integration. The types of EAI solution sets can be viewed from the perspective of several different perspectives.
Data level. 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 EAI-enabled enterprise it might mean drawing from as many as 100 databases and several thousand tables. It may also include the transformation and application of business logic to the data that is being extracted and loaded.
The advantage of data-level EAI is cost. This approach largely leaves the application alone and does not change code, so organizations don't need to incur the expense of changing, testing, and deploying the application. What's more, the technology that provides mechanisms to move data between databases as well as reformat that information, is relatively inexpensive.
Application interface level. Application interface level EAI refers to the leveraging of interfaces exposed by custom or packaged applications. Developers leverage these interfaces to access both business processes and simple information. Using these interfaces, developers can bundle many applications together, allowing them to share business logic and information. The only limitations that developers face are the specific features and functions of the application interfaces.
This type of EAI is most applicable to packaged applications such as SAP, PeopleSoft, and Baan, which all expose interfaces into their processes and data, but do so in very different ways. In order to integrate those systems with others in the enterprise, developers must use these interfaces to access both processes and data, extract the information, place it in a format understandable by the target application, and transmit the information.
Method level. Method-level EAI is the sharing of the business logic that may exist within the enterprise, or between enterprises. For example, the method of updating a customer record may be accessed from any number of applications by invoking a common shared method, typically residing on a shared application server or distributed object infrastructure. By sharing methods, applications are tightly coupled and therefore tightly integrated.
The mechanisms to share methods among applications are numerous, including distributed objects, application servers, TP (transaction processing) monitors, frameworks, and simply creating a new application that is the combination of two or more applications.
There are two basic approaches: 1) organizations can create a shared set of application services (methods) that exist on a shared physical server, such as an application server; or 2) methods already existing inside of applications can be shared using distributed method-sharing technology such as distributed objects.
Method-level EAI is something companies have been using for years as they've sought to reuse application development efforts within enterprises. Unfortunately, the approach has not been very successful, due to both human and technological issues.
User-interface level. User interface-level is a more primitive approach. Using this scenario, architects and developers can integrate applications by using their user interfaces as a common point of integration (a.k.a. screen scraping). For example, mainframe applications that do not provide database- or business-process-level access may be accessed through the user interface of the application.
Although many consider leveraging the user interface as a point of integration to be an unstable and archaic approach, the fact is that it has been done this way for many years and many of the issues, such as performance, reliability, and scalability, have been worked out. Although not preferred, it may be the only solution in many instances. The heart of EAI is the ability to leverage any existing system by finding a reliable point of integration.
Information Portal. The information portal type of EAI is very popular today due to the rise of the Web. Using this EAI approach, application architects can integrate applications by presenting information from several applications within the same user interface. Information from many places, such as other sites or applications, is presented within the same user interface, typically a Web browser. Enterprises are leveraging this integration approach as a means of integrating enterprise systems at the user interfaces, thus avoiding the complexity and expense of traditional back-end integration.
Inter - Enterprise Integration (E-business)
EAI can extend its reach outside the enterprise to include both trading partners and customers within the application integration architecture. This enables any application or data store to share information with any other application or data store that exists within the supply chain scenario. Traditional B2B integration scenarios leveraged traditional technology such as EDI and proprietary value-added networks. Today, however, most B2B architects opt for more real time and Internet-enabled technology such as application servers and message brokers.
Application servers. An application server is server program in a computer in a distributed network that provides the business logic for an application program. The application server is frequently viewed as part of a three-tier application, consisting of a graphical user interface, an application (business logic) server, and a database and transaction server. More descriptively, it can be viewed as dividing an application into:
1) a first-tier, front-end, Web browser-based graphical user interface, usually at a personal computer or workstation
2) a middle-tier business logic application or set of applications, possibly on a local area network or intranet server
3) a third-tier, back-end, database and transaction server, sometimes on a mainframe or large server.
Older, legacy databases and transaction management applications are part of the back-end or third tier. The application server is the middleman between browser based front-ends and back-end databases and legacy systems.
Application servers not only provide a location for application logic, but they also coordinate many resource connections using transactional semantics. This enables users of application servers to integrate back-end resources using the notion of a transaction (start, extract information, move information, update information, stop), as well as expose information from those resources to connected Web browsers or though client/server interfaces.
Application servers provide an up-to-date approach to sharing methods using the power of transactions, thus supporting method-level EAI, as well as a mechanism for integration. However, each application server has its own approach as to how this happens. Therefore, making wise decisions regarding the selection of an application server requires an understanding of the category of features, as well as the problem at hand.
Message brokers. Message brokers are servers that broker messages between two or more source or target applications. In addition to brokering messages, they transform message schemas and alter the content of the messages so the messages make sense to the application receiving the message.
In contrast to application servers, message brokers tend to move information using event-driven mechanisms. Message brokers watch for state changes at the source or target systems (e.g., update to a customer database) and react accordingly, typically by moving and reformatting business information. Application servers, by contrast, use a transactional model where transactions are invoked within the application server. The application server carries out a preprogrammed function, perhaps communicating with an application resource. The message broker model is a loosely coupled solution that typically does not require changes to source or target applications, and is least expensive to implement.
Message brokers represent the nirvana of EAI-enabled middleware. They are a technology that allows many applications to communicate with one another without actually understanding anything about each other.
Here are some key EAI vendor web sites: