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.
|
This content developed or partially developed by Empulsys
BV.
|
|
|
