There are two ways in which the Role component type is typically used in a model:
As a stand-alone abstracted representation of a set of skills, competencies, behaviors or responsibilities for use in design time modeling;
As a way of representing standard roles that are performed in the organization, and associating them with the people who carry them out.
The first of these is often used when designing and modeling business processes, mapping roles to process steps or tasks, with swimlanes showing the hand-off between different roles. It is also used to show how different types of users interact with business systems (see How to adopt the C4 model with Ardoq for more details on this).
A System Landscape Diagram showing how three different roles interact with personal banking systems
A similar use of the Role component type occurs when Roles are Assigned To Processes. See Business Process Management Metamodel for more details.
The second way involves adding an Assigned To reference from people to the roles they perform. This can add valuable information to your model, but it is important to plan your modeling approach and understand how different approaches will affect how your model works.
Linking People to Roles
We often want to record the roles that individuals perform (many individuals carry out more than one role in their jobs), and show the specific responsibilities they have (owners of applications and processes, managers of other people). Here’s an example that shows how having people linked to roles can lead to great visualizations:
Reporting lines in an organization grouped by Role
In this example, the roles of the organization have been modeled with Role components, and each employee has an Assigned To reference to the Role they perform from their corresponding Person component.
As roles encapsulate responsibilities, it may be tempting to show the ownership relationship that exists between a role and, for example, the applications a role might own, using a metamodel such as this:
This appears to make good sense, since the person carries out their application ownership responsibilities in the course of their duties that come with the role they perform. However, if two or more people perform the same role, the ownership responsibility has become ambiguous:
Who is responsible for which Application?
Accountability and responsibility for the application does not belong to the role - it lies directly with the Person who is performing the Role. And if we want to be able to engage with the individual owners of applications, send them alerts, surveys, dashboards that relate to “their” applications, then we need to make sure we have a direct connection between the Person and the Applications they own.
Whilst a Role might have a Consumes reference to components such as Applications, we recommend that it should never have an Owns reference, because the Role cannot be directly addressed (it can’t, for example, be a recipient of a survey about a particular application).
This way of connecting people to their roles can be used to distinguish between different types of owner. The following example shows an Application that has two owners, Helen and James. By looking at the Roles they are assigned to, we can see that Helen is the technical owner of the Application, while James is the business owner.
The two approaches to using Role mentioned at the start of this article can be combined, without the need to use different Role components for each approach. For example, at design time, a new Role might be used stand-alone as an abstracted representation of a new type of internal user, involved in a new business operation with a new organizational unit, new processes, services and applications. The Role component will be used in models that represent the corresponding new designs. Once the new operation is up and running, and the new unit is staffed, real people will be assigned to the Role. In Ardoq, their corresponding Person components will have an Assigned To reference added to the Role, and a Belongs To reference will be added from them to their Organizational Unit. The Role will keep its Consumes reference to Applications from the original design, and will now also contribute to visualizations of the organization and its people.
In summary, the Role component type is useful in developing and visualizing models that show the interaction between different groups of people and the systems and processes they use. The same component type can be used to show the different roles performed in an organization, and to identify the individual people who are assigned to them. When modeling responsibilities, such as ownership, it is important to remember that it is the Person who has the ownership responsibility, and the Person component should have the direct Owns reference to the asset they “own” (such as an Application or Process).
For a more detailed exploration of people, roles and relationships, see Modeling People, Roles, and Relationships in Ardoq.