Checkpoints:  Business Architecture Document

In general, the business architecture appears to be reasonable if:

• The business architecture appears to be stable.

Past experience with the architecture can be a good indicator: if the rate of change in the architecture is low, and remains low as new scenarios are covered, there is good reason to believe that the architecture is stabilizing. Conversely, if each new scenario causes changes in the architecture, it is still evolving and baselining is not yet warranted.

• The complexity of the business architecture matches the functionality and value it provides to its customers.
• The conceptual complexity is appropriate given the skill and experience of its:
  • users
  • operators
  • developers
• The business has a single consistent, coherent business architecture definition. 
• The business has a consistent enterprise-wide security facility.  All the security components work together to safeguard the business.
• The products and techniques on which the business and its automation is based matches its expected life.
• The business architecture provided defines clear interfaces to enable partitioning for parallel team development.
• The business designer of a model element can understand enough from the business architecture to successfully design and develop the model element (business worker or business entity).
• Packages (organization units) have been defined to be highly cohesive within the package, while the packages themselves are loosely coupled.
• Similar solutions within the common business domain have been considered.
• The proposed solution can be easily understood by someone generally knowledgeable in the problem domain.
• All people on the team share the same view of the business architecture as the one presented by the business-process analyst(s).
• The Business Architecture Document is current.
• The Business-Modeling Guidelines have been followed.
• All risks been either mitigated or have been addressed in a contingency plan. New risk discovered have been documented and analyzed for their potential impact.
• The key performance requirements (established budgets) have been satisfied.
• There are routines in place for verifying the business works as specified.
• The business architecture does not appear to be "over-designed".

• The mechanisms in place appear to be simple enough to use. 
• The number of mechanisms is modest and consistent with the scope of the system and the demands of the problem domain.

• All business use-case realizations defined for the current iteration can be executed by the business architecture.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process