Overall, the architecture is sound, because:

• The architecture appears to be stable.

  The need for stability is dictated by follow-on phases. Instability at this level results in even higher instability in the lower level Logical and Technical perspectives.

  The importance of a stable architecture cannot be overstated. Do not be deceived into thinking that 'pretty close is good enough'—unstable is unstable, and it is better to get the architecture right and delay the move to the Logical or Technical view rather than proceed. Changes to higher level architecture perspectives and viewpoint models have broad impact: they tend to be expensive, disruptive and demoralizing.

  The real difficulty of assessing architectural stability is that "you don't know what you don't know"; stability is measured relative to expected change. As a result, stability is essentially a subjective measure. We can, however, base this subjectivity on more than just conjecture. The architecture itself is developed by considering 'architecturally significant' scenarios—sub-sets of activities that represent the most technologically challenging behavior the system must support. Assessing the stability of the architecture involves ensuring that the architecture has broad coverage, to ensure that there will be no 'surprises' in the architecture going forward.

  Past experience with the architecture can also 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 architecture is consistent, coherent and comprehensible
• The architect can understand enough from the architecture to successfully develop the Logical Perspective.
• The packaging approach reduces complexity and improves understanding.
• Packages have been defined to be highly cohesive within the package, while the packages themselves are loosely coupled.
• The architecture can be easily understood by someone generally knowledgeable in the business area.
• Existing Architectural Decisions have been consulted and followed.
• The Business Perspective viewpoint models and included documentation is current.
• The architecture does not appear to be "over-designed".
  • The structures and detail is sufficient for comprehension.
  • The structures and detail is modest and consistent with the scope and objectives of the architecture.
• All business activities defined can be executed by the architecture, as demonstrated by diagrams depicting:
• • Interactions between activities and processes,
  • Interactions between activities/tasks and business entities.

• There are no more than seven (plus or minus two) layers;
• The rationale for layer definition is clearly presented and consistently applied;
• Layer boundaries are respected within the architecture;
• Layers are used to encapsulate conceptual boundaries between different kinds of services and provide useful abstractions which makes the design easier to understand.

• Is the name and description of the business entity clear and understandable?  
• Is each relationship to/from the business entity used in the workflow of at least one business activity?
• Does the business entity participate in at least one business activity?
• Does the business entity have an owner, and actor responsible for its creation/management?
• Does the business entity get created before it gets used or manipulated?
• Do significant state changes of the entity trigger a business event?
• Have all appropriate (required business level) attributes been identified?
• Does the business entity have the appropriate/required relationships with related business activities, business events, and other business entities?
• Considering the entire business; are all things in it, such as products, documents, and contracts, modeled as business entities?
• Does the business entity represent significant information within the business?
• Will the business entity be updated or referenced at some stage?
• Does the business entity represent persistent information?   

• Do the business activities conform to the business you want them to describe?
• Have all the business activities been found? Taken together, the business activities should define the complete business.
• Are there multiple business activities with very similar names? If so, consider merging them or changing their names.
• Are the business activities aligned with the business strategy and other business plans?
• Does each business activities support at least one business goal?
• Are all activities within the "system" included in at least one business activity?
• Is there a balance between the number and the size of the business activities?
• Is each business activity unique? If not, consider merging it with a similar business activity.
• Is each business activity involved with at least one business actor?  If not, is it meaningful?

• Do the business locations conform to the business being described?
• Have all the business locations been found? Taken together, the business locations should define the complete business.
• Are there multiple business locations with very similar names? If so, consider merging them or changing their names.
• Are the business locations aligned with the business strategy and other business plans?
• Does each business location support at least one business goal?
• Are all locations within the business included in at least one business activity?
• Is each business location conceptually unique? If not, consider merging it with a similar business location.
• Is each business location involved with at least one business actor?  If not, is it meaningful?

• Have all business actors/roles been found?
• Does each business actor express a role, not a person? Try to name at least two people (or a system) that can act as the actor.
• Is each business actor involved with at least one business activity? If not, remove it.

The complexity of the business viewpoint models should have a similar level of complexity (and also in relation to the scope/complexity of the "system") ... actually it should be less complex that the actual "system" since that is the point of modeling something, to define simpler abstractions as an aid to comprehension. This is a relative evaluation, therefore as always when creating an architecture the level of complexity and detail required is always a judgment call. The level required should be driven by the intended use for the architecture.

Given the high-level nature of IT architecture models, more work is required before an implementation project is started. The business analysts, architects or other concerned parties must be able to take this next step based upon the Business Perspective viewpoint models: producing the Logical Perspective viewpoint models. A judgment call is required regarding the level of detailed needed within each Business level viewpoint.

This is very much enabled by have clear separations of concerns in the model, and in the functional view having clear separation between business functions and few interfaces.

• 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.

If the architecture appears to be stable, the Business Perspective models will in general be reasonable. 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. One must not get too hasty in viewing a business model as 'unstable', since this view could be caused by the influence of technological change, which in turn may impact the business but not necessarily—in other words, a business viewpoint model if crafted well is totally independent of technological change and defines the important aspects of the given business domain (e.g., car manufacturing, or retail sales, etc.). This independence of the business perspective models from changes in technology (i.e., in how technology supports business activities) may not hold if the business is heavily dependent, driven and involved in information technology; if the enterprise is in the information technology business, such as a telecommunications or computer equipment manufacturer.