BPL Summary
UAM defines an integrated set of four viewpoint languages for each perspective, integrated into perspective languages. A summary of the Business Perspective Language is provided here, with links included to the complete definitions of each perspective.
Relationships
Main Description

Introduction

This document provides an overview of the Business Perspective Language defined in UAM. Overviews are defined for the other perspectives as well:

For very detailed descriptions of each perspective language see:

Business Perspective Overview 

The Business Perspective Language is based upon a very small subset of BPMN elements, with the addition of business entities, business locations, and business roles elements. The image below summarizes, using UML notation, the language elements and inter-relationships of the UAM Business Perspective language.

UAM Business Perspective Language Summary

This metamodel summarizes the Business Perspective language.

Business Entity Viewpoint

The Business Entity Model defines the high-level business entities involved in the enterprise or system, as defined by the scope of the modeling effort. The objective is to clearly define the business entities involved, and the relationships between them. The definition must be valid for the defined scope, and must eliminate any ambiguity regarding what they represent.

Relationships between entities are derived directly from analysis of the business, its functions and processes. Two main aspects are important, the relationships supporting the business processes and functions, and the relationships supporting the monitoring and management of the business. Note that generalizations, aggregations and other types of analysis are not done, and shouldn't be required when working at this conceptual level of analysis. Only simple associations are modeled, and the modeling is done and definitions derived at the business level using business terminology.

UAM Business Entity Model viewpoint language

The business actors that work with these entities are also identified. This is simply a start at identifying these important relationships. The majority of the analysis will take place at the logical level where the structure of actors and roles is defined and refined, along with their relationships to business entities, to identify the access controls aspect of IT security required.

Business Process Viewpoint

The Business Process viewpoint defines the high-level business activities and processes involved in the enterprise or system, as defined by the scope of the modeling effort. The objective is to clearly define the business processes involved. The definition must be valid for the defined scope, and must eliminate any ambiguity regarding what they represent.

The workflow of a business activity describes what the business must do to provide the value the served business role requires. A business process consists of a sequence of activities that, together, produce something of value for the business (role and associated actor). The workflow often consists of a basic flow and one or more alternative flows. The structure of the workflow is described graphically with the help of process diagrams. In summary, a business process is a sequence of activities that, together, produce something of value for the business role. Activities may have hierarchical structure defined in order to capture the level of detail required by the context and objective of the architecture effort.

 UAM Business Process Viewpoint Language

Optionally, relationships between Business Activities and Business Entities may be defined-namely, the Business Entities created, read, updated or deleted (CRUD) by the Activity.

Business Locations Viewpoint

The Business Location Model defines the high-level business locations involved in the enterprise or system, as defined by the scope of the modeling effort. The objective is to clearly define at the conceptual level the business locations involved, and the sorts of services provided within and between them. This information is important (in the long term) in deciding on the architecture for applications and services, so that they operate effectively over a slow speed WAN for example (i.e. addressing non-functional requirements). Security implications and requirements are also derived from this model, for example at this conceptual level some of these defined logical "locations" may include security domains and zones; however the full definition of required domains and zones is done at the logical level.

UAM Business Locations Model viewpoint language

It is important to clearly define the business locations and the relationships between them in terms of the services (activities and workflows) provided and notionally the services provided (data, voice, etc.) between them.

Business Roles Viewpoint

The Business Roles Model defines the high-level Business Actors and Roles involved in the enterprise or system, as defined by the scope of the modeling effort. The objective is to clearly define the Business Actors and Roles involved, and the sorts of interactions they have with the system. This information is important in deciding on the presentation architecture activities and services, so that usability concerns, integration concerns (at the user level) and other issues are understood. Security implications are also derived from this model-for example, access to information and services may be controlled based upon a user's role (e.g. Analyst vs. reporter vs. editor roles within a newspaper for example).

UAM Business Roles Model viewpoint language

It is important to clearly define the business roles 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 and requirements for software development specifically the interface to activities and tasks (i.e. Graphical User Interfaces (GUI), etc.).

It should be noted (as shown in the figure) that there can be multiple roles associated with a Business Activity and that each of these roles may have some specialization defined. This enables the capturing of multiple ways of interacting with the system for a given set of business activities and functions. The high-level conceptual perspective that one typically works at (at least initially) when developing the business views demands that the language supports this ability.