News

The BPMN 2.0 Debate Continues

Posted by Boris Lublinsky on Jul 13, 2008 03:35 PM

Community: Architecture,; SOA
Topics: Business Process Modeling ,; Business Process Management
Tags: BPMN ,; BPEL

The debate about the future of BPMN 2.0 continues. Co-chair of the BMI task force in OMG (responsible for BPMN and other BPM standards) Fred Cummins, talks about one of the current BPMN submissions focusing on resolving differences between BPMN and BPDM and specifically concerns about BPDM complexity:

BPDM is a member of a suite of business modeling languages being developed by OMG. For example, SBVR (Semantics of Business Vocabulary and Rules) supports modeling the semantics of business concepts and the expression of business rules incorporating those semantics. BMM (Business Motivation Model) provides a framework for capturing strategic planning models. A strategic objective of the Business Modeling and Integration task force of OMG is to develop a full complement of business modeling standards that work together to support more effective enterprise planning, analysis, design and improvement. As a result, BPDM has a robust abstract metamodel supporting the BPMN modeling concepts. This abstract metamodel defines basic concepts, many of which will occur in other business models, but in different contexts

Within BPDM, these concepts provide a consistent foundation for modeling business processes regardless of the specific modeling tool. At first glance, Fred states that:

BPDM metamodel might look complex. However, it should be understood that this complexity provides precision in the definition of the concrete elements. The abstract concepts do not appear as additional BPMN graphics and they do not appear as additional concepts expressed in the XML ... In summary, the appearance of complexity of the BPDM metamodel makes the specification more precise and robust, and supports development of consistent, complementary business modeling capabilities in the future. The complexity does not make business process modeling more complex for users, and it does not unnecessarily constrain the implementations of tool vendors

In response to Fred, Bruce Silver notes:

I have to say that complexity of the metamodel would not rank at the top of my list of complaints about BPDM. More serious is the view that the notation is secondary to the metamodel, and that user-defined semantics are OK as long as the underlying metamodel can describe them.

Nick Malik discusses whether high level BPM languages/notations will allow one to completely automate creation/implementation of business processes:

According to the "true believers" we can give end users one of our pretty languages (BPMN or BPEL) and they will write their own software, and we can fire all the IT developers

Nick points out that although these languages can often simplify implementation,they can’t completely replace IT developers (and a proper development process) for business process implementation:

...BPM languages model HUMAN behavior. The things that "become code" are indicative of COMPUTER behavior. We have to be 1,000 times more explicit with computers than with humans. So we need to develop 1,000 times as much code for computers as we do for humans.

Unfortunately (although with the good intentions), Nick combines together both BPMN and BPEL - 2 languages serving completely different purposes, which immediately caused a reply from Bruce Silver, who points out the mistake, but agrees with the overall conclusion:

Let’s hypothesize that Nick has some clue about what BPM is, even though BPMN can not by itself generate implementation (it’s just activity flow modeling) - BPEL is definitely a developer language, not for ‘end users’. (Maybe Nick thinks that only Java programmers are "real" developers?) BPM Suites based on BPMN do provide a more agile implementation style in which business and developers collaborate on process automation

Based on these debates it is obvious that neither role nor direction of BPMN 2.0 is still not clear or completely agreed upon. This uncertainty can significantly impede progress of BPM design and development