William Vambenepe's blog

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.

While doing some research on the different ways to probe and squeeze business process definitions to extract insight relevant for IT management I ran into this very interesting paper: Querying Business Processes. It defines a query language (called BP-QL) to query process definitions. Not much in common with CMDB Federation at first sight, and CMDBf was not on my mind at the time. Until I looked at the description of the query language that the researchers came up with. It is strikingly similar to the CMDBf query language. This is not very surprising since both are graph-based query languages that rely on patterns (where the patterns mix topological aspects with constraints on node/link properties).

CMDBf is more complete in some respects. It supports properties on the relationships, not just the items. The “depthLimit” element provide more control than BP-QL’s double-headed edges. BP-QL has its own extra features, including support for joins (something we discussed in CMDBf and that could be added to the specification) and negation at the graph level (e.g. A and B are not connected by any relationship of type “foo”, which may be useful but one should remember that CMDB discovery is rarely guaranteed to be comprehensive so an open-world approach is often preferable).

Assuming a suitable CMDB model for business processes, a CMDBf-compliant CMDB should cover many of the simpler use cases addressed by BP-QL. And reciprocally, the more advanced features in BP-QL are not really specific to business process definitions (even though that’s the scope of the paper) and could well be applied to CMDBf. I was also very interested by the BP-QL “compact representation” and the implementation choices. I hadn’t heard of Active XML before, something to look into especially if, as the paper hints, it does a better job than XQuery at dealing with idrefs. And Active XML introduces some interesting federation (or at least distribution) capabilities that are not currently exploited by BP-QL but which I find intriguing and which reinforce the parallel with the declared goal of CMDBf.

Is this similarity between the query languages just an interesting pattern to notice? Or is there more to it? The parallel between BP-QL and CMDBf invites the question of whether one should model business processes in a CMDB. And if so, is a business process represented by just one CI or do you break it down into a model similar to the one the BP-QL query language works on? You would need to go that far if you wanted to use queries to the CMDB to answer questions such as those handled by the BP-QL engine. And by doing this in the context of a CMDB that contains a lot more than just process definitions, you’d be able to enrich the queries with considerations from other domains, such as application or host topology. Modeling business process steps/activities may seem like very fine-grained modeling for a CMDB, but isn’t this part of the sales pitch for federated CMDBs, that participants in the federation can provide different levels of granularity? Of course, CMDB federation might never work out. If it does work and if we use it that way, we are not talking about just supporting change management processes (which are more likely to take place at the level of the overall process definition than the individual step) but rather about management integration for a wide variety of use cases. If that means we need to drop the term CMDB along the way (and leave it for the sole usage of the IT process people), I am more than happy to oblige.

[UPDATE on 2008/01/11: Prof. Milo pointed me to this follow-up paper that proposes a similar looking query language except that this time it is targeted at monitoring process instances rather than analyzing process definitions. And the monitoring runs as a set of BPEL processes within the monitored BPEL engine. Her group is doing some very interesting work.]