6.1. Integration Requirements and Scenarios

Before delving in the details of the technologies, it is helpful to illustrate the major concerns for integrating enterprise information systems and to get a sense of the extent of the EAI problem. We discuss three types of integration scenarios: data integration, application integration, and business process integration. Often, an enterprise's integration needs span these different types.

6.1.1. Typical Integration Scenarios

Data integration involves integrating existing data living in different enterprise systems, and it often occurs when an enterprise relies on multiple types of database systems. For example, some database systems may be relational, others may be hierarchical or based on objects, and still others may be file based or even legacy stores. As an illustration, a newly developed Web-based order management system might have to integrate with an existing customer order database. Data integration involves not only integrating different data systems, but it also entails integrating different informational or data models.

Application integration involves integrating new applications with existing or legacy applications. Since an enterprise's business relies on the continuity of its existing applications, it is important to integrate the new applications with minimal disruptions. Integrating with home-grown legacy applications presents a bigger challenge, since these systems have no vendor-provided or off-the-shelf adapter layers. Not only do you have to write the adapter layers yourself, these home-grown applications may be more idiosyncratic, with an architecture that is more opaque and difficult to understand.

Business process integration involves integrating an enterprise's existing systems to support a set of business processes. A business process is a series of (often asynchronous) steps that together complete a business task or function. For example, the adventure builder enterprise has a business process for fulfilling purchase orders submitted to its order processing center. The order fulfillment business process includes such steps as validating a customer's credit card, communicating with various suppliers to fill different parts of an order, and notifying the customer of the order status at various stages of processing.

Integration is often accomplished by exchanging documents, which more and more are XML documents, among business processes according to defined business rules. The different processes transform the documents by applying their individual business rules, and then they route the documents to other processes. Good examples are business processes that do such things as handle purchase orders and invoices, or incorporate supplier catalogs. Each such business process runs a workflow that interacts with other entities, either internal or external.

6.1.2. Example Integration Scenarios

Examining some typical scenarios helps to bring these integration requirements into better perspective. We use the scenarios present in our adventure builder enterprise example for illustration. One common integration scenario is that of the adventure builder enterprise, which may want to make its inventory available online to expand its customer reach. The enterprise may have existing applications and databases—for example, catalog and inventory databases, along with order processing and customer relationship management (CRM) systems—for its business. These systems and databases need to be enhanced to accommodate the e-store.

Adventure builder enterprise purchases and customizes the CRM package, but its order processing system may be homegrown. As much as possible, the enterprise wants to reduce software duplication and keep its infrastructure costs to a minimum. To that end, it may want to use these same systems to handle the e-store business, especially since its existing customers may also buy products through the online store. Adventure builder enterprise also wants to leverage its customer service department and have these same specialists service both types of customers: store front as well as online. Adventure builder enterprise expects to include additional databases relevant for the Web site only.

This scenario illustrates an application and data integration problem. The enterprise's existing databases store information needed by the e-store, which may need to update these databases. The databases have existing security settings, plus protocols for transactions. The vendor for the CRM system may have provided a J2EE connector that could be used to plug the CRM system into the enterprise's J2EE application server. However, the order processing system, since it is homegrown, may have no such support.

Figure 6.1 illustrates the scenario of this application with respect to the EISs that it uses. This example scenario touches upon many of the integration requirements that pertain to all enterprises. Because it is open to anyone on the Internet, the adventure builder Web site may potentially have a large number of users, making scalability and performance important issues. Security is an important consideration, since adventure builder's Web site handles customer data that it must keep private. The enterprise has the further challenge of ensuring that its legacy systems are not stretched beyond their capabilities and that heterogeneous platforms may host the EIS systems.

The enterprise relies on an order fulfillment center to process orders placed through the e-store Web site. A separate department owns the order fulfillment center, and it uses its own set of databases separate from the e-store's Web site. To keep the two data models decoupled, orders flowing between the e-store and the order fulfillment center are kept in XML format. Communication is also asynchronous, allowing clients to continue their own work while an order is processed. In essence, the order fulfillment center initiates a business process whenever it receives an order. The business process, following a set of automated rules, interacts with several systems in a workflow to complete or fulfill the order with no human intervention. Part of the workflow includes sending confirming e-mails to customers and keeping records for administrative reports.

The order fulfillment center interacts with external business partners to complete its workflow. For example, the order fulfillment center might rely on a separate credit card billing service to process its customer billing. Some of its products may be supplied directly by another vendor. The order fulfillment process initiates multiple business processes for each external business with which it interacts.

Let's look at a different integration scenario. A human resources application, designed for internal use only, may have a similar scenario to an e-store, since it concerns a new application that uses existing enterprise assets. However, the application's internal use limits the scalability, performance, and security concerns. The principal concerns with internal applications such as this are fast delivery time, platform heterogeneity, and the capacity to grow the application and support multiple types of clients as the enterprise expands. The application may also want single sign-on for users across various security domains, but, at the same time, permit access only to employees whose proper access privileges adhere to company-wide rules.

Internal applications may also provide some limited mobile functionality; that is, they need to be accessible from mobile devices such as PDAs and cellphones. For example, a travel expense tracking application may want to allow employees who are on the road to keep track of their expense records. Likewise, enterprises whose departments are geographically scattered may find it more efficient for employees to use the Internet for internal communications. Web service interfaces are particularly useful in these situations, although there are the additional concerns of distributed and multiple security domains.

Often, systems developed for internal use rely on home-grown legacy systems. While systems bought from third-party vendors may be integrated using standard connectors supplied by their vendors or third parties, this is not true for homegrown systems. These homegrown, or one-off, applications must still be integrated with other applications in the enterprise and accessed from a Web browser.