Toward an on demand service-oriented architecture

IBM Systems Journal,  March, 2005  by C.H. Crawford,  G.P. Bate,  L. Cherbakov,  K. Holley,  C. Tsocanos

• E-mail
• Print
• Link

2. Add dependent medical coverage.

3. Add beneficiary to 401(k) retirement plan.

4. Open 529 account (college savings plan).

5. Run advice engine (using High Performance Computing [HPC] analytics) to suggest an investment strategy to achieve 529 goals.

6. Create payroll deduction to fund investment options for 529 plan and to adjust options for 401 (k) plan.

7. Increase term life.

8. Run advice engine to suggest funding mechanism for term life, with minimum tax implications.

9. Suggest selling shares to fund term life increase and execute sell.

10. Run portfolio analysis including pension-plan estimate with various fund accounts to meet new long-term financial objectives.

11. Suggest rebalancing of portfolio and execute rebalance.

This overall process is shown in Figure 1. Black arrows indicate the functions outlined above that are initiated from the customer's Human Resource's (HR) site. Red arrows indicate the functions that are initiated from the company's Web site. Blue arrows indicate functions that are now initiated by a phone call to an advisor and are asynchronous in nature. The light blue arrow indicates a third-party interaction.

[FIGURE 1 OMITTED]

The current implementation of this process consists of applications and resources distributed across not only different departments (for example, health benefits and investment benefits), but also resources outside the company (external investment funds). From an application point of view, these steps include stateful and stateless transactions, stateless analysis engines, and stateful data interactions. (Stateful implies the capability to maintain last-known or current status; stateless does not.) Furthermore, the process is currently supported by on-line subprocesses and off-line batch analysis and advice engines driven by asynchronous requests, including phone center requests. These flows are illustrated in Figure 1.

The current process implementation requires customers to follow a list of action items, connect to different Web sites or electronic forms, make phone calls, wait for data to be generated by various applications, and share data among the different applications. In our scenario, the client company has indicated that the current process results in a significant level of customer dissatisfaction as well as a number of customer requests that cannot be served by existing resources. This threatens competitiveness in the marketplace, and therefore the client is in danger of losing business in a highly competitive market.

The financial service company's primary goal is to find a low-cost solution to improve customer satisfaction and increase request throughput. The resulting higher efficiency from the improved process would in turn generate higher volumes of completed requests and drive additional business as more customers are served. More specifically, we can define the objectives of business process transformation for the Life Change scenario to be:

1. Use of a single identity for customers for both internal and external interactions