Introduction

A primary purpose of modeling business actors is to describe how the business activities are interacted with by various internal and external actors, and most importantly by its customers and partners. All interactions of actors with business activities are defined. Employees that interact with business activities and process are also modeled as actors.  

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. 

In addition to the diagrams described below, at the business level a context diagram is defined. This diagram is very useful in not only understanding the scope and context of the system but also in identifying the associated Actors. The example below defines the context for ThuNorTech, the fictional company in the UAM example architecture. The outermost 'square' defines the ThuNorTech Domain, with the various Actors and their interactions defined. 

Diagrams used in the Business Roles Model are:

• Roles Summary Diagram
• Roles in Context Diagrams

Roles Summary Diagram

A roles summary diagram is used in the Business Roles Model to detail the structure of Actors and also of Roles. It also shows the relationships between Actors/Roles and business activities. At the business level it is quite simple, with much more analysis and detail being defined at the logical level where the roles are actually defined:

This may be redundant if the system is simple, since this roles information may be shown on the Business Process Model, however, in a complex system it is useful to document additional GUI/Interface details in this diagram, particularly at the logical and technical levels.

Roles in Context Diagrams

A "roles-in-context" diagram is used in the Business Roles Model to detail the interactions of roles/actors with the activities in the system. Note that roles are defined at the logical level, but may be rolled up to the Business Perspective. This example diagram is similar to the one above, but is a simplified version showing only the relevant activities and with extraneous information removed:

There is one of these diagrams for each process defined within the system. Note that since roles are defined at the logical level, not all "roles-in-context" diagrams will be defined at the business level—only those important when briefing stakeholders.

Layering the roles model (to deal with complexity) isn't as convenient as with other types of diagrams, but can also be of value. Start with a top layer of roles that are abstractions of all the enterprise 'actors' and activities representing the presentation layer that they interact with, with the next layer of detail showing roles structures (and more presentation layer detail).

Focus of Business Roles Model

In the Unified Architecture Method (UAM), and the business roles model, the activities do not represent the complete business activity, just the presentation layer or interface. These activities therefore represent the boundary portion of the Business Process Model. In other words, the Business Process Model captures all of the business processes, activities and tasks, but with the interface/GUI portion also being represented in the Business Roles Model. The Business Roles Model is complete, but the two models together define the complete business solution. If the system is simple, with few roles and little structure to the roles then just use a Business Process Model.

This is a useful construct for complex systems since separation out of the GUI/interface early in the definition of the architecture will result in a more flexible design and implementation that better serves the business and the actors. The roles model is also used to analyze the structure of roles, since there usually is much duplication and overlap between roles in early iterations. Clearer separation of roles and identification of role structure will aid greatly in developing a logical design and technical model that will be effective, flexible and economical. The same holds true for the analysis of actors. See: Guideline: Roles Structures and Guideline: Business Perspective Views.

The detail and structure of the overall solution will be made apparent as the views of the enterprise architecture are developed and layers added within views. See: Concept: Architecture Perspectives and Viewpoints and Concept: Complex IT Architectures.

Note: Since UAM may model a complete enterprise (or business domain), the level of detail to be included in this model is a judgment call of the architect, based upon:

• The objective of the architecture effort;
• The size of the enterprise or (business line);
• Time and resource constraints.