Even though the meat-and-potatoes of BPM 2.0 -- business-oriented, top-down model-driven process implementation (without code), based on some form of SOA -- hasn't yet been finished, BPMS vendors want to skip ahead to dessert, with system-generated recommendations on how to optimize the process design. Lombardi was the first out with this, but now both BEA and Savvion are planning to offer a similar concept in their next major releases.
Ismael posts an interesting reader request on IT|Redux addressed, it seems, to both of us:
Ismael, Bruce:
Do you think maybe it?s time for experts such as yourselves to get together and establish a standard model for BPM 2.0 in simple, concise and hopefuly universally applicable terms that can be ported throughout various functions and industries?
My work is in the supply chain arena, where about 10-15 years ago there was a similar debate regarding what constitutes a supply chain, which business function was responsible for what portion of the chain, what were some characteristics unique to the supply chain, but standard enough that could be used across all industries, etc? you get my point.
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:
Here is the right half of the diagram:
Image 2: 
(click to enlarge)
How many errors can you find? By my count, about 12.
Human-centric BPMers' lack of love for BPEL is today taken for granted, but who knew there were BPEL-haters out there in the SOA world as well? After taking a look at the BPEL 2.0 spec, Dave Linthicum tries to reignite the bashing, based mostly on the facts that 1) processes still aren't portable and 2) BPEL 2.0 is not backward-compatible with BPEL 1.1. Active Endpoints' Fred Holahan counters with a spirited defense of BPEL. He says yes, BPEL is not 100% runtime-portable, but it is "knowledge-portable" -- I guess sort of a process modeling language for programmers?
While I don't think of myself as a BPEL-lover, I actually come down more on Fred's side here than Daves's. And I've moved to a more nuanced view that might provide a middle ground.
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.
Today is the half-year anniversary of BPMS Watch, time to reflect on how it's gone, and where to go next.
[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.
Yesterday Ismael posted something about a new team collaboration offering from Webex called Webex Connect, that appeared to have some connection to Cordys BPM, one of the offerings described in my 2006 BPMS Report series. I couldn't tell exactly what it did, but Ismael seemed unusually excited about it, so I called my friends from Cordys to get more details.
BPEL 2.0, the long-awaited love-child of the OASIS WS-BPEL TC, is at last in its final public comment phase. See John Evdemon's blog for all the links. Sure, conventional wisdom says two years is a long time to change Switch to If-then, but if Assaf's comments are correct, fixing BPEL 1.1's primitive data manipulation syntax may prove to be a far more significant change. Once the thing is finally approved we can anticipate a ripple effect on BPMSes, and a round of new questions.
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:
