Рабочий продукт (Артефакт): Business Analysis Model

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.

Причины для отказа

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.

Опции представления

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:

Build an "incomplete" Business Analysis Model, including only the domain entities.
Build two versions of the Business Analysis Model, the current (as-is) and the target (to-be) model.
Build the target (to-be) model.
Exclude the Business Analysis Model.

Domain Modeling

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.

As-Is and To-Be Models

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.

To-Be Model

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.

Exclude the Business Analysis 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.