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)
R&A IT Strategy & Architecture 
Hello Gerben,
In the custom approach I’m creating for a customer, I took the same conclusion as you did, namely to map ArchiMate’s Business Process to a BPMN Pool. Besides that, for describing a process I use only one Pool. This is because I don’t like the starting points for using black pools. 1) External participants interacting with a process? => participants should interact with each other; a process cannot interact. 2) No activity to be specified for external participants? => I explicitly want to model request and acceptance steps.
Important to know is that in my situation executable BPMN is not necessary.
I am interested to know how you map Business Role and Business Actor to BPMN concepts. I map a Business Role to a Swimlane. From this should follow that the business actors BAn that are assigned to business role BR1 have a relation with swimlane S to which BR1 is mapped to. However I didn’t find whether that can be modeled in BPMN. I think I have to draw diagrams twice: once with swimlanes mapped from business roles, once from business actors.
-Jacob Vos
LikeLike
Drawing Swim Lanes twice, once for roles and once for actors would be unacceptable for me as there is no way to properly maintain that. But there are possibilities in BPMN beyond what BPMN supports at the graphical level that can be used. As BPMN is limited, graphically, you need to decide on extra graphical support for those extra possibilities if you want to model it on the BPMN side. More on that in follow up posts. Another option is to chose to limit yourselves to roles on the BPMN side and leave the actor-role structure to ArchiMate.
Either way, you will have situations that can not really be modeled. One example is a process where actor A must check what actor B does and vice versa (4-eyes principle). When an actor has been assigned to role X for a certain case, another actor must play role Y. This assignment is dynamic and changes case by case. The next case the roles can be reversed. In (abstract) roles, it can still be modeled easily, but not in actors.
Swim Lanes in BPMN seem to be second class citizens. You don’t need them for proper process models, they are graphical extras and have no real meaning in BPMN. Using them for roles is a natural way to use them.
LikeLike
Very interesting discussion and relevant to the group I am working for today. We took a very simplistic route with our Visio/iServer tool. We mapped an entire BPMN process diagram to an ArchiMate ‘Business Process’ and Pools to ‘Roles and Lanes to ‘Actors’. The Concept was to try and be very ‘simple’ in that our BPMN diagrams will contain BPMN activities. That is more detail within our Business Process of how it is performed. This is very simplistic and we haven’t gone too far in demonstrating this in models. I think I will need to put a few days aside to examine this more closely before we build too much BPMN!
Thank you for this discussion and any comments on our very simple approach are welcome.
LikeLike
If a Pool stands for a role, that means that all lanes must be performed by that same role. And that multiple actors you use for the lanes are all assigned to that same role. It means that that role must be a very wide one, probably at a company level. BPMN calls this a ‘partner role’ (which has no visible representation in BPMN) with your organisation as one of the partners.
If you put Actors in the lanes, you don’t have a place for more finegrained roles (such as are customary in BPM) so where do you leave those? Might it be that your ‘Actors’ in BPMN are in fact GOFBF (see book and elsewhere on this blog)? In that case using ‘actor’ on the ArchiMate side does not really match and you are using Actor where you probably mean a business function (but not a business function as ArchiMate defines it). See my book too in the Advanced Patterns sections.
So, as you map Actor on a lane and role on a Pool, your mapping cannot make sense on the ArchiMate side and there is no room for the actual roles you want on the BPMN side if you are going to do detailed process modelling.
LikeLike
Hi, Gerben.
BPMN is quite explicit about pools representing organisations, and if you model processes within your organisation (your own swimming pool), the participants in your process are Lanes within your Pool. You may have flow of work between elements across the lanes of your pool, but you may not have messages flowing between them. These are the private business processes of that organisation. Business processes that exist and run within the boundaries of an organisation are represented by a Business Process Diagram, and if any of them are referenced within a BPD they are typically shown as a sub-process element (which is defined by a different BPD).
Messages are defined as inter-organisational interactions. Messages may only be used to show interactions between pools, and the level of detail in these public diagrams is a lot less. BPMN also later introduced the choreography as a kind of diagram – specifically for better depicting the interactions between pools.
Messages must not be confused with data interchange or even emails within the organisation.
(I always like to tell the delegates I train that they should think of messages (the open arrows with the open circle at the back) as water balloons: these water balloons are strictly to be used for throwing some of your water into your neighbour’s pool, and you may not throw that water balloon at anyone within your own pool.)
So, when we draw inter-organisational processes we are looking at how the POOLS interact, and therefore the pools themselves are participants in a public process or choreography. Pools are never participants in a private BPD.
If you do not make this distinction, then the mapping from ArchiMate to BPMN will necessarily be difficult and confusing.
So, in ArchiMate we have to look at whether the process we are looking at is an internal (private) process (in which we can control the flow of work), or whether it represents an external inter-organisational process we are trying to map the interactions between organisations (and we cannot control how they do work in the other organisations).
I believe we should start by considering only the internal business processes of the organisation, and mapping those concepts to BPMN. This will map more naturally, with
– ArchiMate Process = BPMN Business Process Diagram
– ArchiMate Business Role = BPMN Participant (for human participants)
(This could be Business Actor, but it’s good practice to model roles and not posts that are hardcoded to the current and changing organisation structure as process participants.)
– ArchiMate Application Component = BPMN Participant (for processes automated by that system)
– ArchiMate Application Service = BPMN Service Task
– ArchiMate triggering flow = BPMN sequence flow
The pool (only one for a private BPD) will be the organisation itself, which we may have modelled in ArchiMate as a Business Actor. (It can also be unspecified, implying the internal organisation.)
I don’t see the sense in maintaining a catalogue of manual tasks in ArchiMate. They are the steps followed by the participant who performs the process, and I don’t think it’s significant enough to make it into the EA repository. (If you wanted to, it would be closer to the actual definition of business process in ArchiMate at the moment, where there is only one participant allowed.)
I believe we could go a long way to finding alignment within this perspective, and the majority of EA work will be about what happens within the organisation (for most kinds of organisations)
When you look outside the boundaries of your organisation and explore customer or supply chain interactions, you have to operate at a higher level of detail (i.e. less details), and focus mainly on the interactions themselves.
In ArchiMate, if we modelled all of the organisations as Business Actors and are looking at the interactions between these, each Business Actor would map to a pool in a BPMN public diagram, or a participant in a choreography diagram. The inter-organisational process may be modelled in ArchiMate as a Business Process, but in this case in BPMN it would be represented by a public BPD, choreography or collaboration, but not a private BPD.
In this case far fewer items need to be mapped:
– ArchiMate Business Actor = BPMN Pool / BPMN Choreography participant
– ArchiMate Business Process = Public BPD / Collaborative BPD / Choreography
– ArchiMate information flow = BPMN Message flow
I am sure we are going to collaborate on this topic within the Open Group ArchiMate forum, but I would welcome your comments and feedback.
Regards,
Pieter
LikeLike
Hi Peter.
I do not fully agree with you. First, Pool is defined in the BPMN standard as ‘the graphical representation of a Participant’ and a Participant is the real BPMN concept and it is not by definition the organisation as a whole. In fact, there are many patterns inside an organisation that can only be modelled properly in BPMN by using multiple Pools. See for instance the examples Bruce Silver gives. The BPMN documentation itself (from the top of my head, the primer I think) also uses multiple Pools for different processes inside the organisation.
However, it would be possible to link ArchiMate Business Roles to both the BPMN Participant/Pool as well as the Lanes, but frankly, from an information perspective, linking to the Participant/Pool would be superfluous as it can be derived from the links to the Lanes.
Secondly, Lanes are in BPMN not defined as participants (in the meaning of roles). In fact, Lanes are completely free in BPMN, they do not stand for anything, they are constructs that can divide up activities in a process. But using them for roles is not prescribed by BPMN, it is a custom.
Linking ArchiMate Application Service to BPMN Service Task is an option. However that begs the question why you would link Application Services that are automatic, but not those that are in support of human process activities. You end up mapping an arbitrary part of the application landscape in the BPMN model. Besides, you still have the question that even a Human Task can depend on an Application Service. To be a good description of the process and how the application landscape interacts with the process, you need both. But it is a viable option, I think. Of course, Application Service on the ArchiMate side is not so much all of the behaviour, but the ‘externally visible’ or ‘usable’ behaviour. Such behaviour in ArchiMate is used by a process, but in BPMN you have it modelled as being (part of) the process. I would expect that you would use Application Function there. But I can see that leads to problematic consequences.
LikeLike
Hi, Gerben.
The definition of Pool has indeed changed in BPMN 2.0, and it is no longer restricted to only meaning the organisation.
We have to, however, keep the scope and type of diagram in mind when mapping to BPMN.
COLLABORATION
The key part of the definition you give above is that (in a collaboration diagram) a Pool represents a Participant OF THAT COLLABORATION. “A Collaboration usually contains two or more Pools, representing the Participants in the Collaboration.” – from BPMN spec, chapter 9, p111. Collaborations focus on the interactions between participants only.
I don’t believe we need to map an ArchiMate element to a BPMN Collaboration, Choreography, or even most Public scope diagrams. These are specific inter-organisational interaction views that are equivalent to ArchiMate views you can create using the Actor Co-operation or Business Process Co-operation ViewPoints – they don’t have specific ArchiMate element equivalents, and really only contain organisations and messages for a specific context.
There are other BPMN process types that it makes more sense to map to.
PRIVATE SCOPE, NON-EXECUTABLE
“Private Business Processes are those internal to a specific organization” – chapter 10, p149. So, if you are modelling a private scope BPD, it all occurs within the same organisation.
“A non-executable Process is a private Process that has been modeled for the purpose of documenting Process behavior at a modeler-defined level of detail.” – chapter 10, p149.
This is more in line with what business understands as a process, and is to me a good candidate for mapping from the ArchiMate Business Process element. You are correct that the use of lanes is a convention and not a rule, but one that resonates with business.
I am open to the argument, but I don’t think keeping a catalogue of manual/human tasks in ArchiMate is useful or architecturally significant. We could rather map the Performer of those BPMN Tasks to a Business Role in ArchiMate (and put it in a hopefully appropriately named lane.)
PRIVATE SCOPE, EXECUTABLE
An executable Process is a private Process defined for (web service) execution, and is designed to map to WS-BPEL. This is the reason that the pool definition in BPMN 2.0 was amended: “A Business Process Diagram can be made up of a set of (semi-) independent components, which are shown as separate Pools, each of which represents an orchestration Process. … each of these orchestration Processes maps to an individual WS-BPEL process.” – chapter 14, p 445.
These processes are not for business consumption and I would contend that we would rather map an ArchiMate Application Service to this kind of process (as the definition of the service orchestration, the way we would defer to UML for design specs for application components), and not an ArchiMate Business Process.
(Service Task is interesting. It makes sense to have a catalogue of our Application Services in our ArchiMate repository, so the Service Task in a BPD could be related to that ArchiMate Application Service. The Application Service, in turn, may refer for its definition to a BPMN executable process if it is an orchestration of services and not an atomic service.)
PUBLIC SCOPE, PROCESS CHAINS
One could use a public scope process diagram to string together a chain of private processes (as per view 275 in your book) through the use of messages, but this should only be if those processes are totally independent and not part of an end-to-end process.
Public scope diagrams are usually at a basic interaction level of detail (with a private scope diagram definition it aligns to), but if they are used this way we have the option of mapping an ArchiMate Business Process to the public Process itself – it doesn’t really matter how that process is defined in BPMN.
I don’t think this BPMN diagram that simply chains together other processes adds much value beyond what you could have defined in ArchiMate in a Business Process Co-operation view. It might make more sense to only map each of the individual processes to their BPMN definitions, but to keep the process chain in ArchiMate, (and/or BPMN if required).
Regards,
Pieter
LikeLike
Have a look at OMG’s document BPMN by Example, specifically Section 6 and figures 6.1 and 6.2.
Have a look at BPMN’s PartnerRole and PartnerEntity and how they relate to a Participant/Pool. I think it would be correct to map PartnerEntity to Business Actor and PartnerRole to Business Role, if you want want to map to BPMN.
A Pool represents a Participant in a Collaboration. True. But is that a ‘collaboration of processes (behaviour)’ (what ArchiMate would call an Interaction) or a ‘collaboration of actors’? I think the former is meant in BPMN. The fact that the word is the same does not make the meaning the same.
You wrote: “I am open to the argument, but I don’t think keeping a catalogue of manual/human tasks in ArchiMate is useful or architecturally significant. We could rather map the Performer of those BPMN Tasks to a Business Role in ArchiMate (and put it in a hopefully appropriately named lane.)” Agreed and this is exactly how my mapping works. Except that I also accept Application Component as a performer of Business Activity (as in ‘automated processes’)
What might be a reason we differ in some respects is that I wanted a linkage that is not subject to human interpretation (so can be automated). If you link elements, but it is somewhat arbitrary when you apply the link yes or no, the result becomes a maintenance nightmare. On paper you have something that works, but it is not practically applicable at any large scale because of the human effort needed to maintain the links.
LikeLike
Thanks, Gerben.
This discussion has been useful in framing the problem.
I look forward to collaborating with you in the ArchiMate Forum on resolving the matter.
LikeLike
I’ll attempt to commiserate by suggesting that much of the ambiguity arises because (I claim) it is the canvas of the BPMN Diagram which is, in fact, the context that is the Business Process and that all the elements appearing on the diagram are properties of that context. We can find evidence of this perspective in the OMG UML Profile for BPMN Processes, Chapter 11, where it states:
“BPMN Participants are roles in collaborations, rather than things or kinds of things that participate in collaborations, so each BPMN Participant is in exactly one collaboration. UML Collaborations are classifiers that have properties to identify participating things, and UML Properties are always in exactly one classifier. The Participant stereotype indicates which properties of UML Collaborations identify participating things, providing semantics equivalent to BPMN’s. BPMN PartnerEntities are individual things, such as WalMart or particular persons, while BPMN PartnerRoles are the kinds of
things that play roles, such as buyers or sellers, rather than roles in the collaboration. Partner entities and roles can refer to participants (roles in collaborations), specifying individual things or kinds of things playing those roles in collaborations. The PartnerEntity stereotype constrains UML InstanceSpecification semantics to specify exactly one instance, providing a semantics equivalent to BPMN’s.”
Therefore, a BPMN Participant is not a “ephemeral object in between that sometimes looks like a performer and sometimes like what is performed” but is rather a role in a collaboration and it is not the case that BPMN “does not contain a specific graphical object to represent a process” but rather uses the canvas of the graphical BPMN Diagram to represent the UML Collaboration that is the classifier for the properties of the diagram’s Participants, Pools, and DataObjects. It is the fact that the canvas is unbounded that makes it difficult to apprehend. Note that this BPMN Diagram canvas is unlike Kantian Space in that there can be multiple BPMN Diagrams and so multiple BPMN Processes are possible (and, of course, necessary).
If my argument is persuasive then we should map an ArchiMate Business Process to a BPMN Diagram, an ArchiMate Business Role to a BPMN PartnerRole, and see that a BPMN Participant is a property constraint for any instance of an ArchiMate Actor, performing as one of that Actor’s Roles, in the specific context of the current Business Process.
Let us try an example. If, during one specific execution of a Business Process that we here name “Sell Products” and show on a BPMN Diagram within a tool that conveniently shows a labelled Diagram Frame, the Sam Walton in the WalMart on the corner of 5th and Main happens to satisfy the role of vendor as a Participant in that process, then (1) Sam is an Instance not a Type, (2) further let Sam be an instance of the Classifier type VendorCashier where VendorCashier has at least one Role with Classifier type Vendor, then (3) there should be an ArchiMate Business Role of type Vendor, (4) there should be an ArchiMate Business Actor of type VendorCashier, (5) there should be an ArchiMate Business Process named “Sell Products”. Additionally it should be appreciated that ArchiMate lacks concepts in its Business realm for actual individuals and that in all modeling and in all notations it is far too easy to start mixing categories and instances of categories.
Ontologically, we all mix up ABox things with TBox concepts and generally get along fairly well until we try to make formal statements about what we really meant. (And, of course, I may have foobarred my argumentation above; if so, I hope I still have contributed clarity rather than more confusion into the discussion.)
LikeLike