Introduction to Business Modeling
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, end 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.
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
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.
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.