Comments on: BPMN “Levels” and Tool Interoperability

By: BPMN Method and Style - 2-Day Class in San Francisco

BPMN Method and Style - 2-Day Class in San Francisco — Fri, 29 May 2009 16:14:58 +0000

[...] been using the new levels-based method and style approach in private classroom training for the past couple months. I think it makes learning BPMN [...]

By: bruce

bruce — Wed, 13 May 2009 15:09:52 +0000

Robert,
You bring up something I forgot to mention. Unlike XPDL, BPMN 2.0 serializes the subprocess expansion identically whether it is visually represented as inline expansion or hierarchical expansion. Identical except for the graphics (DI) part, which I think many vendors will ignore. So, to your point, a tool that does not support inline expansion should – in my opinion – be free to render as standalone expansion on import. In the BPMN semantic model, there is no difference.

This also calls to mind the question of whether Level 1 or XPDL SIMPLE should distinguish regular subprocesses (“embedded”) from Call Activity (the calling part of a “reusable” subprocess). I am with Scott on this… Notions of “reuse” are techy things that confuse business people, so I choose to leave them to Level 2. But it is true that in BPMN 2.0, Subprocess and Call Activity are distinct semantic elements with different graphics.

By: Robert Shapiro

Robert Shapiro — Wed, 13 May 2009 12:50:51 +0000

1. Expanded subprocesses may be useful for didactic purposes and can be good for simple embedded subprocesses, particularly when they are AdHoc. But, should this be a criteria for model portability? Does it mean that if a process is exported with an expanded subprocess that another tool, on importing it, has to show the expanded subprocess?
2.I think OR gatweways are a big problem. The execution semantics are challenging because it requires a complex analysis to determine what to do at OR merges. Multiple inputs at an activity are now defined as an XOR (exclusive) merge and I think that is good. XPDL inherited a more sophisticated underlying semantics (Transition restrictions) which allowed more complicated logic both on the inputs and the outputs of an activity. This may help power users but basically obscures the sequence flow logic. In my opinion leaving out gateways is a shortcut to be used only when it is clear what is meant. So multiple parallel outputs from an activity is a clear shortcut for sticking in a parallel split. Multiple inputs is a clear shortcut for sticking in an Exclusive (XOR) merge. Multiple outputs, some with conditions, is arguably a mess.

By: sfrancis

sfrancis — Wed, 13 May 2009 05:05:48 +0000

Bruce,

great post as usual, interesting food for thought.
re: the question around merge vs. or-join semantics – I think simply that bpmn practitioners need to do a better job of explaining why it behaves that way – as you did – because split/join semantics are always explicitly modeled, and otherwise you have merely decision/merge semantics. it is actually a pretty simple rule and works well, though it takes getting used to.

regarding your 3 points:
1. expanded subprocesses are nice eye candy , but a bit confusing at implementation level – some tools have expanded subprocesses, but not “nested processes” that can be re-used by multiple parent processes. some have limits about how deep you can go. some allow no expanded subprocesses but do the reusable nested processes. at the “novice” level i prefer to keep this to just a visual discussion and not get into the re-use aspects.

2. OR gateway. Although it is important to understand, new modelers will make LOTS of mistakes about the right split/join (gateways) to use. Better to just get them to approximately diagram the right thing, and then have an expert quiz them about the actual semantics they want on these splits and joins depending on the circumstances.

3. yep, makes sense to me…

By: bruce

bruce — Tue, 12 May 2009 17:57:21 +0000

Marlon,
Funny you should bring this up, because Vishal Saxena of Oracle has been on a similar campaign lately. He even managed to resurrect this issue for reconsideration in last week’s team meeting. I don’t know what the outcome of that was. Perhaps Vishal can comment?

I am conflicted on the matter. I agree that making the implicit uncontrolled merge semantics OR-join instead of XOR (ie pass-through) would a)conform to business modelers’ expectations (as you note) and b)save valuable real estate on the page. On the other hand, it is inconsistent with BPMN’s notion of sequence flow as control flow, so that without an intervening gateway (or the diamond-on-the-tail thing), completion of one node automatically enables the next one. More important for me, it is a major change at the last minute, and a semantic difference from BPMN 1.x. I would have to make 11th-hour changes to my book, my training, etc. Not a compelling argument perhaps, but I think the inconsistency with BPMN 1.x might be the determining factor in the team’s decision.

In the end, this is not a question of method and style but fundamental semantics of the notation. Let’s see what OMG finally decides on the matter.

By: marlon_dumas

marlon_dumas — Tue, 12 May 2009 17:28:05 +0000

Bruce,
There is one design choice in BPMN that I have not understood before and maybe now that you have “insider” knowledge you can explain it to me. By default, when two flows point to the same task, the semantics is the same as if the two flows in question converged into an XOR merge gateway and then there was a flow from this “implicit” XOR merge gateway into the task in question. In other words, a token coming from any of the two incoming flows activates the task.
Now, why wouldn’t the semantics be a bit different here: when two flows point to the same task, the semantics should be the the same as if the two flows in question converged into an OR gateway and then there was a flow from this “implicit” OR-join gateway to the task in question.
This simple design choice in the standard would obviate in many cases the need for merge gateways, and would be quite handy when doing “high-level design”. The OR gateway simply behaves like an AND gateway or like an XOR gateway depending on the context. In high-level process models, people could omit merge gateways and simply connect multiple incoming flows to a single task. The merge gateways could be added later when making the models more detailed and executable, since it is likely that in many process execution engines, the OR-join will not be executed as efficiently as XOR or AND-joins.
I know this is a bit of a side-track with respect to the questions you pose in your post, but it is also somehow related. Because the question you’re asking basically boils down to “What subset of BPMN do I need for high-level process modeling”? This is basically your level 1 palette and the usage guidelines that would be associated to this palette.

By: frenchdk

frenchdk — Mon, 11 May 2009 23:07:47 +0000

Expanded (inline) subprocess.
I really like this as an opportunity to show where the design of an activity is heading. The subprocess may not be completely understood or defined at the time a Level 1 diagram is appropriate or sufficient but using an inline subprocess can explain ideas about organisational peculiarities better than just the activity name or a note somewhere else.

OR gateway
I would like the OR gateway to be available even in early modelling stages as it has specific meaning that may be relevant well before people worry about a specific executable. I am particularly anti anything that deliberately ignores the ‘rules’ of the BPMN specification because I feel that will cause problems in exchanging models between tools where A is pedantic and B is lax.

Pools, message flow, and Message start/end events.
I am really in favour of these constructs from the earliest point of modelling if the expected end point is an executable BP that is derived from the BP work. There is a practical difference between knowing all the information of the process and having the information constrained by the content and timing of a message. I think that there is merit in breaking what may be seen as a single process through multiple areas of responsibility in the organisation (say widget provisioning through sales, manufacturing, finance) into separate pools to formalise the relationship between areas of responsibility.