This article will talk BPMN 2.0’s conformance sub-classes and how applying the conformance to modelling efforts can deliver higher engagement from users of BPMN models.
BPMN is the default modelling standard for capturing business processes. Its predominance over other standards comes from its intuitive layout which doesn’t require the casual user to invest a lot of time in order to understand the process being described. However it is also able to capture those ad-hoc events and actions which replicate real-life day-to-day operations and thus differentiate BPMN models from those models which are limited to describing a process at a general level only.
Why should this interest the keen modeller who is looking to model a business process architecture of the business they work in? Because although simple models can communicate a lot of information, there are a lot of symbols in BPMN (over a hundred) so it can be easy to get your meaning off-message. To this end, the idea of palettes has been introduced by Bruce Silver (in his book BPMN Method & Style). As you know a palette from those painting on canvas is a thin piece of wood where an artist can place the colours that they are using and also mix them together to get the shades they want on their work. Fast-forward a few hundred years and now we all use palettes on software like ms-paint which has a range of colours to choose from to ms-visio which offers a palette of shapes to drag and drop onto a sheet (also known as a stencil).
Thus the idea of a palette of shapes for BPMN models actually restricts the actual number of shapes that are available to the modeller to use in their diagram. Why would you want to restrict the range available for use? What happens to that exact meaning that you want your model to transmit, doesn’t restricting elements make for a less granular diagram? Actually in terms of meaning for a model architecture, the opposite is true, but it depends on what you are trying to achieve with your diagram. Models can have different purposes, so before putting pen to paper, it can be worthwhile to have a think about what is the model to be used for and who will be consuming the model.
Models can have all sorts of uses such as:-
- Software specification
- Process Improvement efforts
The level of detail required can vary across these different uses and also within each use. However one key concept in increasing communication across an array of models is consistency. Models that are similar in the elements they use engender confidence in the viewer. The person viewing a model of a process as say part of an on-boarding experience can look at a model of a different process and because the model is built with the same elements there is less for the viewer to worry about. The viewer who doesn’t have to waste energy worrying about elements they haven’t come across before can spend more time understanding the meaning of the model. When a model uses elements not on the palette, then the viewer will be spending more time trying to understand what is happening in the model (we hope, more often than not making the model difficult to understand just makes it easier for the viewer to switch off).
The palettes are based on the amount of conformance that vendors producing modelling tools for needed to match to show their level of conformance to the standard. The 3 levels of conformance are:-
- Common Executable
Descriptive conformance is for software tools concerned with “visible elements used in high-level modelling. It should be comfortable for analysts who have used BPA tools”. Whilst Analytical has a bigger palette and so is able to deliver models at a lower level detail for more analytical use. Whilst the last conformance class is all about the elements required to take a model and execute it on a BPMS. These conformance classes thus represent palettes of elements for use in our models. The key then is to use the relevant palette bearing in mind the use of the model.
So for models who are going to be viewed by people who want a bird’s eye view of the model architecture then, say someone who wants to see how the business’s architecture supports their company’s strategy, then use the Descriptive palette, then restrict yourself to the Level 1 Palette. Whereas for people who are producing models for a process improvement program then more detail is required and so the bigger palette of level 2 would be more adequate.
Finally level 3 is the executable level and this isn’t really a palette as such as no elements are restricted. These type of models are used for execution and not so much for communicating understanding about the process.
The palette is a great idea and it is based on a lot of experience from silver and so I definitely recommend its use. The viewer’s precious attention should be spent on understanding the process semantics and not deciphering un-familiar elements from the standard. It should be used as part of a variety of techniques to leave the viewer with as little to worry about as possible, such as layout style, naming standards and number of objects in a model.
As with life, it’s always good to question and be pragmatic rather than blindly follow the rules. So if you want to have different objects in your palette because the area you are modelling require them, then add them so that all your models have them. Bear in mind that by adding more you are taking away some of the power of the palette and that the palette itself is based on a lot of year’s experience as to what works. Other than that, happy modelling and get in touch if you have any queries.