• Business Roles Model

• IT Architecture Delivery  >  Review the Architecture  >  Review Business Perspective  >  Business Role
• IT Architecture Delivery  >  Business Perspective Delivery  >  Business Perspective Iteration [n]  >  Business Role
• IT Architecture Delivery  >  Architectural Decision Delivery  >  Business Role
• IT Architecture Delivery  >  Business Perspective Delivery  >  Business Role
• IT Architecture Delivery  >  Logical Perspective Delivery  >  Logical Perspective Iteration [n]  >  Business Role
• IT Architecture Delivery  >  Maintain Architecture  >  Deliver Updated Business Perspective  >  Business Role
• IT Architecture Processes  >  Define Business Perspective  >  Business Role
• IT Architecture Processes  >  Review an Architecture  >  Business Role
• IT Architecture Processes  >  Manage Architectural Decisions  >  Business Role
• IT Architecture Processes  >  Develop a Migration Plan  >  Business Role
• IT Architecture Processes  >  Analyze Models  >  Business Role
• IT Architecture Processes  >  Develop Training  >  Business Role
• IT Architecture Processes  >  Consult with Stakeholders  >  Business Role
• IT Architecture Processes  >  Define Solution and Impacts  >  Business Role
• IT Architecture Processes  >  Business Role
• IT Architecture Processes  >  Define Logical Perspective  >  Business Role
• IT Architecture Processes  >  Update Business Perspective  >  Business Role
• IT Architecture Processes  >  Update Logical Perspective  >  Business Role
• IT Architecture Processes  >  Update Technical Perspective  >  Business Role

A role is played in relation to the business by someone or something in the business environment. A role is equated or defined by the behavior (and by extension its responsibilities) that it interacts with in the system — the activities that it interacts with. A role is in essence the “interface” to the activities with which it interacts. Business Roles are high-level conceptualizations of the Roles with the system; further analysis is required to fully understand and define required roles. A role can be assumed (aggregated) by any kind of actor, either human or a system. An actor may be aggregate multiple roles, and an actor can be associated with multiple physical people (or systems). Roles also include security concepts and constructs. An employee of the enterprise is typically multiple actors with the system and therefore has many different roles.

Therefore Roles are a categorization, based upon specific interactions with the system ... the interfaces. These interfaces may eventually be defined as either human (i.e. GUIs) or as interfaces with other systems.

NOTE: Roles are not defined at the Business level, but they may be rolled back into the Business Perspective once defined at the Logical Perspective, in order to facilitate a more complete descriptions for business stakeholders.

In addition to IT Architects, the following people are interested in Roles:

• Business Analysts, when defining the boundaries of the organization and business processes;
• Business designers, when describing business processes and their interaction with business actors;  

A Business Role is played in relation to the business by someone or something. A role relates directly to the set of business activities invoked to perform the work associated with the role.

UML Representation: «stereotype» BPL_Role

Extends: «metaclass» Interface

It has the following properties:

• id: string - This attribute is used to uniquely identify elements.
• name: string - A descriptive name for the Role.
• description: string - Description of the Role, its interactions and other relevant information such as security aspects.

Constraints

• Must be named, usually with “er” or “or” extensions on the associated activity name (e.g. “invoicer”, “claimer”, “helper”);
• Can only have associations to Business Actors and Business Activities. Furthermore these associations must be binary;
• Shall be aggregate by at least one associated Business Actor; 
• Allowed to have (derived) associations with Business Entities (through associated business roles); 
• Allowed to have (derived) associations with Business Activities (through associated business roles);
• Structuring (i.e. aggregation) of Business Roles is allowed, based upon the Business Activities involved.
  
  

• Actor and Role Checklist

• Roles Structures
• Users, Actors and Roles

• BPL Summary