Overview
Choosing the right Back-end Integration pattern design can only be done in the context of specific enterprise requirements. These requirements encompass not only the specific Back-end Integration to be deployed, but also the enterprise's IT infrastructure and technology preferences. This page details considerations to be made and questions to ask in determining which Back-end Integration design best fulfills your enterprise needs.
Request for Information vs. Request for Processing
Is the integrated solution for informational access only or is it intended to integrate requests for processing?
Foreground vs. Background integration
Is there a user awaiting the outcome of the operation or is this operation running behind the scenes? An example of a foreground process may be a user retrieving a price quote for the purchase of product whereas a background process would be the synchronization of pricing information from the central office out to all of the local stores.
Scope of Integration
Does the integration project involve only a single Business pattern, multiple Business patterns, or the creation of an entire e-infrastructure for multiple e-business solutions?
Operation Latency (applications and/or data queries)
How long will it take the operation to complete in the application? Operations that can not complete in less than a couple of seconds dictate the need for asynchronous methods of integration. A query on product inventory may be a quick operation whereas the computation of the production plan for the manufacturing of that inventory could take minutes to hours to complete.
Geographic Proximity
How close do the applications being integrate reside to one another? Similar to the idea of operation latency, an often overlooked element of the EAI design is the proximity of the participating applications in relation to each other. Integration of applications residing in the same data center has a much smaller integration latency than integration of applications spread around the world.
Degree of Application Conformity
Do the applications support standardized interfaces (either directly or through adapter abstraction) or application specific interfaces? Many environments have significant number legacy interfaces that make it more cost-effective to do transformation centrally in an integration hub rather than implement standardized interfaces.
Process Re-engineering
Is the customer re-engineering their business processes or extending an existing business process? Most legacy business processes are locked in the applications themselves. Business Process Management (BPM) is performed by the existing application(s). Sometimes the EAI effort merely is trying to better integrate functional operations of a stovepipe business process. Other endeavors are more ambitious with the desire to improve business processes through integration.
There are varying degrees of process extensions for application-based BPM:
- extending reach of the business process with integration to other applications
- joining together two separate application-based business processes into one unified process
- separating BPM from application logic by implementing the process in a Process Manager. This option extends the domain of the process by allowing it to encompass any participating application under any specific sequencing and process flow control.
Application Portfolio
What is contained in the mix of applications? This might include pre-packaged software, legacy applications, or newly developed applications. One of the most important elements of an EAI project is to survey the application landscape. Some environments are heavily based on pre-packaged software. Other environments are completely homegrown custom applications. Other environments may be a mixture of pre-packaged applications working with legacy homegrown applications.
This survey will detail several key points about the enterprise environment. First, if the application interfaces can be extended as part of the integration activity. Homegrown applications may have standardized interfaces or can extended to implement standardization. Interfaces into pre-packaged applications typically can only be standardized through implementation of sophisticated adapters. Second, is there a central cornerstone application in the enterprise environment or a portfolio of peer applications. Is the business processing focused around one key application (perhaps an ERP system) with all other applications being subservient to that application?The third measure is the number of applications being integrated. For instance, a typical Self-Service application may be integrating the web application server with one back-end system. At the other end of the spectrum would be a project creating a centralized customer information system that may require feeds from 100+ different applications. Integration of two applications has different pattern requirements than integration of 100+ applications.
Invasive vs. non-invasive
What is the level of independence between application implementation and the EAI interface. How likely is it that changes to the application will require changes to the interface or changes to the integration processing. The degree of invasiveness not only effects the application adapter. It can also affect the integration hub processing and even require changes to the partner application. The further across the Back-end Integration topology a change ripples, the more expensive this change will be. The degree of invasiveness is often described in terms of coupling (loose coupling vs. tight coupling) or black box vs. white box approach.
Ideally, the less invasive the integration, the more successful the integration will be long-term. This is the primary reason for the use of messaging based integration to isolate as much of the integration processing from any application-specific dependencies. EAI best practices should be employed to ensure that the integration is as non-invasive as possible.
However, EAI projects will vary in the level of independence available based on completeness of the participating applications functionality and interfaces. For environments with heavy application-specific processing required, it is best to implement these using a sophisticated integration broker component supported by easy to use Application Development tools. This ensures that future extensions to the integration can be implemented quickly and easily.
Enterprise Architecture
To what degree is the overall enterprise process and data model defined? The enterprise architecture is an instantiation of the application functions, application data model, application interfaces, and application flow of control. Beyond capturing the existing an accurate description of the current enterprise environment, a good Enterprise Architecture (EA) takes into account new business processing requirements.
The completeness of the EA often will dictate the level of invasiveness in the EAI integration. A well conceived EA enables a more extensible enterprise Back-end Integration design.
The different types of Enterprise Architectures dictate different Back-end Integration patterns. For instance, the User to Business is divided into web up and enterprise out scenarios. Enterprise out scenarios have heavier legacy content than web up scenarios. Key characteristics of the EA that affect the EAI approach include the:
- number of applications
- degree of centralization of the data repositories
- completeness of the application interfaces
- conformity of the participating applications to the EA data and interface model
What's Next
Now that you better understand the requirements of an Back-end Integration design, the next step is to select an Application pattern.
If you have determined that the Back-end Integration pattern is not appropriate for your development efforts, review the Business patterns to determine which pattern best addresses your e-business needs.