Drawing business process diagrams can be tricky. Just getting the layout on the page to look good can be tricky. Intermediate link events can be used to clean up diagrams. They can also be used to jump from a specified point in one process to a specific point in another process.
Background
We presented an introduction to BPMN diagrams in July. 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).
Intermediate events are one of the more unfamiliar items in the BPMN language. They also allow for some of the cleanest, unambiguous expressions of steps in business processes.
Business Process Model of a Requirements Analyst
One of the many jobs of a requirements analyst is to document requirements. Ideally writing good requirements, but regardless of quality there is a process to follow. First we review a classical flowchart of the requirements documentation writing process.
The requirements analyst begins by writing a requirements document. If she gets the document approved, she will baseline it and be done. If the document is not approved, it may only need editing, or it may need to be started over from scratch. If the document is edited, the approval process is repeated. If the document is approved after editing, it will be baselined. Otherwise, it will either be edited again or the requirements analyst will start over from scratch.
The “go to A” symbol and the “A” symbol work together to jump around on the same page without cluttering the diagram with too many lines (or line crossings). This is a handy tool in classical flowcharting, and BPMN has an analogous symbol.
BPMN Example
In this BPMN example of the same process, we use a link intermediate event to control the jumping around.
The requirements analyst writes a requirements document, then the flow proceeds to a complex gateway. If the document needs to be rewritten, flow returns to the original task. If it only needs to be edited, flow continues to the “Edit Requirements Document” task. If the document has been approved, it will be baselined and then the process will end.
A link intermediate event follows the “Edit Requirements Document” activity in the diagram. There is a single normal flow branch feeding into one of two link events. When control reaches this first half of the pair of link events, it jumps to the second link intermediate event at the top of the diagram. Flow proceeds from this link event to the complex decision gateway.
Summary
Using link intermediate events is just as powerful as using the “go to” symbols in a classical flowchart.
Um, shouldn’t the link event feeding the complex gateway be ‘catching’, and therefore unfilled? It appears there are two throwing ink events on the diagram and no catching link event.
Hey Mark, thanks for the great question – you may very well be correct. I haven’t used BPMN since 2009, unfortunately. The project for which I learned it ultimately went with standard swim lanes and flowcharts. Five years later, I’m worse than rusty.
You were correct at the time Scott. The throw/catch distinction was introduced after you posted this article.
Thanks, Chris!
Any suggestions on a comparable article, with examples that show the current specs? I’m sure that anyone who finds this article would appreciate it.
Other sources say that intermediate link events link to another part in the same process. However, you say that they can also link to a point in another process. Which is correct?