Self-Service: Select Application pattern

Please select either the Application pattern heading or the picture of the Application pattern most relevant to your design.

The specific business functionality supported by applications that automate the Self-Service business pattern varies from one industry to another. Yet, a survey of such applications in multiple industries reveals certain common approaches that have been successful. Such successful approaches are captured in the following seven Application patterns. Additionally, information is presented for use as criteria by which to evaluate these Application patterns for use in your own development efforts. Keep in mind that the Application patterns are logical constructs that can be physically implemented in different ways. For example, an Application pattern diagrammed with three logical tiers might be implemented as two, three, or four physical tiers.

The Stand-Alone Single Channel application pattern provides a structure for applications that have no current need for integration with other systems and need only focus on one delivery channel. While this Application pattern can be used to implement any one of the delivery channels, the following discussion focuses primarily on the Web delivery channel.

Business and IT Drivers

• Time to market
• Minimize application complexity

Time-to-market is often the primary business driver for choosing this Application pattern. This approach can be used to extend quickly beyond web publishing into providing self-service capabilities on the web.

There should be no immediate business requirements for integration with back end applications. Although Web applications typically need to integrate with back end applications, to achieve quick time-to-market and to minimize application complexity such integration can be postponed to a later stage of development. Manual processes can instead be used to synchronize data between Web applications and back end applications.

This is the ideal Application pattern to choose if the current focus is only on supporting a single delivery channel. In other words there is no current need for seamless integration between various delivery channels such as Web, voice recognition units, kiosks, and call center applications.

Solution

Select this Application pattern

As shown in the figure above, this is the simplest of all the Application patterns that automates the Self-Service business pattern. In this Application pattern, the application is divided into two logical tiers and presentation logic is separated from business logic. The primary reason for this separation is to ensure the maintainability of the developed application and to support thin clients.

• The presentation tier is responsible for all the user interface-related logic, including data formatting and screen navigation.
• The application tier is responsible for implementing business logic and for accessing data from a local database.

The requester interaction between the presentation tier and application tier is synchronous, which means that any request coming from the user interface directly invokes business logic on the application tier. After the execution of the business logic, control is passed back to the presentation tier, which uses the returned results to update the user interface.

During the next level of elaboration, these tiers may be further subdivided into more granular functional components. For example, the presentation tier may be partitioned into user affinity and process affinity pieces. In a typical Web implementation, the user affinity piece can represent the presentation logic that runs the user interface on the client device. For example the JavaScript that implements the screen navigation and the simple input validation is downloaded and runs on the browser client. The process affinity piece may represent the dynamic page creation aspect of the presentation logic that runs on the server. For example, Java Server Pages (JSP) are executed on the server and dynamically generate the HTML pages. Web application servers, like IBM WebSphere Application Server, are often used to implement this Application pattern.

Guidelines for use

Some application server vendors can support only the Stand-Alone Single Channel application pattern. If you anticipate a need in the future to integrate your Web applications with back end applications, you must choose an application server that provides a clear path for such enhancements.

Some application server vendors do not promote a clear separation of presentation logic and business logic. If you choose such a vendor, you will increase the total cost of ownership because this lack of clear separation reduces the maintainability of the application. When presentation and business logic are intermingled, any changes to presentation logic can impact the business logic, and vice versa, resulting in a significant rewrite of the application. Separation of these logical tiers is especially important in e-business applications where the user experience and the look and feel of the site need to be constantly enhanced to leverage emerging technologies and attract and retain site users. New business functions have to be constantly added to the site to meet customer demands and to avoid losing customers to competition. This separation also allows for quick adoption of new types of user interfaces, such as emerging wireless Personal Digital Appliances (PDAs) and net appliances.

Benefits

• This Application pattern is the ideal target architecture for those applications that have no current or future need for backend application integration.
• This Application pattern uses thin clients such as browser-based HTML clients. The majority of the presentation and business logic runs on the server. One can scale the application either by increasing the power of the server machine or by spreading the application logic across many servers. This achieves scalability without having to change the Application pattern.
• This Application pattern uses a connection-less protocol such as HTTP for communication between the user interface clients (for example, browsers) and pieces of the presentation tier that run on the server. This server side component of the presentation tier can maintain a limited number of connections to the application tier (which contains the business logic and accesses the data base) and pool these connections across multiple users. This strategy enables Web applications to scale to support tens of thousands of concurrently active users. In contrast, traditional client/server implementations use protocols that maintain a connection between the user interface clients and servers for every user. Maintaining these connections consumes significant resources such as memory and processing power on the server. Moreover, there is usually a limit to the maximum number of connections a server can maintain at a given time. As a result traditional client/server applications face severe scalability constraints in supporting thousands of concurrent users. This Application pattern overcomes the scalability problems of traditional client/server applications.

