Discipline: Business Modeling
This discipline provides guidance on different modeling techniques which may be used during a business engineering effort.
Main Description


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.


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.

More Information