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

How are you going to test it

Answer 2

Does it use SOLID principles?

Answer 3

Some other points to consider:

• Are all stakeholders identified? (Examples: Customer, end users, business analysts, user interface designers, developers, testers, maintainers.) Is the architecture verified with the stakeholders?
• How does the architecture address security?
• Are the requirements to availability and reliability specified? How does the architecture address these? (Examples: mean time between failures, mean time to repair.)
• How is disaster recovery handled?

Two good books for more ideas:

• Software Systems Architecture by Nick Rozanski and Eóin Woods
• Software Architecture in Practice by Len Bass, Paul Clements, and Rick Kazman

Answer 4

Is there a single person who can be responsible for the architecture with enough (1) technical knowledge of proposed architecture, (2) experience managing things, (3) standing in the company so that his decisions cannot be overridden by a management who doesn't know a thing.

Since (2) and (3) don't really depend on the architecture, I would find the person and ask him what he'd like to do.

Now assuming you're that person (and that's not obvious from your question -- that applies only if you think you'll still with being a chief architect of this thing for a while), I'd take an advice of Joel On Software blog and write a design specification, with the plans, goals, customers, explaining design choices, everything. That should clear the view.

Later thoughts

I tried to think a little as for what exact questions you might ask yourself after you've written the specification, like 'Is it easy to update your project', 'Does it allow flexibility in end goals', 'Will it make things easy to support', 'Are there any security problems' etc., but, while it's worthwhile to ask questions like these, I simply don't see any way they could be used for any 'evaluation' because other than with filtering out clear mistakes I don't think any specific question would help much to 'evaluate the architecture'. Perhaps your question would benefit from rephrasing?

Answer 5

Is the architecture in line with the technology vendors' guidance and roadmap?

You want to get support from your chosen platform, not fight it.

e.g. For Microsoft centric solutions this means documenting where and why your choices deviate from the Microsoft Architecture guidance.

Answer 6

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.