Conformance sub-Classes on the BPMN 2.0 FTF Ballot

April 18th, 2010


We have proposed a set of conformance sub-classes for BPMN 2.0 Process Modeling. There are three sub-classes with provisional names: SIMPLE, DESCRIPTIVE, and ANALYTIC (aligned with DODAF-OV-6C). There is also a sub-class for BPMN2.0 Execution: COMMONEXECUTABLE. The FTF has decided that SIMPLE is too simple; we retain it for historical purposes and as a suggestion to modeling tool companies for a minimal palette. Here we describe ‘personas’ for each subclass. We reference a separate white paper arguing for the choices made by the DODAF community.

In addition to the ‘elements’ the proposal for the BPMN2.0 specification also contains for each visible element the specific attributes in support of the element. The ‘persona’ descriptions focus only on the visible elements.

SIMPLE: Process Capture Persona

SIMPLE contains only seven FlowNode symbols and a single SequenceFlow symbol.

•          Task (None)

•          Subprocess (expanded and collapsed)

•          Gateways (exclusive data-based, parallel)

•          Events (None start and None end)

•          SequenceFlow (uncontrolled)

A common situation for use of the SIMPLE class is process capture. A business analyst is sitting in a room with a group of process owners. The session is attempting to map out a currently deployed set of processes that have never been suitably documented. Technology for such a session may range from a low-tech whiteboard to a laptop and projector. A process map is drawn by the business analyst as the process owners describe their operations step by step.

In this setting the bare minimum of graphics is required. There are process steps (BPMN activities) and decomposition of some of these steps using hierarchy (BPMN embedded subprocess, possibly drawn as a separate diagram). There is a simple flow structure connecting the steps, with decision branch/merge depicted (exclusive data-based gateway) and parallel branch/join depicted (parallel gateway). A shortcut is provided by interpreting multiple inputs to an activity as an exclusive merge and multiple outputs from an activity as a parallel branch. All sequence flows are depicted as uncontrolled.

Naturally there are other settings in which this persona is also appropriate. For instance: sketching out a process, focusing on the main pathways and ignoring exceptions, special cases etc.

We imagine that tool-builders would provide a UI that allows the user to designate his or her persona and this would select a pallet of shapes appropriate. In the process capture persona only eight symbols.


DESCRIPTIVE contains: (elements from SIMPLE are depicted in red)

•          Activities

–        task (task type: None, User, Service)

–        Embedded and Reusable/Call subprocess

•          Gateways

–        exclusive data-based, parallel

•          Events

–        start events (None, message, timer)

–        end events (None, message, terminate)

•          Pool, Lane, Misc(data object, text annotation, association, Data store, documentation)

•          Flows

–        SequenceFlow (uncontrolled) and MessageFlow

‘documentation’ is not visible in the diagram. It is an attribute of almost every element and as such a place where the modeler can provide invaluable information to help with understanding the process model. We have decided to make this the single exception to the ‘visible element’ focus.

A common situation for use of the descriptive class is fleshing out the details omitted in a process capture session. Using elements familiar from traditional flowcharting, the business modeler extends the routing logic to include the more critical exceptions (such as time-outs) and special cases, adds information about resource or role requirements for performing activities, adds some basic information about data flow and provides an overview of communications between participants/processes pertaining to the start and end of processes.

ANALYTIC (aligned with DODAF-OV-6C):

ANALYTIC contains: (elements from DESCRIPTIVE are depicted in red)

•          Activities

–        task (task type: None, User, Service, Send, Receive)

–        Embedded and Reusable/Call subprocess

–        Looping Activity, MI Activity

•          Gateways

–        exclusive data-based, parallel, OR, Event-based

•          Events

–        Link event (catch and throw)

–        start events (None, message, timer, signal, conditional)

–        catching intermediate events in sequence flow (timer, message, signal, conditional)

–        throwing intermediate events in sequence flow (message, signal)

–        boundary ((message, timer, signal, conditional)(interrupting and non-inter), error)

–        conditional event

–        end events (None, message, terminate, error)

•          Pool, Lane, Misc(data object, text annotation, association, Data store, Message)

•          Flows

–        SequenceFlow (uncontrolled and default) and MessageFlow

Discussion of the DODAF class is in the document:

Department of Defense – BPMN Guideline for DoDAF (Process Model OV-6c)

ANALYTIC extends DESCRIPTIVE primarily with support for intermediate events, useful for describing exception handling.  ANALYTIC supports a model structure sharable by business and IT. The activity flow and exception paths are all shown. But details such as the actual expressions for determining routing logic, assignment of values to properties and so forth, are omitted. The model is ready to be studied using a simulator (additional simulation-specific information will have to be added). Thus various types of analysis can be performed at this stage of elaboration, but the model cannot be executed by an enactment engine. Note that there are approximately another 50 elements in the full Processing Modeling conformance class that are not included in ANALYTIC. What has been included is based on extensive experience from BPMN training sessions and analysis of DODAF BPMN models.

BPMN Process Interchange

May 2nd, 2009

BPMN has become the de facto standard for graphical representation of business processes. Unfortunately, the early versions of the specification provided no serialization format for a BPMN diagram. This was still true of the last approved version, BPMN1.2. The only standards-based alternative for serialization has been XPDL2.1, which incorporated the graphics and attributes of BPMN into the specification and XML serialization. In addition, XPDL2.1 defined subsets of BPMN, referred to as Portability Conformance classes, with software tools (XSL transforms) to test XML documents for conformance. These subsets allowed vendors a stepping-stone approach to full conformance and users the chance to benefit from model interchange for high-level designs early in this process.

Some people have claimed portability by the use of BPEL. This is a misrepresentation. BPEL does not support all legal BPMN diagrams and does not contain the graphical information required. Nor does BPEL represent a pathway for model interchange at the design level, where it is commonly required to support round-trip between business analysts and IT programming specialists, or model interchange between high-level models and simulation technology.

BPMN2.0, when approved, will offer an XML serialization. More is required to achieve process model interchange. The specification contains many new ideas; it is not simply a document presenting a serialization of BPMN1.2. Some of the new ideas have yet to be proven in practice. Some of the process model extensions increase the complexity of the models. There is no clear distinction between the attributes required for execution and those for high level design such as what would be used by a business analyst.

Portability Conformance classes will need to be defined for BPMN2.0 in order to create the possibility of any kind of round-trip interchange in the next few years. Validation tools for checking XML documents for structural integrity will be required. These should be developed both for the proposed BPMN2.0 XML serialization as well as the XPDL2.2 serialization (an extended version of the existing XPDL2.1 serialization). XPDL strives for backward compatibility so that older XML documents that were previously conformant will still be usable.