Artifact: Business Perspective

The Business Model describes the "system" in terms of Business Entities, Business Processes, Business Locations, and Business Actors/Roles. It serves as an abstraction of how these aspects need to be related and how they collaborate in the business. It also defines the business services that are invoked by Business Actors/Roles.

Domains: UAM Deliverables
Work Product Kinds: Business Level

Purpose

The purpose of the Business Perspective is to describe how the business operates (activities and processes), what is involved in these processes (entities), where the business has a presence (locations), and who interacts with the business activities (actors/roles). It makes no assumptions about the structure of the business or how business activities are implemented. The Business Perspective, on the other hand, concretely defines the services offered by the business (to be invoked by business actors/roles in the performance of business activities), defines the internal business actors and the information they use (the business entities), and to some extent describes the structural organization (business organizations), and defines how they all interact through the definition of business processes.

The Business Perspective describes business structures and interactions without necessarily prescribing design choices for business actor/role and business entities in terms of role bindings (to human workers (users) or automated systems). That is the purpose of the Logical Perspective, into which the Business Perspective evolves, as automation and refactoring options are explored.

The Business Perspective is used by stakeholders and business-process analysts to understand how the business currently works (if in an as-is form), and to analyze the effect of changes to the business (if in a to-be form). The IT architect is responsible for the structure and integrity of the model, while business designers are responsible for detailing elements within the model. The model is used by architects for deriving the Logical Perspective models.

Relationships

Parent Deliverables	Architecture Review Package Architecture Update Package Consultation Review Package IT Architecture Technology Analysis Package Training Course Creation Package
Contained Artifacts	Business Entity Model Business Locations Model Business Process Model Business Roles Model
Roles	Responsible: Business Line or Domain Architect Business Unit or Project Architect Enterprise Architect	Modified By: Enterprise Architect
Tasks	Input To: Analyze Business Opportunities Analyze Options and Pick Solution Analyze the Architecture Assess the Architecture Consult with Stakeholders Define a Migration Plan Define an Architectural Decision Define Impacts of Solution Define Simple Architecture Models Define Technology Change Impacts Develop a Training Course Existing Architecture Analysis Manage Follow-up Organize an Architectural Review Organize an Architectural Update Organize Consultation Organize Development of Training Organize Technology Analysis Refine Problem Definition Review an Architectural Decision Review an Architecture Review a Training Course Target vs. Existing Gap Analysis Update an Architecture Perspective	Output From: Update an Architecture Perspective
Process Usage	Business Perspective IT Architecture Delivery > Architectural Decision Delivery > Business Perspective IT Architecture Delivery > Review the Architecture > Review Business Perspective > Business Perspective IT Architecture Delivery > Business Perspective Delivery > Business Perspective Iteration [n] > Business Perspective IT Architecture Delivery > Business Perspective Delivery > Business Perspective IT Architecture Delivery > Maintain Architecture > Deliver Updated Business Perspective > Business Perspective IT Architecture Processes > Define Business Perspective > Business Perspective IT Architecture Processes > Review an Architecture > Business Perspective IT Architecture Processes > Manage Architectural Decisions > Business Perspective IT Architecture Processes > Develop a Migration Plan > Business Perspective IT Architecture Processes > Analyze Models > Business Perspective IT Architecture Processes > Develop Training > Business Perspective IT Architecture Processes > Consult with Stakeholders > Business Perspective IT Architecture Processes > Update Logical Perspective > Business Perspective IT Architecture Processes > Update Technical Perspective > Business Perspective IT Architecture Processes > Business Perspective IT Architecture Processes > Update Business Perspective > Business Perspective IT Architecture Processes > Define Solution and Impacts > Business Perspective

Description

Main Description

The Business Perspective has the following parts or aspects:

Business Entity Model - model of business entities consumed and produced by Business Activities;
Business Process Model - model of the structure of Business Activities (which produce and consume entities), forming processes;
Business Locations Model - model of the Business Locations where the "system" has a presence;
Business Roles Model - model of the Business Actors/Roles (Note: Only Actors defined at the Business level).

Each of these viewpoints is actually a collection of models that (typically hierarchically) define the aspect. See: Concept: Architecture Perspectives and Viewpoints.

Illustrations

