What should be included in an Application Architecture checklist?

Question

I'm trying to come up with a checklist or set of questions/criteria to assess and evaluate proposed or emergent architectures (perform architectural reviews). What are the most important questions you ask when trying to plan, assess or review an architecture?

I know this is a large topic so I'd like to constrain it to a single end-to-end system and not the architecture for an entire organization.

Code Complete provides a decent starting point:

Architecture

• Is the overall organization of the program clear, including a good architectural overview and justification?
• Are modules well defined, including their functionality and their interfaces to other modules?
• Are all the functions listed in the requirements covered sensibly, by neither too many or too few modules?
• Is the architecture designed to accommodate likely changes?
• Are necessary buy-vs.-build decisions included?
• Does the architecture describe how reused code will be made to conform to other architectural objectives?
• Are all the major data structures hidden behind access routines?
• Is the database organization and content justified?
• Are all key algorithms described and justified?
• Are all major objects described and justified?
• Is a strategy for handling user input described?
• Is a strategy for handling I/O described and justified?
• Are key aspects of the user interface defined?
• Is the user interface modularized so that changes in it won't affect the rest of the program?
• Are memory-use estimates and a strategy for memory management described and justified?
• Does the architecture set space and speed budgets for each module?
• Is a strategy for handling strings described, and are character-string storage estimates provided?
• Is a coherent error-handling strategy provided?
• Are error messages managed as a set to present a clean user interface?
• Is a level of robustness specified?
• Is any part over- or under-architected? Are expectations in this area set out explicitly?
• Are the major system goals clearly stated?
• Does the whole architecture hang together conceptually?
• Is the top-level design independent of the machine and language that will be used to implement it?
• Are the motivations for all major decisions provided?
• Are you, as a programmer who will implement the system, comfortable with the architecture?

I'm looking for practical knowledge with examples, e.g., what were the most painful points in an architecture you've created?

Answer 1

Based on my research, here are some architectural review checklists I've found that do this question a little more justice, and provide some background on what an architecture review is. (Seems to be a bit of confusion about it here.)

Each of these potential candidates include a number of different categories. The overall importance of these categories will vary somewhat depending on business needs. IMHO, that's OK. It's much less costly to ask another question when going through a checklist for a review and rule it out than it is to miss a question or category entirely because it didn't seem important enough to include on a checklist initially.

• "Software architecture review guidelines" by Alexander Nowak
• "Review Checklist for Architectural Design Document[s]" by Tom Verhoeff
• "Checklist: Architecture and Design Review" from Microsoft patterns & practices Developer Center
• "Conceptual Architecture Checklist" by Craig Borysowich
• "App Arch Guide 2.0 Knowledge Base: Checklist - Architecture and Design" by J.D. Meier, Alex Homer, et al. (found via Peter Stuer's link)
• "TOGAF Architecture Compliance Review Checklists" from the Open Group
• "Architecture Review Process" by Ricky Ho

There also appears to be a white-paper written on this topic, although I have not read it. It attempts to answer this question over the course of about 11 pages.

• Architecture reviews: practice and experience by Maranzano, Rozsypal, et al.

Additionally a colleague recommended a set of books from Springer, though I have not checked any of these out myself:

• The Enterprise Engineering Series from Springer