Brought to you by Adobe
- Adobe® Acrobat® 9 Pro Extended - a complete PDF solution
- Create interactive presentations
- Bring people & ideas together
- Communicate with impact
Featured White Papers
- ERP end-user business productivity: A field study of SAP and Microsoft (Microsoft)
- 5 Strategies for Making Sales the Engine for Growth (AchieveGlobal)
- Enterprise PBX buyer's guide (VoIP-News)
Technology Industry
Industry: Email Alert RSS FeedToward an on demand service-oriented architecture
IBM Systems Journal, March, 2005 by C.H. Crawford, G.P. Bate, L. Cherbakov, K. Holley, C. Tsocanos
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:
