• Business Entity Model
• Business Locations Model
• Business Process Model
• Business Roles Model

• None

• Analyze Existing Architecture
• Define Migration Plan
• Gap Analysis

• None

• Architecture Glossary Template
• Business Perspective Document Template

• 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

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.

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.

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.

• Architecture Glossary
• Business Perspective

• Complex IT Architectures
• UAM Perspectives Contexts

• Business Perspective
• Business Perspective Views
• Plan the Business Perspective Activity

• BPL Defined
• BPL Summary