Everyone knows what a role is.  It is obvious.  We talk about them all the time.  But every time I hear a programmer say the word “role” my ears pick up. The term is very often misused.  How, then, might one use the term correctly and avoid the pitfalls?

What is a Role?

Lets start by talking about roles in the setting of a Broadway play.

1. There are generic roles that can be taken by anyone without any particular skill; for instance “audience member” or “crew member”.
2. There are roles that are defined by a basic skill level, such as “fork lift driver” or “actor”.  When something heavy needs to be moved from one place to another, you need a fork lift driver, but it really does not matter which driver you get — any qualified driver will be as good as any other.  There are parts in a play (sometimes called “extras”) where you simply need a reasonably behaved person, and it does not matter if the person playing that role changes from show to show, or even within a single show.  These roles have no specificity.
3. There are very specific named parts in the play, such as “Tony” in West Side Story.  The person who plays this role is not only a skilled actor, but has also studied and learned that particular role.   These roles have moderate specificity.
4. There is the starring (or superstar) roles which are so specialized that only particular people can play them, like the way Peter Falk would play the part of “Columbo”.  It is really not possible for someone else to play this role.  These roles have very high specificity.
5. There are roles that are very ephemeral, such as the “person talking” in a conversation.
6. There are roles that seem to stick with people, such as “troublemaker” or “saint”.

These are all appropriately called roles, and people play those roles.  People are usually playing many roles at once.  For example the crew member, might be playing the role of Tony, and might also be the singer / dancer at that moment.  In some shows an actor may actually play the role of an audience member as part of the show.

Upon inspection you will notice that every role is relative to a context.  The audience and the crew is relative to a particular production (that is a series of shows).  Obviously, a crew member might go watch another show and be part of the audience.  The part of “Tony” is specific to the show “West Side Story” but not to a particular production of that show. Obviously other plays might have a part named “Tony” that have nothing to do with this Tony, and other production might have a different person playing Tony.  The person talking is relative to a particular conversation.  The role of teacher and student is relative to a particular learning situation, and there are many situations where the roles will reverse when the subject changes.

A role is defined as a relationship of the player to the particular context.

That relationship then defines a set of acceptable actions.  The fork lift driver will drive a fork lift.  Tony has specific lines to recite at the right times.  The person talking may hold the floor of the discussion, but a listener also has the possibility of interrupting. The writer of a particular book is allowed to write, while the reader is not allowed to write in that book.  The reader might be a writer of a different book.  By citing a role, we put a label on a set of actions that we expect a person might make, or might be restricted from making, in a particular context.

That’s Obvious, what could be the Problem?

Too often the context is forgotten, ignored, or assumed to be a single global context.

Next time you get into a conversation about business processes, pay attention to how people use the term “role”.  For example, someone may say “this process for running a classroom is defined by roles;  we have a role for the teacher, and a role for the students.”

What a programmer typically means by saying that “there is a role for the teacher” is that there is some sort of memory location that hold the identifier of a person, or list of people, who play the teacher role.  This location might be in database, or in a directory server, it does not matter how the list of names are stored.  The programmer is thinking: we don’t have to exactly specify the people who play this role because in the process we reference that memory location and use the list of people from that.  This is a variable that allows the players of the role to be changed at any time.

Directory servers implement a kind of variable in something called a group.  A group is a label that specifies a particular set of people.  A group might in fact be a single person, or even no people if no one has been assigned to that group.

A job skill appears in the directory exactly like a group.  For example, the skill of “fork lift driver” is a label that represent a group of people.  Whether this is implemented as an attribute of the person object, or as a collection of person objects, the external effect is the same: a label is associated with a list of people.  Similarly, if you have a group called “writers” and all the writers are put into that group, being a member of the group is essentially the same as having an attribute called writer.

A particular job position, like “president” or “chief executive officer” also appears exactly like a group designed to be filled by at most one person.  A job title is a label that specifies a particular list of people, usually only one.

The role of president seems like a pretty simple thing to put in a directory server, and it seems very convenient to use them in a BPM process.  An activity might be assigned to “The President” and the process will simply look up the president from the directory server, and assign those tasks to that person.  It seems that the directory server is providing roles directly, and that roles can be simply and easily read from the directory.

