45

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?

vmg
  • 4,176
  • 2
  • 20
  • 33
cwash
  • 4,185
  • 5
  • 43
  • 53
  • This assumes that the application is well-known otherwise you may not have these questions answered. For example, if you are with a company that is moving out of their comfort zone, or exploring a new concept, then you may not have it fleshed out, but there are still some issues that could be asked, as you design the architecture, while developing the application. – James Black May 30 '09 at 06:19
  • Point taken. The question will probably need of some revision. I'm looking less for CC-style questions and more for the types of things you find yourself asking about or look for when trying to evolve an architecture or "right the ship." The analogy to coding would be if I'm at a point where I can refactor, I look for duplication or code smells. If you were doing something similar with architecture, what kinds of things would you look for? – cwash May 30 '09 at 07:05

6 Answers6

41

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.

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.

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

cwash
  • 4,185
  • 5
  • 43
  • 53
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:

markusk
  • 6,477
  • 34
  • 39
  • I checked out the Rozanki and Woods book - It's a bit academic but the information is of very high quality. Thanks. – cwash Jun 23 '09 at 20:23
2

How are you going to test it

Community
  • 1
  • 1
Steven A. Lowe
  • 60,273
  • 18
  • 132
  • 202
2

Does it use SOLID principles?

aleemb
  • 31,265
  • 19
  • 98
  • 114
2

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.

Peter Stuer
  • 1,945
  • 2
  • 19
  • 18
0

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?

ilya n.
  • 18,398
  • 15
  • 71
  • 89