Blog Posts Process Management

BPMN Primitives for the Department of Defense

One of the features in BPMN 2.0 are four different subclasses of BPMN that reduce the number of modeling constructs to cater for different modeling purposes and levels of sophistication. One of these four classes is the analytic conformance class, modeled after the Department of Defense’s BPMN primitives. Robert Shapiro gave a presentation on the state of BPMN 2.0 and Sandy Kemsley is providing her usual, excellent coverage here. In it, she raised the question:

Also not sure why the US DoD’s enterprise architecture standard is impacting what is supposed to be an international standard

I want to give some background on the DoDAF conformance class, and how it came about, since I wrote most of the DoD document (the initial release is available here, if you are interested in a more recent version please email me).

Background

Large-scale system descriptions for government projects have to be delivered in views the follow either the DoD Architecture Framework or the Federal Enterprise Architecture Framework (FEAF). The DoD Architecture Framework (DoDAF) in its original form didn’t even contain a view for modeling processes, because it was closely designed with UML views in mind. Recently people have taken to using the Event-Trace-Description view (called OV-6c technically) and populated it with process models. Process modeling is increasingly important in the government space, but there is a large variety of approaches that people employ, and frameworks like DoDAF are not prescriptive in terms of how their individual views should be populated, i.e. which methods people should use. That leads to the situation that people use IDEF, BPMN, FlowCharts, and all claim to be DoDAF-compliant.

The Primitives Project

In May 2008 a project was launched by the CTO and Chief Architect of the Business Mission Area to address three points

How can the DoD enforce a consistent representation of architecture descriptions (i.e. how can we ensure the diagrams created by different modelers will look similar)
How can the DoD leverage existing standards for architecture descriptions (i.e. we didn’t want to invent a new notation)
How can the DoD enforce that the resulting models are interchangeable between platforms (i.e. how do we create process model portability)

Pretty much from the get-go we determined that BPMN was the graphical standard for process modeling that the DoD would settle on. It was already in use in different projects, there is a broad base of tool-support, and an increasing knowledge base of modelers that are conversant in BPMN. Moreover, BPMN provides excellent support for cross-organizational process modeling and the handling of events, making it preferable to using IDEF0 or UML Activity Diagrams.

Not all BPMN models are created equal

Even if modelers all use the same notation (BPMN), there are different ways to express the same semantics. One particular example is the conditional sequence flow element in BPMN – you can model a split using an exclusive or inclusive OR gateway, or you can express the same semantics using conditional sequence flow elements. The example below shows two process fragments that are semantically equivalent, but the casual reader would have to read the transition conditions for the conditional sequence flow example on the right to determine whether this is an exclusive or inclusive OR split. The gateway on the left signals this semantic through the use of the X symbol.

Implicit and Explicit Gateways in BPMN

In previous research Jan Recker and I had looked at the uptake of BPMN in practice, and found that there were some language elements that were rarely used in the models we analyzed. Thus we started to tailor the set of BPMN constructs that we thought were sufficient to model processes at the requirements engineering level (the DoDAF OV-6c), and the systems engineering level (the DoDAF SvcV-10c and SV-10c). This led us to a first cut of “BPMN primitives”, but we needed to validate it. So we used the BPMN subset in the documentation of various processes within the Department of Defense, from the Business side (hiring people, paying suppliers, managing property etc.) to the Warfighter side (performing close air support missions). We also sent the specification to a number of individuals outside the DoD that provided feedback, and we presented it to a number of BPM vendors for their input.

BPMN meets patterns

It quickly became clear that if you want to ensure consistent modeling practices you need more than just a restricted set of the BPMN syntax – you need to provide guidance on how to apply the modeling elements in practice. Thankfully, Artur ter Hofstede and Wil van der Aalst provided a great foundation for this in form of their workflow patterns work. We adopted as many of these patterns as we thought feasible, and they became a mandatory part of the BPMN primitives specification. But beyond the elementary patterns (e.g., how do I model a process split?) we found that there were recurring situations with specific semantics – reviewing and approving a document, collaboration between two parties, voting on an issue etc. These were captured in a high-level pattern catalog that is meant to be extensible, work that is currently ongoing.

Beyond Modeling – Model Execution and Exchange

The final question we are after relates to the exchange of models between platforms (e.g. to take a model from an architecture tool to an execution platform). It is clear that not every vendor will support the full set of BPMN 2.0 constructs. The most frequent explanation from execution-level vendors (i.e. BPMS vendors) is that they don’t want you to model what they can’t execute. So if an execution engine cannot interpret a non-aborting attached timer event then its development environment will most likely not contain that symbol. But that doesn’t mean we are not pushing the vendors to extend their systems in this direction, and since the US federal government is a rather significant technology buyer having the BPMN primitives as a guide in terms of what BPMN support is expected should provide clarity for vendors that are working on their development roadmaps.

BPMN Primitives and the BPMN 2.0 Standardization Effort

A vendor that currently supports just a subset of BPMN has little guidance which elements should be supported in the future – in BPMN 1.0 through 1.2 there was just a core set and the full set of the language, and a big gap in the middle. In BPMN 2.0 there will be more milestones that a vendor can target: Simple, Descriptive, DoDAF and Full. There still is a big gap between the Descriptive and the Full subclasses, and there was debate within the OMG and with interested parties on the outside how a suitable subclass could be introduced between Descriptive and Full. That’s where the DoDAF BPMN Subset (i.e. the primitives) comes in – it is a user-driven, practically validated subset of BPMN that ensures a high level of expressiveness, while leaving out many of the constructs that can either lead to inconsistent representations for the same semantics or that are so technical that the vast majority of IS and systems engineers will not miss them. It is a yardstick for vendors that may still have gaps in their own coverage of BPMN constructs and it gives members of the training community a target set for higher-level BPMN certifications.

So there you have it – history and rationale for the DoDAF subclass in the draft BPMN 2.0 spec. Whether the DoDAF name is a wise choice for the standard spec I don’t know, Sandy certainly raises a valid question. But in terms of content I am very confident that its applicability goes way beyond the confines of the Pentagon.