BPMN 2.0: PartnerEntity or ParnerRole?

[Geert Bellekens]

I'm trying to decide whether I need to use a PartnerEntity or a PartnerRole, so I naturally look at the BPMN 2.0 specs and try to figure out the differnence between the two.
That was kind of a disappointment. What I found was this:
- PartnerEntity: A PartnerEntity is one of the possible types of Participant (see the section above).
- PartnerRole: A PartnerRole is one of the possible types of Participant (see the section above).

So that didn't help all that much. The "section above" (could you be more specific please ) I assume refers to this part:

- partnerRoleRef: PartnerRole [0..*] The partnerRoleRef attribute identifies a PartnerRole that the Participant plays in the Collaboration. Both a PartnerRole and a PartnerEntity MAY be defined for the Participant. This attribute is derived from the participantRefs of PartnerRole.
- partnerEntityRef: PartnerEntity [0..*] The partnerEntityRef attribute identifies a PartnerEntity that the Participant plays in the Collaboration. Both a PartnerRole and a PartnerEntity MAY be defined for the Participant.This attribute is derived from the participantRefs of PartnerEntity.

Again, no definition of the difference between the two things.

Have I missed something, or is the specification of this language really this poor? :-/

Geert

[Paolo F Cantoni]

If its any consolation, the language is probably poor.

I'm trying integrate ArchiMate, BPMN, SoaML and UML.  It's really difficult as the same term means different things in the various symbologies.

I've come to the conclusion that:
Actors are entities that are capable of action, Roles are an action on an object, Players are actors acting out a role (from IBM System Architect)  <- this is what REALLY acts on things  Participants are players participating in some form of Activity.


Actor: Person
Role: (course) Student
Player: (Person as) Student
Participant: (Person as) Student in Course Enrolment
Participant Role: ((Person as) Student in Course Enrolment) as (course) Enrolee.

As you can see, Player is the intersection of Actor and Role.
I suspect UseCase Actors are actually Players.

Does that help?
Paolo

[philchudley]

My very simple understanding is

partnerEntity used as a reference within Pool
partnerRole used as a reference within a Lane

Does this help or just add to the confusion?

Cheers

Phil

[Geert Bellekens]

My very simple understanding is

partnerEntity used as a reference within Pool
partnerRole used as a reference within a Lane

Does this help or just add to the confusion?

Cheers

Phil

Hi Phil,

I just checked that and the specs on Pool say

A Pool is the graphical representation of a Participant in a Collaboration. A Participant (see page 114) can be a specific PartnerEntity (e.g., a company) or can be a more general PartnerRole (e.g., a buyer, seller, or manufacturer).

On Lane they say

A Lane is a sub-partition within a Process (often within a Pool) and will extend the entire length of the Process level, either vertically (see Figure 10.123) or horizontally (see Figure 10.124). See page 305 for more information on Lanes.

and on page 305 it says

Lanes are used to organize and categorize Activities within a Pool. The meaning of the Lanes is up to the modeler.
BPMN does not specify the usage of Lanes. Lanes are often used for such things as internal roles (e.g., Manager, Associate), systems (e.g., an enterprise application), an internal department (e.g., shipping, finance), etc. In addition, Lanes can be nested (see Figure 10.125) or defined in a matrix. For example, there could be an outer set of Lanes for company departments and then an inner set of Lanes for roles within each department.

So the only clue they leave is that a PartnerEntity is something specific  like a company (e.g. "IBM", "Sparx Systems"), and a PartnerRole is something more general like "the buyer" or "the seller".

There is no direct indication that you should use one or the other on Pools or Lanes.

This is really really poor

Geert

[philchudley]

I guess that's why I do not read the specs very often

I tend to focus on models that communicate their meaning and make sense to all stakeholders, rather than cross every t and dot every I according to the spec, however, I must state, then most if not all my clients don't care about the specs.

If I was creating an modelling tool, however, then yes I would attempt to follow the specs to the letter and I agree with you the specs are very often written very poorly.

Had similar discussions about interpretation with ArchiMate and SysML

Cheers

Phil

[Geert Bellekens]

Hi Phil,

I see your point, but the problem arises when you have to share models with people you didn't explain your way of viewing things beforehand.

That is the main reason why we have standards, to avoid ambiguity and make sure everyone understands things the same way.

So it's not so much about crossing the T's and dotting the i's (although I must admit that I very much like them crossed and dotted ), but more about having guidelines and avoiding ambiguity.

In this case I was making an example model for an article about document generation I'm writing.
I was hoping to use that same example model later on in one of my courses. And because I'm no BPMN expert I looked at the specs in hopes to find out which of the two I should use.

Turns out I can pretty much choose for myself

Geert

[Eve]

I don't have concrete references in front of me, but my understanding based on too much time reading about it may be valuable.

I think it's easiest to express via example.

If between us we were modelling processes we might model partnerEntitities of 'Sparx Systems' and 'Bellekens'. While there would probably be partnerRoles of 'Software Vendor', 'Support Provider', 'Reseller', 'Trainer', Disgruntled? 'Customer'.

In general I would prefer to use a partner role to keep the process generalized.

On occasion we might have a customized process for providing support to specific customers. In that case I would probably assign both an entity and role. Depending on personal preference and how many processes you have with that entity you could omit the role.

The last scenario would be if the entity in question is serving a unique role in your system (or it hasn't been generalized yet). In that case just using a partnerEntity would be appropriate.

[Eve]

I don't believe that either partner entity or partner role should be used with lanes.

If effect a pool is a partner in an interaction. A lane should represent a Category or CategoryValue instead. (Based on a lot of reading between the lines)

A lane has a partitionElement. They type is any BPMN element, but the comment says - "Using this partition element a BPMN compliant tool can determine the FlowElements that have to be partitioned in this Lane."

In order for that statement to be true a flow element must have a corresponding relationship. The only one that seems to fit for me is the categoryValueRef.

Category and CategoryValue have a bi-directional relationship between them that would allow a mapping to be defined between the lanes and Flow Elements whichever you used as the partitionElement.

Having said that, I've usually found it most meaningful to have a strong correlation between lanes and resources. This relationship isn't available until the Activity sub-type of the flow element though and causes difficulty when you need multiple resources of different types.

[Geert Bellekens]

Thank you Simon, that helps.

The BPMN specs would be a lot clearer with explanations like this.

Geert

[philchudley]

Interesting.

I just tried setting the tagged value partitionElementRef of a Lane to a Category and then a CategoryValue and hey presto!

[highlight]The same behaviour as for a Pool and partnerEntity, that is the name of the Lane if blank adopts the name of the referenced Category or CategoryValue.[/highlight]

You learn something new every day, and I will update my training material accordingly.

Cheers

  

[Eve]

Geert,

Happy to share my hard won understanding. I agree that a few more 'non-normative' in many specs would be helpful.

The same behaviour as for a Pool and partnerEntity, that is the name of the Lane if blank adopts the name of the referenced Category or CategoryValue.

Interestingly, there's nothing in the spec about displaying the Partner/Category name for Pools/Lanes. We added it to support the needs of our customers with using this relationship instead of re-using the same Pools and Lanes in multiple processes. Version 12.1 helps with traceability of this link even more by allowing it to be displayed in the traceability window.