After I posted re the piling-on Assaf Arkin was taking on IT|Redux over insisting that BPMN belonged to BPEL, the man himself posted a thoughtful response on BPMS Watch. I was waist-deep in real work at the time and didn't have time to think through an appropriate continuation of the thread, so I dashed off a quick response by email. That began an interesting out-of-band conversation that, if nothing else, narrowed the gap between the BPEL-si and BPEL-no positions, and shifted the debate from lofty analogies and name-calling to things reasonable people can at least discuss.
Even though I come off as the simpleton in the dialogue, I learned something about BPEL, so with his permission I reproduce it here. I haven't caved, but I think I understand the question better now. I'm hoping as the issues become more concrete, others can move the conversation forward more constructively.
I'm seeing more and more BPMN on the web and elsewhere. OK, the spec is still a bit loosey-goosey, I admit, but a lot of these examples are just plain wrong, both in terms of the notation and the semantics behind it.
Consider the following diagram of a sample travel reservation process downloaded from a well-known tool provider:
Image 1: 
(click to enlarge)
Here is the right half of the diagram:
Image 2: 
(click to enlarge)
How many errors can you find? By my count, about 12.
In his comment on my post What's Wrong With This Picture?, FairIsaac's James Taylor asks many of the right questions about BPMN and Business Rules. I thought it deserved its own thread. He asks,
- how do I differentiate between decisions that are simple ?Customer is New/Not New? and complex ?Customer?s credit is good/bad?? One of these is about routing rules, one is about decision rules
- are there any subsets of the activity box to allow me to show decision services as activities more explicitly? Has this been discussed ever particularly in terms of allow looser synchronization of rules and process?
Actually, BPMN barely deals with rules at all, and where it does, it does it in kind of a strange way.
[Preview of next week's BPMS Watch column on BPMInstitute.org]
It?s conventional wisdom in business that 80% of the problems are caused by 20% of the work ? the ?exceptions.? In BPM, therefore, you?d think that exception handling would be a critical focus of process modeling and analysis. In most cases you?d be wrong.
Certainly the designers of the Business Process Modeling Notation (BPMN) standard at BPMI (now part of OMG) had exception handling in mind from the start. BPMN introduces to process modeling the notion of intermediate events. It?s a godawful name but an absolutely essential concept for making exception handling visible in the process diagram and understandable to business people. In fact, events are the key difference between BPMN and traditional flowcharting.
eClarus today declared they've cracked a tough nut in the BPMN-BPEL roundtripping problem.
If you follow that topic, you probably know that Yi Gao of Seattle startup eClarus and Marlon Dumas of Queensland University of Technology are basically the two guys in the world who know what they're talking about. Way back in February, when I was still blogging on Ismael's site, I posted on the roundtripping problem. You can find that thread here on BPMS Watch or here at IT|Redux.
In the comment thread, Marlon responded to my post by describing some of his group's academic work on the question.
We have recently defined a BPMN-to-BPEL translation that can deal with BPMN graphs with arbitrary topology. In this translation, if the original graph is well-structured, the resulting BPEL code follows the structure of the original graph and everything works well. But if the BPMN graph is not structured, the translation generates rather convoluted BPEL code and the way back to BPMN would be far from easy. For those interested, see this technical report....
There are classes of models for which a reversible BPMN-to-BPEL-and-back translation is possible. We can define three such classes of models:
Even though I made a point of not identifying the author in print, the creator of Figure 3 in my original What's Wrong With This Picture post takes me to task for not contacting him discreetly with my correction. Welcome to the blogosphere, my man. Anyway, he posts his own correction, basically repeating my explanation.
But if the guy were really engaged, he would have noticed that images 4, 5, and 6 are also his bogus examples. So to accelerate this thing, let's just post the answers here so we can move on to more interesting stuff.
Last week I posted several examples of illegal and nonsensical BPMN that you can find online in popular free tutorials and BPMN tools. If you believe that the notation is too hard for business analysts to use, you might consider instead that widely propagated disinformation such as this is mostly to blame. Of course you can teach people to use BPMN effectively, including the part where it represents the biggest advance in process modeling, handling of business exceoptions.
Re yesterday's post, Yi Gao of eClarus wanted to get this image in his response, so I'm posting the following note on his behalf.
From Yi Gao, Oct 13, 2006:
In eClarus Business Process Modeler 1.0 that was released in June, we could translate the BPMN models with synchronization links. We had some samples that show the capability even though we did not explicitly categorize the models in our website.
The simply structured BPMN models defined as Class 3 can be translated to ?readable BPEL? using context-free pattern matching. The technique is similar to computer language parsing based on a finite number of production rules. However, with synchronization link, the context-free pattern matching is not sufficient.
Let me use the following diagram to explain.
Recently a BPMS Watch reader wrote with some questions about modeling ITIL processes in BPMN. ITIL is an industry standard framework for managing IT services. It describes a number of interrelated business processes, including Change Management and Release Management. These processes are linked, but not in a one-to-one correspondence - one release does not correspond to one change - and it thus provides an interesting real-world example of the 1:N problem in BPMN, which I also call the batching/debatching problem.
[This is next week's BPMS Watch column at BPM Institute.]
When you get started in BPM, the first step invariably is documenting your current, or as-is, process. You can gather the facts from process participants and process owners in a variety of ways ? in a group, putting yellow stickies on the wall, or in separate interviews. But eventually you face the challenge of reducing that collected knowledge into a structured, semantically precise yet intuitively understandable, diagram ? a process model.
