BPM origami

Tom Baeyens (leader of JBoss jBPM) recently wrote a DZone article titled “Seven Forms of Business Process Management With JBoss jBPM”. It’s an interesting article. It does a good job of illustrating the difference between using BPM tools to capture/communicate business intent versus using them to implement asynchronous interactions, especially with Web services.

While it is very much worth reading, the article is not a good reference document for defining/explaining BPM, because it is much to tied to the jBPM product. This happens in two ways, one harmless and one more consequential.

The harmless tie-in is that each flavor of BPM comes with a description of the corresponding jBPM features. Not something you want to see in a generic reference document but Tom is very upfront about the fact that the article is going to cover the jBPM product (it’s even in the title) and about his affiliation with jBPM. No problem there.

What bothers me more is a distinct feeling that the choice of these seven use cases is mainly driven by the availability of these supporting jBPM features. It’s not just that the use cases are illustrated through jBPM features. What we are seeing is the meaning of BPM being redefined to match exactly what jBPM offers.

The most egregious example is use case 6, “thread control language”. Yes, threads are hard. It sounds like Tom and team are planning to make this easier by adding some Erlang-like features in jBPM (at this point the tense changes to future “we’ll develop a thread control language…” so there isn’t much specifics). Great. Sounds interesting, I am looking forward to seeing it. But if this is BPM then are threads a BPM features of the various programming languages? Are OS processes a BPM feature? Are multicore CPUs part of BPM while we’re at it?

Use cases 5 (“visual programming”) and 7 (“easy creation of DSLs”) are treading in the same waters. I have the feeling that if jBPM was able to synchronize the podcasts on my MP3 player, we would have had an 8th use case for BPM.

Tom is right to write that “the term BPM is highly overloaded and used for many different things resulting in a lot of confusion”. By adding a few more use cases that nobody, as far as I know, had previously attached to the BPM bandwagon, he is creating more, not less, confusion.

This is especially glaring if you notice that one of the most important BPM use cases, monitoring, is not even mentioned. Maybe it’s just me and my “operations time” bias versus Tom’s “development time” bias. But it seems that he is pulling the BPM blanket a bit far towards his side of the bed (don’t read too much in the analogy, I have never met Tom).

Rather than saying that “these use cases give concrete descriptions for the different interpretations of the term BPM”, it would be more accurate to say “these use case give concrete descriptions for some of the different interpretations of the term BPM, ignore others and add a few new ones”.

I didn’t learn a lot about BPM, but the article did make me interested in learning more about jBPM, which is probably its primary objective. There seem to be some interesting design goals towards providing a flexible set of orchestration-related tools to application developers. Some of it reminds me of the workflow efforts at Microsoft (some already shipping and some to be revealed at PDC).

1 Comment

Filed under Articles, BPEL, BPM, Business Process, Everything, JBoss, Middleware, Open source

One Response to BPM origami

  1. Good analysis, William.

    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