BPMN Diagrams document business processes. Those processes have a flow to them, and that flow can branch and merge. It has a beginning and an end. Flow happens from the perspective of a single organization or person – but multiple people can talk to each other. Learn how to diagram flow and messaging in this article.
Background
We presented an introduction to BPMN diagrams two weeks ago. 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).
Be One With the Flow
There’s an interesting notion of encapsulation and perspective that is implicit in BPMN diagrams. When drawing a diagram, each actor or entity has their own view of their own process. And those two processes talk to each other with messages.
The pool on the left represents the customer’s process, and shows the flow from the perspective of the customer. The pool on the right shows the flow from the perspective of the bank. Flow is drawn with solid lines and solid arrowheads. The customer and the bank send messages back and forth to each other, denoting their shared perspective on how they interact. Messages are drawn as dashed lines with hollow arrowheads and hollow circles (to indicate the direction in which the message is passed).
The business process modeling example below shows an interaction between a customer and an extermination company. The customer and the exterminator each have their own pools. This example process also shows some details about what happens within the extermination company. There are two swim lanes, one for the phone rep, and one for the technician.
From the customer’s perspective, the business process is “request service” (sending a message) and “receive service” (receiving a message). From the exterminator’s perspective, the process is “receive request” (receiving a message) followed by “schedule service” and “perform service” (sending a message). “Schedule Service” and “Perform Service” are diagrammed as subprocesses – activities that represent simplifications of more complicated processes.
Within the exterminator pool, we have two swim lanes – one for the phone rep who answers calls from customers, and one for the technician who goes out and performs services. The swim lanes make it very visible who performs which task. The phone rep clearly does not provide services, nor does the technician schedule services to be performed.
Process Flow and Messages
There’s an important rule in BPMN about how flows and messages are diagrammed. Flows always happen within a swim pool. Messages always represent communication from one pool to another. The interactions between the customer and either exterminator employee are messages, because they cross from one pool into another. The interactions between the sales rep and the technician are flows because they happen within the exterminator pool, even though they cross swim lanes.
Two actors within the same company will never message each other – the business process will always flow between them.
