To BPEL or not to BPEL

In Why BPEL is not the holy grail for BPM, Pierre Vigneras thoroughly covers the issues of using BPEL as the implementation layer of a business process solution. From the article conclusions ...

• Therefore, we consider BPMN notation as the only currently viable solution for Business Analysts
• Transformation from BPMN to (readable) BPEL is quite hard to implement, and produces --- when correct --- hardly readable code.
• Therefore, we may wonder why BPMN is transformed to BPEL since there
  exist a graph-based standard that maps directly BPMN constructs ---
  namely XPDL v2.0
• Of course, one may claim that XPDL 2.0 lacks some execution specifications that makes him (sic) unsuitable for direct execution.

Although I am generally a fan of Intalio, Pierre provides a good example of the problems they get when BPMN is used as though it is a convenient graphical expression for BPEL. In particular, a real business analyst can express the process in valid BPMN which is then transformed by Intalio into BPEL which bears little relation to the designer's intention. Worse, the Intalio developers have removed valid BPMN constructs from the business analyst, probably because they do not readily fit with the BPEL implementation. To add insult to injury, there is a general impression that if your valid BPMN does not work, you must have designed your process against some mystic best practice rather than expressed real business events and activities.

I am less concerned about the round-trip issue. If the BPMN is transformed by a product into an execution language which then remains untouched by human developer hand why we should care about the readability of that executable code? The answer is that the maturity of product development in BPM does not give users much faith that the generated code will do what we expect.

If we concentrate on developing BPMN into the way of real business analysts express the business processes and assume an automatic transform into a executable, the choice of implementation paths is only of concern to product developers. Out in the real world we can judge their products by the ease with which we can describe the processes that we find (as-is) and design (to-be).