You may be right, I don’t know. It is clear that the BPEL-based BPMS vendors will adopt executable BPMN 2.0, since they are writing the spec. The question is whether the non-BPEL ones will, like the ones I listed, who in my view are the ones responsible for the current popularity of BPMN in the marketplace. I’m saying I doubt they will adopt more than the abstract flow portion (i.e. what displays in the diagram), because their incentive to do so is purely defensive, i.e. if enough others do they might be forced to go along or be considered proprietary. This would take a few years to play out. But your view, which is they have nothing to fear from a commoditized BPMN “engine”, could in the end be correct.

I suspect the issues around metamodels and semantics, etc., are more important to new tools, coming from a SOA or MDA direction, thinking about how to support BPMN in the future rather than to the BPM Suites based on BPMN 1.1 today.
–Bruce

But if I were a non-BPEL BPMN-based BPMS – like Appian, Adobe, Cordys, Fujitsu, Lombardi, Savvion, Singularity, SoftwareAG, Tibco, or Vitria – would I want this? … in a way it commoditizes the runtime, which only favors the “stackers” and open source guys.

Bruce,

Just my opinion, but commoditization of the runtime isn’t really of concern to BPMS vendors – the Process Manager is only one important piece of the BPMS puzzle and there’s plenty of room for differentiation.

We’ll know when BPM has “really” reached the mainstream when we begin to see sofware companies making money selling “add ons” to the major BPMS suites.

-John

Without me wanting to elaborating on the entire Ontology-approach once more (history repeats itself anyway), I believe you are very much argumenting towards “semantics” from an object-related point of view. Meaning that you would like to put a clearer understanding to questions like “What exactly is an activity?” or more conrete “What does my activity ‘approve order’ do with my business object ‘order’?” (didn’t quite get what meta-level of annotation you’re on – doesn’t matter anyway because the matter discussed here is a completely different one).

This certainly is a correct use of the term “semantics” since it captures the semantics of different semantically related concepts. However, the kind of semantics discussed by Bruce and Marlon can more precisely be described as “execution semantics”…

That is, Marlon’s and Bruce’s (and my) understanding of “semantics” does not involve any annotations of anything in order to explain “what something is”, but rather about “how a syntactically correct model is to be interpreted during execution”. (put in your gateway example: it’s about how a gateway with n incoming and m outgoing arcs are actually interpreted rather than what certain condition expressions mean in a particular context)

And unless there will be any sort of reference implementation or at least semi-formal specification how to execute a BPMNEL/BPMN 2.0 model, this will result in impracticability of reuse of process models (so no difference to today).
More precisely: a BPMNEL/BPMN 2.0 model which is syntactically correct to whatever kind of meta model (and maybe even annotated with any fancy kind of ontological knowledge) will result in two different execution behaviours in two different vendor’s execution engines…

That’s nothing about liking or disliking any of the ongoing standardization efforts. Actually, its just about the _completeness_ of the efforts! The consequences are pretty clear: will any sufficiently detailed execution semantics definition included there might be a chance of interoperability within the next 2-3 years. Will there be not: history repeats itself (as I already put it).

Cheers,
Torben

First of all, there is a debate here about syntax and semantics, as they’re used interchangeably. In my opinion (could be wrong), relationships and restrictions on them represent core semantics of any datamodel/model (in addition to some business rules).

Any valuable information (semantics) you know about metamodel, you should add it up-front to become formalized. The inclusive merge gateway case (by Marlon), of when should it fire, and when should it not, is a good example of adding those extra information/restrictions to metamodel to get more robust behavior from that gateway at runtime.

The myth here is not what OMG is delivering; rather, it’s the way vendors carry out the metamodel to capture semantics and build an executable BPMN engine for example, and OMG does not enforce any specific implementation. It matters most to choose the right implementation that can accommodate such complexity in a consistent way.

Here comes the question of what the right implementation for complex metamodels would be. You would hear different opinions based on people’s backgrounds. XML camp would say XML/XSD can do everything (as Bruce pointed out). Personally and based on my technical background, I wouldn’t buy this.

As I pointed before, all XML-based technologies are handicapped when it comes to handling semantics (for reasons that can be discussed later). XSD might work fine for small models/metamodels, but they would certainly blow out and become un-manageable for complex ones such as BPMN-2.0.

DBMS can do little better, but it is very week to handle complex relationships (especially across packages) such ones in BPMN-2.0.

One straight shot here would be using ontology and semantic technology to solve this semantic issue inherently and natively, in addition of being formal standards by W3C. The power of using ontology to handle semantic complexity in a consistent and robust way is a natural capability that puts ontology in a superior position over other technologies. In addition, you will get inferencing capability to deduce implicit information not stated in the metamodel. This great capability is not provided by all other technologies and only attributed to ontology.

So, is there a catch here by easily solving that semantic problem? Yes, a small one. To do something useful using ontology and semantic technology, the learning curve is steep. So, it will either take a long time, or you hire an expert to get the job done (don’t let the carpenter design your house!).

The value of OMG metamodel in XMI (not XML) format as the blueprint for all kinds of implementations is a tipping point (as Bruce pointed out before). XMI format fits perfectly with ontology representation (RDF/OWL), where both have object oriented roots. It also establishes a solid foundation for automating the transformation between both formats, which is a huge advantage not visible for many people.

From now on, it does not matter who likes the metamodel or not, it only matters who can take it all the way to leverage it the most, and all others are going to stay behind in the dark.

Scott

For example, one can say that “a BPMN gateway may be an inclusive merge gateway”, but that tells me absolutely nothing about the meaning of an inclusive merge gateway (when should it fire, when should it not fire).

My second point is that standardizing on the semantics is not easy and it requires a lot of will from vendors. Part of this effort can be done within a standardization body, but part of this effort needs to be done in addition to the standardization effort.

As Bruce points out, one way to start building consensus around a semantics is by defining strict conformance criteria (what does it mean to be BPMN-compliant?). Secondly, it helps a lot to define conformance test suites to complement the standard. This approach has been used in many other standarization efforts, e.g.:
http://www.w3.org/XML/Test/
http://www.thefreelibrary.com/.....a090984484

Another way to build consensus on semantics is to have a reference implementation. Or yet another way is to define translations from BPMN to other languages that have a semantics, such as translations from BPMN to Petri nets or translations from BPMN to YAWL:
http://eprints.qut.edu.au/7115/1/7115.pdf
http://bpt.hpi.uni-potsdam.de/.....n2yawl.pdf

There are many approaches to achieve consensus on the semantics of BPMN. But at the end, what matters is that there is a will from vendors to reach this consensus, as well as to achieve tool interoperability.

It’s great to see people like Bruce taking leadership on these issues.

Once you handle semantics, you can do a lot more than conforming syntax. A quick example would be validating your diagram (instance) against the metamodel. For example, you easily can check that a Choreography or Collaboration diagram must have 2+ Pools, which stated in the metamodel.

It does not make sense that because you won’t use the metamodel or you don’t know how to use it, you undermine what OMG is doing. Someone else or vendor will make the right use of it. So until you (or Marlon) can provide a formal alternative way/format/mechanism different from the metamodel as a base to handle semantics, stop trashing it out.

Scott

I am a supporter of BPMN 2.0, and I want it to be as good as it can be. That’s why I get up early 3 days a week for 7am teleconferences. It is adding a few valuable things to BPMN 1.1 – non-interrupting events and an official interchange format most important among them. But I would guess that 99% of BPMN users do not – and should not – care that it will be based on a formal metamodel.