OMG could define a compliance spec for BPMN 2.0 - the elements,
attributes, and flow patterns that MUST be supported to claim BPMN
support. They have made some murky noises about it, but I haven’t seen
anything concrete yet. Since IBM and Oracle are driving the bus there,
it would make sense that that subset would have a defined mapping to
BPEL, but it would allow non-BPEL engines to be compliant as well.
That would be a healthy thing for the industry. But I’m not holding my breath.
I may be more used to specifications for computer languages (like FORTRAN, COBOL) than business process but I suggest that the specification for BPMN 2.0 itself should be what vendors comply with and not a separate compliance statement. Compliance statements from vendors will then effectively state what they have not achieved (yet). Purchasers and consultants can then judge whether the level of compliance of a particular product is sufficient for there purpose.
As BPMN is unlikely to stop at 2.0, a really supportive vendor should not only be compliant with the currently approved specification but also support proposals for future versions, so that practitioners can work with the new ideas while they work through the acceptance process of a standard.
Execution is a different issue. A vendor could opt for a BPEL execution engine (as Intalio uses at present) and reflect that decision by flagging bits of the model as not-executable. An organisation working from the compliant BPMN model could than decide on a method for implementation ...
- use a tool that will generate an executable directly from the model, or
- hand the model to an IT developer as a requirement specification
Even for Intalio, the execution engine could be replaced by something easier to map to BPMN without changing the user view.