Indeed, not all the use cases are on the same level. And I didn’t intend to write the article as a reference document. As you mention, the primary purpose is to show how the term BPM is overloaded. (and yes, as I did the effort, I thought the shameless jBPM plug was permittted :-)

I see many people talk about how *their* form of BPM is the best one. Especially in the BPEL early days when no-one yet knew the difference between service orchestration and BPM as a discipline. The main objective is to show that there is not just 1 single best form of BPM, but instead, there are a lot of things which are called BPM.

All of those interpretations that I mentioned have one thing in common: they are based on executable graphs. And in most cases, paths of executions can enter wait states from the perspective of the system that is executing the graph.

That is why I didn’t mention business intelligence or monitoring. As those are not executing graphs. It’s an aspect that you can start doing when you have your executable graphs running.

Also your reference to Microsoft is spot on. Our Process Virtual Machine and their Workflow Foundation are very similar concepts. They also extracted the common parts of all these different forms into a framework for building executable graphs. The node types (or process constructs) are like components that you plug onto that core foundation. Process languages can then be implemented as a set of those components. See also http://www.infoq.com/articles/process-component-models

regards,
Tom Baeyens
JBoss jBPM