More on What is a Process

I received an email today from a reader asking: "If you have multiple call activities that occur within a process pool, is there any reason you can't create another pool for Call Activities and use that to group the call activities / processes, other than the fact that a sequence flow connection cannot be used?" Again, I think this goes back to the issue of what is a process in BPMN. Recall that a process is simultaneously a collection of activities linked by sequence flow AND an independent actor - an imaginary (or possibly real) process engine - that requests the performers of those activities to do their thing. A Call Activity is just like a subprocess with the exception that the called process is defined independently of the calling process, usually in a separate document. In a Call Activity, the process as an independent actor "calls" the external process, but it does not mean that the performers of the called process are external. Since the Call Activity is an activity in the process, its performers are "inside" the process, so you would not represent the called process as an external pool. If you wanted to represent the called process as an external pool you would use Send and Receive tasks (or throwing/catching Message events), not Call Activity. In that case, the process as an independent actor also effectively "calls" the external process by sending a message, which is the source of the confusion. I would note also that Method and Style asks you to model an end-to-end process as a single BPMN process "if you can" - and the reason why you sometimes cannot has to do with instance alignment, not the actors - so it would generally prefer Call Activity to Send/Receive tasks in this case.

For executable BPMN, there are some additional technical differences between a process called with Call Activity versus a message. With Call Activity, as with a subprocess, data is passed between calling and called process with data associations not messages. Also, the Call Activity and called process are supposed to magically be aware of the other's state, so if the calling process terminates abnormally (e.g. via Terminate or Error event) before the called process is complete, the called process is notified somehow and is terminated. Also, an Error end event in the called process can be caught by an Error boundary event on the Call Activity. If you model the called process as an external pool linked by messages, you need to model all that synchronization explicitly.

Actually, I doubt that the principal authors of BPMN 2.0, IBM, Oracle, and SAP, who were so meticulous on the execution semantics, even respect these technical nuances in their own BPMS implementations. For me, a the bigger issue is for non-executable models: when to model a called service using Call Activity versus a black-box pool versus a white-box pool. I tend to fall back on the principle that the detailed process logic of external actors is unknown to the process, so if the performers of the called process are "external" to the organization providing the process, it's best to use a black-box pool. If you know the details of the called process, and the instance is aligned with the calling process, it's best to use a Call Activity (and model its performers as a lane). But reasonable people can disagree on that.