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

Scott Francis
Next Post
Previous Post
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.
  • Pingback: Tweets that mention Process for the Enterprise » Blog Archive » Takedown: Bruce Silver has had enough of the BPMN vs. BPEL Debate -- Topsy.com()

  • Pingback: Process for the Enterprise » Blog Archive » BPMN vs BPEL (again?!)()

  • Scott:

    it is sad that neither the BPMN nor the BPEL camp understand how these two standard relate to each other and each camp is trying to annihilate each other. Until both understand how they relate (I don’t mean “map”) then we will stand where we are, i.e. no where.

    There is nothing to cheer about this situation, only sorrows on so many opportunities wasted across IT departments to make BPM successful.

    JJ-

  • Scott:

    it is sad that neither the BPMN nor the BPEL camp understand how these two standard relate to each other and each camp is trying to annihilate each other. Until both understand how they relate (I don’t mean “map”) then we will stand where we are, i.e. no where.

    There is nothing to cheer about this situation, only sorrows on so many opportunities wasted across IT departments to make BPM successful.

    JJ-

  • @jj – I feel your expressed sentiment is a bit more negative than the reality on the ground (from my perspective). It isn’t about annihilation to me, for sure. Your article is an excellent read, but overall just so much more negativity than I would feel with your same set of facts. I’ve talked to bruce about BPMN/BPEL before, and I think he can defend his own points of view on it, but I think most BPMN folks feel that BPEL is neat stuff, it just has little to do with the business process per se because it is designed for a different use and audience.

    There is a critical point in your article (http://www.infoq.com/articles/seven-fallacies-of-bpm) where you make the point that Bruce is wrong, because he thinks you keep layering implementation on your process until you’re done, and you argue that that is clearly wrong because these state-changes must be modeled separate from BPMN (the BEL if you will)… But I think you misunderstand where the “BPMN Camp” would draw the line around the process – indeed, those state changes would not be part of the “process” per se – triggering the state changes, but the actual management of the state changes will be via webservices, or other means. Those webservices are outside the BPMS for obvious encapsulation reasons.

    It just seems to me to be that there’s a massive failure of communication. Which is easy to have happen when you have so many vague buzzwords floating around that can be interpreted so many different ways. And so many abstractions, also easily interpreted differently. I read a few of your articles and they seem to have a running theme of being brutally negative about everyone you’re quoting – they’re all “missing the boat”. I have to admit that on specific points I often agree with you :) But I also have perspective on the roles of these folks in the BPM ecosystem. My role is to make processes real for customers. For some, their role is “analyst” for some, “trainer”, for some, “CTO of software vendor” , etc. Each has their own lens through which they see BPM, BPMN, and BPEL. As a BPM practitioner, BPMN has been far more useful to me than BPEL. Just because I don’t find BPEL useful as an implementation of BPMN, doesn’t mean that I think BPEL should be resigned to the 7th circle of Hell – it just means that it should be used for what it is good at – orchestrating webservice calls. The fact that people mistook BPEL for process implementation explains a lot about why stack vendors thought that BPM was a “feature” on their EAI/SOA stack… and I think that’s where much of the confusion has come from…

    I am, right now, using Lombardi to implement a process that interacts with webservices that manage the lifecycle of business data. Its a fantastic process, if I say so myself (and truly, I’m paying compliment to the customer for arriving at it, I am merely realizing that process in Lombardi). There’s no removing developers from BPM so long as software is involved in BPM. It would be like trying to remove statistics from Six Sigma (good luck!). But that doesn’t mean that the development can’t be done in the context of a model that everyone can grok (understand).

    I choose not to be sad, but rather to move forward creating value with BPM. Sometimes the small actions of water molecules add up to a wave. Not all waves will build at the same speed. Not all markets will develop equally quickly. BPM is complex, its taking longer to come to fruition. But rather than be discouraged by this, I think it has given some of the software vendors time to mature (e.g. Lombardi) and some bigger vendors time to invest in the space (e.g. IBM, Oracle). Its even provided some space for people to develop the skills to roll out these BPM initiatives – the human capital component that takes the longest to develop!

  • @jj – I feel your expressed sentiment is a bit more negative than the reality on the ground (from my perspective). It isn’t about annihilation to me, for sure. Your article is an excellent read, but overall just so much more negativity than I would feel with your same set of facts. I’ve talked to bruce about BPMN/BPEL before, and I think he can defend his own points of view on it, but I think most BPMN folks feel that BPEL is neat stuff, it just has little to do with the business process per se because it is designed for a different use and audience.

    There is a critical point in your article (http://www.infoq.com/articles/seven-fallacies-of-bpm) where you make the point that Bruce is wrong, because he thinks you keep layering implementation on your process until you’re done, and you argue that that is clearly wrong because these state-changes must be modeled separate from BPMN (the BEL if you will)… But I think you misunderstand where the “BPMN Camp” would draw the line around the process – indeed, those state changes would not be part of the “process” per se – triggering the state changes, but the actual management of the state changes will be via webservices, or other means. Those webservices are outside the BPMS for obvious encapsulation reasons.

    It just seems to me to be that there’s a massive failure of communication. Which is easy to have happen when you have so many vague buzzwords floating around that can be interpreted so many different ways. And so many abstractions, also easily interpreted differently. I read a few of your articles and they seem to have a running theme of being brutally negative about everyone you’re quoting – they’re all “missing the boat”. I have to admit that on specific points I often agree with you :) But I also have perspective on the roles of these folks in the BPM ecosystem. My role is to make processes real for customers. For some, their role is “analyst” for some, “trainer”, for some, “CTO of software vendor” , etc. Each has their own lens through which they see BPM, BPMN, and BPEL. As a BPM practitioner, BPMN has been far more useful to me than BPEL. Just because I don’t find BPEL useful as an implementation of BPMN, doesn’t mean that I think BPEL should be resigned to the 7th circle of Hell – it just means that it should be used for what it is good at – orchestrating webservice calls. The fact that people mistook BPEL for process implementation explains a lot about why stack vendors thought that BPM was a “feature” on their EAI/SOA stack… and I think that’s where much of the confusion has come from…

    I am, right now, using Lombardi to implement a process that interacts with webservices that manage the lifecycle of business data. Its a fantastic process, if I say so myself (and truly, I’m paying compliment to the customer for arriving at it, I am merely realizing that process in Lombardi). There’s no removing developers from BPM so long as software is involved in BPM. It would be like trying to remove statistics from Six Sigma (good luck!). But that doesn’t mean that the development can’t be done in the context of a model that everyone can grok (understand).

    I choose not to be sad, but rather to move forward creating value with BPM. Sometimes the small actions of water molecules add up to a wave. Not all waves will build at the same speed. Not all markets will develop equally quickly. BPM is complex, its taking longer to come to fruition. But rather than be discouraged by this, I think it has given some of the software vendors time to mature (e.g. Lombardi) and some bigger vendors time to invest in the space (e.g. IBM, Oracle). Its even provided some space for people to develop the skills to roll out these BPM initiatives – the human capital component that takes the longest to develop!

  • Scott:

    thanks for your response, please see my response at:

    http://www.ebpml.org/blog/208.htm

  • Scott:

    thanks for your response, please see my response at:

    http://www.ebpml.org/blog/208.htm