• Business Perspective

• Business Actor
• Business Role

• Enterprise Architect

• Define Logical Roles Model

• Define Logical Process Model

• Define Business Actors

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

A Business Roles Model is created (at least a subset) very early during the architecture development, and fully detailed and adjusted as the architecture progresses. This artifact is enclosed within the Business Perspective artifact.

The Business Roles Model is a way of expressing the Business Activities interacted with by Actors. Actors are conceptual at the highest level. The types of Actors and interactions they have with Business Activities are what are modeled. Business Activities in this context equate to "business interactions", which will be detailed more at the Logical and Technical levels. Note that only Actors are defined at the Business level since defining Roles requires that a "automate" vs. "manual" decision to be made, which is not done at the Business level; this is left to the Logical level.

This information is important in deciding (in later models) on the presentation architecture activities / services, so that usability concerns, integration concerns (and the user level) and other issues are understood. Security implications are also derived from this model, but only starting at the Logical level (i.e., access to information / services may be controlled based upon a user's Role). It is important to clearly define the Business Actors and the interactions that they have with the system. This information is used by stakeholders, business-process analysts and business designers to understand and improve the way the business interacts with its environment, and by systems analysts and software architects to provide context for software development.

• Business Perspective Document Template

• Business Role Report
• Business Roles Model Report

Failure to produce this model means you run the risk that architects and designers will give only superficial attention to the way the business operates. They will do what they know best, which is to design and build systems in the absence of proper business knowledge. The result often is that the constructed systems do not support the need of the business.

UML Representation: Package stereotyped as «BPL_BRM» containing class diagrams.  

A Business Roles Model may have the following properties:

• Introduction: A textual description that serves as a brief introduction to the model.
• Packages: The packages in the model, representing a hierarchy.
• Role: The Roles in the model, owned by the packages stereotyped as «BPL_Role».
• Actor: The Actors in the model, owned by the packages stereotyped as «BPL_Actor».
• Relationships: The relationships in the model, owned by the packages.
• Diagrams: The diagrams in the model, owned by the packages.

If the purpose of the business modeling effort is business process re-engineering the target organization, you should consider maintaining two variants of the Business Roles Model: one that shows the business actors and business activities of the current organization (sometimes called "as-is"), and one that shows the target organization with new business actors and business activities ("to-be"). This separation is needed when doing business process re-engineering, otherwise the redesign will be developed without knowing what the proposed changes really are at the end, and you will not be able to estimate the costs of those changes. 

The cost of maintaining two Business Roles Models is not insignificant, and you should carefully consider how much effort you put into a current model. Typically, you would not do more than identify and briefly describe the business activities and business actors. You would also briefly outline the business activities you determine are key to the effort, possibly illustrating this with a simple activity diagram. The level of detail you choose should aim at providing a shared understanding of the target organization.

You would not need this separation if:

• There is no "new" organization (the goal is to document an existing organization);
• There is no existing organization (i.e. a "green field"). 

• Business Perspective

• Complex IT Architectures
• UAM Perspectives Contexts

• Business Perspective
• Business Perspective Views
• Business Roles Model
• Modeling Basics
• Plan the Business Perspective Activity
• Roles Structures
• Users, Actors and Roles

• BPL Summary