Why BPMN Matters
Monday, April 17th 2006 | Ismael Ghalimi
This is the sixth edition of our weekly BPM 2.0 post. Today, I will try to explain why BPMN matters. Until now, there has been no standard notation for designing business processes. ARIS — the Brainchild of Dr. August-Wilhelm Scheer — is a great notation, but it’s a very propriatery one that is not supported by any other tool than IDS Scheer ARIS. UML Activity Diagrams are cute, but business analysts somehow cannot use them. Flowcharts is what they’d rather go for, but these tend to be limited to the modeling of single processes, which does not accomodate the requirements of a Service Oriented Architecture (SOA). Something better was needed, and this is why BPMI.org developed BPMN a couple of years ago.
Unlike BPML, BPMN immediately received the support of industry heavyweights such as IBM, which made it much easier to establish it as a standard. Also, unlike BPML, there was no real competition for BPMN. To be fair, BPMN is not perfect yet, and version 2.0 is adding very little to version 1.0. A standard serialization format is needed (XMI is not enough, being way too low level), and the way one can go from BPMN to BPEL is not fully specified. Adding to the complexity, nobody really knows how to go from BPEL back to BPMN, for there is no single way of doing this. Such a problem is also known as BPMN-BPEL round-tripping, and my friend Bruce Silver did a good job at describing it, following a great article from John Deeb and Devesh Sharma published by Business Integration Journal. Conventions will have to be defined, and I would be willing to bet that a standard round-tripping path will be defined sometime in 2007. In the meantime, vendors that support both BPMN and BPEL will have to give it their best shot. Too bad there are so few of them working on the problem today…
Eventhough BPMN still needs more work, it has the merit to exist, and nothing else comes even close. It’s the first notation I have seen that can be used by business analysts, process analysts, and software engineers alike, without much ambiguity getting in the way of their collaborative efforts. It’s also one of these very rare notations that can provide a clear path to execution, something that is an absolute must-have if one needs BPM to do more than helping in the design of pretty pictures. As such, BPMN really matters and is one of the most powerful enablers for BPM 2.0.
Entry filed under: BPM 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

















Just to note that there is a tool supporting diagrams using the ARIS notation. It is named ARPO and is produced by Klug Solutions. I am not a user and have only tested the demo, but it seems to be a usable tool. I don’t know if there are intellectual property issues.
To the best of my knowledge, eClarus (a young start-up company) has implemented the first round trip engineering between BPMN and BPEL in eClarus Business Process Modeler, and the product is ready to ship by the end of this month.
eClarus has worked on the round trip engineering problem for the last year. The biggest technical challenge we encountered was to semantically map the BPMN flow to BPEL. BPEL is a block structured language with limited flow capability. In contrast, BPMN is a constrained, but relatively free-form graph. Mapping BPEL to BPMN is easier than the other direction.
The approach we take is through a two-phase transformation with token-based flow analysis as first phase to partition the flow model in a set of sub-flows, and then transform the sub-flows according to some patterns. We have documented the technical approach with many examples in a white paper written by our CTO Yi Gao.
Jeff,
Your tool looks really nice.
I’m glad to finally some real competition in the BPMN+BPEL space.
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment