What is a role?
Those of us accustomed to thinking of doing work using formal processes are well aware of the concepts of roles. A role is an abstraction of the individuals or organizations that habitually perform certain activities. Not only does a role describe what a person does habitually, it also describes what they are supposed to do. The principle advantage of thinking in terms of roles is to allow a single process definition to be easily applied to many contexts and organizations.
But this is not the only use of the term role. Roles exist in various other contexts that may be related to process roles, but are not quite the same. It is useful to distinguish the different types of roles and understand how they may be related. We will example the following domains of roles:
- Process roles
- Organizational roles
- Functional roles
- Asset roles
- Application roles.
Process Roles
I use the term process in a very loose way here, referring to any formalized means for getting work done. I intend it to cover such approaches as business process management, adaptive case management, etc. Naturally, the degree to which a role might be defined depends largely on the approach used.
Process roles may be thought of both in terms of generic roles that are applicable to all processes and in terms of the roles that are specific to each process. There are two generic roles that are typically cited for processes: the process owner and the process manager. Whether these roles are specific to processes or are, in reality, the same roles as the asset roles (see below), is a distinction to fine for me to make. Insofar as a process is an asset, I tend towards treating them as asset roles. The true generic process roles are as follows:
Executor
The executor is obviously the role of executing or performing one or more activities. It is the one generic role that is absolutely necessary, so it befuddles the mind that such techniques as RACI analysis ignore it completely.
Informee
The informee is the role of receiving output from an activity. The person playing this role is always the executor of a different activity using that output as input. Were this not the case, then it would serve no purpose to send that output to the informee.
Consultee
The consultee, too, receives information from the executor of an activity. The difference between the informee and the consultee is that the latter must provide a response that is used as part of the same activity, whereas the former executes a completely separate activity. Obviously, this distinction is quite artificial. The difference between informee and consultee is more a question of scale and granularity of activity than a difference of responsibilities. The only formal difference is that the consultee must return feedback to the source of the information. In fact, the consultee role may be treated as a subclass of the informee role. The distinction between the Consultee and the Informee roles is show in Fig. 1 below. Note that this figure shows three different actors. This is purely conventional to clarify the distinctions among the roles, although we would not expect the executor and the consultee to be played by the same actor (would you consult yourself?). The key point is that the same actor plays both the informee role with respect to one activity, but the executor role with respect to a different activity. In principle, the informee could also play a responsible role, but this would be inefficient.
Decider
Another potential subclass of executor is the decider, who is responsible executing a decision at gateways in the flow of work. A decision may be as simple as “go” or “stop”, or could be much more complicated, with diverse paths diverging from the decision. It is typical in hierarchic organizations for the executor role to be played by someone playing the organizational operator role, whereas the decider role is played by someone playing the organizational manager role (see below for these roles). However, we do not expect this mapping in other organizational structures that are less command and control oriented or are more teamwork and consensus oriented. Note that a when a decision is made by consensus, the role of decider is played by all those persons forming the consensus.
Approver
A sub-class of the Decider role is the Approver role. The particular decision made is whether to authorize some proposed or requested work. A single authorization might require multiple approvers, either in series or in parallel. Consensus is an example of parallel approval by multiple approvers. Other bases for approval are possible, such as approval by a majority or by an absolute majority.
Requester
A process may be triggered in many ways. One of the most common triggers is the receipt of a request from a customer of the service provided by the process. The process role played by this customer is that of requester. As for the informee role, a requester also plays an executor role, performing whatever activity depends on the output of the process triggered by the request. The requester may play an organizational role in a separate organizational unit, such as a customer from a different company. But a requester may also be part of the same organizational unit, such as the server administrator requesting an IP address from a network administrator (in the sense that they might both be part of the same IT organization).
Responsible – Organizer
The responsible role in a process is analogous to the manager role in an organization. Whether or not the one is played by the other is a matter of organizational culture. The responsible is distinct from the executor in the sense that the responsible must ensure that the process activity performed correctly; the executor performs it. In an organization where work is self-managed, the same person plays both roles. In command and control organizations, or in organizations hyper-sensitive to risks, the roles are likely to be played by different people. While this segregation reflects the reality in many organizations; I believe that over-segmentation of responsibilities should be avoided.
The name “responsible” is the source of much confusion, insofar as every role has responsibilities. I feel that “organizer” is a much clearer title for the role, but the title “responsible” is so well embedded that it might be difficult to change.
Accountable
Just as the responsible-organizer is analogous to the manager, so the accountable is analogous to the governor. As the word “accountable” would have us understand, there is typically a revenue or an expense account or other analytical category associated with the process activity for which the role is accountable. In short, the funding of the activity, as well as whatever revenue may be generated by the activity, are under the accountable’s control. As the controller or allocator (to avoid confusion with the role of “financial controller”) of funding, the accountable must ensure that the appropriate resources are available to the responsible who, in turn, organizes those resources to properly execute the process activities. The accountable may furthermore specify the policies, guidelines and other rules to follow in the course of performing the activities.
In fact “controller” might be a much better title for this role than “accountable” for various linguistic reasons. “Accountable” is not really translatable into other languages. Furthermore, the use of an adjective for a noun often leads to misunderstanding of syntax. But using “controller” would lead to its own ambiguities, considering that a financial controller is not accountable for the accounts he or she “controls”.
Organizational Roles
Before anyone formalized the idea of process and process roles, there were organizational roles. These roles abstract the structure of the organization. Organizations have owners, governors, managers and operators.
Owner
The role of owner may be played by individuals or organizations, such as shareholders or private owners; or by broader social structures, such as the state or “the people”. The owner bears to legal and financial accountabilities for the organization as a whole. Insofar as an organization is an asset (and certain organizations are not), an organizational owner is the same as the role of asset owner.
Governor
The governance roles are usually played by board members and various types of auditors. As the etymology of the word indicates, the role of governor is one of keeping an organization on whatever course is designated by the owners.
Manager
Once that heading is established by the governor, it is the role of the manager to organize the operators such that the heading is maintained and the goals of the organization are achieved. Managers include anyone making decisions that determine the nature of the organization. They are typically responsible for sub-units of the organization. They embody many of the organizational capabilities, such as the ability to effectively and efficiently deploy resources to perform useful work.
Operator
The operators are simply the people who perform the useful work. They are supposed to perform that work according to the policies and rules established by the governors. They are organized to perform that work by the managers, who also control the work and ensure that meets the requirements set by the governors. Operators have the skills, experience and teamwork capabilities needed by that work.
Individuals are often called upon to play multiple organizational roles. The CEO is typically both the highest level manager, but also has governance responsibilities. All other managers are also operators, in the sense that they have line managers that deploy and control their work. Indeed, the role of operator might be played by virtually any member of the organization.
Organizational roles are typically, but not necessarily, mapped to process roles. For example, the process role of request approver is generally played by the line manager of the requester.
Functional Roles
A job in an organization may be understood as a functional role. It implies a specific set of skills, knowledge and responsibilities in a certain domain of activity. Examples of functional roles would include business analyst, application developer, database administrator and service desk agent. In common parlance, a functional role is also called a “job”.
A functional role and functions in general are distinct from organizational roles and organizational structures, although they are closely related. For example, any organization that uses databases is likely to need someone to play the functional role of database administrator. But, from an organizational perspective, a DBA might be part of a production management organization, an infrastructure engineering organization, an application development organization or even part of a third party organization. Although there are common patterns for structuring functions and functional roles into organizations, almost every organization is slightly different in this respect. It is therefore important to distinguish between function and organizational structure.
The names given to functional roles are often the same as the names given to the organizational roles responsible for the function. This is especially true in larger organizations where, for example, a person playing a functional role of database administrator is likely to have an organizational title that is also “database administrator”. In smaller organizations, where everyone must play multiple functional roles, the organizational titles tend to be more generic and ambiguous, such as “infrastructure engineer”.
Given the breadth of economic activity, it is impossible to list functional roles here.
Asset Roles
An organization uses various types of assets in order to execute its mission. The people in the organization have various types of relations to those assets, the roles they play with respect to different assets. The most common asset roles are owner, user and maintainer or administrator.
The role of owner is named ambiguously. An asset used in an organization has a legal owner that is generally the organization itself. However, it is common for suppliers to that organization to deploy their assets at its customers’ sites, for the customers’ use.
The term owner is also used to describe a set of responsibilities or accountabilities or an individual or an organizational unit with respect to individual assets or classes of assets. These responsibilities are distinct from, although related to, the roles an owner might play in the processes used to manage assets. The distinction, which might be too fine for some, is that the asset ownership role is in direct relation to the asset itself and is independent of any processes that might be used. In other words, my ownership of an asset is a verifiable fact. A relationship exists between myself and that asset, whether I do anything at all to manage that asset.
Similarly, users and administrators of assets are generally the people who play specific roles in processes. The asset user role generally plays the process role of whatever business processes are used to deliver services or transform products. For example, a person may play a functional role of accountant. By virtue of being an accountant, that person plays an asset administration role with respect to the financial accounts of the organization. That same person is an asset user of the software used to execute the accounting processes. Finally, the accountant is playing one or more process roles in the course of using an asset to fulfill the responsibilities of the function played. An example of different roles played by a single actor is shown in Fig. 2 below.
Thus, asset roles may be mapped to functional roles, based on the assets used, administered or owned by the function. An obvious example would be the mapping of the asset role of administering a database to the functional role of DBA. Indeed, a functional role consists in large part of a set of asset roles.
Application Roles
Application roles are perhaps the last layer of role abstraction that an organization is likely to use. An application role maps an identity—that is to say, an account in the application—to a set of permissions to access functionality and data managed in the application. In a sense, an application role is a type of asset role, with the application being the asset.
In principal, however, the choice of an application role for a given identity is based on the functional and/or organizational role(s) played by the person using that identity. In more complex organizations, especially where compliance with industry and legal requirements differ from country to country, data and functionality may need to be segmented by jurisdiction. Application role would be determined by both functional role and organizational role.
A flexible application will provide sufficient granularity of its permissions to allow the application administrator to construct the set of permissions that correspond to each of the functional and organizational roles.
Documenting Roles
It should be clear that the traditional tools for documenting roles, such as the RACI matrix, are not adequate to document all the role types and relations described here. I reserve for a future posting the description of a new documentation method.
Roles Ontology
In order to codify the information in this posting in a more structured way, I have prepared an ontology in OWL format. That file may be downloaded here. It is made available under the terms of a Creative Commons Non-Commercial-Attribution-ShareAlike 4.0 International License. This means that anyone may use it and modify it for any non-commercial purpose, excepting that they may not claim the ontology as their own intellectual property and they must cite the origin of the ontology, namely, myself, should they use the ontology for any purpose. To view the ontology, users may wish to use an ontology editor, such as Protégé.
The diagrams in this posting are licensed to you under the terms of the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license.
Leave a Reply