Limitations

• Since there is no back end application integration, the Web applications and related data are isolated from other enterprise systems. If many departments in the organization implement such disparate systems, each system might have mismatching data. Synchronizing this information manually is prone to errors and will reduce the overall organizational efficiency. As a result, the total cost of ownership will increase.
• When many departments implement and run disparate Stand-Alone Single Channel applications in an organization, systems management efforts could be duplicated across the organization.
• In addition, when many Stand-Alone Single Channel applications are run in one organization, business logic reuse also could be a challenge and as a result this increases the total cost of ownership.
• Since this Application pattern does not support integration across various channels such as the Web, call center applications, kiosks, voice recognition units, and so on, users might get different answers from different channels.

Putting the Application pattern to Use

A major insurance company wishes to extend their reach through a Web sales channel. Their existing infrastructure includes a telephone sales channel and back end policy, claims, and billing systems that are run in batch. It uses "green screen" terminals for online transactions. In the short term, modifications to the back end applications to make them available on a 24x7 basis are not possible.

The insurance company chooses to establish an online presence by providing services that do not require back end integration. These services include locating the nearest office, locating brokers and agents, and using financial calculators and insurance needs-analysis tools. To support this, the insurance firm chooses the Stand-Alone Single Channel application pattern because this pattern does not require back end integration.

The Directly Integrated Single Channel application pattern provides a structure for applications that need one or more point-to-point connections with back end applications but only need to focus on one delivery channel. This Application pattern can also be used to implement any one of the delivery channels. However in this chapter we focus primarily on the Web delivery channel.

Business and IT Drivers

• Improve the organizational efficiency
• Reduce the latency of business events
• Leverage existing skills
• Leverage legacy investment
• Back end application integration

The primary business driver for choosing this Application pattern is to reduce the latency of business events by providing real-time access to back end applications and data from Web applications.

The IT Driver for choosing this Application pattern is to leverage legacy investments and existing skills.

Solution

Select this Application pattern

As shown in the figure above, the Directly Integrated Single Channel application pattern extends the Stand-Alone Single Channel application pattern by using point-to-point connections to back end applications and databases. In this Application pattern, applications are divided into at least three different logical tiers: presentation, Web application, and back end application. These tiers make a logical three-tier architecture. In this Application pattern, data can reside on the second and third tiers.

• The presentation tier is responsible for all the presentation logic of the application.
• The Web application tier is responsible for implementing some of the business logic and for accessing back end application logic and data. Usually new data, such as user profiling information, resides on this tier.
• The backend application tier can represent a new application, a modified existing application, or an unmodified existing application . The data of existing systems resides on this tier and is most likely accessible only through the existing back end application. It is important to note that multiple back end applications can be accessed by the same Web application tier.

The requester interaction between the first and second tier is synchronous. The requester interaction between the Web application tier and the back end application tier can be either synchronous or asynchronous. The chosen requester interaction style between these tiers depends on the characteristics and capabilities of the back end system.

Note that a synchronous (or blocking) request at the Application pattern level can be carried over either a synchronous or an asynchronous communications protocol at the Runtime pattern level.

When integrating with an existing batch system, the requester interaction has to be asynchronous. Integration with back end transactional systems and database systems, however, can be synchronous. Once again such connections are point-to-point so that, if the interface or the behavior of the backend system changes, it will directly impact the behavior of the Web application tier. Web application servers like WebSphere Application Server and message-oriented middleware like MQSeries are often used to implement this Application pattern.

Guidelines for use

The guidelines for the separation of presentation logic and business logic that are documented under the Stand-Alone Single Channel application pattern apply here as well. In addition, the following apply:

• In this Application pattern, corporate data can reside in more than one tier and be distributed physically. As a result, systems management complexity can increase. Because of this, care must be taken to ensure that the deployment of this application minimizes such systems management complexities.
• Normally, different IT organizations are responsible for developing Web applications and maintaining back end applications. Under such a scenario, development might be difficult to coordinate, especially if the interfaces between the Web and back end applications are not properly defined and documented. Because of this, it is important to clearly define such interfaces in advance.

Benefits

In addition to providing all the benefits of the Stand-Alone Single Channel, this Application pattern offers the following:

• It works with applications that have simple integration requirements with only a few back end applications.
• By avoiding manual synchronization of data between back end applications and the Web application, this Application pattern overcomes the related shortcomings of the Stand-Alone Single Channel application pattern. Because of this, it increases the organizational efficiency and reduces the latency of business events by providing real-time access to business data and business logic.
• Direct access to backend applications reduces the duplication of business logic across multiple tiers. As a result, changes to business logic can be made in one tier rather than in multiple applications.

