WorkProductDescriptor
Work Product (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 |
|
Roles | Responsible:
| Modified By:
|
Description
Main Description | This 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
Concepts |
|
Guidelines |
|
Whitepapers |
|
Licensed Materials - Property of IBM
© Copyright IBM Corp. 1987, 2012. All Rights Reserved.
|
|