An introduction to the Activities elements of business process modeling diagrams.
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).
Activities are initially very straightforward – they represent the things that happen within a business process.
A fun and simple example comes from the Underpants Gnomes made famous in episode 217 of Southpark. In short, the gnomes form a corporation that has a single, simple business process with three phases:
- Steal Underpants.
A very funny commentary on many dot-com business models. A BPMN diagram of the gnomes’ corporate plan looks like the following:
Each box with a rounded rectangle represents an activity. The activities flow as drawn with the solid arrows from each rectangle to the next. Notice that the activity for “Phase 2” is different than the other two activities – there is a small box with a plus sign (+) in the center of the bottom of the rectangle. The other two activities do not have a plus sign.
BPMN tasks are easy to read – what you see is what you get. There is one task, represented by one rectangle. This is the simplest form of activity used in business process modeling.
BPMN sub-processes are a very handy way to roll-up, or combine a whole process into a single activity. This is a great way to make high level process diagrams easy to read. The plus sign inside the rectangle indicates that it can be “expanded” – that there is another process inside of it. For the software folks out there, this is a simple form of encapsulation. For the non-software folks, a sub-process is a level of abstraction that allows us to talk about an entire process as if it were a single step.
We could create diagrams without subprocesses. To be useful, business process modeling has to go down to a pretty detailed level of representation. Any relatively complex or large process will quickly become unreadable if every detailed step were displayed.By analogy, think about the wiring diagram for a computer motherboard. We can see a bunch of boxes (chips) connected to each other. Someone who knows how to interpret the traces on the motherboard could understand this. Inside each chip are millions or billions of additional boxes and steps, encapsulated like the sub-process activity. If we had to look at all of those circuits whenever we looked at a motherboard, we would be overwhelmed with complexity. When we don’t need to look at the details, we show the sub-process. When we do need the details, the sub-process will be defined separately.
The gnomes in the Southpark cartoon are funny because they have no idea what the sub-process is. They are just merrily working against the high level plan that we showed in the example. The problem for the gnomes is that they never created the sub-process. Reminds us of the “advertise website during the superbowl, ????, profits!” model.
Business process modeling allows us to draw easy to read diagrams that show the steps in a business process. Each step is an activity, and there is a flow from one activity to another. Some activities are tasks that represent a single action, while other activities are sub-processes that represent an entire contained process.
There are more details and ways to diagram tasks and sub-processes. We will discuss them soon.