Embedded versus Re-usable Subprocesses in BPMN
Anatoly often posts the best examples and cautionary tales in BPMN2. In the latest post, he derides the limited usability of Swim Lanes in BPMN 2 – And he has a point. On the one hand, embedded subprocesses can’t have swim lanes (the best way to think about these is simply a set of collapsed activities, for notational convenience). On the other hand, “Reusable subprocesses introduce additional complexity because unlike embedded they are executed in a separate data context”. Anatoly’s conclusion is that overusing reusable subprocesses is bad practice, because of this overhead. I conclude differently: the BPMS should minimize or optimize this overhead – and the business process designer should be able to ignore it on a robust BPMS. To make a coding analogy: we should be talking about the difference between an embedded block of code and a function call. Yes there is overhead, but it should be managed by the BPMS transparently. In fact, some BPMS authoring environments don’t even allow for the embedded subprocess- treating it as just a special case of the reusable subprocess who’s primary difference is that it doesn’t happen to be re-used. I don’t think we should optimize around the shortcomings of a particular BPMS too much, in terms of our general BPMS modeling advice. However, I’ll concede that once you’ve chosen your BPMS, you might as well optimize somewhat around its capabilities as they become known to you, and model accordingly.