On CBS.com: A bride is murdered at her wedding
Find Articles in:
all
Business
Reference
Technology
News
Sports
Health
Autos
Arts
Home & Garden
advertisement
advertisement

Content provided in partnership with
Thomson / Gale

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

<< Page 1  Continued from page 7.  Previous | Next

Highly dynamic application environments that are built upon readily instantiated services require an on demand SOA infrastructure that can

* support the dynamic allocation of resources needed to instantiate the service

* measure the service level characteristics of the service, and

* sustain service level agreements within tolerance by adjusting the infrastructure using available resources.

Furthermore, both integration of the underlying resources with these services and the enablement of corresponding IT management systems must be accomplished through the use of open standards. Applying open standards allows companies to maximize the benefit of various vendor component solutions and to ensure that these components will work together.

We now proceed to the steps required to design an on demand SOA solution. These steps will focus on the concepts of business process and policy as well as application and IT infrastructure enablement. More specifically, we need to understand the business process in the following contexts:

1. Current workflow definition

2. Compliance with industry standards

3. Componentization of workflows

4. Parameterization of workflows

5. Policy definitions within the workflow

After we understand the business process within these contexts, we can proceed with application and IT infrastructure enablement. Indeed, one of the goals for our solution framework is that the business process and policy drive the application and IT-infrastructure implementation.

Process and policy definition

The first step in building a solution for the financial services company's Life Change scenario is to clearly articulate the goals of the business-process transformation. As discussed, these goals can be summarized as follows:

1. Increase customer satisfaction with a more uniform and seamless approach to the Life Change business process.

2. Increase the throughput of available request processing by leveraging existing resources and improving their utilization.

Overall, the combination of these two goals will result in the financial service company remaining competitive in the marketplace.

We described the Life Change process as a series of steps executed to build a complete business process, and we also alluded to the fact that this process could be thought of as a meta-service composed of a set of service components in a workflow pattern. That workflow is shown in Figure 2.

[FIGURE 2 OMITTED]

We now must define several overall process policies, which will in turn generate policies for each individual service. Let us assume that in order for the financial service company's implementation of the Life Change process to be competitive, the start-to-finish time for completion of a request must be less than 5 minutes. In addition, customers expect a 95 percent availability rate for the Life Change service (across all components), and are willing to pay more for increased availability or throughput. Finally, to reduce complexity the financial service company needs to present a single client facing portal for all services within the Life Change process. We can therefore set the following process policies: