• Is the description of the architecture complete, meaningful, and clear?
• Is the architecture at an appropriate level of detail, given the objectives?
• Are concepts handled in the simplest way possible?
• Does the architecture clearly convey not only the solution but also the motivation and objectives related to the decisions that have been made in shaping the architecture?
• Are the key assumptions and decisions that the architecture is based on documented and visible to reviewers and those who will use the architecture?
• Is the architecture description current?
• Have the design guidelines been followed?

• Have the Architectural Goals been clearly described?
• Have any Architectural Constraints been identified and documented?
• Have the Architecturally Significant Requirements been identified and are they clearly described.
• Is the architecture is consistent with the architectural goals, constraints and requirements?

• Is it clear when each Architectural Mechanism should be applied?
• Is there a clearly defined design pattern in place to support each mechanism?
• Does each mechanism adequately address the requirements it is intended to meet?

• Is partitioning approach clearly described and applied consistently?
• Does the partitioning approach reduce complexity and improve understanding?
• Have the partitions been defined to be highly cohesive within the partition, while the partitions themselves are loosely coupled?

• Have the Key Abstractions adequately defined?
• Have the the key design elements (i.e., Components) adequately defined?
• • Do the components have well-defined interfaces?
  • Have the system's responsibilities been allocated to the components?
  • Are the number and types of components reasonable?

See Guideline: Representing Interfaces to External Systems

• Can the architecture easily evolve, so that expected changes can be easily accommodated?
• Are all technical risks either mitigated or addressed in a contingency plan?
• Has the architecture been overly structured to handle unlikely change at the expense of simplicity and comprehensibility? (Hint: "Yes" to this question is not good.)

• Does the architecture provide a suitable basis for organizing the development teams?
• Does each team have the skills required to implement their allocated components?
• Are responsibilities divided well between teams?
• Do all team members share the same understanding of the architecture as the one presented by the architect?
• Can team members understand enough from the architecture to successfully design and code their allocated components?

• Have the deployable software components been mapped to physical nodes?