Limitations

• This Application pattern focuses on a single channel. There is no integration between various delivery channels. Consequently, users may get different answers from different channels.
• Point-to-point interfaces between the web applications and backend applications make this Application pattern inflexible especially when there is a need for accessing multiple backend applications from multiple web applications. As a result changes to one application can have knock-on effects on other applications. Under such circumstances one should consider more advanced Application patterns, such as the Router, Decomposition, or Agent application patterns, which exploit a hub-and-spoke architecture between the second and the third tier.

Putting the Application pattern to Use

A major insurance company wishes to extend their reach to a web sales channel. Their existing infrastructure includes a telephone sales channel and backend policy processing, claims, and billing systems that are run in batch. The quoting engine, however, can run either online or in batch. The engine uses "green screen" terminals for online transactions.

This company has already established an online presence by providing services that do not require backend integration. These services include locating the nearest office, broker, or agent, and using financial calculators and insurance needs analysis tools. In doing so, it used the Stand-Alone Single Channel application pattern to achieve quick implementation.

Now the company has realized that manually synchronizing the broker database on the web application tier with the backend database is both inefficient and expensive, especially since the company recruits many new brokers every month. In addition, this insurance company wants to provide online quoting services on the web. The underlying quoting rules are complex hence they decide not to duplicate this business logic in multiple tiers.

To meet these requirements, the company chooses to extend the existing applications using the Directly Integrated Single Channel application pattern. They will use an asynchronous batched update to replace the manual update between the web application tier and the backend broker database. For the quoting requirements, the company chooses to use a synchronous requester interaction between the web application and the backend-quoting engine.

The As-Is Host application pattern provides wider Intranet access to existing host applications. These applications may previously have only been available to employees through green screen devices or PCs with emulators.

Business and IT Drivers

• Time to market
• Improve organizational efficiency
• Minimize total cost of ownership (TCO)
• Leverage existing skills
• Leverage legacy investment
• Back end application integration

Time to market is often the primary business driver for choosing the As-Is Host application pattern. This approach can be used to quickly implement a green screen replacement policy so that user can be offered additional browser-based services.

The primary IT driver for choosing this Application pattern is to minimize the total cost of ownership by providing browser-based access to existing green screen back end applications without rewriting or re-engineering them. This reduces the software distribution cost by eliminating the need for distributing host terminal emulators for 3270/5250/ASCII devices.

Solution

As shown in the figure above, the As-Is Host application pattern has two logical tiers: the presentation tier and the host application tier:

• The empty presentation tier shown above represents an off-the-shelf middleware component such as WebSphere® Host on Demand® that can be used to provide browser-based access to host applications. The browser-based user interface can be based on either Java® applets or HTML. This tier does not include any custom built code.
• The host application tier represents the existing back end application.

When this Application pattern is used, the existing back end application remains as is. Even though the delivery mechanism used is browser-based, the presentation continues to look and behave the same as existing green screens. It uses a synchronous requester interaction between the presentation tier and the existing back end application tier. Both presentation and business logic continue to run inside the existing host application.

Guidelines for Use

Green screen application usage requires a significant amount of training. Consequently, this presentation style is normally suited for employees (as opposed to external users) and should only be chosen for deploying green screen applications through the Intranet to these users. In some special cases, this same strategy can be used to deploy green screen applications to external users such as business partners.

Benefits

Using the As-Is Host application pattern, there is no need to modify or re-engineer existing applications. Because of this, deployment risk is minimal.

Limitations

Under this scenario, the user interface continues to look and function the same as existing the existing green screen interface. Because of this, the presentation does not take advantage of the user-friendly features of the browser interface.

Putting the Application pattern to Use

An airline company uses green screen applications using 3270 terminals for ticketing and check-in procedures. The company is quite satisfied with the application as it is, and has no current plans to change the user interface. However, they would like to move away from 3270 terminals in order to provide e-mail and Internet access to their employees using a network computer.

Using the As-Is Host application pattern, the airline company can choose to deploy the existing 3270 green screen applications on network computer terminals or desktop PCs. Products such as IBM Host On Demand could be used for this implementation.

Implementation

The As-Is Host application pattern is not documented with additional runtime patterns or product mappings on this Web site. This solution design can be implemented by using an off the shelf middleware product such as WebSphere Host on Demand as discussed in the "Solution" section above. Further practical implementations of products supporting this Application pattern can be found in IBM redbooks: IBM Web-to-Host Integration Solutions (SG24-5237) and Using WebSphere Host Access Transformation Services V5 (SG24-6099).

