Checklist: Architecture

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 some items may only be able to be addressed to 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.

Architecture can be performed every day. Use this checklist regularly to ensure 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 overall structure of the architecture clear?

Are the key abstractions adequately defined?
Have necessary Architectural Mechanisms been identified and described?
Does the architecture divide the system’s responsibilities into well-defined subsystems with well-defined interfaces?
Does the packaging approach reduce complexity and improve understanding?
Is subsystem and package partitioning and layering logically consistent?
Are packages defined to be highly cohesive within the package, while the packages themselves are loosely coupled?
Are all of the subsystem components for the iteration identified?
Do the dependencies between subsystems and packages correspond to dependency relationships between the contained classes?
Do the classes in a subsystem support the services identified for the subsystem?
Are the number and types of components reasonable?

Have the supporting requirements been adequately addressed?

Does the architecture adequately address the global Functional requirements?
Does the architecture adequately address the Usability requirements?
Does the architecture adequately address the Reliability requirements?
Does the architecture adequately address the Performance requirements?
Does the architecture adequately address the Supportability requirements?
Does the architecture adequately address the other needs identified in the Supporting Requirements?

Can the architecture be delivered by the team?

Does the component 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?

Is architecture showing appropriate stability?

If in Inception, is a candidate architecture emerging?
If in Elaboration, is the architecture beginning to stabilize?
If in Construction, is the architecture generally stable?
If in Transition, is the architecture very stable?

In general, does the architecture seem sensible?

Is the architecture at an appropriate level of detail, given the objectives?
Are concepts handled in the simplest way possible?
Can the architecture easily evolve, so that expected changes can be easily accommodated?
At the same time, 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).
Are the key assumptions and decisions that the architecture is based on documented and visible to reviewers and consumers of the architecture?
Is the architecture description current?
Have the design guidelines been followed?
Are all technical risks either mitigated or addressed in a contingency plan?