Let's quickly cover some basics so the blog makes more sense.  

In a classic academic SOA scenario, your organization is made up of bunch of services. When you orchestrate them, you define their invocation sequence along with some other information in an xml file, which follows WS-BPEL specifications. You then deploy the process in a compliant process server. The server invokes the services turn by turn applying other rules and logic (e.g. stop the process if outcome of a service invocation is xyz) defined in the process.

In a top down scenario, you model your business process as a WS-BPEL compliant process, you define services that implement the tasks defined in the process, and you deploy the process in a compliant process server, which invokes the services to execute the tasks. 

This sounds simple on the surface but many architects don't realize that there is a performance overhead involved in having a process call different services - the overhead gets worse if the process is too fine grained.

 As can be seen from the figure above, the more 'boxes' you have, the more the invocations from the process server to the services and the more the overhead.

When I work with clients on SOA/BPM projects, I always encourage them to first identify the business need to deploy something as a process. The high level questions I ask are:

o    Do you want to collect runtime data on the process? If yes, what kind of data?

·         Time take by the process or a task to complete

·         Revenue generated by a particular activity

·         Number of times a particular task was performed

·         Revenue generated out of a task or frequency of revenue generated compared to the number of times a task was performed

o    Do you need business flexibility when you can switch tasks around?

o    Do you already have existing IT systems but you just need a central coordinator?

Sometimes, there are situations when there is a technical need to deploy something as a process. If an organization has correctly implemented SOA, it would have services that behave like black boxes, in which case you need a coordinator that will do all the plumbing work. It may be a good idea in that case to orchestrate services and deploy a process in a runtime. Some examples of technical need are:

o    You need to massage (map/transform) data between service invocations

o    You need to implement some logic to invoke different services based on different situations

It may be possible to use an ESB to satisfy some of the technical needs but that's another topic.

When you do decide to deploy something as a process, an interesting exercise it to determine the granularity of the process. Should you deploy every business task as a task in the process or should you combine some tasks making the process more granular? I will address this with an example some time in the future.