The Customized Presentation to Host application pattern can be used to provide a more user-friendly interface to existing host applications without changing the underlying application.

Business and IT Drivers

• Time to market
• Improve organizational efficiency
• Minimize application complexity
• Minimize total cost of ownership (TCO)
• Leverage existing skills
• Leverage legacy investment
• Back end application integration

The primary business driver for choosing the Customized Presentation to Host application pattern is to enhance the usability of existing host application without rewriting or re-engineering them. These presentation enhancements can take advantage of the user-friendly features provided by graphical user interfaces such as HTML browsers, Java applets, and Java applications. They are preferable to the cumbersome green screen user interfaces. such a move can not only increase the overall productivity of users of the system, but also reduce the training costs associated with training new users of the system.

The key IT driver is to extend the availability of an existing application to a wider audience without incurring significant application development costs.

Solution

As shown in the figure above, the Customized Presentation to Host application pattern implements a thin client that provides a customized presentation to an existing host application while keeping the back end system as is. It has two logical tiers: the customized presentation tier and the host application tier.

• The customized presentation tier accesses the host application and presents the results in a rich GUI format.
• The host application tier represents the existing back end application.

This Application pattern uses a synchronous requester interaction between its two tiers. The client portion of the presentation logic on the browser presents a GUI-rich input screen. This GUI captures the user input and sends it to the server portion of the presentation tier, which converts the GUI input to a green screen input and synchronously communicates with the host application. Subsequently, the results received from the host application are converted to a GUI format and sent to the client for display.

A variation on this Application pattern supports access to the business logic and data on multiple back end applications so that a combined view can be presented to the user.

As shown in later product mappings, middleware products that support this Application pattern include IBM Host Publisher ® and IBM CICS Gateway for Java®.

Guidelines for Use

The increased ease of use and the universal accessibility of the application through the Web channel can result in more connections than the host can handle. Care must be taken to ensure that the physical implementation does not result in an unsupportable number of connections from the Web. Alternatively, however, one could increase the capacity of the host application.

Benefits

The Customized Presentation to Host application pattern provides all the benefits of the As-Is Host application pattern including minimal deployment risk and reduced software distribution cost. In addition, it offers the following:

• This approach increases systems usability by taking advantage of the user-friendly features provided by GUI interfaces. This ease of use can increase the overall productivity of users and reduce cost of training new users.

Limitations

• The primary focus of this Application pattern is on customizing the presentation logic without making any changes to the existing back end application. If the customized presentation is targeted towards a new set of users, such as customers and business partners, this new set of users may have requirements that cannot be met by the existing back end application. Because of this, the functionality offered by this pattern is limited to the current capabilities of the back end system.
• There is a tight coupling between the customized presentation logic and host application. As a result, any changes to the host application can require changes to the presentation logic. This increases the maintenance requirements of the system.
• The availability of the Web interface is limited by the availability of the existing host application. The same arguments hold true about the performance and the scalability of the system. Businesses usually can impose these limitations on internal users of the system. However, such limitations cannot be enforced on external users such as customers and business partners.

Where these limitations apply, more advanced Application patterns discussed later should be considered.

Putting the Application pattern to Use

Bank tellers of a regional bank currently use a green screen CICS application to access account information. Training new users to use this system takes a long time. The bank faces a huge turnover of teller employees and incurs huge initial systems training costs. In order to reduce this training cost and increase the productivity of new teller employees, the bank wants to develop a user-friendly GUI interface.

To meet this goal of providing a customized presentation to teller users of the accounts management system, the bank chooses the Customized Presentation to Host application pattern. The back end applications functi on and perform very well. Because of this, there is no need to rewrite or re-engineer the host system. Under this scenario, the bank uses IBM's CICS Gateway for Java product and deploys a Java applet-based GUI. Alternatively, the bank could have deployed the IBM Host Publisher where access to back end applications other than CICS is required.

Implementation

The Customized Presentation to Host application pattern is not documented with additional runtime patterns or product mappings on this Web site. This solution design can be implemented by using an off the shelf middleware product such as IBM Host Publisher® or IBM CICS Gateway for Java® as discussed in the "Solution" section above. Further practical implementations of products supporting this Application pattern can be found in the IBM redbooks: IBM Web-to-Host Integration Solutions (SG24-5237) and Using WebSphere Host Access Transformation Services V5 (SG24-6099).

The Router application pattern provides a structure for applications that require the intelligent routing of requests from multiple delivery channels to one of multiple back end applications.

Business and IT Drivers

