BPMN Conformance Sets And Unrealistic Ambitions

In the recent BPMN discussion, Bruce clarifies that he also sees a partitioning in BPMN:

"
The SIMPLE conformance set includes task, collapsed subprocess, gateway (exclusive data-based and parallel), None start and end events, pool, lane, data object, text annotation, sequence flow, and association.

The STANDARD conformance set includes task (task type User, Service, Send, Receive); collapsed and expanded subprocess, looping or multi-instance activity, gateway (inclusive, exclusive data-based, exclusive event-based, parallel), start events (None, message, timer), catching intermediate events in sequence flow (timer, message), throwing intermediate events in sequence flow (message), attached intermediate events (timer, message, error), end events (None, error, message, terminate), pool, lane, data object, text annotation, sequence flow (uncontrolled, conditional, default), and association. [Looks like we left out message flow… not sure why.]

The COMPLETE conformance set includes the full BPMN 1.1 spec.
"

This is very close to (and much more concrete then) the levels that I envisioned. That puts our opinions indeed much closer as I initially estimated. Especially if you only look at the modelling perspective, then I totally agree with you, Bruce.

So now, my only disagreement is not with Bruce, but with the picture that the traditional BPMS vendors paint. He describes it like this:

"
And, like Michael, the tool vendors factor into my thinking as well, in particular the BPMS vendors who support BPMN’s model-driven implementation style.
"

IMO, the BPMN model-driven implementation as pursued by most vendors is flawed. They see the executable language as the byte-code behind the BPMN model. Then round tripping is envisioned between the model and the "byte-code". I believe that it is impossible to let the non technical people drive the executable byte code.

Instead, I think it is much more realistic that the analyst delivers an initial analysis model. This model can be in 'the COMPLETE conformance set' as described by Bruce or it can be boxes and arrows on a napkin. Then this serves as the requirements input for the development team. The executable process language should be a selection of the development team. They can select a language that fits their architecture and the environment of the process best.

The clue is that a good executable process language would allow the developers to build a process that exactly looks like the analysts input. That way, the implementation model is structured in the same way as the analysis model. As a result, analyst and developer can speak the same language.

But crucial is that after the translation of an analysis model into an executable process, the responsibility is transferred to the development team. In subsequent iterations, the communication between analysts and developers can happen around the diagram, but it's the developers that should do the updates to the executable process.

With general purpose executable process languages, it's not possible to let the non technical business analyst modify executable software. The exception is in the specific process languages with a specific target and limited scope. For example a language to specify approvals in a document management system. In those cases, the analysts can build fully executable processes.

The round tripping approach that traditional BPMS vendors put forward tries to automate the translation of requirements into software design. That is, IMO, an unrealistic ambition.