We talk about something called a “Role”. We all know what it means — or do we? There are a number of meanings to this term, and there is a kind of sleight-of-hand which is used to sometimes trick the unwary. Here I expose some of that trickery.
What is a Role?
Everyone has an intuitive grasp of a role, but before you read any further, find a scrap of paper, and write down your definition, and hold on to that for a moment.
Usually people will say that a role is kind of like a job. A role is a name that we give to a set of activities that someone might be responsible for. Some examples of roles are: driver of a car; or passenger in a car; a teacher in a classroom; and a student there as well; a chef in a restaurant; a waiter/waitress; a host/hostess; a manager; a goalie in a soccer game; a pitcher in a baseball game; a quarterback in a football game.
A role defines a set of activities abstracted from the person. No matter who the driver is, there are things that the driver is expected to do to safely drive a car. Some roles are exactly like jobs, and indeed most jobs are roles. “CEO” is both a role and a job title. A manager is a job title, and it is a role within a certain team of people.
As individuals, we can play many roles: maybe someone plays the driver role until arriving at work, and then plays the “worker” role, or the “teacher” role, and at other times the “bill-payer” role. We even play multiple roles at the same time. Using a hat metaphor, we say that we are changing hats when we change our active role. Think of the the number of hats that you wear on a daily basis. You might play a different role in every work situation you are involved in.
Using Role in BPM
In the case of a business process, the use of roles is pretty obvious. If you are modeling the process for managing newspapers articles, you are going to have a role for “writer” and a bunch of activities that the writer is expected to do, a role for “editor” and activities that they will do, a role for “typesetter” and the jobs that they are expected to do, and probably many more roles. The nice thing about a role is that you can define it once, and use it like a kind of variable. For article XYZ the writer will be Billy-Bob, the editor will be Dorothy, and so on. Roles are often represented as a swim lane on a BPMN diagram, and that swim lane contains the activities performed by that role.
So What’s the Problem?
The problem comes right at the point where people describe how you will map people to playing the role. They will say: the roles are defined in the organizational directory. Pay attention because this is where the science gets a little tricky.
They will have a simple process like a purchase order, that goes through a “department head” for review, a “CEO” if the amount is high enough, and a “purchasing agent” to place the actual order. They will then say that department head, CEO and purchasing agent are defined in the organizational directory. This is very cool, because if the CEO changes and a new person is put in the position of CEO, then the process does not need to be changed — it just continues to work. The role might be tied to a specific title, or maybe another attribute like a specific skill. In some cases you might have a pool of people with the required skill, and then one person from the group steps up and does the job.
So what is wrong? That example is a special case because it is small. A given organization has one directory server, and it has one CEO. One entry in the directory will do fine. Such an organization might have one purchasing agent and so again one entry might be fine. Even if multiple purchasing agents, it doesn’t really matter which one does the job. But most readers should have realized right away that in such a process can not just be any department head in the organization. It must be the head of the department of the person making the request. Yes, all the heads of all the departments might be in the organizational directory, but it should be clear that some more complicated logic is needed to get the requester department and the locate the leader. But in a quick demo, they make a directory entry called “department head” and it works.
A More General Example
Consider a better example: creating an article for a newspaper. The organization will have lots of writers. They might all be listed in a group called “writers” in the organizational directory. The organization might also have lots of editors and typesetters who are listed in groups for “editors” and “typesetters.” When you draw that process, the swimlane can not be simply associated with the group of all writers. The organizational directory can tell you all the people who have the title of writer, or have the skill of writer, but it can not tell you who the writer of a particular article is.
Each article has a very specific individual writing it. One person is expected to do all the tasks around writing. Changing the writer for a particular article is non-trivial. The fact that changing the writer is extraordinary, indicates the assumption that the writer will not be changed arbitrarily in the middle of the process. The writer role is sticky. The editor role is also sticky; the activities for an editor are designed for one person doing all of them.
A teacher is also a sticky role. The same person remains a teacher of a given course, and the students remain students. Those roles might be reversed in a different class. You can put all the teachers in a group called “teachers” and all the students in a group called “students” and there very well may be people in both groups. If you designed a process for the class, you would not simply assign tasks to any teacher in the teachers group. The process must assign tasks to the teacher of that particular class — something that is not likely to be found in the organizational directory.
Not all roles are sticky. The tasks for a fork-lift-driver, a tire mechanic, or a bank teller can be done by anyone who happens to be available with the requisite skills. In those cases, it is possible to use a pool of people defined by the organizational directory. The task can be completed by anyone in the pool.
Another special case is when there is a single activity from a role: when there is only a single activity, it does not matter whether it is sticky or not.
It is about Relationship
Go back and look at the list of example roles above. In every case you will see that a role is actually a relationship to a particular context. The writer is a writer of a particular article. The driver is the driver of a particular car (or group of people) at a particular time. The editor is editing a particular article. The teacher teaches a particular class. (In your definition, did you get the part about the context or situation?)
The simplified examples use roles as if they were global. The CEO is a relationship to a particular organization. It just happens that there is one directory for the organization, and one CEO, so it looks like it a global setting. A small example organization might have just one teacher, and one group of students, making both groups appear to be global.
In every role, it is important to recognize the context that the role is in a relationship to. In many cases, it is a relationship to the business process itself. The process of writing an article has a writer for that article, an editor for that article, and a typesetter for that article. The process of delivering a class has a teacher for that class, maybe teaching assistants for that class, and students for that class.
In general, a role is a property of the process instance, not a property of the organizational directory. The organizational directory can provide information which leads to a potential role player, but it does not have the specific context needed for most roles. You might think of the organizational directory as being useful to the calculation that initializes the role, but after that if the role is sticky the process needs to remember who the role player is and offer future activities from that role to that person who is playing the role.
What do we do?
Most commercial BPM suites have figured this out — because they would not work otherwise — but at the BPM 2015 conference I noticed a couple of papers making this overly simplified assumption that the roles would be defined in the organizational directory. They assumed that the roles were in the organizational directory, and then went on to discuss the effectiveness of the process modeling. How can we trust results of these studies?
I also regularly see slick vendor demos doing the same thing. Next time you see a BPM demo, ask the presenter where the roles are defined, and I will bet you will get the answer that “the roles are defined in the organizational directory.” (Or worse, they are defined in a global table mapping role names to people.) The simplistic demo scenario usually makes that look like a good idea, but in the real world it is not.
Confusion over this is widespread. I have even seen customer RFPs that request that roles be defined in the organizational directory. If they are roles for the entire organization, like CEO and CFO this works. For non-sticky roles like “bank teller” that might work. But most sophisticated roles that involve more than one action require that the process instance remember the role player.
We talk about changing hats all the time, and everyone knows that everyone wears many hats. It should be obvious that the organizational directory will NOT include all the hats you wear. Nor all the hats that anyone wears. The organizational directory will have your job title, and maybe some skills, but it can’t possibly have the specific roles you are playing in every work context you are involved in.
In Interstage BPM, we implemented what we call true roles to distinguish them from organizational roles that you see in the organizational directory. A true role uses a process variable to track the role player for that process instance. The variable would be named “writer” or “teacher” to match the role. The set of activities done by the role (and typically displayed in a swim lane) are associated with that variable such that when an activity is started, the assignee is taken from the variable, and when completed, the ID of the actual person who completed the activity is placed into the variable. The variable can be initialized a number of ways. In some cases it is initialized with a group of people, from the organizational directory, but as soon as one of them responds, the role is claimed by them, and they get the joy of doing all the other activities. It is not simple, but once set up, modeling the processes becomes much more effective. Don’t be fooled by simplistic approaches.
The biggest challenge remains the conceptual leap to understanding that a role is a relationship with a specific context that defines a set of activities that might be performed in that context. Don’t forget the context!
Totally agree that the way roles are defined and implemented in most BPM tools I know of is ambiguous to say the least.
However I do not agree (or misunderstood) on your writer example. If a writer submits a paper, the process execution continues to run binding the writer to that specific entity. Another example, consider a sales process. The “customer” role does not appear in any directory, however when we talk about the customer, we assume it is that particular customer who placed the order, not any customer.
As you speak about BPMN, I believe that this was the intent of the specialization of the Participant concept. I say I believe as the BPMN specification, as verbose as it is, is again not clear about that… A Participant could be either a PartnerRole or a PartnerEntity. My understanding is that a Participant defined as PartnerRole means anyone having that role can perform pool’s activities, even if he wasn’t the one who was initially involved in the process instance. On the other hand, a Participant defined as a PartnerEntity means that, in a given instance, tasks belonging to that role must be performed by the exact same individual.
However, where I find it to be tricky and can’t think of any provision in the specs is the fact that a usually a role have to be “computed” at runtime. Consider for example a sales business process. The salesman who should get the case should be one of the company salesmen who are affected to the particular region where the customer lives. I can’t think of a way to put that into a BPMN model.
Sounds like you are actually agreeing with my point about the writer: The process must always assign tasks to the person who submitted the article, and this is not found in the organizational directory. (Instead, the process remembers who this person is.) Similarly the customer is not found in the organizational directory. My point is simply that the organizational directory does not contain these roles. These are the easy cases to understand (no one would ever suggest using the directory for these roles) but the same is true of any other sticky role.
The BPMN spec is not clear about the tie between role and swim lane. Rather it is purposefully vague because often people associate a swim lane with a department or other unit bigger than a single role. It depends upon the story you are trying to tell with the diagram.
I agree, the idea that a role is sticky is hard or impossible to express clearly in BPMN. However, that is not a problem if you are only drawing a diagram, because people view it already know that all the writing tasks are supposed to go to a particular writer (the one who submitted it) and not just to ANY writer. Some have called these “role instances” to distinguish them from “global roles.” The BPMN diagram is not complete, and this detail must be filled in at implementation time.
I think what everyone is looking for is a shortcut on the work. They want to get roles for free and not have to do the data entry to say what roles each person is in (either at instance creation time, participant adding time, or process design time). No one wants to pay the data entry toll 🙂
But that doesn’t change the fact that LDAP directories are not the right way to define someone’s roles in most scenarios. I’ve seen it done, and seen it work, but i’ve also seen it become a major point of friction (trust me, the keepers of LDAP don’t want to be maintaining your roles either ; )
To me, this is a classic refutation of the idea that the average business user/person wants to define their own processes. They likely don’t even want to define who is in each role. To the extent that roles can be implicit as “process instance creator” etc. that helps, but often that’s only part of the answer.
Incidentally, by way of validation, the True roles section above defines exactly how role assignment is done in IBM BPM as well (though there are options to customize this behavior, it starts out with that simple and good assumptive behavior).
Good points, and I am not surprised that IBM BPM does this.
I’m expert in enterprise architecture and to manage this question of role , we defined two roles: Business Role and Application Role . And the relationship between Business Role and application role is n /n relationship. 1 Business role can have N appplication roles and 1 Application role can have N Business roles.
OK, that sounds powerful and flexible, but I don’t understand how it pertains to the examples I have given. Could you elaborate with a specific example. Take “writer” as an example. Each article has a specific writer. Is the article considered an “application” in your terms?
Great post Keith.
“Next time you see a BPM demo, ask the presenter where the roles are defined” – If you really want them to squirm, ask them “How can I grant access for folks that I need to bring in to handle special cases (and make sure they can only access the specific case)?”