• Reduce the latency of business events
• Easy to adapt during mergers and acquisitions
• Integration across multiple delivery channels
• Minimize total cost of ownership (TCO)
• Leverage existing skills
• Leverage legacy investment
• Back end application integration
• Minimize enterprise complexity
• Maintainability
• Scalability

The primary business driver for choosing the Router application pattern is to support seamless integration across multiple delivery channels. In this digital economy, users demand universal access to information. To satisfy this demand, many corporations support multiple delivery channels including the Internet, voice recognition units, kiosks, call center applications, and so on. Users expect to retrieve the same information irrespective of the delivery channel they use to access the information. For example, it is important for a discount brokerage firm to ensure that users can retrieve trade execution status consistently either through a Web site or through a voice recognition unit. At the same time, these organizations have multiple back end applications. For example, due to different tax requirements, discount brokerage firms often maintain IRA and regular investment accounts on different back end applications. Because of this, many channels have a need to access the information from multiple back end applications.

Applications, over a period of time, evolve either to take advantage of new technological breakthroughs or to accommodate a changing business environment. Ideally such changes to one application should be isolated from another. In other words, if a back end application is replaced with a new system to take advantage of a new technology, that replacement should not result in significant changes to all the delivery channels that access that back end applications. At the same time a business decision to support a new delivery channel such as wireless PDAs should not require major changes to back end applications. such extensibility is especially important for organizations that are in a highly volatile business environment and have plans for mergers and acquisitions. The Router application is ideally suited for such organizations.

The primary IT driver for choosing this Application pattern is to minimize enterprise wide complexity and reduce the total cost of ownership by using a hub-and-spoke architecture instead of a point-to-point architecture between delivery channels and back end applications

Solution

Select this Application pattern

As shown in the figure above, the Router application pattern is divided into at least three logical tiers: presentation, router, and back end application.

• Unlike the previous Self-Service Application patterns, the presentation tiers of this Application pattern can support many different presentation styles, including the Internet, call centers, kiosks, and voice recognition units.
• The router tier receives requests from multiple presentation components and intelligently routes them to the appropriate back end transactions. In doing so, this tier may use a read-only database to look up routing rules. In addition, the router may be responsible for message transformation, protocol conversion, the management of different levels of security, and session concentration. In most cases the router tier implements minimal business logic. This routing capability can also be used for routing requests from one of the back end systems to the other.
• The majority of the business logic for this Application pattern is concentrated in the back end application tier.

A router providing protocol conversion can isolate back end transactions from the details of delivery channel specific protocols. For example, the Internet application would typically use HTTP for communication between the browser and the server-side portion of the presentation tier. This tier, in turn, might use RMI or IIOP to communicate with the router. In contrast, call center applications might use RMI or IIOP to send requests directly to the router. The router tier converts these protocol specific requests into protocol independent requests before invoking the back end transactions. This approach enables future support of new types of delivery channels, such as wireless PDAs, without making changes to the back end applications.

Different delivery channels require different levels of security. Call center application users are usually allowed to see certain details about customer accounts that are not shown to customers when they access their accounts through, for instance, the self-service Web channel. These different levels of security are tightly coupled with the requirements of the delivery channel. Because of this, the back end application should be isolated from these details. The router tier is ideally suited for making such security decisions.

In order to achieve high scalability and superior performance, session management and session concentration can be done on the router tier. The router tier is thus responsible for establishing a few back end connections and pooling them for thousands of users originating from multiple delivery channels, when the backend systems security capabilities permit it.

The requester interaction between the presentation and router tier is synchronous, as is the requester interaction between the router tier and the backend application. As a result, if the back end system is not available, the business function supported by that back end application would be unavailable across all delivery channels.

Bear in mind that a synchronous (or blocking) request at the Application pattern level can be carried over either a synchronous or an asynchronous communications protocol at the Runtime pattern level.

In providing the capabilities outlined above, this Application pattern uses elements of the Access Integration and Application Integration patterns described elsewhere in this Web site. For example, in supporting multiple delivery channels this Application pattern could use the Device Support Services application pattern for Access Integration. Similarly the Router tier uses the integration techniques outlined by the Application Integration::Router application pattern.

As described later in the product mapping portion of this solution design, Web application servers like WebSphere Application Server and message brokers like MQSeries Integrator are often used to implement this Application pattern.

Guidelines for Use

The availability, scalability, and performance of the delivery channels in this Application pattern are heavily dependent on the availability, scalability, and performance of the back end applications. Because of this, robust transaction processing systems should be used to implement the back end applications. This Application pattern can be used to Web-enable either an existing or a new transaction processing system.

While developing new back end applications or changing existing ones, transactions should be defined to be channel-independent and reusable. This will make it easier to quickly extend such transactions to newer channels such as wireless PDA devices.

