About 99% of the effort in drafting the BPMN 2.0 standard, and 95% of the bad rap it has received, relates to "executable" BPMN 2.0 models. It's been over a year since publication of the final spec, and it seems that executable BPMN 2.0 tools don't really exist yet. I hope I'm wrong.
For years any BPM tool that had some notion of boxes and arrows claimed to support BPMN, and no doubt many BPM Suites now claim to support BPMN 2.0 in their executable design tools. But putting the marketing spin aside, what does it mean to support executable BPMN 2.0? I have a whole section of my book, BPMN Method and Style 2nd edition, devoted to executable BPMN 2.0, so I have given the question some thought lately.
Actually, before answering that, what does it mean for a tool to support BPMN 2.0 at all? The notation is barely changed since BPMN 1.2. Version 2 adds only non-interrupting boundary events, Escalation events, data stores, and event subprocesses. So any tool that supports some of those could possibly claim "BPMN 2.0 support". But fundamentally, what's new in BPMN 2.0 is not the notation but the metamodel and its XML serialization. BPMN 2.0 support really means support for that. And not even all of it. The spec enumerates the elements and attributes of three Process Modeling Conformance subclasses, and "support" for them is required in order for a tool to claim BPMN 2.0 conformance or compliance. The Descriptive and Analytic subclasses relate to non-executable models, and contain only information visible in the diagram - the basic shape type, its icons and markers, border style, and text label (plus ids and id references necessary to hold the model together). That's it. There's no description of data, gateway conditions, or messages. All that belongs to the executable process domain.
I suspect that BPMN-based BPM Suites will continue to use the notation part of BPMN, and model the data and data mappings, messages, gateway conditions, and so forth in their own proprietary way, as they have for the past several years. To me, that's BPMN support but not BPMN 2.0 support. What would make those BPMN 2.0-based tools, in my book, would be the ability to export (and ideally import as well) the information visible in the diagram consistent with the BPMN 2.0 XML Schema (XSD). There are a number that do that today, including a few that include execution engines: Activiti, BonitaSoft, SAP Netweaver Process Integration... I don't think Oracle will do it until BPM12c next year. IBM claims some kind of BPMN 2.0 support in Process Designer 7.51, and I'm supposed to find out more about it in a few days. I don't think any of them yet can export all of the base Descriptive subclass in the spec, a limited working set equivalent to what we call the Level 1 palette in my BPMN Method and Style training. No doubt by next spring several BPM Suites will be able to do that, and maybe even some will do Level 2, which includes the most common intermediate events, as well.
But that's still not executable BPMN 2.0. It's not what took three years in OMG to hash out. What took all those weekly 7am conference calls (and work in between) were the parts of the metamodel and XML dealing with process data, data mapping, data conditions, service interfaces, messages, and human task assignment. To me, an executable BPMN 2.0 tool is one that supports those things. Not necessarily as its internal object model, because BPMN 2.0 isn't really a process execution language like BPEL. Most executable BPMN 2.0 tools - assuming they eventually come into being - will treat the XML as an export, an interchange format, that can be mapped unambiguously to and from its internal native objects. And that is just fine.
The open source tools - BonitaSoft, Activiti, maybe jBPM - have been much more aggressive than IBM, Oracle, and SAP - the authors of executable BPMN 2.0 - in implementing the standard. And they've been much more interested in my BPMN-I Profile for model interchange than the major vendors, who keep telling me, "our customers aren't asking for it". (I have to ask if they care so little about it, why did they so tightly control the spec-drafting process, or make the standard so complex and hard to implement?) In one of the last chapters of my book, I use an example from BonitaSoft v5.6 to illustrate what an executable BPMN 2.0-based BPMS will look like. It's a bit of an artist's conception, because the current version of BonitaSoft doesn't generate the export as it would if the data, mappings, expressions, etc. were all surfaced in BPMN 2.0 XML compliant with the XSD. But Bonita is committed to doing that in version 6 early next year, which is really heartening to me.
Perhaps the biggest difference between executable BPMN 2.0 as it appears in the XML and actual design in a BPMS is in automated steps. In the BPMN metamodel those are called service tasks, invocations of some business function via a service interface. Unlike BPEL, the implementation doesn't have to be a SOAP-based web service, but it must be synchronous and must have requests and responses that fit into the XML as messages. In a real BPMS, the majority of service implementations use some kind of service adapter or "connector" provided by the suite - to send or receive email, do a SQL query, write a file, or insert a new customer into the ERP system. The service adapter exposes an interface that is configured in point-click fashion using a wizard in the BPMS design environment. The verbose XML that results - all kinds of data inputs, data outputs, mappings, messages, etc. - must be generated by the tool in the BPMN export. The tool also should expose the service interface of each adapter in some kind of XSD file imported and referenced by the process model. It's a bit of work for the tool vendor, nothing that the process designer needs to think about. If you're interested, you will find more details in the BPMN Implementer's Guide section of my book.