Business process modeling examples showing how to use the five different gateways defined in the BPMN specification.
We presented an introduction to BPMN diagrams last week. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.
The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).
Gateways are the evolution of the diamond-shaped boxes we’re accustomed to in flow charts. In BPMN, gateways can have one of five distinct interpretations. The gateways are used in diagrams both to separate flows and to recombine them.
- Exclusive OR (XOR) Decision/Merge based on data
- Exclusive OR (XOR) Decision/Merge based on an event
- Inclusive OR (OR) Decisions/Merge
- Complex Decision/Merge
- Parallel Fork/Join
Exclusive OR (XOR)
An exclusive OR, which logicians call XOR, represents a decision to take exactly one path in the flow. More than one path can not be taken – they are mutually exclusive, hence the name. This is the behavior generally assigned to the familiar diamond from flow charting.
Data based XOR Gateway
The first thing to note is that this gateway can be drawn in either of two ways. It can be drawn as an empty diamond, or as a diamond with an ‘X’ in it. Whatever style is chosen, it should be consistent within the diagram and all diagrams. We prefer to use the diamond with the ‘X’ in it.
In our business process modeling example above, after opening the mail, the person will either read the mail (and then discard it), or discard it without reading it. The first gateway represents the choice based on data available in the process. The available data is the content of the mail (either junk or real).
The second gateway is optional. We also could have drawn the diagram as follows:
Event Based XOR Gateway
When an event, such as an external message, causes us to make an exclusive OR (XOR) decision, we use a different XOR gateway. The distinction is if the information required to make the decision is available within the process (use data based) or comes from an external source (use event based). This will make more sense when we consider the example business process model.
In this business process modeling example, our actor invites a girl to the prom. If her response, a message that is external to the process, is yes, the actor rents a tuxedo and attends the prom. If she says no, he will stay home and play XBOX games all night.
We could also have modeled this by bringing the girl’s response into the process as data. Once it is in the process, we would use a data based XOR gateway, as shown in the following example.
This alternative approach, while potentially easier to read, is also more verbose (Adding an extra task to the process). Either style is acceptable in the BPMN official spec. We suggest using the event based gateway for a cleaner diagram.
Inclusive OR Gateway
An inclusive OR Gateway specifies that one or more of the available paths will be taken. They could all be taken, or only one of them.
In this example of a business process model, our actor purchases a car. After that purchase, if the car needs to be cleaned, it will be cleaned. Also, if it needs to be repaired, it will be repaired. If the car needs to be both cleaned and repaired, both things happen. The possibility that neither a cleaning nor repairs are required.
The first OR gateway represents the control of the flow of the process along one or more paths in the model. The second OR gateway represents the reconnection of those paths and the continuation of flow. When reconnecting paths like this, the OR gateway explicitly requires that all paths that were activated must be completed prior to continuing in the process.
By explanation, if the car needed only to be cleaned, then the car may be driven once the cleaning is done. If the car needed to be both cleaned and repaired, the car could not be driven until both the cleaning and repairs were completed.
Complex Decision Gateway
A complex decision gateway allows for a more expressive decision within a business process. Multiple factors, rules and analyses can all combine to yield results. The analysis should result in at least one path always being taken.
In this business process modeling example, our student takes the SAT (a college entrance/aptitude exam common in the USA). If the student scores under an 800 (the possible scores range from 200 to 1600), the student will enroll in an expensive class to improve his test score – and then retake the exam. If the student performs moderately, he will read a low-cost book designed to help him improve his score – and then retake the exam. If the student scores above 1000, he will immediately attend university.
A parallel gateway (also called a fork, or join) is used when a process can perform multiple branches of operation in parallel.
In this business process modeling example, our inventor invents a better mousetrap. The process flow then splits (forks) into two parallel paths. Along one path, the inventor files for a patent. In the other branch, the inventor creates a prototype. Once both of those steps have been completed, the inventor gets rich.
A fork gateway (the first one) explicitly states that all paths must be followed. A join gateway (the second one) explicitly requires that all paths have been completed before advancing the process. Our inventor can not get rich without a patent, and also can not get rich without a prototype.
We now know how to use the five different types of gateways in our business process modeling diagrams. We should use the BPMN diagramming standard to make our diagrams consistent within and across projects.