Guideline: Business Perspective Views
This guideline provides an overview of the main diagrams that can be used in illustrating the structure of the Business Perspective.
Relationships
Main Description

attributesIntroduction

Various viewpoints are used in documenting the enterprise at the business level, namely the Business Entity Model, the Business Process Model, the Business Locations Model and the Business Roles Model. Several diagrams are used to document each of these aspects of the model as shown below.

Business Perspective (level) 

The following overview is organized by viewpoint / aspect:

Business Entity Model

Viewpoints used in the Business Entity Model are:

  • Class Diagram  

Class Diagram

Class diagrams show associations, aggregations and generalizations between business entities. The following kinds of class diagrams might be of interest in the context of the business entity model:

  • Inheritance hierarchies, aggregations or compositions and other structures.
  • How business entities are related to activities by means of associations.

The class diagram below shows a partial view of the business entities involved in the airport example.

Entity model showing entities, attributes, and relationships 

Class diagrams show generic structures in the business entity model, but can also be part of the documentation of the Business Process Model by showing how business entities participate in business activities (object flows) as shown below (i.e. Boarding Passes are delivered to the Passenger).  

Activities and their relationships with baggage

A process diagram showing participating business activities and business entities in the business activity Check-in.

Business Process Model

Diagrams used in the business process model are:

  • Context Diagram
  • Activity (Collaboration) Diagram
  • Nested Activity Diagrams
  • Entities on Activity Diagram

Context Diagram

The context diagram, as its name implies, defines the context for the system—the boundaries of the system are defined along with the relevant actors and high-level activities as illustrated in the example below.



The context for the airline passenger system

This COntext Diagram indicates that there are Client actors that make reservations, check status and cancel reservations, and Individuals or Tour Groups that check-in, and interact with the airline in various other ways.

Activity Diagram

An activity diagram or (BPMN) collaboration diagram is used to detail a workflow and how business entities are used. This diagram, which is very simple in the Business Perspective, may use the following elements:

  • Activities represent the performance of a task or step within the workflow.
  • Sequence Flows show what activity state follows another. 
  • Gateways represent decision points in the workflow for which a set of conditions and choices are defined. Gateways control which sequence flow path, of a set of alternative flows, follows once the task is complete. You may also use the gateways to show where the threads merge again. Gateways allow you to show alternative threads in the workflow of a business process.
  • Events are used to show where the process starts and ends.

 Activity diagram detail for Individual Check-in

The diagram above is an activity diagram for the Check-In Business Activity for an airline.

Nested and Partitioned Activity Diagrams

An activity (subprocess) may contain another activity diagram (subprocess), which may show the internal structure of the activity. Stated another way, you can have nested activities or subprocesses that show all the details. Alternatively the subprocess enclosed within the parent may be "collapsed" and refer to another diagram where the internal detail is shown. As shown below an activity may contain further detail inside it, including other activities or structured activities, who's detail is shown in a separate activity diagram. 

Activity diagrams may also be partitioned to separate the workflow and components into logical groupings—these partitions are called lanes. As indicated in Guideline: Business Roles Model, this is generally used to define processes and sub-systems, similar to the example below. In this example there is a "research sub-system" and a "distribute reports" sub-system:

Activity diagram partitions 

The "drill down" decorators (Drill Down Decorator) on some of the activities indicates that these activities are defined in more detail in other diagrams. Note also that roles, defined in the Logical Perspective, have been imported back into this view.

Entities on Activity Diagrams

Details may be added to activity diagrams showing the business entities involved in the workflow (and roles as shown above). Unlike traditional data flows, however, these entities exist at a definite point within an activity diagram and illustrate their usage by particular activities. The diagram below has entities added to the scenario that illustrate what is produced and provided to the Customer to satisfy a request for consulting:

Activity diagram with object flows 

Business Location Model

Diagrams used in the business locations model are:

  • Business Location Model

Business Locations Mode

A deployment diagram is used to detail the business locations model.  At the business level, the locations model is mainly concerned with modeling the conceptual locations at which the business has a presence, along with the activities supported at these locations. The locations model is also concerned with security aspects, and illustrate how the various conceptual locations are structured and connect to support both the business and to address IT security requirements, at least at a very high-level through the definition of domains and zones. See Whitepaper: A Reference Model for Enterprise Security.

High-level Business Location Model 

The trivial example above illustrates how this is shown in a business locations model. Note that all the locations above are shown as domains, however using the strict definition of domain results in a picture as shown below, where some locations are not domains, but just extensions of the headquarters domain, in other words they are zones.

More probable locations model applying the strict definition of Domain 

The association of business activities with conceptual business locations can be done through the descriptions of the domains and zones in the model, but it more preferable to do it through the structuring of the model within the tool. In other words, the domains and zones defined are used to structure the business model, with all business activities being subordinate to the appropriate domain or zone. This approach also provides feedback on the level of abstraction and structure of the model in that if business activities are duplicated across several domains or zones then perhaps the business locations model isn't conceptual enough or the structure isn't incorrect. This duplication may be required, but it should be a warning sign regarding the structure of the model.

The locations models really come into their own at the logical and technical levels where technology elements are added to the modeling language.

Business Roles Model

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:

Business roles use-case model 

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:

Structure of roles within the enterprise 

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.