3.1 General guidelines

 < Day Day Up > 



3.1 General guidelines

To help you determine if the Application Integration pattern is appropriate for the design of your intra-enterprise application integration scenario, this section details the business and IT scenario into which a solution using the Application Integration pattern will fit.

It also discusses how the solution requirements can help determine which of the two Application Integration categories (Process-focused or Data-focused) you should use in designing your e-business solution.

3.1.1 Business and IT drivers

Businesses developing a solution needing the following characteristics should consider using the Application Integration pattern:

  • The business processes need to be integrated with existing business systems and information.

  • The business activity needs to aggregate, organize, and present information from various sources within the organization.

3.1.2 Context

Application Integration patterns can be observed in solutions that call for close integration with systems and databases that exist in the organization. It serves as a back-end integration pattern, and is critical for the successful implementation of certain Business patterns. For example, solutions that use the Self-Service business pattern or Extended Enterprise business pattern often rely on these same application integration techniques. Similarly, many Custom designs and Composite patterns use Application Integration application patterns.

In our sample business scenario, described in Chapter 6, "Business scenarios used in this book" on page 111, ABC Electronics wants to integrate their retail and wholesale departments. Currently, both departments have proven IT infrastructures but have no interconnectivity. The Process-focused Application Integration patterns address this problem. These patterns can be applied in a case where the business process needs to be integrated between existing business systems within the organization. The Process-focused Application Integration patterns can be used to integrate the retail ordering and wholesale inventory systems in ABC Electronics, eliminating ordering lag and providing an up-to-date inventory.

3.1.3 Solution

The Application Integration pattern typically consists of the following:

  • Business applications and data that need to communicate, interact, and integrate with other business applications and data within the organization

  • A network which:

    • Is based on TCP/IP and other Internet technologies, or on proprietary protocols

    • Can be a dedicated LAN or WAN connection

  • Other business applications and data which can be:

    • Custom developed systems (old and new)

    • Enterprise Resource Planning systems and other packaged applications, such as SAP, BAAN and PeopleSoft

    • Databases

It is typically based on the patterns described in Chapter 2, "Fundamental concepts in Process Integration" on page 17.

3.1.4 Putting the pattern to use

This is probably one of the most common patterns and it can be observed in any solution where an application needs to integrate with other applications, legacy systems, and databases. Examples include:

  • An electronics retailer/wholesaler, ABC Electronics from our sample scenario, needs to integrate their retail ordering process with their inventory management system.

  • A telecommunications company needs to integrate their online sales systems and their core provisioning systems to improve efficiency and customer service.

3.1.5 Application Integration solution requirements

Choosing the right Application Integration pattern can only be done in the context of specific enterprise requirements. These requirements encompass not only the specific application integration to be deployed, but also the enterprise's IT infrastructure and technology preferences. This section details considerations to be made and questions to ask in determining which Application Integration pattern best fulfills your enterprise needs.

Request for information versus request for processing

Is the integrated solution for informational access only or is it intended to integrate requests for processing? The Process-focused Application Integration patterns are concerned with integration of the functional flow of processing between applications. The Data-focused Application Integration patterns are concerned with integration of the information used by applications.

Foreground versus 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 (or real-time) process is a user retrieving a price quote for the purchase of product, whereas a background (or batch) 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 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 integrated 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.

Process re-engineering

Is there a need to re-engineer business processes or extend an existing business process? Most legacy business processes are locked in the applications themselves. Business Process Management (BPM) is performed by the existing applications. Sometimes the EAI effort merely is trying to better integrate functional operations of a disconnected, narrow (or "stovepipe") business process. Other endeavors are more ambitious, incorporating 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? The portfolio 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; others are completely homegrown custom applications. Other environments may be a mixture of pre-packaged applications working along with homegrown ones.

Your survey of applications will detail several key points about the enterprise environment:

  • Can the application interfaces be extended as part of the integration activity? Homegrown applications may have standardized interfaces or be extensible to implement standards. Interfaces into pre-packaged applications typically can only be standardized through implementation of sophisticated adapters.

  • 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?

  • How many applications are 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 or more different applications. Integration of two applications has different pattern requirements than integration of 100 applications.

Invasive versus non-invasive

What is the level of independence between the 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 affects the application adapter, it can also affect the integration hub processing and even require changes to the partner application. The further across the application 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 versus tight coupling) or a black box versus 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 as possible 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 achievable 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 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 application integration design.

The different types of Enterprise Architectures dictate different Application Integration patterns. For instance, Self-Service 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

3.1.6 What's next

If you have determined that the Application Integration pattern is appropriate for use in your solution, the next step is to select an Application pattern.

If the Application Integration pattern is not appropriate for your development efforts, review the Business patterns to determine which pattern best addresses your e-business needs.



 < Day Day Up > 



Patterns Direct Connections for Intra- And Inter-Enterprise. Direct Connections for Intra- And Inter-Enterprise (IBM Redbook) (Paperback)
Patterns Direct Connections for Intra- And Inter-Enterprise. Direct Connections for Intra- And Inter-Enterprise (IBM Redbook) (Paperback)
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 139

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net