The Business Analysis Model describes the realization of business use cases by interacting business systems, business workers and business entities. It serves as an abstraction of how business systems, business workers and business entities need to be related and how they need to collaborate in order to perform the business use cases. 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 Analysis Model is to describe how business use cases are performed. The Business
Use-Case Model describes what happens between business actors and the business, and makes no assumptions about
the structure of the business or how business use cases are realized. The Business Analysis Model, on the other hand,
concretely defines the services offered by the business (to be invoked by business actors in the performance of
business use cases), defines the internal business workers and the information they use (the business entities),
describes their structural organization into independent units (business systems), and defines how they interact to
realize the behavior described in the business use cases.

The Business Analysis Model describes internal structure and interaction without necessarily prescribing design
choices for business workers and business entities in terms of role bindings (to human workers or automated systems).
That is the purpose of the Business
Design Model, into which the Business Analysis Model evolves, as automation and refactoring options are explored.

The Business Analysis Model is used by stakeholders and business-process 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-process analyst is responsible for the structure and integrity of the model, while business designers are
responsible for detailing 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 business processes. 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.

The business analysis model describes how the business works internally to perform business functions, so the
model 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 this model.

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 the Business Analysis Model is not needed.

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

Whether you choose to keep and maintain two models - a Business Analysis Model and a Business Design Model -
depends on a number of considerations: if the Business Analysis Model is retained, to be useful it
must be maintained alongside the Business Design Model - and this is costly. If the business is stable, then the
Business Analysis Model is useful because it allows technology decisions, which do not affect the more abstract
business structure, to be revisited more easily. If there is high organizational or functional churn - there may be
less value, because the essence of the business changes and you need a new Business Analysis Model anyway.

Representation Options

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

The business analysis model may 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.

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

The Business Analysis Model is a way of expressing the business processes in terms of responsibilities, deliverables,
and collaborative behavior. When a new software system is to be developed or deployed, creating a Business Analysis
Model is mandatory in order to assess the impact of the system on the way the business works. Organizational changes
resulting from deploying new software are often overlooked and excluded from the Business Use Case, resulting in a
working software system that cannot be used.

Failure to produce a Business Analysis Model means you run the risk that software developers 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 software systems that are built do not support
the needs of the business.

We have identified four main variants for tailoring the Business Analysis Model:

You can choose to develop an "incomplete" Business Analysis Model, focusing on explaining "things" and products
important to the business domain. Such a model does not include the responsibilities people will carry; it only
describes the information content of the organization. This is often referred to as a domain model. In such a case, you would stereotype the model as <<domain model>> instead of <<business
analysis>>. A domain model is very useful for providing a common basis with which concepts can be clarified and
defined. For more information, see the Concept: Domain Design.

If the purpose of the business modeling effort is to do business (re-) engineering, you should consider building two variants of the
Business Analysis Model: one that shows the current situation and one that shows the envisioned new processes (target
situation).

The current version of the Business Analysis Model is simply an inventory of the Business Use-Case Realizations. The
elements of the Business Analysis Model are not described in any detail. Typically, brief descriptions are sufficient.
The Business Use-case Realizations can be documented with simple activity diagrams, where swimlanes correspond to
elements of the Business Analysis Model. The target version of the Business Analysis Model requires most of the
work. The current processes and structures need to be reconsidered and aligned with the business strategy and goals.

When you are business modeling for business
creation (a new line of business or organization, 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.

If the business analysis is well understood by all stakeholders and the project team, the benefits of developing a
Business Analysis Model are significantly diminished. Where this occurs, the Business Analysis Model may be omitted
entirely. However, it is usually a good idea to develop at least a minimal Business Analysis Model to improve
understanding of the way the business works among stakeholders.