Purpose
The purposes of business modeling are:
-
To understand current problems in the target organization and identify improvement potentials.
-
To assess the impact of organizational change.
-
To ensure that customers, users, developers, and other parties have a common understanding of the organization.
-
To derive the software system requirements needed to support the target organization.
-
To understand how a to-be-deployed software system fits into the organization.
An organizational chart is not enough to understand how a business works. We also need a dynamic view of the business.
A business model provides a static view of the structure of the organization and a dynamic view of the processes within
the organization.
A business needs to change according to the factors that drive it and keep it healthy. These factors might be goals
such as reducing costs, improving quality, or shortening time-to-market. We need to model the business to localize
problems or identify opportunities for improvements. A characteristic of a healthy-and-learning organization is that it
is able to adapt as its business drivers change.
Many different people (stakeholders) need to understand the business. Because all of these people have different
backgrounds and interests, they have different views of the business. We need to model the business in a simple,
understandable way, using a common notation. The business model must support the ability to be described in different
ways using different views and levels of abstraction. If everybody cannot understand your business model, you are
missing the point of modeling the business!
Business is about delivering value to customers to make a profit. Running a business is about making decisions, and
information is the most important determinant in the quality of decisions [MARS00]. Information systems must be
designed to ensure that the information provided is timely, accurate, sufficient, and relevant. We can ensure that
information systems support business decisions in this way only if we understand the context in which those decisions
are made.
Artifacts
To achieve these goals, the business-modeling discipline describes how to assess the current organization and develop a
vision of the new organization. Using this vision as a basis, it then defines the processes, roles, and
responsibilities of that organization in a business use-case model and a business-analysis model.
Complementary to these models, the following artifacts are developed:
-
Business Vision
-
Business Architecture Document
-
Supplementary Business Specification
-
Business Rules (either as a document and/or as elements in the Business Analysis Model)
-
Business Glossary
Process and Notation
There are many available business-modeling techniques and notations that have been used with varying
degrees of success. However, there are fewer business-modeling
processes. The RUP provides a process for business modeling. The Unified Modeling Language (UML) can be effectively applied to modeling both
software and a business. The single most important advantage in using the same modeling notation for both business and
software modeling, is that business analysts and software developers share a common language. This allows a direct and
efficient translation between models of the business and models of the software systems that support that
business.
Modeling, understanding, and improving a business is very much like building a software system. There is a journey of
discovery in the beginning that includes defining the objectives and scope. This journey also involves making a broad
high-level outline and filling it in piece by piece. We cannot focus on one piece, finish it, and never look at it
again. Very often we must revisit pieces that we already have modeled and change them based on new insights and
understanding. We cannot wait until we have completely finished modeling the entire business before we start verifying
our work and making improvements.
Business modeling is therefore best done in an iterative fashion, starting with the broad overview and filling it in
piece by piece. In every iteration, we revisit the broad overview and make any necessary adjustments. We then fill out
more of the overview and verify the work that we have done. These steps must be completed before starting the next
iteration.
Relation to Other Disciplines
The business-modeling discipline is related to other disciplines, as follows:
-
The Requirements discipline uses business models as an important input to understanding the requirements of
the system.
-
The Analysis and Design discipline uses business models as an input to defining software systems that
seamlessly fit into the organization.
-
The Deployment discipline uses business models as an aid in planning the deployment of a software system.
-
The Environment discipline develops and maintains supporting artifacts, such as the Business Modeling
Guidelines.
|