Benefits

• By using routers to manage session concentration and robust transaction processing systems for implementing business logic, this Application pattern delivers high scalability, and superior performance. This is often the target architecture for most of the current high-volume e-business sites.
• This Application pattern isolates back end implementation details from the delivery channels and the delivery channel implementation details from back end applications. This loosely coupled architecture makes it easy to change, replace or add back end applications and delivery channels without heavily affecting other applications in the architecture.
• This loosely coupled architecture also increases maintainability and reduces the total cost of ownership.
• It uses the same back end transactions across multiple delivery channels, which avoids duplication of the same business logic on multiple systems. As a result, changes to business logic can be made in one system. This increases the maintainability of the overall system.

Limitations

• The availability of certain business functions is heavily dependent on the availability of the back end applications. Currently many organizations have transaction processing systems that are only available for a limited amount of time every day. During the rest of the time, they are brought down for batch processing, backup, and maintenance activities. Such systems will have to be enhanced for 24x7 availability to support delivery channels offering Self-Service capabilities on the web. These enhancements to existing systems can be expensive and time consuming.
• The focus is primarily on providing access to back end applications from multiple delivery channels. Most back end applications are product-specific and the Router application pattern does not address how to move beyond a product-specific view and into a holistic customer-centric view. Under such circumstances, one should consider more advanced Application patterns such as the Decomposition or Agent application pattern discussed below.

Putting the Application pattern to Use

A premier financial services company currently provides brokerage, mutual fund, banking, and credit card services to its customers. Obviously these lines of business activities are very different in nature and are supported by different back end applications. Delivery channels operated by the company include Internet self-service, kiosks, voice recognition units, 24-hour call centers, and tellers at the branch offices.

All account information cannot be obtained from all channels. For example, the brokerage and mutual fund accounts can be accessed only through the Internet, voice recognition units, and call centers. On the other hand, the bank account information can be accessed only through kiosks (ATMs), voice recognition units, and tellers at the branch offices.

Currently, different channels use point-to-point connections with back end applications. Some of them also duplicate the data, which results in inconsistency of information across different channels at a given point in time. Fortunately, most of the product related back end applications are robust transaction processing systems that can be made available on a 24x7 basis.

The company wants to provide consistent access to all product information through all channels. In addition, the target architecture must be highly scalable, highly available, and support superior response time. To achieve these goals, the company chooses the Router application pattern.

The Decomposition application pattern extends the hub and spoke architecture provided by the Router application pattern. It decomposes a single, compound request from a client into several, simpler requests and intelligently routes them to multiple back end application. Typically the responses from these multiple backend applications are recomposed into a single response and sent back to the client.

Business and IT Drivers

• Improve organizational efficiency
• Reduce the latency of business events
• Easy to adapt during mergers and acquisitions
• Integration across multiple delivery channels
• Unified customer view across Lines of Businesses (LOB)
• Minimize total cost of ownership (TCO)
• Leverage existing skills
• Leverage legacy investment
• Back end application integration
• Minimize enterprise complexity
• Maintainability
• Scalability

All business and IT drivers listed under the Router application pattern apply here as well. Additional drivers relate to the fact that many organizations have back end applications that are focused on certain product lines. For example, insurance companies use different systems for supporting health insurance policies and life insurance policies. Such product specific silos evolved out of necessity since the business logic and data requirements of different products were vastly different. For the same reason, many companies plan to continue to use separate systems for separate product lines.

These same companies, however, want to provide a unified customer view when customers visit the self-service web sites or contact the call centers, rather than providing a fragmented, product-specific view. Similarly when changes are made to customer information in one system, they should be automatically reflected in other systems. In the above example of an insurance company that sells health insurance and life insurance policies, changes to address information should be automatically reflected in both the systems. Such features are increasingly important since customers often ask for a consolidated view of their multiple accounts.

Solution

Select this Application pattern

As shown in the figure above, this Application pattern is divided into three logical tiers: presentation, decomposition, and back end application.

• The presentation tier is responsible for all the user interface-related logic, including data formatting and screen navigation. It can support many different presentaion styles, including the Internet, call centers, kiosks, and voice recognition units.
• The decomposition tier supports most of the services provided by the router tier in the Router application pattern, including intelligent routing of requests, protocol conversion, security, and session concentration. In addition, it implements the intelligence to break down a single request received from a presentation client into several, simpler requests which it routes to multiple back end applications. In doing so, it typically uses a local Work In Progress (WIP) database to store routing, decomposition, and re-composition rules and to cache the results from multiple back end applications until a re-composition of the desired response has been generated. The Decomposition tier implements significantly more business logic than a Router tier. Such business logic focuses on providing a unified customer-centric view.
• The majority of the product and function specific business logic is still concentrated in the back end application tier. Some of these back end applications are highly available and scalable online transaction processing systems and others are batch applications.

