Perhaps the greatest failing of the BPMN 2.0 spec is the inadequate explanation of its most fundamental concept: process. That failure lies at the root of so much confusion and modeler error.
A process in BPMN has four distinct aspects: as an “orchestration”, as a collaboration “participant”, as a container of activity performers, and as an actor in its own right. It is all of these things at once.
As an orchestration…
The spec defines a process as “a sequence or flow of Activities in an organization with the objective of carrying out work.” Mmmm… no. A process is that, but many other things that are not a BPMN process are that as well: a case in adaptive case management, for example. A process in BPMN is a certain kind of activity flow with the objective of carrying out work, called an orchestration. An orchestration is not just any old set of activities intended to do some work. The set of activities must be performed repeatedly in the course of business, meaning it has instances with a well-defined start and end. It is not some business function performed continuously. Books of BPM architecture famously talk about Management Processes – Manage This or Monitor That. These are not BPMN processes because they are not performed repeatedly on instances.
The phrase “carrying out work” implies some particular initial state of the instance and some desired final state. BPMN acknowledges the possibility that some instances may not reach the desired final state but will end in some other exception end state. In fact, a BPMN process is not merely a log of the path of one instance from start to end but a map of all possible paths from what is normally a single initial state (start event) to any allowed end state (end event). Only paths defined by the process are allowed. Ad hoc insertion of new activities for a particular instance is not allowed, and you can’t do the activities out of the prescribed order, either. That’s orchestration. These are the constraints that drive ACM people batty. They would maintain that real processes don’t work that way. I would say that many processes do work that way, and many do not. BPMN is really well suited only for those that do.
As a participant…
Many people confuse BPMN’s term participant with the performer of an activity, but that is incorrect. In BPMN, participant and performer are different things entirely. A participant is defined in the context of a collaboration, that is, a pattern of interactions between a process and entities external to it. It only has meaning in that context, and in that context, the process itself is one of the participants, and other pools in the collaboration diagram represent the other participants. If those pools are empty, or black-box, they are not associated with any process. In other words, the process as a whole is an actor in some interaction with other entities. If the process describes a seller’s order handling, for example, the buyer would typically be represented as an external participant. You might say the participant on the process side is not the process itself but its role in the collaboration, seller. There is logic in that, but in the BPMN 2.0 metamodel, a participant (that is not a black-box pool) is uniquely associated with a SINGLE process. So even if you label the process pool Seller or MyCompany, the participant represented by the pool does not really mean that role or entity in general but just Seller/MyCompany’s order process. Any other process performed by Seller/MyCompany would need a different participant id. That’s why I say that in a collaboration, a process IS one of the participants.
In my book and training, for that reason, I recommend that process pools, if drawn, should be labeled with the name of the process. It’s the only place in the diagram where the process name appears. But that drives some folks nuts, and I still get occasional hate mail for it. If you want to label your process pool MyCompany, go right ahead. The spec is silent about the link between shape labels and the semantic elements. But the unique association of the participant with one particular process cannot be denied.
As a container of performers…
As evident from the above discussion, a person or system performing some action related to the process can be either inside or outside the process. It must be one or the other, not both simultaneously. What does that really mean? Again, the spec is largely silent. If an activity is part of the orchestration, it is inside the process, and its performer is implicitly inside as well. But that really begs the question. Is the Customer inside or outside? I think normally outside, because of their participant role in the collaboration. Employee-facing processes are a gray area. They are part of the organization providing the process, but they may have no defined performer role in it. They might simply be an effectively “external” requester.
Modelers are thus faced with deciding whether various actors are inside or outside the process, whether their actions connect to the rest of the process via sequence flows or message flows. Other than saying a particular actor must be either inside or outside, not both, there is no absolute rule about it.
As an independent actor…
This aspect is strangest of all to business people, but it’s baked into the concept of orchestration. We say that the performers of all activities inside the process are themselves part of the process. But who is the “performer” of a Message end event? What actor sends the message? It actually is “the process” itself, not a performer. In a BPMS, it would be the process engine, but even in non-executable BPMN this “virtual process engine” is implied. It derives from BPMN’s origins as a service orchestration language, a graphical front end for BPML and later, equally unsuccessfully, for BPEL. In web services, there is a service requester and a service provider. In BPEL, an invoke node in the process was the requester and the partnerLink, the service endpoint, was the provider. BPMN tries to hide the distinction, but it’s still there. In a BPMN activity, the “process” is the requester and the “performer” is the provider. A Service task implies the performer is “inside” the process and a Send/Receive task pair implies the performer is “outside”, but there is no fundamental difference. (A Script task means there is no performer; the action is performed by the process itself.)
While these aspects are fundamental in executable BPMN, they are less critical in non-executable models. Nevertheless, appreciating all four aspects of process is helpful to all modelers in making decisions about what is inside the process and what is outside.
Thanks for raising this topic, Bruce.
Apart of said above, two key aspects of BPMN processes are often missed:
– BPMN processed are discrete – one needs to cut the continuos flow of work to some finite chunks before applying BPMN
– inputs and outputs of BPMN process are events, not resources as most people assume
Thanks Anatoly. For your first point, the way I say it usually is that many real-world business processes cannot be modeled as a single BPMN process because of batching, i.e. if one activity is once per order and another is once per month, they must be in separate processes. This I believe is the chunking you refer to, and it is also baked into the concept of orchestration. And that means I must restate a point I made in the post, which is that a resource cannot be both inside and outside the process. That is probably good advice for abstract participants (black box pools), but because of this chunking, an actor may in fact be represented in two separate pools that interact via message flows, i.e. simultaneously inside and outside a BPMN process.
Actually I referred to things like “steel production process” or “brand promotion process”. People try to apply BPMN to these yet it’s only possible after some decomposition and splitting such “processes” into discrete and repeative sequences of work, e.g. “oil well lifecycle” or “advertising campaign”.
When I started out mapping the Enterprise Architcture language ArchiMate to BPMN I also wrestled with BPMN’s Participant & Process. A write down can be found at http://wp.me/p1z6Wc-c6
Very glad, btw, that I found Bruce’s book before designing the link.
Thanks for one of the marvelous posting! I seriously enjoyed reading it, you’re a great author.I will be sure to bookmark your blog and definitely will come back in the foreseeable future. I want to encourage you continue your great job.
How about the case of a catching message event within process P1 thrown from another process P2? Who is the “performer” of the catching message event? Since performers make sense for activities, what would be the extension of “performer” meaning relative to catching events? No “performer”, just “execution” by engine, I assume…
Cristian,
In BPMN, only activities have performers. Events and gateways do not. But if you substitute Send and Receive tasks for the message events, it is a valid question. In my view, Send/Receive tasks act like events, and have no performer. They are just flow control nodes. The action performed – sending or receiving a message – is done by the process as a whole. In an executable process, it makes a bit more sense, “process” meaning the process engine vs “performer” meaning some other “internal” resource.
I know performer doesn’t apply to events, I used the quotes around performer. In my opinion, the performer attribute exists on tasks other than User Task simply because in the BPMN model the performer attribute was added to abstract Task instead of just to User Task.
Thanks for always replying to me.