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.
The following overview is organized by viewpoint / aspect:
Viewpoints used in the Business Entity Model are:
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.
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).
A process diagram showing participating business activities and business entities in the business activity
Check-in.
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.
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.
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:
The "drill down" decorators ( ) 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:
Diagrams used in the business locations model are:
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.
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.
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.
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.
|