Definition

There is often confusion regarding the usage and specific meaning of user, role, and actor. UAM defines and clarifies these concepts. An actor aggregates (perhaps multiple) roles which are “interfaces” to the system, and an actor can be associated with multiple physical people.

To understand the business, its activities and tasks one must understand who the business interacts with; that is, who puts demands on it, or is interested in its output. The different interactions are executed by and represented as actors, with a role defining a set of related skills, competencies, and responsibilities required to perform the associated activity. Roles are associated with and defined by the specific business activities and tasks with which they interact. Therefore a role is equated to the business behavior or activities, and by extension the responsibilities, of the role as it interacts with the system. An actor can assume multiple roles. The figure below clarifies the relationship between users (i.e. physical people, and other systems, that interact with activities), actors and roles in relation to the activities and tasks within the system. The definitions and relationships are slightly different than the UML and RUP  definitions. Actors are very similar to UML and RUP; however the concept and usage of role is expanded and clarified along with their relationship to actors and users.

Note: Roles are not defined at the business level—they are define in the Logical Perspective. This is because roles imply a decision regarding the implementation of the associated activity (i.e., manual, user, or automated). These decisions are only made at the Logical level. Therefore only Actors are defined, but roles defined at the Logical level may be added to the Business Roles Model if desired. 

Roles vs. Actors

The following types of business users are examples of potential business actors:

• Customers
• Suppliers
• Partners
• Information Suppliers
• Local authorities
• Employees.

Hence, an actor is associated with a human user. However, there are situations where, for instance, an information system is an actor. An actor represents an external interaction with the system rather than necessarily a real physical user.

The actors defined above, on the other hand, may interact with multiple business activities. The following are examples of potential business activities for a customer actor:

• Purchase - purchase a product from the enterprise
• Support - get support for a purchased product from the enterprise

A single physical user of a business, equated to an actor, may interact with multiple business activities; for example a "customer" may interact with the "purchase" business activity or the "support" activity. Also, the same physical user can be several different actors with the system, for example a person acting as a "customer" at one point may act as a "supplier" at another point. This means that one and the same person can embody instances of different actors—and different physical people may interact with the organization as the same actor. 

A role defines a set of related skills, competencies, and responsibilities (defined by the activities that they are associated with). Roles are associated with business processes or tasks (i.e., Business Activities, see Whitepaper: BPMN - an Introductory Tutorial ) to specify who performs these activities, and by inference the set of business entities they consume and produce. Therefore a role in the Business Model, is equated to the business-level behavior (and by extension the responsibilities) of an actor that interacts with the system. Also see: Term Definition: Role, Term Definition: Contextual Role and Term Definition: Functional Role.

In order to avoid confusion between functional roles and contextual roles the following conventions have been adopted: Functional and organizational roles will always be expressed as nouns (e.g., TigerTeam); Contextual roles will always be expressed as verbs (e.g., Collaborating). This rule reflects the core differences between the role types: functional (and organizational) roles really do refer to persons, places, or things; contextual roles are actions performed by a subject on an object. Roles are used as the fundamental method for defining access permissions to protected objects (i.e., RBAC, see: Role-Based Access Control on Wikipedia), as defined in: Whitepaper: A Reference Model for Enterprise Security.

There is no simple user-to-actor and actor-to-role analysis, as illustrated in the figure below. The same actor with the system may be assumed by multiple users (people) and vice versa, and actors may assume multiple roles during their interaction with the business. Analysis of these interactions must be done in order to categorize them into the various actors and roles. The benefit of this analysis is a better understanding of the required user interface and the possible simplification of the user interface defined at the Logical and Technical Perspectives to support the various users. Also, analysis of access control requirements for users can be performed resulting in the definition of roles-based access controls (at the logical and technical levels). Note that some roles (i.e., the interfaces) may never be defined and implemented, if for example the activity is automated, however the role may still be used for roles-based access control purposes.

People (or other systems) that interact with the system are users that are associated with the actors that interact with the system (through roles). A single user may also be different actors with the system at different times. Actors define (or collect) a set of roles that the person may assume in relation to the system (or enterprise), with a role being closely associated with the activities that they interact with and the required competencies and privileges.

This set of relationships is illustrated below where <user a> interacts with the system as a Manager actor, and <user b> interacts with the system as Manager and Employee actors:

The figure below precisely defines these user-actor-role relationships using UML notation:

How to Name Actors

An actor should be given a name that reflects its interaction with the business—the business service that it interacts with, similar to the names suggested above. The name should be a noun and be applicable to any person—or any information system—playing the part of the actor.

How to Name Roles

A role should be given a name that reflects its specific business activity interaction, similar to the names suggested above. The name should be a verb for contextual roles and nouns for functional roles, and reflect to responsibilities of the activity.

Actor/Role Characteristics

There are no specific characteristics that an actor should cover, however roles are associated in the model with activities with the implication that there are knowledge and skills required. The following characteristics are of use when describing roles: 

• Prior knowledge and experience;
• Job, tasks, and skills requirements;
• Cognitive characteristics.

Note: At the Business Level only external Actors are defined, leaving the definition of Roles (and the associated implications for this definition) to the Logical Perspective.