Evolute Consulting - Architecture & Process

There are some broad guidelines on how to visually organize a process in the Seven Process Modelling Guidelines (7PMG), but mostly they focus on the semantic and structural part, and not the general layout of the process. As a reference, here are the guidelines:

1. Use as few elements in the model as possible.
2. Minimize the routing paths per element.
3. Use one start and one end event.
4. Model as structured as possible.
5. Avoid OR routing elements.
6. Use verb-object activity labels.
7. Decompose a model with more than 50 elements.

There are also the typical readability tips & tricks incorporated in modelling tools in the form of auto-layout rendering, that have migrated to the world of BPMN tooling. Typical implementations include the following: avoiding line crossings, alignment of the boundaries of elements to each other (for example putting the upper boundary each activity on the same line), a minimum distance between elements, rounded corners in sequence flow arrows (or even Bézier curves)… However, there has to my knowledge never been any study to determine whether or not these implementations have any bearing on readability. It just increases the attractiveness of the process model, and our collective gut feeling is that this indeed increases our ability to comprehend the process.

The aforementioned book by Bruce Silver dips its tows a bit in the visualization water when elaborating on explicit versus implicit elements that can be on a model, such as start events, end event, and gateways. Certainly it must be clear to all that explicitly modeling start/end events does indeed help tremendously with the readability of the process model. However, I have caught myself not explicitly modeling some merging gateways (certainly with XOR-gateways) without too much detriment to the understandability.

The OMG standard doesn’t really elaborate on the topic of “secondary notation rules” to improve understandability of a model. For example, the direction of a process was never really important in the BPMN specification. They suggest either having your process left-to-right or top-to-bottom, and based on that choice model incoming and outgoing events in a 90° angle from the process. But they won’t go any further in this than a superficial mention. At least the SpringerLink study goes a bit deeper into the topic of direction, as they investigate the consistency of the flow. This boils down to the idea that most of the sequence arrows should point into the same direction (start-to-end), or what they call the temporal logical ordering. They even make this computable using vectors, so they can measure when a redraw of a model has improved this statistic.

Another example of ambivalence is the size of the elements on the diagram. We typically let each task have the size dimensions in the model. However, how strong is this natural rule? When the description of the task is large enough to necessitate a resize of the task to keep the description readable, do we resize only that task, or go about adjusting the dimensions of all tasks to keep this uniformity in the model? Another approach could also be to make the tasks that are more important than others larger in the model. This concept of importance is not there in BPMN 2.0. All tasks are created equal. We could even see that the color of the elements could be given a semantic meaning, to be agreed upon by all stakeholders. Naturally, all “extensions” upon the BPMN syntax are unknown to outsiders, and adds to the difficulty when bringing new stakeholders into the fold. When adding additional syntax such as color coding, a legend in each diagram is almost a necessity to minimize to learning curve. Studies however reveal that experts of the notation becomes less and less dependent on such extensions.

There are several layout techniques that can be applied to make the overall process model more comprehensible. Layout techniques address the overall presentation, much like the consistency of the flow. Some of these layouting techniques such as the Manhattan layout (otherwise known as the orthogonal layout) have migrated from Very-Large-Scale Integration chip design (VLSI) where all edges are oriented along a the coordinate axes of the diagram into general graph design, and as such can also be applied to process model diagrams. However, this is more a consideration for automatic layout generation, as humans tend to apply this type of layout naturally, aligned with whatever reading direction we are most accustomed to.

The study also references a previous study done by Reijers, Mendling,… called “A Study into the Factors that Influence the Understandability of Business Process Models”. This study identifies two different types of factors: Model factors (relating to the process model itself) and personal factors (relating to the personality and knowledge of the reader).

Model factors act on the process model characteristics, of which the more obvious ones are density and structuredness. These factors can have several measuring points of which the study proposes the following:

• Abstraction Gradient: A quantification of the grouping capabilities of the model notation. Most notations are abstraction-hating since there is no straight-forward possibility to group together elements that are closely related to each other.
• Hard Mental Operations: The complexity of the model depends for a large part on the number of elements in the diagram, as well as the number of different elements. The more complex and large a model becomes, the harder it is to easily understand how the process works.
• Hidden Dependencies: The visibility of all dependencies. Are there dependencies not shown or easily deduced from the model. This is a concept that typically pops up in BPMN when we have several branches splitting of other branches, and it becomes more difficult to gauge which merge gateway is related to which split gateway. Especially when the gateway has been dropped, and is implicitly there.
• Secondary Notation: Extra information added to the model. The color coding I talked about earlier would be a prime example of how we would extend the model notation with non-formalized rules and syntax.

Personal factors are related to the target audience of your process designs. What is their level of expertise and education? This heavily influences the complexity of the process design you can present to them. The aim is always to effectively communicate the process, and to maximize comprehension of each intended target audience member.

It is clear that there is already some work been done in this area, but no real consistency exists between all studies and personal experiences. The SpringerLink study at least tries to make their observations and suggestions measurable, which merits some added value to the discussion. I feel this topic should at least be tackled in any discussion on where BPMN 3.0 is going, and could make up a new section of the OMG standard. This should probably have a name such as esthetic adherence, but since the two previously mentioned adherences both start with the letter S, maybe something like stylish adherence might be a contender as well?

Thought

BPM

Comment