A reader asked me to comment on an interesting paper by the European BPM academics Mendling, Reijers, and van der Aalst entitled Seven Process Modeling Guidelines (7PMG). Like my book BPMN Method and Style, 7PMG is asking the right question: what are the principles of style that improve a model's chance "(1) to become comprehensible to various stakeholders and (2) to contain few syntactical errors." I don't completely agree with their recommendations. See what you think.
They begin with the refreshingly honest statement (with which I concur 100%):
A notorious problem is the low level of modeling competence that many casual modelers in process documentation projects have.On the other hand, the authors' assumed tool for these folks is ARIS or Casewise, which are really tools for architects not casual modelers. The diagrams in the paper are all EPC. I wonder why they did not write the paper in context of BPMN. But let's look at the recommendations. After applying some academic hocus-pocus, they arrive at the following prioritized list:
- Make the model as structured as possible. That's one of my top ones also, but they mean something completely different than I do. To Mendling et al, "structured" means "block-structured." That would make Michael Rowley happy, but not mainstream BPMN modelers. No, I think these guys are living in a BPEL yesterworld. Enforcing block struture probably does reduce syntactical errors, but at a heavy price: Only developers are willing to go along with it. In BPMN Method and Style, I emphasize structured models as well, but I mean hierarchical structure, in which a single end-to-end semantic model can be viewed at different levels of detail.
- Decompose a model with more than 50 elements. I'm not sure what constitutes an element, since EPC diagrams include everything but the kitchen sink. In BPMN, my recommended style limits you to 5-10 activities in a process level (subprocess).
- Use as few elements in the model as possible. In other words, if an element is redundant, leave it out. I agree with that. But how did it make the top 3? Kind of a motherhood statement.
- User Verb-Object activity labels. Yes I have that one too.
- Minimize the routing paths per element. I agree that expressing process variation by overuse of gateways and alternative paths makes models harder to read. But minimizing routing paths as a broad guideline seems misguided. The model should reflect how the process works, first and foremost. I think the most likely response to 7PMG's recommendation would be to omit exception paths from the diagram entirely. Which would be a bad thing.
- Use one start and one end event. I'm on board with one start event, but definitely NOT one end event. Using separate end events to represent distinct end states of a process or subprocess is critical in my method and style. It's what makes hierarchical diagrams traceable from the top down.
- Avoid OR routing elements. Again the BPEL/block bias. But it would seem to contradict items 3 and 5 above if the process semantics really are conditionally parallel flow.