Is BPMN to BPEL Round-tripping Real?

Marlon Dumas raises couple of excellent objections to my earlier post BPMN to BPEL Round-tripping. His objections are so worthy of analysis that instead of replying to his comments, I am writing this post.

Marlon’s objections may be put in two buckets:

1. Semantic Mismatches Between BPMN and BPEL

Marlon writes:

Another thing which people seem to ignore (Ismael first in the line), is that BPMN allows for models where activities are connected in arbitrarty manners, with almost no restrictions, whereas BPEL is largely based on block-structured activities.

I could not agree more. When I did this first at Siebel, we decided to allow arbitrary BPMN. Theoretically, this was possible as we generated BPEL transparently to the user (just like Siebel users never see SQL, which is generated from Siebel metadata). In practice, this meant complex graph-to-tree and other semantic conversions, which, I suspect, the engineers loved but was a constant source of frustration to me, as a Product Manager, as it complicated adding support of semantics already supported on either end.

My current belief aligns with what Marlon goes on to propose:

Maybe what vendors should do is to clearly document and perhaps even enforce in their tools the restrictions they make on the BPMN models they can round-trip (e.g. classes of BPMN models as discussed in Bruce Silver’s blogs.

And this stems not only from the implementation difficulties described above, but also
from my sincere belief that this provides for high-fidelity preservation of business intent. The cost is some lack in flexibility for the business analyst; however, in my experience, educating business analysts about the limitations of what is executable and what is not, actually clarifies their thinking on what they want their processes to do.

Although I did not want this post to be about Oracle products, since the original post was, I will mention here that this is the approach we are taking at Oracle. Our Business Analyst tool will validate the analyst processes marked to be made executable to ensure that they meet constraints imposed by BPEL semantics.

However, this begs the question of why use BPMN at all, if it is constrained by BPEL. The answer is not so much that BPEL lacks a notation standard but more that the business analyst models are multi-layered and not all layers are meant to be executed. The freedom allowed by BPMN is valuable for the higher layers; for the executable layers, the analyst has more constraints but nevertheless the same notation.

2. Is Refinement a Realistic Model

Marlon questions mapping between logical and physical activities:

I’ve seen BPMN models produced by domain analysts which contain tasks that you would simply not automate at all (i.e. one task in the logical model = zero tasks in the executable model). I’ve also seen cases where a few steps are added in the technical model (especially data extraction steps) which the domain analyst wouldn’t care less about. Moreover, these additional steps in the executable model are not always related to a uniquely identifiable activity in the “logical” model.

I agree with both scenarios. In fact, some common examples of the two are:

a. The analyst model may model human activities that do not involve computer interactions – such as research customer, file document in cabinet etc.

b. The implementation model needs things like initialize variable etc.

However, this is not inconsistent with the notion of refinement. Logical activities may be refined as empty activities in the implementation model. Further the implementation model is not constrained to add implementation steps that do not expand upon a logical activity. Implementation activities may be added anywhere in the process as long as the flow in the analyst model is not violated. (I think the confusion stems from some process modeling tools which allow a developer to only add code behind empty boxes put in by a Business Analyst.) Of course it helps from a maintenance perspective if the additions in the implementation model are some how anchored to activities in the analyst model, as it facilitates updating the implementation model while correctly preserving the additions when the analyst model changes. However, “within” is not the only possible anchoring relationship – “before” and “after” are also possible.

Marlon also presents some evidence from a project at Danske bank in Denmark:

“…an activity was described as “create all cards”. When the developer should implement such an activity, he had to consider if a new service should be developed to create a bunch of cards, if an existing service for creating one card should be called several times in a loop structure, and what should be done in case of failures when creating the cards? Such decisions are not implementation issues; it is decisions that should have been modeled in details in the [high-level] model.”
And also that:
“Activities in a process may depend on each other. For instance, an account must be created before creating a card. Such dependencies were not always described explicitly and the developer had to figure out how to organize the control flow. These dependencies should have been described in the [high-level] model.”
And yet another example:
“Some important information was neither defined by the analyst, nor by the architect. The architect had not considered which data to use when defining service invocations or user interface based activities. Both activity types may require data that is not present and that has to be retrieved from somewhere else.”

I am not sure I read the above evidence the same way as Marlon. To me this seems to be more about a specific instance rather than about the methodology.

Let’s start with the easy one – the second observation about dependency description in the analyst model. This is exactly what refinement is for – analysts capture the high level flow, which of course includes dependencies, and developers implement it. The fact this was not done does not appear to be a criticism of the refinement model. Also, the refinement model, in fact, enables the business analyst and developer to work out such issues; note it is not a one time hand-off but a multi hand-shake interaction. In fact, I would say that the above project will benefit from using the Refinement model.

The third observation about data is again not a criticism of the Refinement model. The Refinement model supports refinement of data the same way as process. Business Analyst models business view of data (entities, their key attributes, and relations, etc.) and developers refine them to fully fleshed out schemas.

The first observation is an interesting one. First, I agree that there is a continuum between what an analyst should do and what a developer should do. Every organization may find it at a different point in the continuum depending upon the skills and roles. However, having business analysts sweat about loops seems to be a bit too much. There is a distinction between functional developers (not hard core developers) and business analysts – the former should use the implementation level tools, most of which come today with graphical drag and drop modeling tools.

Another Objection to Refinement

The best argument I have heard to date against Refinement is that business models and implementation models are entirely different entities – one deals with people, organization, etc. while the other deals with systems and applications.

I completely agree – business models are multi-layered and many layers, such as value-chains, do not map to execution. However, the point is that business increasingly wants to have high-fidelity control over the executable processes; and Refinement applies to such processes.

In Summary

I am a strong believer in the Refinement model. The basic premise of Refinement is not new – applications have been specified and built according to this model for a long time, where Business Analysts (Product Managers) have mocked up User Interfaces and developers have then implemented them. In fact when I think Refinement model, I think Visual Basic. However, what has been missing in the earlier applications is the ability to preserve the Analyst view and keep it current, as well as the ability for the Analyst to continue making changes. In the world of BPM, we have the opportunity and the requirement to be address these issues, as I discussed in my original post.