Work Product Descriptor (Artifact): Business Model
The Business Model describes the realization of business use cases by interacting business elements such as business workers, business entities, services, or business systems. It also defines the external business services that are invoked by business actors in the performance of business use cases.
Purpose

The purpose of the Business Model is to describe how the business works to provide that which is described by the business use cases.


Relationships
Contained Artifacts
RolesResponsible: Modified By:
Description
Main DescriptionThis artifact defines the services offered by the business in terms of interfaces and operations, the information that is passed around (business entities), the internal business structures (that is, organization and business workers), and how they collaborate to realize the external behavior described in the business use cases.

This Business Model is used by stakeholders and business analysts to understand how the business currently works (in as-is form), and to analyze the effect of changes to the business (in to-be form).  The business analyst is responsible for the structure and integrity of the model along with detailing the elements within the model.  The model is also used by systems analysts for deriving system requirements based on how automated systems - that is automated business workers (usually software-intensive) - will be used as part of the business process.  Software architects use the model to define a software architecture that fits the organization seamlessly and to identify classes in software analysis and design models.

Brief Outline

The Business Model can have the following properties:

  • Introduction: A textual description that serves as a brief introduction to the model.
  • Business Systems: Components in the model, representing a hierarchy*.
  • Business Workers: The Business Worker classes in the model, owned by the Business Systems.
  • Business Entities: The Business Entity classes in the model, owned by the Business Systems.
  • Business Events: The Business Event classes in the model, owned by the Business Systems.
  • Business Rules: The Business Rules captured in the model. These are not the Business Rules that are captured in document form in a separate artifact.
  • Relationships: The relationships in the model, owned by the Business Systems.
  • Business Use-Case Realizations: The Business Use-Case Realizations in the model, owned by the Business Systems.
  • Business Context Collaboration: The external realization of the interactions between the business and the business actors, showing the services provided by the top-level Business System (that is, the business itself), the interfaces for these services, the connections to the business actors, and the Business Entities input and output.
  • Diagrams: The diagrams in the model, owned by the Business Systems.

For a more detailed description of different flavors of this artifact see descriptions of the artifacts contained within the Business Model.

*Note that the business itself is the top-level component (Business System), and directly encapsulates business workers, business entities etc.

Properties
Optional
Planned
Illustrations
Key Considerations

Early design work generally begins with analysis and is abstract. This analysis model is transformed into a design model as abstract elements become more concrete.  For example the initial Business Workers can be mapped or refined into human workers or automated systems.

The Business model captures both the analysis work and the design work.  This work can be captured in two separate business models - the Business Analysis Model and the Business Design Model. In larger efforts there can be aspects of the business that are still under analysis while others are being designed.  In this case the business model contains both analysis and design.

See Guideline: Maintain Business Analysis and Design Models if you're considering maintaining analysis and design models side-by-side.

Tailoring
Impact of not having

This artifact is essential when considering changes to the business processes or the organization (structure, roles and responsibilities). You will be unable to reason about such changes without an artifact that describes how the business operates.

Failure to produce this artifact increases the risk that software developers give only superficial attention to the way business is done.  The result is software systems that do not support the needs of the business. 

Reasons for not needing

If the objective of the business modeling effort is simply to specify needed behavior (through Business Use Cases), or to formulate a Business Vision, then this artifact is not needed.

Representation Options

UML Representation:  Model, stereotyped as <<business>>.

The following are variants for tailoring the Business Model: 

  • Build an "incomplete" Business Model, including only the domain entities.
  • Build two versions of the Business Model, the current (as-is) and the target (to-be) model.
  • Build the target (to-be) model.
  • Build and maintain a separate Business Analysis Model and a Business Design Model
  • Build one Business Model that might begin as analysis and transforms into design.

More Information