Saturday, 25 October 2008

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).

5 comments:

Antoine Toulmé said...

Dave, what exactly did we get wrong regarding the BPMN valid constructs ?

I agree regarding the BPEL readability. This is not an issue as this not something our users face.

Thanks for your feedback and welcome to the debate!

David French said...

Antoine,
Error Flows are only allowed a single activity (task or subprocess) in the Intalio implementation of BPMN. That is, the error flow cannot go anywhere or rejoin a sequence flow. This is contrary to the 1.1 spec.
While this is trivial to avoid in new process design, defining "as-is" requires a representation of how the business actually operates and spaghetti style processes are a reality.


Sorry, the example was in a footnote to the post but it got lost.

David

Antoine Toulmé said...

David,

BPEL is block-based and that's an issue for this particular construct. We are still thinking of the best way to support this.

If you have an insight on how to translate such diagrams into BPEL, I'd be happy to listen!

David French said...

I understand the difficulty with BPMN to BPEL and I am glad that you are thinking about this issue. If you are not much better than me for insights into solving the implementation, you are in real trouble over there.
I think that there are benefits in being able to draw the BPMN alone, especially in the documenting "AS-IS". Documenting a non-executable model from business perspective can be followed by a refinement by someone with more of a coding attitude to get the generation of process executable.

David French said...

Antoine, With the exception of cases where the exception flow (correct term for error flow used in error by me) is interleaved with parallel flows, BPMN 1.1 Appendix A1.13 seems to specify the BPEL4WS requirements.