Earlier, I wrote about an ongoing attempt to map #BPMN to #ArchiMate. Now that some time has passed, we have come to a solution, though at this stage it is not yet 100% complete. In a couple of posts, I want to explain what the solution is, and also a bit on what the stumbling blocks to a solution were. In this post, I discuss one of the important issues: BPMN’s Pools and Processes.
The previous post in this series about ArchiMate and BPMN can be found here.
Coming from ArchiMate, the first stumbling block was of course properly understanding BPMN. Very helpful in that respect was Bruce Silver’s “BPMN Method & Style”, which, I must say is understandably the ‘gold standard’ for BPMN modeling out there. Very usable and lucid. Studying BPMN with Bruce’s help resulted in me understanding something about BPMN that — if I look at many other examples and publications — is understood in a couple of contradicting ways: the meaning of Pool/Participant in BPMN.
BPMN took the rather unstandardized ‘flow charting’ and formalized it. In that formalization, they chose the following setup:
- A Process contains Activities connected by sequence flows (and gateways, but that can be safely left out at this stage);
- A Participant (which may also be called Pool, the terms are synonyms in BPMN, that is: a Pool is the ‘graphical representation’ of a Participant) may or may not contain a Process. If it does not, it is a ‘black pool’: the Participant is there, but the actual process details are unknown.
- Between Pools, only message flows are allowed, between Activities inside a Pool, only sequence flows are allowed.
I was looking for a way to map ArchiMate’s Business Actor, Business Function, Business Role and Business Process to BPMN. And my first idea was to use BPMN’s Swim Lanes for ArchiMate’s Business Roles (because that is closest to how Swim Lanes are generally used) and I was wrestling with te question what to map BPMN’s Participant/Pool to. Business Actor? Business Function?
As I was studying the specification, I first thought that I had to see BPMN Participant as the performer of a BPMN Process. This is easy to conclude because the BPMN 2.0 spec actually says this in the text (formatting mine):
A Participant represents a specific PartnerEntity (e.g., a company) and/or a more general PartnerRole (e.g., a buyer, seller, or manufacturer) that are Participants in a Collaboration. A Participant is often responsible for the execution of the Process enclosed in a Pool; however, a Pool MAY be defined without a Process.
In other words, according to the text of the BPMN 2.0 specification, the Participant represents a performer (of a process).
But then I noted something strange in the UML Class Diagram that describes the relation between Participant and Process (Figure 9.7 on page 115 of the BPMN 2.0 Specification):
What this means is that:
- A Participant may maximally only ‘have’ one Process (it may ‘have’ no Process for a ‘black pool’). This is the meaning of the “0..1” label on the relation;
- A Process may be ‘of’ zero or many Participants. This is the meaning of the “*” label on the relation.;
Now, if you see a Participant as the performer of the Process, this is weird and opposite of what you would expect: namely that a performer can perform (‘have’) multiple Processes. Not allowing for a ‘performer’ to perform multiple processes is weird. Why can the Client (a clear ‘performer’) not perform two clearly different processes such as ‘buy product’ and ‘claim warranty’?
BPMN has more in its metamodel, which clears up some of the confusion. It has in fact an explicit ‘Partner’ concept in its metamodel. Actually it has two: PartnerEntity for what we in ArchiMate might call Business Actors and PartnerRole for what we in ArchiMate might call Business Role. They have no structural relation with each other in BPMN as they have in ArchiMate, but they exist as two independent variants of the same. From now on, I will call these together ‘Partner’.
Extending the previous fragment of the UML Class Diagram for Participant to
we see both Partner and Process and the Participant concept linking them. In fact, in BPMN, the real ‘performer’ is the ‘Partner’ (or multiple ‘Partners’). Linking ‘performer’ with ‘what is performed’ is not a direct relation, but a rather ephemeral object in between that sometimes looks like a performer and sometimes like what is performed.
Now, the UML Class Diagram in the BPMN 2.0 specification does not tell the whole story. Suppose we create not a Class Diagram but a more object-like view with specific processes, pools and partners. The Class Diagram allows something extremely silly like this:
That same process A is performed by ‘Our Company’ but also performed by ‘Our Company’, ‘Buyer’ and ‘Seller’ together. Clearly that does not make sense. It would’t even make sense if Pool Y was only connected to, say, ‘Seller’, because it would mean that Process A was both performed by Our Company and by Seller (quite a different player). Obviously, there are other design rules at play here which are not immediately clear from the Class Diagram (that is a normal limitation of a Class Diagram, btw).
In a diagram which is not quite UML or BPMN, but an unholy mixture of both, it can be illustrated how these types of objects can be used properly. A simple example would be:
This example shows our company that runs an ‘arbitrage’ process, where our process profits from price differences on the different markets where we sell and where we buy while ‘owning’ as little as possible. Our process interacts concurrently with both a seller in one market and a buyer in another. I have left out the possibilities that the messages actually connect to Activities inside the Process, it does not really change the story.
But BPMN’s option to have the same process represented in different collaborations enables us to split this into separate interactions of our process with buyer and seller:
Note that both our Participants represent the exact same Process. In other words, that same process can be part of several pools/participants, but that is only the case so we are able to model the interaction of that process with other processes flexibly and separately. For this to make sense, however, we will have to find the same ‘performing’ Partner ‘behind’ the Participants that represent that same Process, or we will have contradictions and ambiguities.
The BPMN Participant, therefore, is a bit of a chameleon: it represents Partner and/or Process, depending on where and how you look at it. It is not so much a ‘real’ object, but it is kind of a swiss army knife ‘stand in’ in various situations. The text and illustrations of the BPMN 2.0 specification strongly favor seeing Participant as a performer, but the UML Class Diagram in that same spec only makes sense if Participant is seen as a wrapper for what is performed.
So, what to do? That ephemeral object ‘Participant’, that is a bit Process and a bit Partner, how do we use and map it?
Suppose we would say that we map BPMN Participant to an ArchiMate Business Function, we immediately get into trouble. Because the BPMN Processes are often end-to-end processes that may cross Business Function boundaries. In fact, Business Function is something that is pretty impossible to link to BPMN structures. (but more on that later when the complete mappping is presented)
So, should we map Participant (Pool) to an ArchiMate Business Actor or Business Role? That is close to what the BPMN specification’s text tells us. If we do that, we run into the same problem as with Business Functions: you need to choose such a high level abstraction actor or role to be able to catch all the actual roles that perform Activities of the Process.
There is another disadvantage to mapping BPMN Participant to either Business Function, Business Actor or Business Role: if we do, where do we then map ArchiMate’s Business Process visually in BPMN? If we do not map it to a Pool (BPMN Participant), we have to map it to BPMN’s Process. Now, though this makes sense, there is a disadvantage: where do we attach the name of the process? Because weird as it sounds: though BPMN is a language for making descriptions of processes, it does not contain a specific graphical object to represent a process. If we model a Participant with a Process that has a single Swim Lane, and we map Swim Lanes to ‘performing roles’ as customary, there is no place to map the Process name unless we add an extra Lane Set just for that. In other words, even BPMN Processes with a single Swim Lane need to embed that in a Lane Set so that the most outer Lane Set can always be used for the Process name. That does not match BPMN very well and it also feels like kludge.
So, after trying a couple of approaches, this is what we came up with:
- We decided that we see a BPMN Participant is not primarily as the Partner, but as the Process and we link ArchiMate’s Business Process to the Pool (Participant). This is the way Bruce Silver does it too for Processes of which details are known. However, contrary to what Bruce suggests, we do it for ‘black pools’ too: For instant, when you label a ‘black pool’ ‘Client’ in Bruce’s setup, we will label it something like ‘Client’s Process (unknown details)’. The latter deviates from Bruce Silver’s “Method & Style” as he chooses to label a ‘black pool’ with the Partner’s name. Such intelligence is possible in a free-drawing world with humans maintaining all the connections, but it is not possible to automate very well.
- BPMN’s Process represents not so much the process but the process details.
What the ephemeral BPMN ‘Participant’ then is, in our setup, is more a ‘participant’ in a collaboration of processes, not a ‘participant’ in a collaboration of roles/actors‘. In ArchiMate terms: what BPMN calls a Collaboration, in ArchiMate we call a Business Interaction. So, I personally think that BPMN might be clearer if it would state:
A Participant represents a (possible unknown) process of a specific PartnerEntity (e.g., a company) and/or of a more general PartnerRole (e.g., a buyer, seller, or manufacturer) that is a participant in a Collaboration between processes. A PartnerEntity or PartnerRole is responsible for the execution of the Process enclosed in a Participant; however, a Participant MAY be defined without a Process. All Participants that enclose one and the same Process must be assigned to one and the same set of PartnerEntities or PartnerRoles.
That would make more sense in the light of the UML Class Diagram in the specification. But that of course is not up to me and people more knowledgeable might disagree for very good reasons.
Let me end with an observation. ArchiMate is a purely visual language, it has visual elements for all its concepts and relations. BPMN only has visual representations for a minority of its concepts and relations and among the missing visual representations is the one for Process (which is quite amusing). That means that we will end up having to add stuff to BPMN if structure there needs to be visually maintained. More on that later.
PS. If you know both standards, you might wonder why I do not link up BPMN’s Collaboration with ArchiMate’s Collaboration/Interaction. Without going in too much details now: there are some rather unfriendly snakes in the grass when you go that route. Maybe something for another post, also.
[Update Wed 11 June 2014]
Looking back on this post there was one obvious thing I could have added: the confusion may be in BPMN’s graphical representation. That multiple Participants can refer to the same Process might be understood as multiple roles performing activities in that process. This is not quite what BPMN has in mind and certainly not in the way flow charting is generally used to link performers to activities. But that way we could say the a Participant is equal to a performer of a process and can be mapped to either an ArchiMate Business Role or am ArchiMate Application Component (for automated processes). The problem them is that there is no graphical way in BPMN to model it that way. You need to model a Pool for each Business Role and have all these roles contain the same Process without having the possibility to use Lanes for that. It gets pretty ugly. So, we see here again how BPMN is really geared towards cooperating business rule engines where the BRE is the performer (Participant) of all that goes on inside the process. Quite different than what the business wants with flow chart models. Bruce is rather right about BPMN’s technical bias (as mentioned in the previous post)