[Posted 6 Sept 2007 on BPMInstitute.org]
One of the most powerful features of BPMN is the least appreciated? by modelers and tool vendors alike. I?m talking about subprocesses. Most of the process models I have seen would be much improved if they were used more liberally, and more effectively.
In BPMN, a process is viewed as a flow of activities, and an activity ? a rectangle in the diagram ? can signify only one of two things: a task, meaning it has no subparts of interest to the model, or a subprocess, meaning the activity has subparts of significance to the model. So right off the bat, any process activity can be represented as a subprocess, whether you show the internal detail or not. In BPMN, you can draw a subprocess either collapsed as a single rectangle with a + symbol inside, or expanded ? either inline in the diagram or in a separate linked diagram. Both representations mean the same thing; they just show different levels of detail.
In my BPMN training we talk about five fundamental benefits of subprocesses. The simple idea that any process fragment can be displayed either collapsed or expanded accounts for Benefit #1. Subprocesses allow the end-to-end process to be described at multiple levels of detail.
When you are first capturing the workings of an as-is process, it?s ok to begin with a ?flat? model taking thirty feet of wall space. But flat models are no good for shared process understanding. Better to start with a top-level view in which the whole end-to-end flow fits on one page, using very coarse-grained subprocesses. Then you can expand any of those top-level subprocesses in another BPMN diagram. Ideally, all these second-level diagrams should be hyperlinked to the top-level diagram, and in a few tools they are. The second-level diagrams probably contain subprocesses as well, so you can use this nesting technique to drill down to any level of detail without losing the end-to-end context.
This feature of subprocesses in BPMN accounts for their second benefit as well. Subprocesses encourage top-down thinking and analysis, also known as the end-to-end view. Use BPMN subprocesses to describe the entire process, end to end, on one page, so the handoffs between the major process components are visible to everyone from the start. BPM as a management discipline is all about breaking down the functional stovepipe views of business that stymie performance improvement and replacing them with end-to-end views and KPIs. If you use BPMN correctly, the end-to-end view is not an ?artist?s conception? but actually the top-level of a real working model.
A third benefit is that subprocesses fit well with distributed process ownership. Each part of an end-to-end process may be only known in detail, and ultimately controlled, by a different group within the enterprise. If the top-level diagram accurately describes the interaction between those parts, including the exception paths, then each part can be modeled and maintained independently, while preserving the integrity of the end-to-end process.
A fourth benefit is that subprocesses are ideal representations of business services in SOA ? units of business reuse that can be invoked by various processes and composite applications. In its collapsed representation, a subprocess describes the inputs and outputs of the service, and where it fits in the business context. Expanded, it can describe and analyze the inner workings of the service, whether or not it is implemented in a BPM suite.
The fifth benefit of subprocesses is in some ways the most powerful, but the least understood by process modelers. In BPMN, a subprocess defines the scope or context of an event, meaning the boundaries of the part of the process where some external signal ? cancellation of an order, for instance ? is valid and can be acted on in a particular way. If the event occurs before that fragment starts or after it ends, it can be ignored. In fact, a subprocess in BPMN may have no business significance other than describing when a deadline timer starts and ends, or where an error results in a particular action.
Developers using BPEL are familiar with this. In fact, BPEL calls it a ?scope? and its primary purpose is to create start and end points for errors and events. As BPMN-based BPM suites increasingly add support for scoped events to their execution environments, process analysts using BPMN will need to understand that behavior in order to effectively model exception paths in their processes.
If your process modeling or design tool doesn?t support these five ways of using subprocesses, you should ask the vendor why not? or start looking for another tool. BPMN imposes some rules on subprocesses that take some getting used to. For example, a sequence flow cannot cross the subprocess boundary. But it?s all readily understandable by a business analyst with a little training.
If you want to step up your modeling game, subprocesses are usually the place to start.
Bruce,
Your observation that “In its collapsed representation, a subprocess describes the inputs and outputs of the service …” is not entirely correct given that one thing a BPMN diagram doesn’t show is data-flows.
Data (ie inputs and outputs) available to a sub-process might be inferred by the observer and in fact might be defined in sub-process/task attributes, but they are not explicit in a BPMN diagram.
Adding annotations to flow lines is one way of providing this information on a model, but that is somewhat redundant if data definitions are also recorded in process attributes.
Bruce,
Your benefit no. 5 reminds me of the transaction concept in database systems: A database transaction, by definition, must be atomic, consistent, isolated and durable.
BAs can and should be asked to think in terms of encapsulation or less technically “all or nothing” to make systems easier to design and less prone to patchwork from change requests.