BPMN to BPEL: going to battle with one hand tied?

I have been looking at business process modeling and I am a bit puzzled about the connections between the different goals (strategy support, process documentation, automated execution….), audiences (LOB, business analysts, developers…) and tools (process editor, registry, simulation bench, IDE…). I see how it would be nice for all these to play well together. What I don’t quite see is exactly how the current tools achieve that.

One example is the goal of improving communications between business analysts and developers by allowing analysts to capture as much of the intended process as possible in a way that can be easily consumed by developers. That is a worthy goal and it should be eventually achievable (though maybe in a reformulated form) based on industry trends (who would have thought that one day business people would use their own computers to retrieve business data rather than having an operator print documents for them). But it is still a very difficult goal, for which many inherent barriers (in terms of shared vocabulary, skills and mindset) must be overcome. My concern is that the current approaches add many artificial barriers to those intrinsic to the problem.

One source of such artificial barriers is that incompatible business process description languages come into play. One common example is the use of BPMN for analyst-level modeling followed by a translation to BPEL for development tasks. I ran into an example of an incompatibility between the two very early in my experimentations with BPMN, in the form of the “inclusive OR” (the diamond with a circle inside in BPMN).

It lets you express something like this: “The customer quote can be reviewed by the region manager, the country manager or the VP of sales. At least one of them must review the quote. More than one may review the quote”. My first thought when encountering this construct was “how does this get mapped to BPEL”, since there is no equivalent BPEL construct. After scratching my head, I could think of two ways to do it, neither of which is very pretty. One is to turn this into a brute-force enumeration of all the legal combinations (“1”, “1 and 2”, “1, 2 and 3”, “2”, “2 and 3”, “3”) which can get out of hand pretty quickly if you have more than three branches. The other relies on event handlers. In both cases, you end up with a BPEL process definition that should be correctly interpreted by a BPEL execution engine but that is hard to read for developers and almost impossible to round-trip back into a nice BPMN description.

Several similar corner cases in BPMN to BPEL translations are described in this paper, in which the authors also have to resort to BPEL event handlers. You can find approaches to improve the BPMN to BPEL mapping in this paper (also check out the list of references, including this paper, for more research on the problem).

Out of curiosity, I ran a translation of a BPMN “inclusive OR” with the Aris tool for Oracle and here is the resulting BPEL fragment in JDeveloper (click on the picture for the full-size version):

Here is a cleaned-up representation of the resulting BPEL (the optional tasks are only represented by “empty” elements because they are waiting to be filled in with real processing instructions):

<flow name="OR__inclusive_">
  <sequence>
    <switch name="OR__inclusive_">
      <case>
        <sequence>
          <scope name="Optional_task_3">
            <sequence>
              <empty name="Optional_task_3"/>
            </sequence>
          </scope>
        </sequence>
      </case>
      <case>
        <sequence>
          <empty name="Empty"/>
        </sequence>
      </case>
    </switch>
  </sequence>
  <sequence>
    <switch name="OR__inclusive_">
      <case>
        <sequence>
          <scope name="Optional_task_1">
            <sequence>
              <empty name="Optional_task_1"/>
            </sequence>
          </scope>
        </sequence>
      </case>
      <case>
        <sequence>
          <empty name="Empty"/>
        </sequence>
      </case>
    </switch>
  </sequence>
  <sequence>
    <switch name="OR__inclusive_">
      <case>
        <sequence>
          <empty name="Empty"/>
        </sequence>
      </case>
      <case>
        <sequence>
          <scope name="Optional_task_2">
            <sequence>
              <empty name="Optional_task_2"/>
            </sequence>
          </scope>
        </sequence>
      </case>
    </switch>
  </sequence>
</flow>

This tools makes the choice to favor BPEL readability at the expense of precision. The BPEL is much nicer but it fails to capture the fact that at least one of the optional tasks must be performed (a BPEL execution engine would allow an instance to go through all three “empty” constructs, bypassing all the optional tasks). In our example, it means that the customer quote could go out without any management review, even though the business requirement is to have at least one.

This is potentially worse than not allowing the analyst to specify the “at least one” business requirement: the analyst assumes that the requirement is captured (since it is conveyed in the BPMN flow) but the developer never sees it (assume the developer only gets hold of the generated BPEL). If the analyst was not able to input the requirement in BPMN, s/he would at least be more likely to add this as an off-line comment for the developer to take into account.

As all the research papers I previously linked to illustrate, this disconnect between BPMN and BPEL is a known problem that people have spent a lot of efforts trying to fix. But in the absence of a satisfying solution, I keep asking myself whether this problem is better circumvented than fixed.

I am not one to shy away from model translations (otherwise I would be in the wrong business) but I see model translation as a tool that can be overused. In the current state, putting my self in the shoes of a BPEL developer, I’d rather get a nice BPMN flow than a weird BPEL process that was auto-generated.

I don’t have a solution to the problem. Maybe it’s to define an implementable subset of BPMN (or an analyst-friendly subset of BPEL, which may be essentially the same). Or maybe not everything goes through explicit business process modeling. The developer will need test cases anyway, so maybe the right approach is to provide a high-level overview of the process followed by a bunch of tests. I can see a system where the business process modeling engine would be used to generate test messages and the analyst would tell, step by step, what happens to each message. The UI could be designed such that the tool could know what element of the message/context the analyst observes in order to chose the next step. And a strawman implementation flow may even be generated based on how the analyst dispatches the messages. At least the messages can be used to drive unit tests. Business process analysis tools already know how to run process simulations (except they are driven by statistical rules to decide what branches are taken rather than interactions with the analyst).

Just wondering.

[UPDATED 2008/10/22: This InfoQ article provides more data about the problems of mapping from BPMN to BPEL.]

[UPDATED 2008/12/11: If this topic is of interest to you, you should read Bruce Silver’s opinion about how to address this in BPMN 2.0.]