Top-down BPMSs suitable for Straight-Through Processing?

It seems that Bruce Silver and Jesper Joergensen have been having an interesting discussion around the marriage of BPM and SOA. Normally I would avoid any post on this subject, since I can look at the patterns of letters on the page through squinted eyes and know that its going to get too deep, too quick. These posts though have led me to a question that keeps coming back to me: should top-down business process targeted BPMSs be used for Straight-Through Processing (STP), and if so what makes one better than another?

In his post, Bruce specifically talks at a level that really makes sense, rather than the usual "we need BPEL/BPMN/WS/SOAP/I'm smarter than you by being able to use technical acronymns in seamingly meaningful ways that are completely unrelated to the real issues". He hits all of the points that I have been seeing over and over, but in a way that does not open the door to deep semantic discussion, which is fine by me. I have summarized Bruce's comparisons heavily:

• BPM is top-down. SOA is bottom-up.
  
• BPM is business-driven. SOA is IT-driven.
  
• In BPM, success is measured by business metrics and KPIs at the end-to-end process level. In SOA, success is measured by architecture, logical consistency, ease of integration.
  
• BPM is project-oriented. SOA is enterprise infrastructure-oriented.
  
• In BPM, what is reused is the process model, i.e. the “abstract” design of a process fragment. In SOA, what is reused is the service implementation.
• In BPM, a business process is inherently hierarchical, composed of nested and chained orchestrations. In SOA, services are inherently independent.
  
• In BPM suites based on service orchestration, process activities are bound to service endpoints. In SOA (supposedly), orchestrated services are supposed to be abstract, with connection and mapping to endpoints mediated by an ESB.

These points make sense since they describe the classes of software-based solutions that are BPM and SOA, not individual vendors take on it. Given these definitions there seem to be different classes of BPMS, some highly human process biased, others more SOA biased. In my head I have not really been able to work out what it is that distinguishes one from another since all of the BPMSs I have had contact with have been human interaction based with some plug and play integration capabilities. Is it just that the more 'toolkit' type BPMSs have an SOA bias since business users can't really use them?

My belief up 'til has been that the top-down BPM types of tools are good for 'STP' where there are breakouts of the process requiring human exception processing. I think that they may also be sensibly applied to business processes that can not be implemented as pure STP as a big-bang reengineering, instead having STP as an end goal that is approached through refinement and iteration of a live business process over time.

In Part 2 of his series, Bruce says he will talk about the way current “SOA-based” BPMSs work. I'm hoping that this addresses my question: should top-down business process targeted BPMSs be used for STP, and if so what makes one better than another? If not, I'm going to have to accept that there is an obvious answer to my question that I'm just missing!

Technorati tags: Financial Services Technology STP BPM SOA