Introduction
 Introduction 
Concepts
 Concepts 
Workflow
 Workflow 
Activities
 Activities 
Artifacts
 Artifacts 
Artifacts
 Guidelines 

Develop a Domain Model Define Roles and Responsibilities Design Business Process Realizations refine Business Process Definitions Identify Business Processes Assess Business Status Describe Current Business Explore Process Automation

You can take one of several paths through this workflow. 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. Concepts: 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 Concepts: Scope of Business Modeling), you will follow the alternative Domain Modeling 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 Concepts: 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 Concepts: 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 Concepts: Scope of Business Modeling), you will envision the new business and build models of it, but skip "describe current business."


This content developed or partially developed by http://www.empulsys.com/rupbm -- This hyperlink in not present in this generated websiteEmpulsys BV.

Rational Unified Process   2003.06.13