“We need spearate languages for human and transactional workflow.”

This statement has two different meanings. One implies two languages that are alternative to each other, like Java and C++. The other implies two languages that are complemantary to each other, like Java and XML.

The point I’m making is that two complementary languages that work well with each other is the best way to get the results we want. For the reason that it will do both automation and human workflow, and because slicing the solution in two separate steps would make it easier to author, implement, and refine each part to maximum effect, without losing the capabilities of the whole.

First, whether we include or exclude human workflow in our focus is a key point in the discussion on the relationship of BPMN and BPEL.

As already mentioned, BPEL is not designed for human workflows. By the way: I was quite shocked that companies like SAP and IBM spend several pages on their argumentation why human beings might participate within a business process; it’s 2006 out here. OK, SOA blinds sometimes, but wasn’t there already some work at Xeroc Parc (where else…) on office automation started in the mid ’70s by Skip Ellis and Gary Nutt? But that’s another point of frustration. Derek, beam me up…

However, BPMN does not make any assumption whether a business process consists of manual (human) or automatic (system-executed) activities. That’s good. As with any traditional definition of workflow, “business processes” consist of activities (or process steps, or whatever you like as your preferred notion) which might be executed by humans or by some IT system. And you will never ever find any business or process analyst using a modeling language limited to the orchestration of some computational statements and operations (also called Web services if wrapped by XML and SOAP).

Consequently, we always should keep in mind that BPEL has evolved from WSFL (Web Services Flow Language) — and this is exactly the correct acronym for BPEL (which even starts with WS-BPEL or BPEL4WS — when did we lose the WS?). Since BPMN has just another focus, there will be no easy mapping between BPMN and BPEL, and vice versa — the same holds for mappings between petri nets, CSP, statecharts, event-driven process chains (ARIS EPK), and so on. I guess tha’s particularly frustrating when implementing a BPMN designer on top of a BPEL engine, resulting in all the errors and misunderstandings in the mapping of BPMN and BPEL — but it’s better than implementing XPDL 2.0, which just adds highly-specific and sophisticated BPEL attributes to the XPDL 1.1 specification, crazy…

The gap is naturally based on abstraction. A high-level model typically requires some step-wise refinement in order to add missing details needed for execution (well, abstraction means hiding details). However, adding data variables, scopes, catch blocks and so on in a BPEL designer is quite equivalent to programming the same in Java. Implementing transactional workflows by drawing shapes and lines will remain a myth — I’m sorry to say that since I believe in modeling, modeling, modeling!

I have a second point: though I agree with Assaf that BPMN should have a more precise and executable semantics, I disagree that we need spearate languages for human and transactional workflow. Of course, both scenarios need different language constructs (ever talked about compensation spheres with your colleagues?); but at the heart of business process modeling is the flow (not variable assignments and catch blocks). Separating human from automated business processes is not a good choice in terms of domain specific models. We still need a core business process modeling language. BPMN is a good step in that direction.

This new thread revived older discussions following Francis Ip’s article.

Definitely worth checking!

Your arguments about workflow are dead on!

Workflow tools do the flow easily, but you need to write a whole lot of code to get anything done. The flow is just not enough.

BPMN has the same problem. Just because you can write a flow of activities doesn’t make a process you can manage.

You need services, data, expressions, and that’s a lot of work that needs to be reinvented, and I wonder: why?

Wouldn’t it be easier to reuse existing specifications that already went through the pain of doing all that work, and are widely supported?

Just a thought.

I like the poetic value of the analogies you’re making, but they totally ignore Assaf’s points as far as I can tell. Also, where is this BPDM thing you’re talking about? Is it available today, or is it just a pipe dream? And what about portability across BPM product? Can you give me a reasonably-complex process (say 25 activities) that is portable from one product to another without using BPEL, while remaining executable? I’m curious now…

And in the same way I would argue I don’t really care about the low level implementation details of a modern BPMS, if the answer is that you have to write a program to do that, I am not really interested. However, I am interested in what the tool does for me out of the box, what does it achieve without having to resort to programming.

Now when we get into modelling at a high level the business process, and seeing that translated into effective execution, I am not interested in whether BPEL is under the hood, or some other proprietary implementation of executable processes (or even a proprietary extension of BPEL).

If the model itself is transportable, across products, then it removes the vendor lock in. And if we were to quote John Evdemon from the last BPM Think Tank, “BPEL was never designed to be portable.” (Must admit I did a bit of a “wow, didn’t expect to hear him say that”).

If the BPMN model is transferrable, via a robust set of semantics and a serialization mechanism (BPDM), the reliance on BPEL as a programming language just becomes a mere implementation detail. How it is achieved is promoted to about as much importance as how I get mains water out of the taps at my house. I don’t care about the pumping stations, the treatment plants, the aquaducts… all the things that transport the water. All I know is that it comes out the taps and I can heat it with a boiler, or put it in my swimming pool.

So bringing this back to the world of business processes, if the business person can model the domain he/she is interested in and have it execute, then they don’t care about the plumbing, about SOAP, about HTTP, about… all they are interested in is the utility that it delivers.

A BPMS is more complex than a programming language. If all BPMSs were identical in functionality — differentiated only by runtime scalability or coolness of their design tool — it wouldn’t be a very interesting software market. The ways in which 2 different BPMSs handle human task delegation has nothing to do with process portability. Nor does whether an activity is invoked via SOAP over HTTP vs some other protocol. In my view those differences exist beneath the portability threshold.

I think if you would clarify the actual result you are trying to achieve with your proposal (and condescend to provide examples of the problem), people might agree that your approach is the only way to get there. But they might not agree that this is the right question to ask of BPMN.

-Bruce