Comments on: BPMN vs BPEL: The Debate Goes On (Sigh)

By: Jay

Jay — Thu, 17 Mar 2011 14:01:43 +0000

BPEL is a better fit for a integration centric workflow, and BPM is a better fit whenever there is a requirement for Human centric workflow. Comparing BPM and BPEL is just like comparing apples with oranges.

By: Process Modeling Euro-Style « BPMS Watch

Process Modeling Euro-Style « BPMS Watch — Sat, 12 Dec 2009 00:47:19 +0000

[...] To Mendling et al, “structured” means “block-structured.” That would make Michael Rowley happy, but not mainstream BPMN modelers. No, I think these guys are living in a BPEL [...]

By: hnehring

hnehring — Sun, 06 Dec 2009 18:42:30 +0000

Jonase, don’t know if I’m getting your point completely. Maybe the problem is with the word “map”, implying some loss of fidelity or indicating round-tripping issues. I guess what works well for programming languages (take Java or Ruby and their standardized “mappings” to execution) is harder to achieve in a standardized way on the business process model level (i.e. executable portability). If we can achieve BPMN meta model exchange between different execution environments (e.g. BPMS) without having to imply the way they’re going to be executed (e.g. BPEL, state machines, native code, …) we’ve already achieved a lot.

By: jonase

jonase — Fri, 04 Dec 2009 13:25:36 +0000

Harald, I’m not choosing side in this matter but wouldn’t that be the case for all attempts to map BPMN to an underlying executable model (not just BPEL)? Unfortunately that will not align with any BPMS vendor’s roadmap (including SAP’s), would it? I thought that BPMN was tha thing and all vendors are aiming for a BPMN modeler – some mapping it to BPEL, some to its own proprietary execution model, and some to BPMN 2.0 model for execution (if there is one?). Is this path good or bad for whom?

By: hnehring

hnehring — Fri, 04 Dec 2009 12:25:26 +0000

Jonase, in my sloppy, black-and-white (marketing) view I relegated BPEL to the past in a very general way. You’re absolutely right, it is and remains very valuable for service orchestration. Which is and remains an activity requiring skilled developers knowing the orchestration itself AS WELL AS the environment it takes place in. Business Process Management on the other hand is foremost a management discipline dealing with an organization’s processes REGARDSLESS of the (technical) environment they might be mapped to eventually. That’s why I think the discipline needs a way to express its assets independently of any mapping to a specific software infrastructure. That’s why we need BPMN and should be wary of any attempt to shackle it to BPEL.
Harald
PS: This doesn’t necessarily map 100% to SAP’s view in all aspects.

By: bruce

bruce — Thu, 03 Dec 2009 22:41:18 +0000

Thanks Keith. If only the problem were as simple as limiting the BPMN vocabulary. For example you could say the BPEL set means no OR gateways (or conditional sequence flows) and no boundary events (use event subprocesses instead). That would get you close (by the way, I don’t think the BPEL section of BPMN 2.0 even suggests that)… but you can create interleaving with plain old XOR gateways. It’s the diagram topologies that are at issue here… and you just can’t explain that to a typical BPMN modeler. Or maybe even a typical Java developer either.

By: kswenson

kswenson — Thu, 03 Dec 2009 21:05:30 +0000

(SIGH)

Discussions of suitability of languages is meaningless when abstracted away from the purpose to which you want to put the language.

As you accurately point out, the decision to use BPEL on the backend will limit your expressibility in BPMN. As long as you say only things that BPEL can do, then converting to BPEL will be problem-free.

As I have pointed out elsewhere, Dr. Seuss used a language of 200 words to write amazing stories suitable to kids learning to read, but would be entirely unsuitable for a medical journal.

Discussing the suitability of BPEL in abstract is like asking whether Dr. Seuss picked the right 200 words. Given a particularly purpose for those words, it might be fruitful, but suggesting that 200 words will work for all possible conversations is mind-numbingly futile. Apparently, 80,000 words is not nearly sufficient for a medical journal; they keep making up new ones every day.

I personally think you are right … the debate is over. BPEL has its place, but it not for everything. Thanks for helping the stragglers to understand this.

By: jonase

jonase — Thu, 03 Dec 2009 19:48:31 +0000

Bruce,

From my understanding Active Endpoints goal is to make their own product better by using BPMN over BPEL, not the way around.

By: bruce

bruce — Thu, 03 Dec 2009 19:06:00 +0000

For those who don’t know him,hnehring above (call him Harald) is SAP’s BPM marketing manager. Not sure if that puts his comments in a different light…

jonase, you raise some good points. I agree BPEL will live on as an orchestration language for SOA developers building business services. And for some shops, maybe even as an end to end BPM runtime. I agree as well there will always be a handoff between business-created “models” and IT-hardened executable designs. But if a single language/metamodel/notation like BPMN can do both ends, I just don’t see how mapping it to a different language and metamodel is better.

By: jonase

jonase — Thu, 03 Dec 2009 18:25:07 +0000

hnehring:

I’m a BPEL developer and from my experience the value of BPEL is more related to the fact its a web service orchestration language and a language aligned to the service oriented model. It’s the same thing as a Java developer would probably say: -The real value of Java is not portability but that Java is very well aligned with the object oriented model. A BPMN guy would probably say the same thing. BPMN is the best notation for the process oriented model and that portability is secondary.

Portability is always a problem, not just technology wise, but also for other reasons like skills. One BPMN diagram is unreadable from one analyst to another (just recall all Bruce’s lecturing of bad process models through the years).

I don’t agree with you that one technology is belonging to the past and the other to the future. Maybe you’re right that the 2 technologies should evolve independently of each other and make both of them drive BPM/SOA forward. Maybe BPMN should be used for modeling only and BPEL for what it does best – web service orchestration. Why should this part of the industry be driving the illusion that we’re required of a zero coding solution. One guy do the model, another do the process, and the third implement the service. If there are just humans involved then use a BPMS with a proprietary implementation.

I doubt that we will ever see a model that executes without round tripping, plus that we need the competition between the technologies and standards.