Templates	Architecture Glossary Template Business Perspective Document Template
Reports	Business Activity Report Business Entity Model Report Business Entity Report Business Events Report Business Locations Model Report Business Locations Report Business Perspective Report Business Process Model Report Business Role Report Business Roles Model Report Business Rules Report

Tailoring

Impact of not having

The Business Perspective describes how the business works internally to perform business activities and provide services. Therefore, the model is essential when considering changes to the business processes or when augmenting or reducing the scope (mandate) of the "system"—reasoning about such changes without this model is impossible. Also, failure to produce a Business Perspective means you run the risk that architects and designers will give only superficial attention to the way business is done. They will do what they know best, which is to design and create software in the absence of business (process) knowledge. The result can be that the systems that are built do not properly support the needs of the business and opportunities for optimizations will be missed.

Reasons for not needing

If the objective of the business modeling effort is simply to specify new capabilities, or to formulate a business vision, then the Business Perspective is not needed, or may be very simple and high-level.

When the intention is to improve some aspect of business performance, and perhaps change the business processes, for example, through the introduction of automation, then it is likely that the Business Perspective will evolve into a Logical Perspective, with choices made about role bindings (human, software, system).

Whether you choose to keep and maintain the two perspectives—the Business Perspective and the Logical Perspective—depends on a number of considerations: the Business Perspective must be retained, to be useful it must be maintained alongside the Logical Model, which is costly. If the business is stable, then the Business Perspective is useful because it will not change but it does allow technology decisions, which do not affect the more abstract business structure, to be revisited more easily. Therefore, if the business is well understood by all stakeholders, the enterprise and domain architects, and the project team, the benefits of developing a Business Perspective are significantly diminished. Where this occurs, the Business Perspective may be omitted entirely—but not recommended! It is usually a good idea to develop at least a minimal Business Perspective (i.e., to-be) to improve understanding among stakeholders of the way the business works: to develop the common language and concepts of the business.

Representation Options

UML Representation: «stereotype» BPL_Perspective

Extends: «metaclass» Package

The Business Perspective has the following parts:

Introduction - A textual description that serves as a brief introduction to the models;
Aspects: The architectural aspects of the perspective, with each possibly defining a hierarchy of detail under four top level models:
- Business Entity Model - model of business entities consumed and produced by logical functions
- Business Process Model - model of the structure of business activities (which produce and consume logical entities), forming processes
- Business Locations Model - model of the business locations
- Business Roles Model - model of the business actors/roles

The Business Perspective is a way of expressing the business processes in terms of responsibilities, deliverables, and collaborative behavior. When a new business line or activity is to be added to the enterprise (e.g. A retailer adding "online purchasing"), creating a Business Model is mandatory in order to assess the impact of the new activity on the way the business works. Note that the management organization of the enterprise is orthogonal to the business model -- in other words organizational changes do not affect the mandate, activities and processes within the enterprise (but often the two (i.e. business change and organizational change) are done at once).

There are two main variants of the Business Perspective:

As-Is - Define the current (as-is) models;
To-Be - Define the target (to-be) models.

As-Is and To-Be Models

If the purpose of the business modeling effort is to do business process reengineering, you should consider building two perspectives: one that shows the current situation (the as-is Logical Perspective) and one that shows the envisioned new situation (target or to-be Business Perspective). The as-is model are defined at the Logical level since they will be typically based upon system documentation, and not existing IT architectures. In this case a Business Perspective is not needed, but this is an optional starting point for the definition of the to-be models.

The as-is version of the Business Perspective is simply an inventory of the Business Activities. The elements of the Business Model are not described in any detail. Typically, brief descriptions are sufficient. The Business Activities can be documented with simple diagrams, where swimlanes correspond to organizational elements within the system. The target to-be version of the Business Model requires most of the work. The current processes and structures need to be reconsidered and re-aligned with the business strategy and goals.

To-Be Model

When you are business modeling to define a new line of business or new product/service offering, for example, there is no existing business framework from which to create an as-is model. You should look for reference business architectures and processes to assist you in the creation of the target model.

More Information

Checklists	Architecture Glossary Business Perspective
Concepts	Complex IT Architectures UAM Perspectives Contexts
Guidelines	Business Perspective Business Perspective Views Plan the Business Perspective Activity
Supporting Materials	BPL Defined BPL Summary