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:
See also Guideline: Target-Organization Assessment.
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.
|