Checklist: Architecture Notebook

The items in this checklist represent good practices for creating and communicating a robust architecture. It may not be possible to address every item, and you may be able to address some items to only a limited extent. In these cases, be sure that there are good reasons for only partially addressing an item or not addressing an item at all.

Architectural revisions can occur every day. Use this checklist regularly to ensure that the results are robust, consistent, and understandable. Make the architecture good enough for the specific goals being addressed by using this checklist to identify areas that have been skipped, ignored, or not sufficiently addressed.

Is the architecture understandable?

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, constraints and requirements been adequately described and handled?

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 rarchitectural goals, constraints and requirements?

Have necessary architectural mechanisms been identified and described?

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?

Have the system partitions been adequately defined?

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 elements been adequately defined?

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?

Have interfaces to external systems been adequately represented?

See Guideline: Representing Interfaces to External Systems

Has all reuse been identified?

Have all reusable assets been identified -- either those reused by the system, or those elements within the system that have been built to be reused. For more information, see Guideline: Software Reuse.

Has the architecture been built to evolve?

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

Can the architecture be delivered by the team?

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?

Has the software been adequately mapped to the hardware?

Have the deployable software components been mapped to physical nodes?