The requester interaction between the presentation and decomposition tier is synchronous. The requester interaction between the decomposition tier and the backend application tier can be either synchronous or asynchronous.

A synchronous requester interaction is required when the presentation client expects an immediate answer, as in the case with the insurance company and its clients. In the insurance company example, a customer logs on to the Self-Service Web site and asks to view a consolidated bill. This request is decomposed into multiple synchronous requests that are targeted towards multiple product-specific billing systems. The decomposition tier waits for responses from these systems and combines the results and displays a consolidated billing view to the customer.

An asynchronous requester interaction between the decomposition tier and back end applications is appropriate when the presentation client does not expect an immediate response. For example, consider the customer who initiates an electronic transfer of funds to pay for his or her monthly bills using a Self-Service Web site. This request can be decomposed into two separate requests. The first request is targeted towards a confirmation engine that synch ronously provides a confirmation number to the customer for tracking purposes. At the same time, an asynchronous request can be sent to a batch system that transmits an electronic funds transfer request to a local bank using EDI technology.

A variation on this pattern includes caching on the second logical tier to avoid a high volume of accesses to the back end application. Another variation is to use fast asynchronous communications so that multiple parallel requests can be sent to the third tier in order to improve response times over serial requests.

As discussed in later product mappings for this Application pattern, advanced Web application servers like WebSphere Advanced Edition V5 integrate with the full range of message-oriented middleware (MOM) or a Process Manager like WBI Server Foundation to enable this application.

Considerations

There are a number of possible approaches to doing business request decomposition into multiple back-end transactions and recombining the responses into a single business response. These include:

• RYO (roll-your-own) programming that issues multiple asynchronous requests to back-end systems and combines the responses
• Using a process manager or a message broker plus a rules engine, possibly with a two-phase commit (2PC) or compensation mechanism

Guidelines for Use

All the guidelines documented under the Router application pattern apply here as well.

Benefits

This Application pattern provides all the benefits of the Router. Additionally,

• It provides a holistic customer-centric view rather than a fragmented product-centric view of information.
• Executing transactions in batch mode, when appropriate, provides several benefits including the ability to free up systems resources for more important tasks at hand. The Decomposition application pattern allows one to distinguish those transactions and use asynchronous mode for communication under such circumstances. This is particularly true for updates that need not be reflected into the appropriate data stores immediately.

Limitations

• The focus of this Application pattern is providing a consolidated customer-centric view of information. However, such information is only gathered whenever required and is discarded at the end of the transaction. Because of this, this Application pattern does not accumulate all the necessary information in an Operational Data Store (ODS) that can be used for mass customization of services and for cross-selling purposes.

Putting the Application pattern to Use

The premier financial services company that was considered under the Router application pattern wants to extend beyond providing consistent access to all product information through all delivery channels.

The company wants to provide a consolidated customer-centric view through all their channels rather than providing fragmented product specific views. For example, they want their customers to see a consolidated net worth across their brokerage, mutual fund, banking, and credit card accounts. They want to do so through all delivery channels, including Internet Self-Service, kiosks, voice recognition units, 24-hour call centers, and tellers at the branch offices. To achieve these goals they choose the Decomposition application pattern.

The Agent application pattern structures an application design that provides a unified customer-centric view that can be exploited for mass customization of services and for cross-selling purposes.

Business and IT Drivers

• Improve organizational efficiency
• Reduce the latency of business events
• Easy to adapt during mergers and acquisitions
• Integration across multiple delivery channels
• Unified customer view across Lines of Businesses (LOB)
• Support effective cross selling
• Mass customization
• Minimize total cost of ownership (TCO)
• Leverage existing skills
• Leverage legacy investment
• Back end application integration
• Minimize enterprise complexity
• Maintainability
• Scalability

All the business and IT drivers listed under the Decomposition application pattern apply to this Application pattern as well. In addition, it allows an organization to exploit a unified customer view for mass customization and for cross-selling purposes on an Internet Self-Service site.

As an example of these requirements, consider a telecommunications company that provides various services including local telephone access, long distance services, wireless services, and Internet access. To effectively cross-sell to customers, this company will require a consolidated view of all its relationships with each customer.

Solution

Select this Application pattern

As shown in the figure above, this Application pattern is divided into three logical tiers: presentation, agent, and back end application.

