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.
In my humble opinion, the executable BPMN 2.0 (or the pure executable BPMN) will never be implemented. Just because no programming language may be highly abstract while allowing low level details at the same time.
I know, it is considered to be a boo-boo to address BPMN 2.0 as programming language. I know, it is just specification. Specification, which may be serialized into XML. And supposed to be understood and properly executed by all compliant BPMN tools. Just no compliant tools out there. Yet. But it is not a programming language. Nope. It is “just a specification”.
Well, for the last 30 years I used to believe that any machine readable notation featuring strict and formal syntax and semantics, used to formally define system behavior is a programming language.
Trying to implement a virtual machine (or executable BPMN tool) for programming language, which is both abstract and detailed at the same time is a waste of time.
Oracle/SAP/IBM know this. They worked on and got exactly what they need – an extremely complex programming language, which may not be implemented in a portable way. A language that may not be implemented in a portable way is a 100% vendor lock.
A language, which is extremely complex requires extremely complex tooling.
Extremely complex tooling requires extensive training.
And here is goes: 100% vendor lock on expensive software bundled with expensive training wrapped and touted as “industry standard backed by OMG”. Brilliant!
Why it works? Just because BPMN works. It shines as a communication media between developer and customer. Non IT (a.k.a business) people tend to think in terms of “happy path” only. BPMN allows to ask ”non happy” questions and immediately register answers while sketching the workflow. “Should a customer be reminded about appointment? When? Who does it? What happens in no-show event? What if check bounced? Who handles this?” – just a few real questions I was asking recently while interviewing loan modification firm owner. Most business people intuitively understand graphical notation and get instantly involved in the process.
This is why and how BPMN allows producing comprehensive specifications in no time.
Building a system based on the specification is where we get to the notion of Holy Gr… oops, sorry Executable BPMN. It would be really nice to load the XML process definition into the system, do some minor tweaking and voila! – system is deployed on production server. Unfortunately, it will not work.
I tried different systems and every time I did the same thing: composing a maze made of property editors, code snippets written in scripting/expression languages like Groovy and MVEL; tweaking standard compliant BPMN XML just to ensure it may be parsed in; developing plugins, extensions or whatever needed for customization. A lot of time spent to produce hardly manageable code…
Finally, we had to completely change the paradigm: instead of trying to “execute” BPMN, we execute good old Java code with each BPMN graph node being represented by plain old Java object. The objects are handled by a simple BPMN engine, which consults BPMN XML only to route tokens between the nodes (POJOs) automatically instantinating and persisting the nodes.
And this paradigm shift works just fine. Sure, this is not the “executable BPMN 2.0”, which I believe will never materialize. But who cares?
Sincerely,
Alex
P.S. Sorry, I had no time to write a short comment :o)
[…] a recent post, I talked about what “BPMN 2.0 support” really means, in both non-executable and […]
[…] BPMN 2.0 – Bruce Silver I suspect that BPMN-based BPM Suites will continue to use the notation part of […]
I’m not sure I agree with your assertion that no tools for executable BPMN 2.0 exist yet (although that just might have been a statement to lure out comments? ;)).
While this is probably true if you’re talking about the full BPMN 2.0 specification, I think several tools already support executable processes using BPMN 2.0 to a large extend (and by that I mean supporting those elements and attributes that are by far the most commonly used ones, not all the rather exotic ones that are rarely used).
In the jBPM project, we use BPMN 2.0 (notation and XML serialization) for representing your business processes (and not just as an import/export format). And in an attempt to try and prove this, I’ve described some examples in this blog entry here, including features like bpmndi, data mapping and service tasks. So if this doesn’t count as supporting executable BPMN 2.0, I would welcome any comments that could help us achieve that status 😉
It’ll probably take a few more years to see the full benefits of the BPMN 2.0 specification (like portability or tool interoperability), but that doesn’t mean they aren’t there.
Kris
Kris,
Thanks for your comment. Yes, the statement was a little bit to flush out vendor assertions. I know that Activiti, BonitaSoft, jBPM, and now IBM have something that qualifies as executable BPMN 2.0. The ones that I looked at seem to conform to bits and pieces of the spec and omit other pieces. Certainly no one is talking about the full element set. I would settle for Common Executable subclass, which is pretty barebones. Now that my book is finally done, I would like to spend some time looking at the various offerings that do exist and discuss their level of support in more detail. If it takes a few years to achieve interoperability (of the non-executable design, i.e. the part that is represented in the diagram), then BPMN 2.0 will be an unqualified failure. I doubt that it will take that long.
[…] am in BPM & SOA by admin Bruce Silver did a blog recently, wondering whether any tools already exist that truly support executable BPMN 2.0. He […]
[…] Bruce Silver??????????BPMN 2.0????????????????IBM, Oracle, and SAP ??BonitaSoft, Activiti, jBPM????????????????????????????????????????JBoss?Activiti?2??????????BPMN????????????BPMN 2.0????????????”??????????????????????????????????”????????????????????? […]
My opinion about executable BPMN2.
I observe OMG standards from 90’s. It seems that the BPMN2 standard has a chance to be exacutable in the sence similar to the concept of executable UML. That means I suspect that the future work of OMG will be focused on incorporation of BPMN2 into MDA concept (via both MOF and Activity Diagram). As you know there is general abstract specification (PIM) on one side and detailed runnable specification (PSM) as well as mappings from PIM to PMS’es on the other side in MDA concept. There are also two groups of MDA application scenarios: generating source code and other project artifacts as well as executing UML model. The BPMN2 concept fits into the second MDA usage scenario. I have very long practical experience with the similar concept (my Component Creator Technology 1997) that makes possible to generate working application from general specification. And I know that it works. But I am of course not sure if I am right with guesses connected to BPMN2 future.
I am sure there are many in OMG who think as you do. It is, I think, the opposite extreme of how modern BPMS work. But both ways are theoretically possible.
Hi Bruce. this is indeed a very nice blog. thank you. Well, Do you have any feedback or suggestions regarding the tool called BizAgi. I think it supports BPMN2.0 and I am at a stage of considering it for small automation projects in coming future. Need your feedback for this.
Thanks,
Niks
I think BizAgi is still BPMN 1.2, so I don’t follow it closely.
IBM Process Designer is not about executable BPMN is about the old coupled workflow. Visual BPMN 2.0 appearance is not enough.