This is the seventh edition of our weekly BPM 2.0 post. Today, I will try to explain why a BPMN designer should be prefered to a BPEL editor. Most BPM vendors that have developed native BPEL runtime components offer a BPEL editor as a development tool. This is better than having to write BPEL code manually, but don’t expect business analysts — or even process analysts — to be productive with such a tool. BPEL is a very sophisticated process execution language, and as such was designed for computers, not human beings.

BPEL is a powerful language, but with power comes responsibility, or in this particular case, complexity. I won’t bore you with too many technical details, but if you want to convince yourself that BPEL is not for the faint of heart, just try to write the chunk of BPEL code you would need to correlate two process instances, say one for an order taking process and the other for an order fulfillment process. If you do, you’ll quickly realize that you’d rather have a tool do it for you when you draw an arrow going from one box to an other. That’s precisely what a BPMN designer does, alongside many other similar tricks.

From a distance, a BPMN designer seems awefully similar to a BPEL editor: they both look like glorified Visio-like diagramming tool, they both show neat little boxes and arrow, they both let you change colors and fonts, but the comparison pretty much stops there. Where the first only requires that you get a good understanding of the different types of flows that BPMN supports, the second mandates that you know the ins and outs of the BPEL specification. Not only that, but you’ll also have to master the WSDL specification if you want to build a process that does anything useful, and that’s where things get really tricky. WSDL might have one of the smallest specifications of all the different standards for Web Services, but it’s also one that will require at least 10 reading sessions before you being to remotely understand what its authors had in mind when they wrote it. To make a long story short, I love BPEL, but I love it even more if I do not have to deal with it directly.

To really grasp the difference, you do not have to go very far. Instead, just read carefully. On one hand, a BPEL editor is exactly what it says it is: an editor for BPEL code. As such, it’s aimed at people who can read and write BPEL code themselves, and such people tend to be very sophisticated software engineers. They know Java, most of the J2EE APIs, and any specification which name starts with ‘WS’. On the other hand, a BPMN designer is for the rest of us. It’s a tool that will generate BPEL code out of a BPMN designer — if you picked a good one that is, but won’t necessarily let you mess with the BPEL code itself, because roundtrip engineering between BPMN and BPEL is a really tricky problem to solve. eClarus is about to release a version of their tool that does it, but I’ll reserve my judgement until I see customers managing to go back and forth between the BPMN diagram and the BPEL code. And beside, one of the ideas for BPM 2.0 is not to deal with code at the first place. It’s called Zero Code, and will be the subject of my next BPM 2.0 post.

So next time you look for a business process modeling tool that will generate code for you, look beyond the pretty pictures. If the tool requires that you master the BPEL specification, make sure that you do before committing. And if the tool generates anything else than BPEL, make sure that you read this article first. If you do both and happen to fit the profile of a process analyst, you’ll come to the same conclusion as I did: a BPMN designer is the way to go.

Author’s note: Vishal Saxena has a good post on BPMN and BPEL.

Author’s request: Vote for Intalio on Bruce Silver’s blog.