Portal Integration

 

Integration Patterns

Start | Previous | Next

Contents

Context

Problem

Forces

Solution

Example

Resulting Context

Context

Many business functions require users to access information that resides in multiple disparate systems. For example, a customer might call a service representative to place a new order. However, before the service representative accepts a new order, he or she has to verify the customer's payment history in the accounting system to ensure that the customer is in good standing. Switching between systems makes the service representative's work tedious and error-prone.

Problem

How can users efficiently perform tasks that require access to information that resides in multiple disparate systems?

Forces

To solve this problem, you need to consider the following forces:

• It is still very common for an end user to have to manually copy information from one system to another. This type of integration is often referred to humorously as "swivel chair integration" because the user has to access multiple systems, often from multiple terminal screens. The user views the information on one screen and then swivels to another screen to enter data based on the information from the first screen. Obviously, this type of manual integration is very inefficient and error prone.
• Process Integration can automate tasks that combine data and functions from multiple systems, thereby alleviating the need for users to access multiple systems directly. However, Process Integration requires a good understanding of the business process so that the business process can be accurately represented in a process model. This is often not the case because users make improvised decisions based on the information they see.
• Entity Aggregation allows multiple systems to share data, which enables the user to access all required information from a single point. However, Entity Aggregation is often impossible or not economical due to strong semantic dissonance between the individual systems and lack of a common vocabulary between systems and people.
• Reading data from an application is generally simpler and less risky than updating information. This is especially true in cases such as Data Integration, which directly accesses application data and bypasses the business and validation logic.

Solution

Create a portal application that displays the information retrieved from multiple applications in a unified user interface. The user can then perform the required tasks based on the information displayed in this portal.

Figure 1. Portal Integration

Portal Integration is a comparatively simple form of integration. It is popular because it is typically much easier to implement and less intrusive than more sophisticated types of integration, such as Process Integration. With Portal Integration, the business process that describes the sequence of tasks does not have to be represented in a precise process model, but instead resides in the user's head. This enables the end user to compensate for mismatches in semantics between the individual systems and to make a case-by-case decision. This approach is naturally less efficient than Process Integration, but it gives the user flexibility and it is typically much faster to implement. In many cases, Portal Integration can be used as an intermediate solution until business processes are better understood and can be incorporated into a process model, thus enabling the transition to Process Integration.

The portal engine shown in Figure 1 interacts with the individual applications using Data Integration, Functional Integration, or Presentation Integration. Because the primary purpose of the portal is the display of information, Portal Integration works particularly well with simpler forms of connectivity, such as Data Integration or Presentation Integration.

Portal Integration comes in a variety of flavors from very simple to fairly complex. The following list categorizes the different variants:

• Display-only. The simplest form of Portal Integration simply displays data in different areas of the screen. Information from each application is mapped to a rectangular area of the screen, also referred to as a pane. This display allows the user to view information retrieved from multiple applications on a single screen. No other functionality is provided.
• Simple post-processing. Instead of presenting the data received from each individual system, many portals add simple rules that help the user make decisions. For example, if the billing system reports that a customer payment is overdue, the portal would list this as an exception in bold red letters at the top of the screen instead of showing the history of all payments received. This type of functionality helps turn raw data into useful information for the user.
• Single application interaction. This variant displays data in different areas of the screen, but it also allows the user to issue commands to one system at a time. This extra functionality enables the user to view information from multiple systems and use the resulting data to perform a business function that is limited to a single system.
• Cross-pane interactivity. In many cases, the information to be displayed in one pane depends on a user selection in another pane. For example, a list of customers might be retrieved from the customer relationship management (CRM) system. When the user selects a customer's name from the list, the portal retrieves the selected customer's payment history from the billing system and displays it in a separate pane. To automate these steps, basic interaction between different portal panes is required. This type of portal speeds up the user's tasks without requiring full integration between systems. However, this type of portal does require the availability of common keys, such as a customer identifier (ID), that function across multiple systems. With this type of portal, the development of the interaction is often difficult to test and reuse.

The Portal Integration solution relies on interplay between the solution components that are described in Table 1.

Table 1: Portal Integration Solution Components

Component	Responsibilities	Collaborators
Portal engine	- Extract information from existing applications - Render information into a unified user interface	Applications
Application	Host relevant business data	None

 

Example

Many customer service functions require access to a range of customer data. For example, a customer may call to place a new order, check whether a payment has been received, and change his or her phone number. Often, this type of information is stored in many different systems, such as the order management system, the billing system, or the complaint system. Giving a customer service representative a unified view of the various records for a customer can be enormously helpful in providing efficient and effective service to the customer. A similar or reduced version of the portal could also be presented directly to the consumer on the company's Web site.

Resulting Context

Portal Integration results in the following benefits and liabilities:

Benefits

• Non-intrusiveness. Because its primary function is the retrieval and display of information, Portal Integration can typically be added to existing systems without disturbing the existing functionality. This is particularly true if Portal Integration uses Data Integration for the retrieval of data from the individual systems.
• Speed of implementation. Adding a portal to existing applications can often be accomplished in a matter of days or weeks, whereas a full integration of the systems could take many months. Many vendors offer Portal Integration platforms in combination with a suite of prefabricated panes that integrate with many popular enterprise applications and data sources.
• Flexibility. Because the user makes the decisions, Portal Integration can be used in situations where business rules are not well understood or not agreed upon.

Liabilities

• Inefficient. Portal integration is best suited to the automation of simple tasks and processes because it still requires manual interaction by the user. For example, because most portals allow the user to interact with only one application at a time, the user might have to perform multiple manual actions in sequence to complete a complex business function. This makes Portal Integration unsuitable for high-volume applications. In these situations, Process Integration is generally a better solution because the sequence of steps can be encoded in a process model and run automatically by the process manager.
• Error-prone. When using Portal Integration, the user makes business decisions and determines the sequence of tasks to be performed. While this provides flexibility, it also introduces the risk of human error. Therefore, Portal Integration is not well suited to integrations that require strict repetition of a defined business process. Process Integration is generally a better choice in those scenarios.

Start | Previous | Next