Activity: Describe Current Business
This activity covers the work around understanding the as-is business and refining the objectives of the business-modeling effort.
Extends: Describe Current Business
DescriptionWork Breakdown StructureTeam AllocationWork Product Usage
The purpose of this activity is to understand the organization's current (as-is) processes and structure, and based on this understanding, refine the objectives of the business-modeling effort.
Parent Activities

The purpose of this activity is not to describe the entire organization in detail--only enough of it to allow the team to prioritize which parts of the organization to focus on for the remainder of the project. The reasons for doing business modeling should guide the breadth and depth of the effort (see Concept: Scope of Business Modeling). For example, a broader, more detailed business model will be necessary for a business process re-engineering (BPR) project than for domain modeling. 

[JAC94] (pages 164 - 167) points out, "While we realize that it is vital to produce this model, we wish to emphasize the importance of not spending too much time on it." It also observes, "There are of course situations where it is necessary to go into more detail, but this should be weighed up against the negative consequences of further modeling". This is said because in practice, it is very easy to end up modeling more than is necessary.

This usually starts with doing some groundwork before beginning to describe the business use cases. Typically, the organization structure is described, or refined if necessary (see the Organization and Geographic Views of the Business Architecture Document). Business Systems might be defined if a large part of the business will be modeled. Independently of this, a first sketch is made of the Business Entities in the Domain View of the Business Architecture Document. This greatly facilitates communication during the business-modeling workshops by providing a context for discussion. Also, one team may make a start at the Business Workers, possibly beginning with the employment positions within the organization. Although business workers represent roles and should therefore not be confused with positions, the positions provide a helpful starting point for identifying business workers.

Next the Business Goals are defined, using any that have been already identified during Assess Business Status. During or after describing the business goals, the Business Use-Case Model is fleshed out with Business Actors and Business Use Cases (and possibly Business Events). Business use cases should be traced back to the business goals that they support. During this tracing, it is possible that you may identify new or refine existing business goals. Where requirements that govern the behavior of the business use cases are uncovered (such as performance requirements), they must be documented in the Supplementary Business Specifications.

Based on the business-modeling objectives, the business use cases are prioritized, and the Business Process View of the Business Architecture Document is updated with the architecturally significant business use cases. Business Use-Case Realizations are then produced for the highest priority business use cases. Business Workers, Business Entities, and Business Events that have already been identified may be used as starting points, although these will be refined. While describing these current business use-case realizations, business rules will be uncovered, which should be captured in the Business Rules-either in a document or directly in the Business Analysis Model.

Any terms, concepts, and definitions discovered while performing these activities must be captured in the Business Glossary. At the end of this activity, objectives and expectations must be reconsidered and adjusted if necessary, based on the experience gained with the highest priority business use cases. If necessary, the Business Vision must be refined. While performing this activity, it might even become obvious that the assumptions or decisions made during Assess Business Status were incorrect. If this is the case, the Target-Organization Assessment might need to be adjusted to reflect the real situation.

Event Driven
Multiple Occurrences

Your business-modeling team, all acting as business-process analysts, should interact with the stakeholders' representatives. This extended business-modeling team needs strong business domain knowledge as well as an understanding of how software systems are currently used to automate the business. The core team members need to have good facilitation skills.

Key Considerations

Perform this activity if understanding the current business is a goal for the business modeling effort. Skip it if you have determined that no major changes will occur to the business processes, or if you plan to develop a new business more or less from scratch.

Conduct a workshop in which the goal is to understand and outline the business use cases and business actors in the current organization. The following sample techniques can be applied to help you collect correct and relevant information: