Last month I gave you five things to love about BPMN 2.0. This time it’s five they left out. As a member of the development team, I understand why they were left out. And as a BPMN educator and author looking to add value on top of the standard rather than just to summarize the spec, I’m glad they gave me room to do that. I’ve developed my own methodology and style to fill in the gaps, but most people might be disappointed to find the following items missing from the standard.
1. Distinction Between Modeling-related and Execution-related Information
BPMN 1.x failed to make this distinction as well. It mattered less then because no tools used BPMN for the execution-related attributes. They all used their own instead. The only part that mattered was what was visible in the diagram, what I call the modeling part.
It’s more of an issue in BPMN 2.0 because the new standard is conceived first and foremost as an executable design language, effectively a BPEL replacement. The team could barely imagine why anyone would care about non-executable models, and would not waste time on which parts of the metamodel are modeling-related versus execution-related.
This issue was my top priority when I joined the team in December, but all I was able to accomplish there was ensuring that BPMN models could be schema-valid without specifying all the data interfaces, WSDL operations and messages, and other implementation details. I could never get an enumeration of the information elements expected to be supported by non-executable modeling tools. Because the spec mostly deals with execution-related information – and no tool with a runtime will support all of that – it is easy for each tool to select subsets of the modeling-related information they will support. That’s not good.
2. Semantics of Non-executable Models
This is related to the previous issue, but not really the same. I did manage to get “non-executable” added as one of the allowed process type values, but its only defined effect is to excuse the modeler from providing the aforementioned data interfaces and WSDL references. Otherwise, BPMN semantics still assume a central orchestration engine, whether one is there or not. For most BPMN modelers today, not only is there no process engine behind the scenes, but no conception that things like process engines even exist.
BPMN essentially assumes the semantics of non-executable and executable models are the same, but the former is merely underspecified. One consequence of this is that sequence flow – the solid arrow connector – really means a token-based flow of control, whether the modeler intends that or not. When activity A completes, the sequence flow to activity B starts activity B immediately. Sure, that’s how it works in BPEL and other workflow systems, but what if you want to say only that B occurs sometime after A, not immediately after? There could be something in between, not shown. Or, simply that B starts sometime after A starts, not necessarily after A finishes?
These are not uncommon in high level modeling. I proposed a flag that would distinguish such lax sequence flow semantics from the strict control flow interpretation, but it never got out of the batters box.
3. Model Portability
Most people simply take it for granted that the first goal of any standard like BPMN is portability or interoperability between tools. You should be able to create a BPMN model in tool X and open it in tool Y. That takes more than a schema. It also requires the spec to enumerate the elements expected to be portable between tools, i.e. that all tools must support and understand. In an execution language like BPEL, this enumeration is the entire set. But for BPMN, currently used as a diagramming notation rather than a complete execution language, no tool with a runtime supports every last bit of it, and that probably won’t change with BPMN 2.0.
The team should have followed XPDL’s lead and defined multiple working sets – a hierarchy of portability levels – from a simple basic palette supported by essentially all tools, up to the full set, with portability conformance requirements spelled out for each level. I drafted language to that effect, but it didn’t get off the ground, either. Instead, the modeling conformance language is so vague as to be meaningless.My interpretation of the reason is that team members were uncertain how much of the BPMN palette their own tools would support in their first “2.0-compliant” release. So don’t expect wide portability between BPMN 2.0 when tools first come out.
4. Graphics Interchange
If I interchange a BPMN diagram from tool X to tool Y, I may not expect it to look exactly the same, but I’m hoping that the basic layout of the graphics would be preserved. And when I think about the tools involved, I’m thinking about today’s BPMN tools, like Appian, Lombardi, Savvion, TIBCO, and ITP Commerce. But that’s not what OMG was thinking about.
Instead, they wanted to make sure BPMN diagrams could be integrated with generic drawing tools like Eclipse GMF, maybe mashing up UML and BPMN shapes, and other things that I can imagine possibly happening but not what I would call top priority. The BPMN-specific information, like pools and lanes, shapes of activities, gateways, and events, aren’t even specified by an XML schema, just what is called an M1 library. It might be UML-friendly, but not XML-friendly. That’s a geeky way of saying that most of today’s BPMN tools will probably not adopt this part of the BPMN spec, so a wasted opportunity there.5. Simulation properties. Here is another case where the team’s focus on execution not modeling is in evidence. Most BPMN tools today provide model simulation based on assigned parameters of activities, performers, gateways, and events. Standardization of those parameters was omitted from BPMN 1.x, and it only makes sense to add them in to 2.0. There are sections of the spec – essentially empty placeholders – devoted to “auditing” and “monitoring,” things few would associate with BPMN. But nothing on simulation.
Simulation has the potential to be an important modeling feature, despite the poor quality of most of today’s simulation tools. I believe including it in BPMN 2.0 would have raised the quality of those tools, as well as the general level of understanding of what simulation can do and how to use it effectively. Sadly, another missed opportunity.