• The presentation tier of this Application pattern can support many different presentation styles, including the Internet, call centers, kiosks, and voice recognition units.
• The agent tier supports all the services provided by the decomposition tier in the previous Application pattern. It also dynamically builds a consolidated view of the user's relationship with the organization. It uses this to identify ways of mass customizing the organization's goods and services to fit this individual user. This results in pushing' an additional browser instance in front of the user so they can accept or reject the customized offer, before continuing with their original task.

In a variation on this design, because it is too slow or too expensive to dynamically gather the consolidated view, the organization may choose to implement an Operational Data Store (ODS) that maintains a consolidated Customer Information File (CIF). This CIF provides a current or near-real-time integrated view of the all the services subscribed by a customer aggregated from multiple operational systems. In addition, it stores additional demographic information about customers that has been collected through various sources. This information is used by the Customer Relationship Management (CRM) systems to enhance customer service.

Internet self-service sites can use specialized information to target certain services that match customer demographics. Call center applications can use this demographic information to prompt customer service representatives (CSR) with cross-selling scripts to solicit customers to subscribe to additional services. This cross-selling process can also be driven programmatically by an application (expert system) drawing conclusions from the customer data.

Another variation on this design allows the work in progress database held by the Agent tier to be also used to hold long running transaction data before committing such information to back end applications. Consider a mortgage company Web site that allows customers to submit a detailed application for a home mortgage loan online.

Users of this site can complete their loan application over several login sessions. In other words, the site allows customers to save their work in progress' loan application and complete the application at a later time. Such work in progress' applications are not submitted to the back end loan approval engine until customers have co mpleted the entire application. The agent tier can be effectively used to store such long running transactions before committing a completed transaction to the back end application.

The majority of the product and function-specific business logic is still concentrated in back end applications. Some of these back end applications are highly available and scalable online transaction processing systems and others are batch applications.

In providing the capabilities outlined above, this Application pattern may use techniques outlined in the Broker, Serial Process, and Parallel Process Application Integration patterns, and the Population and Two-way Synchronization Data Integration patterns. For the latest information on the Data Integration patterns, see Patterns: Information Aggregation and Data Integration with DB2 Information Integrator, SG24-7101.

Guidelines for Use

All the guidelines listed under the Decomposition application pattern apply to this Application pattern as well. In addition one must consider that, because of possible data inconsistencies between back end applications, it may be preferable to reconcile the data first using the ODS variation described above.

The accuracy of the insights drawn about the customer's likes and dislikes heavily depends on the quality of the CIF operational data store and the algorithms used for interpreting this data. Creation of such anoperational data store is both time consuming and complex. Once the data store has been created it needs to be kept up to date by synchronizing the information between the unified customer-centric view and the product-centric application data. In addition, demographic information has to be purchased from external sources on a regular basis and synchronized with the CRM operational data store. Care must be taken to clearly design business processes and technical infrastructure to create, update, and enhance the operational data store.

Benefits

The Agent application pattern provides all the benefits of the Decomposition application pattern. In addition, it enables mass customization of products and services provided by an enterprise to a market of one by using personalization techniques. Similar techniques are used for effective cross-selling purposes.

Limitations

By a using a serial or parallel decomposition approach, the Agent application pattern aims to minimize the complexity of meeting all the business and IT drivers. In spite of this attempt, the implementation of the Agent tier is complex. This is especially true because the implementation of an ODS is often complex and involves synchronization of information between the ODS and back end operational systems.

Putting the Application pattern to Use

A telecommunications company currently provides various services including local telephone access, long distance services, wireless services, and Internet access. The company has built this impressive portfolio of services primarily through mergers and acquisitions. As a result, the company has inherited a number of product-specific back end applications.

To keep up with the ever changing landscape of technology and to quickly capture market share in new areas such as wireless Internet access, telephony over Internet Protocol (IP), and broadband Internet access through cable, the company plans to continue to aggressively seek acquisition and merger partners. These trends suggest that more and more product specific systems will be acquired even in the future.

The overall success of their aggressive growth strategy depends on their ability to effectively cross-sell different services to all their customers. When a customer calls the call center to pay his or her bills, CSRs should be able to effectively solicit them to subscribe to additional services. Such solicitation must be done not only based on customers' current subscription levels, but also on the demographics of the customer. Similarly when a customer logs onto their Internet account, the welcome page must be personalized to reflect the interests of that customer.

To achieve the stated goals and cope with the continued existence of multiple product specific back end applications, the company chooses to implement the Agent application pattern. It chooses to build an operational data store that provides a consolidated customer-centric view. The agent tier will use this data for sophisticated personalization and cross-selling purposes. The use of an ODS has the additional advantage of providing the flexibility required for rapid integration during future mergers and acquisitions.