What is the Catch?

The flaw in this thinking comes from oversimplifying the problem into thinking that there is only one context, or at least that the directory server represents a single context.

This might seem a reasonable simplification when thinking of a high level role like “president” but consider a directory server for more than one organization.  You may have a president for the US operation, and the president for the Canadian operation, as well as presidents for many other branches and subsidiaries in the same directory.  Oops.  We forgot that a role is always relative to a particular context, and that context is a particular company or corporation.

I have also seen the same thing done for teachers and writers.  Certain steps in a process will be assigned to a role called “teachers” which implemented as a group in the directory.  This guarantees that the activity is done by a teacher.  Only one problem: if the process is about a particular class, you do not want ANY teacher to take that, but instead the teacher for that particular class.

If you have a process about making a book with activities for the writer, you can not simply assign those activities to any writer. Instead, the activity must be given to the specific writer of that particular book.  While a directory server might track a skill called “writer” or might have a group of people designated as writers, it is unlikely to have the specific writers of the dozens or hundreds of book projects that may be underway.

I have seen processes for health care talk about a role for doctor, and a role for patient, seemingly ignoring the situation that a person may have many doctors, and that the right doctor may depends upon the specific health problem that provides the context.  An internist for one set of interactions, an oncologist for another.

I know of a number of commercial BPMS products that have a feature called “roles” and they are essentially global variables where you can specify a list of people.  These structures can function as roles only if the context is the application itself.  For example, every application needs people to act as administrators for the application, so a global “Admin” role makes sense.  But you could never use these global structures to represent the role of a doctor for a particular patient.  You can not use these global roles for the writer of a particular book, or teachers of a particular class.  These products claim the ability to make “role based processes” and this fools a lot of people, because so many people forget that a role has a specific context, and that for most roles there is more than one context.

I have seen so many design specs that request that the “roles” be defined and served up by a directory server, but these designer all make the same fatal flaw: they assume that there is one directory server for the particular context.  It works OK for very high level global organizational roles, like CEO and President, because often a directory server contains only a single organization. It also works OK for roles that have no specificity at all, like fork lift drivers, because it really does not matter which driver transfers the crate.  But does not work at all for teachers and writers. Once a book project is taken by a writer, then that particular person fills the role of writer, and can not swapped with other writers.

In another variant on this theme, I have see very intelligent people say that such roles will be stored in a central “access control manager” that will define who will be allowed to take what actions.  Access, like roles, is defined according to a context.  The writer of a particular book may need the rights to update those book files, and may want all other people, including all other writers, from have that same access.  A writer on one book, might be an editor on another book.  Any access defined for all people who are writers, or who are editors, will not be specific enough to control the access of specific process artifacts.

Solution

The solution is simply to always remember:

a role is a relationship between the performer of a set of actions, and a context for those actions.

When considering roles identify the context first:

1. Is the context the whole organization?  Does that organization have a unique directory server?  Then defining the role in the directory server might work.
2. Is the context the application?  Then a global role in the application might work.
3. Is the context is a particular work instance, for example a project, situation, problem, deliverable, or goal, you need to be explicit about what that context is.  In those cases, the “role” needs to be a memory space associated with that context. The design must be prepared to have an open ended number of “instances” of that role.
4. Is the context fleeting?  There are momentary roles that are important, but usually hard to track with any kind of formal mechanism. For example, the person speaking at the moment on the telephone.  These change so quickly that formal tracking is too much overhead.

The third case, roles in a work instance, are the biggest challenge for system designers, and at the same time the most important.  For example, if the context is a “trouble ticket” (a.k.a. a help desk issue) then the record for that trouble ticket needs to include spaces for the players of all the roles that are needed for that trouble ticket.  To put this in BPM terminology, the definition of the role must be part of the process relevant data, and not in a global store of data.  If the context is a book project, then you will need space in the record tracking the book for the writer(s), the editor, the producer, and quite possibly the typesetter.  It should be pretty obvious that you can not store these in a directory server;  such servers were never designed for such volume and rate of update.  Instead, the list of players of these roles must be part of the data of the process instance itself.

Next time someone uses the term “role” consider what the context of that role is, and see if they are using the term in a way consistent with what I have presented here.