Takedown: Bruce Silver has had enough of the BPMN vs. BPEL Debate

  • December 2, 2009
  • Scott
  • 8 Comments

And we couldn’t agree more.

In this post, Bruce rips into a post from ActiveVOS which claims that BPMN->BPEL is simpler than using BPMN.  ActiveVos’ CTO Michael Rowley points out that because of BPMN’s focus on communicating between people (I believe that he means, sharing process definitions so that two people can come to consensus) is also a weakness of the standard – because this people-centric view is bound to cause it to evolve and change over time.  Mr Rowley has it backwards – the point of “code” isn’t to communicate to a machine to get it to do something!  The real purpose of code is to expose an interface into the machine that is understandable by humans – note: the audience is for humanity, the audience is not the machine.  Otherwise we’d have to write machine code (hex or binary) to write programs.  Or assembler.  Languages make the machine instructions and behaviors more accessible to humans, and that is what they are there for.

Also, the most costly thing about code is that so few of us really understand what it does – even really well-written code – making maintenance over time very expensive.  If BPMN is understandable by a greater number of people, that makes it more valuable than BPEL, which as an XML standard is understandable by relatively few people.  The fact that this expressiveness is challenging to the engineering teams who have to turn this into process execution is beside the point – after all, Rational Software did it for UML, there is no reason that BPMS vendors can’t do it for BPMN.  In fact, we can see that BPMS vendors are meeting this standard, despite the fact that they are each proceeding at a different pace on this trajectory.

Bruce’s post is worth a read, but my favorite points are these:

However, for process modelers, and even for executable process designers, there’s no way BPEL execution makes BPMN modeling “simpler.”  That’s because the subset of BPMN supported with BPEL execution excludes the very features that make BPMN attractive to business-oriented modelers in the first place: things like freeform looping back to a previous step in the flow.  BPEL is inherently block oriented, like a computer program, while BPMN is inherently graph oriented, like a flowchart.

Right. From the modeling point of view I don’t care what the engine is as long as it faithfully implements everything I’m modeling without losing any fidelity.

And Bruce wraps up with:

If BPEL were adequate to execute processes the way business wants to model them, it would have become the BPM runtime standard.  It hasn’t.

Well said, Bruce.

Related Posts
  • November 15, 2018
  • Joe
  • 0 Comments

Editor's Note: This is a series devoted to the migrations from the IBM Digital Process Automation eclipse base...

  • November 8, 2018
  • Larry
  • 0 Comments

[Editor’s note: This guest post is the ninth in a series from Larry Taber, BP3’s Digital Strategy Officer ...

  • November 6, 2018
  • Joe
  • 0 Comments

Editor's note: This is a series devoted to the migrations from the IBM Digital Process Automation eclipse base...