BPMN Method and Style

Posted on

Last week I was casually flicking through the pages of a book called BPMN Method and Style and a passage in the introduction caught my attention… words to the effect that the clarity and effectiveness of BPMN models depends more on what’s not stated in the BPMN specification than what is stated in the specification – something that Bruce Silver (the book’s author) calls Method and Style.

I read on…and after a few pages my attention was hooked… It seemed to me that the distinctions that Bruce Silver had invented were potentially very useful for what Centrum is up to. Here’s what I got from reading the first few chapters…


The author’s goal is to provide what is needed to create BPMN Models that are…

  • understandable and can stand on their own without requiring a narrative
  • show the exception pathways as clearly as they show the “happy path”
  • serve to create a shared understanding between Business and IT

And in the author’s experience what is needed over and above the notation found in the BPMN 2.0 spec is Method and Style and to support the application of Method and Style when creating BPMN models the author introduces the concept of Levels Based BPMN.

Levels Based BPMN
The sub-title of the book is “A levels-based methodology for BPM process modelling and improvement using BPMN 2.0″. The levels in the sub-title refer to three levels of BPMN use.

In distinguishing these three levels of BPMN use, three distinct contexts are created for notation, method and style where each context is designed to serve the core concerns of each of 3 distinct user groups. The trick in distinguishing these levels is to have each successive level be a refinement of the upper level.

What the Levels are and How they Work

BPMN Level 1 – Descriptive BPMN
In levels based BPMN, Descriptive BPMN is what business oriented process mapping is all about; simply documenting what the flow is. Descriptive BPMN uses a basic set of symbols familiar to traditional flow charting to describe a typical order of activities and what role or organisational unit performs or is responsible for the process. It may omit some exception paths and may ignore some of the rules prescribed by the BPMN spec. The BPMN modeler is also free to ignore the fiction of the central controlling orchestration engine.

BPMN Level 2 – Analytical BPMN
In levels based BPMN, Analytical BPMN leverages the expressive power of the complete notation to describe the activity flow precisely, including exception paths significant to key performance indicators. The model follows BPMN’s defined semantics and is subject to its validation rules. An important distinction is that Analytical BPMN models are non executable models – they omit the technical details required for execution such as data structures and expressions.

The BPMN specification does not distinguish between notation that serves for execution and notation that serves for analytics but they are easy to distinguish: diagram labels in level 2 take the place of missing technical details.

There are two distinct use cases for BPMN Level 2:

  • documentation of as-is and to-be process flow for the purposes of analysis but not for the purposes of execution in a process engine
  • creating the business view of an executable process design in a BPMS. (Here BPMN is used to define the process model underlying the executable design but absent technical detailBPMS does not use the BPMN for the executable detail instead it layers it on top its a proprietary interpretation)

BPMN Level 3 – Executable BPMN

In levels based BPMN, Executable BPMN fits inside OMG’s goal of model driven architecture where executable systems are governed by graphical models and not “code”. BPMN at level 3 is targeted at developers, not business architects or analysts. BPMN at level 3 begins with level 2 diagram and adds detail in the XML underneath the shapes and symbols. It transforms BPMN from a diagramming tool to a XML language for executable process design. It still early days and at the time of writing there are no tools supporting the language as yet and we can see the emergence of tools that are supporting aspects that are essential to Level 3 BPMN such as process data, service interfaces, human task assignments

On the subject of Style

When Bruce Silver talks about style within BPMN modelling he draws on the meaning of style within english prose as exemplified by The Elements of Style

The central observation here is that the language of experience is not the language of classification – and notation is a language of classification.

The message here is that notation in and of itself does not communicate – as in ordinary prose – clarity of expression is essential for effective communication. And in this case communication and understandability is to be found in the design patterns of notation and not the notation per se.

On the subject of Notation

Along the way the author makes some interesting observations about the BPMN notation itself. The symbols of the BPMN notation are such that it can be used in idealised description AND as a blueprint for automating with an execution engine.

The potential for BPMN is shared understanding and Business IT Alignment where BPMN serves as a common notation for Business IT collaboration. As a diagramming technique it has the twin advantages of familiarity and simplicity wanted and needed by business users and the expressiveness and precision demanded by IT users.

The potential for an unintended bias

Consider that BPMN 2.0′s conceptual foundations assumes executable automation as a hidden subtext – the symbols assume a single engine AND… many BPMN users are non technical and not even considering automation.

The potential here is for the underlying assumptions within the notations to influence the modelling process and create a bias that was not intended

Questions left unanswered by BPMN

Using the notation effectively depends on understanding and even accepting the hidden assumptions and conceptual framework. BPMN does not answer questions like…

  • what is a process?
  • what does it mean to be inside or outside a process?
  • what does it mean to start and complete an activity?
  • what does it mean for an activity to complete normally?
  • why does sending occur immediately but receiving imply a wait?
  • what is the difference between making a decision and taking this path or that based on a decision?
  • what is the difference between a business rule and a routing rule?
  • what does it mean for two activities to be concurrent or sequential?
  • what is the difference between performing an automated function and requesting it?
  • what is the difference between branching based on data and branching based on an event?

Answers to these questions are critical to the correct use of the notation but its not in the spec.

In BPMN a process really means an orchestration – a sequence of activities in which the flow is centrally controlled when an activity completes, the central controller – the process engine – command or enables the next activity to start. A Process model describes all the possible paths from creation of an instance to its eventual completion along with the logic that determines the path which is taken.

The author asserts that to really understand what a BPMN model means we need to come to grips with how a BPMN model produces meaning – and coming to grips with how BPMN models produce meaning and the modelling patterns that foster and develop understandability is what the rest of the book is all about.

Leave a Reply

Your email address will not be published. Required fields are marked *