Capability Pattern: Business Modeling
This capability pattern covers the activities and workflow for the Business Modeling discipline.
DescriptionWork Breakdown StructureTeam AllocationWork Product Usage
Relationships
Description

You can take one of several paths through the workflow of the Business Modeling discipline. The path that you choose depends on the purpose of your business-modeling effort, as well as on your stage in the development lifecycle.

  • In your first iteration, you will assess the status of the organization and determine improvement areas, as defined in Assess Business Status. Based on the results of this assessment, you can make decisions regarding how to continue in this iteration, as well as on how to work in subsequent iterations. Scope of Business Modeling describes some typical scenarios that might occur. 
  • If you determine that no full-scale business models are needed and only a domain model is required (scenario #2 in Scope of Business Modeling), you will follow the alternative Develop Domain Model path of this workflow. In the Rational Unified Process, a domain model is considered a subset of the business analysis model, encompassing only the business entities of that model.
  • If you determine that no major changes will occur to the business processes, and you intend to develop a software system, all you need to do is chart those processes and derive software requirements (scenario #1 in Scope of Business Modeling). Because there is no need to keep a special set of models of the current organization, you can directly focus on describing the target organization. You will follow the business-modeling path, but skip "describe current business."
  • If you intend to deploy a new software system, you need to describe current business processes in order to understand how the software system will fit into the organization. The models will initially describe the current organization ("describe current business"), but will be adjusted to reflect the ways in which the software system will be used. In this case, you also need only one set of models. 
  • If you do business modeling with the intention of improving or re-engineering an existing business (scenarios #3, #4, and #6 in Scope of Business Modeling) or of making significant changes to the business, you will model both the current business and the target business. In this case, the Business Architecture Document is crucial to the assessment of the consequences of architectural decisions.
  • If you do business modeling with the intention of developing a new business more or less from scratch (scenario #5 in Scope of Business Modeling), you will envision the new business and build models of it, but skip "describe current business."
Properties
Event Driven
Multiple Occurrences
Ongoing
Optional
PlannedYes
Repeatable
Usage
Usage Notes

Decide How to Perform the Workflow

The following decisions should be made regarding the Business Modeling discipline's workflow:

  • Decide how to perform the workflow. There are several ways to perform the business modeling workflow, as described in Concept: Scope of Business Modeling. Decide which of the scenarios you will follow.  You may choose to document the decisions in the Development Case. The Artifact: Target-Organization Assessment describes the current status of the organization in which the system is deployed. It serves as input when you decide how to perform the business modeling workflow. 
  • Decide what parts of the Business Modeling activities to perform. For example, you can decide to just introduce a Domain Model if the project only needs a business analysis model, focusing on explaining products, deliverables, or events that are important to the business domain.  
  • Decide when, during the project lifecycle, to introduce each part of the workflow. As a general rule, the business modeling workflow should be introduced early in the project. 

Notice that you often need to assess the business status before you are ready to make decisions on how to use the Business Modeling workflow.