People sometimes ask me, what is Method and Style? For a quick marketing answer, you can watch this Ignite video. But if you want a concrete example, read on…
Method and Style is a systematic approach to creating what I call “good BPMN”… not simply correct according to the spec, but models that fulfill BPMN’s real mission, which is communicating the process logic visually, so that it is understood clearly and completely by those who don’t already know how the process works. Unfortunately, that was never a goal of the BPMN 2.0 task force in OMG, so the spec calls “valid” many models that fail that test. Achieving it requires a methodology and additional rules beyond those of the spec. I call mine Method and Style.
The Method is a 5-step procedure for translating process information gathered from stakeholder interviews and workshops into properly structured BPMN models. I’m not going to discuss that now. BPMN Style consists of the additional rules… much easier to understand than methodology, and even better when the rules are incorporated in your BPMN tool, as they are in ViziModeler from itp commerce, Trisotech BPMN Editor, and Signavio.
A fundamental principle of Method and Style is “if it’s not in the diagram, it doesn’t count.” Like an iceberg, most information defined by the BPMN spec is “below the waterline”. It’s in the XML serialization, but it has no visual representation in the diagram. That’s fine for programs that execute the model, but useless for visual communication. The vast majority of BPMN modelers are not trying to automate the process. They’re merely trying to describe how it works, for documentation, analysis, or possibly business requirements for IT.
A good example of BPMN Style concerns the labeling of XOR gateways and end events. In the BPMN spec, each gate of the gateway tests some condition based on data known to the process at that point. Again, in executable BPMN – i.e., modeling automated processes – this makes perfect sense, because the design tool lets you (or more likely, a developer) define the variables and conditional expressions in some programming language. The names of variables and the gateway conditions don’t appear in the diagram. All you have there are labels. Tools for process modeling (as opposed to executable design) – like Trisotech, ViziModeler, and Signavio – don’t even let you define data and conditional expressions.
So there is a disconnect between the BPMN spec and what process modelers are trying to do. Enter Method and Style, which adds a constraint: The condition tested by each gate (outgoing sequence flow) of an XOR gateway must be the end state of the previous activity. End state simply means, how did that activity end, successfully or in some exception state? We name end states noun-adjective, or sometimes simply an adjective phrase, like Credit OK or Item out of stock. So applying that name to the gate label unambiguously defines a data condition, without the need to define variables or an expression language.
But there’s more to it. If the previous activity is a subprocess, there is an additional style rule, which says that each end event of the subprocess corresponds to a distinct end state, again labeled noun-adjective or adjective phrase. (If the previous activity is a task, you cannot look inside it to see its end events, so its end states are simply implied by the gateway.) And one more rule: Each end state of an activity corresponds to a different next step in the flow.
Put these together and you see the following:
- If a subprocess (or process) has multiple end events, each must be labeled as an end state.
- An XOR gateway must be preceded by an activity, and the gate labels describe the end states of that activity.
- The count of subprocess end states must equal the count of gates on an XOR gateway following the subprocess.
- The labels of the subprocess end states must match the labels of the gates.
Validation in the tool reports any violations of these and other style rules.
While constraints like these might seem overly restrictive at first, in practice it turns out they are not. Their value is that they allow the consumer of your BPMN models to trace the logic from parent level diagram (with gateways) to child level diagram (with end states) in a simple mechanical way, by matching the text labels. Here is an example. In the top-level process diagram below, Collect payment is followed by a gateway with gates Charge ok and Charge failed. Method and Style says that means that Collect payment has two end states – two different ways it could end – called Charge ok and Charge failed.
To someone unfamiliar with the process, the meaning of Charge failed is not yet completely clear. Clarity comes from drilling down to the child level diagram. The instances that take the Charge failed gate are those that reach the child level end state named Charge failed. It’s simple label matching. From that, we see that Charge failed means that the automated initial attempt to charge the credit card failed and a subsequent human attempt to resolve the problem also failed.
This basic mechanical device can be a big help when the consumer does not already know how the process works or even the terminology employed.
Style rule validation in the tool checks that the child end state and parent level gate labels match. Style validation not only improves model quality and readability, but it teaches modelers the rules. After fixing the same error two or three times, they stop making that mistake.
Get your whole process modeling team on the same page. BPMN Method and Style training teaches you not only the shapes and symbols, but the Method and the Style rules. The training includes 60-day use of a tool that supports style rule validation, lots of hands-on exercises in class, and post-class certification based on an online exam and mail-in exercise that must be iterated until it is perfect. Over 1300 have completed the certification, which demonstrates mastery of both BPMN and Method and Style. The training is available web/on-demand, live/online, and live/onsite. Check it out.