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.

True Roles

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!