Bruce Mayfield posts a comment on an old thread exploring different ways to model business exceptions in BPMN. Since that original post I've worked out some best practices for different types of exceptions (business exceptions vs system faults, exception detected interanlly to the process vs signaled by external event, etc). As a reminder that our BPMN training is now available from bpmessentials.com, it's worth reprinting his comment here and showing the solution.
Keith Swenson is one of the true superheroes of BPM, and a pioneer in the development of interoperability standards. Known for his stalwart defense of XPDL, he periodically feels called upon to insist that XPDL does not compete with BPEL... then usually adding that XPDL is actually better. But I've always felt that Keith obscures the real difference between XPDL and BPEL and their relationships to the "real" BPM standard, which is BPMN.
[My new column on BPMInstitute.org]
Lacking support for fundamental concepts like human tasks and subprocesses, BPEL has become a favorite whipping boy of BPM vendors and consultants. But for all its faults, BPEL enjoys something that BPMN advocates can only dream about: an XML storage and interchange format that makes sense. It?s often said that BPEL is an XML language not a graphical notation, but the reality is that graphical BPEL design tools all use more or less the same notation, based on a simple mapping to native BPEL language constructs: Receive, Reply, Invoke, etc. BPMN has a standard notation, but still lacks a standard storage and interchange format consistent with the fundamental goals of BPMN itself.
I?ve been thinking about this recently with the announcement from OMG that the ?official? XML format for BPMN, based on OMG?s new Business Process Definition Metamodel (BPDM), is in its final stages of ratification. Besides BPDM, Intalio has developed an alternative XML format for BPMN and has contributed it to the Eclipse Foundation. And let?s not forget XPDL 2.0, the Workflow Management Coalition?s reworking of its old process interchange warhorse to encompass various pieces of the BPMN spec. But to me, none of these proposals is as satisfying as BPEL?s approach, which makes the XML format closely match the terminology and semantics of the process constructs, their target audience, and business purpose.
Over the past several months I've been doing a lot of work with SAP to beef up the modeling-related content on their BPX community site. BPX stands for Business Process Expert, a term intended to describe a new role in the organization, straddling the line between business and IT. I see BPMN as a critical enabler of this role, because it for the first time allows process modeling, a business function, to be directly integrated with process implementation design.
Summary: BPMN has become the standard language of the Business Process Expert, usable for descriptive process modeling, simulation analysis, and even executable implementation design of end-to-end business processes. BPMN extends the familiar swimlane flowchart paradigm with events, the key to incorporating exceptions into process models and mapping to today?s SOA middleware. First of six parts. For the text of this article, go to https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/10852310-ac6a-2a10-02be-d83f4d2dd647
[Posted 15 Aug 2007 on BPMInstitute.org] When I launched my course "Process Modeling with BPMN", I discussed in this column why so many people beginning to "do" BPM were looking for training in modeling, and why that was especially needed for BPMN. Now, having delivered the training for five months, I have a better appreciation of BPMN's strengths and limitations, a better understanding of what students really want, and what they really need to know about BPMN modeling.
Marlon Dumas provided a thoughtful response to my post on roundtripping. In order to address it point by point, I am reposting Marlon's comment here in a new thread., with my responses inserted: Bruce, I agree with many of the points you make, but I strongly disagree with the proposition that BPEL is like an assembly language and that the readability of BPEL code generated from BPMN diagrams is unimportant. My three main counter-arguments are: 1) You won?
Michael zur Muehlen posts a lengthy response to my post On How Much BPMN Do You Need. He elaborates on his data analysis procedure - their procedure, actually, as Jan Recker was a co-author - and it's actually kind of interesting, looking at statistical correlations between diagram elements in a sample of BPMN collected in the wild. Sort of an anthropological survey - maybe archeological, given where we are on the adoption curve - of which shards of BPMN are used, correctly or incorrectly, in diagrams today.
[Posted 29 Oct 2007 on BPMInstitute.org] The Business Process Modeling Notation (BPMN) standard from OMG has a lot to recommend it, but it?s not perfect. Since late February of this year, I?ve been doing BPMN training, and through that I have come to appreciate the subtle power of the notation and how it maps ? or sometimes not ? to the way real business analysts and architects want to model their processes.
There's no denying that BPMN is gaining traction in the marketplace. I see it in my training. I see it in BPMS and BPA vendors getting on board. But what's amazing about this is that it's happening without a standard way to store and interchange BPMN between tools. It almost boggles the mind that the creators of BPMN "forgot" about this when they started, and its current owners place model interchange so far down the priority list (it's still not in the draft BPMN 1.
