This article is based on the book SOA Patterns (http://www.manning.com/rotem) scheduled to print February 2009. This article is courtesy of Manning Publications (http://www.manning.com). The ebook is available and sold exclusively through Manning Publications.

Workflodize Pattern
For one of the projects I worked on, we had to build a sales support system for a mobile operator. It would probably not come as a surprise to you if I told you that the competition between mobile operators is very fierce. The result of this competition is that the operator's marketing departments burn the midnight oil trying to come up with new usage plans and bundles to increase their sales. You know, plans such as friends and family, PTT for closed groups, reduced rates for international calls, and bundles for 3.5G usage. For this particular operator, new usage plans were created several times a week. The billing system was based on Amdocs, and SAP systems took their time to be adjusted to new plans. However, since marketing campaigns were usually initiated by the marketing department regardless of the IT readiness, there was a burning need to be able to support new sales procedures ASAP.

Changing business needs is something that is common to many if not all businesses - it might not be in the same intensity as described earlier, but it is there. We need to find a way to enable our services to cope with these changing processes.

The Problem
How can we increase the service's adaptability to changing business processes?

The most obvious option is to just wait for the change requests, and develop the code and update the services every time there's a requirement change. This poses several problems. First, you need a full development cycle to make the change happen .Second, code changes means big portions of the system need to be retested - think of questions like "does the new change affect the plan we added yesterday?"; "What about the one we added last week that's similar?" etc. More development and testers immediately translates to longer time-to-market. For our example, it means that making the new plan operational will take a few weeks, which, in turn, means management would not very happy. Which means your job just went down a notch or two. This is clearly not the way to go.

A better approach would be to try to isolate the more stable parts of the application from the ones that constantly change. For our sample scenario the demographic data like getting the customer's name, address, etc., is probably the same regardless of the plan we want to sell. Nevertheless writing the choreography for the stable logic is still a daunting and error-prone task. Maybe we can do even better than that...

The Solution
Introduce a workflow engine within the service to handle the volatile and changing processes and orchestrate the stable logic

The Workflodize Pattern as depicted in Figure 9 is based on adding a Workflow Engine to the service to drive business processes. The Workflow engine hosts instances of a workflow. The nominal case is a workflow per request type; however, workflows can also be more complex to handle long-running processes and have several entry points, where requests or data arrives from an external service.