How to do a preproject Architecture review

Question

It is relativility easy to see an architecture error when the project is over. X gave us security problems, or Y gave us a lot of extra work. These are caught in the retrospectives, but it would be nice to catch them earlier.

We are planning on carrying out architecture reviews before the coding starts.

One way is just to get the architect to present the project and see if we can find flaws in the design.

Does anyone have a more structured approach, maybe with a "Have you thought of" or "How are you going to do" check list.

I was thinking of something like:

• Security
• Logging
• Data Access
• Deployment
• Upgrading

Answer 1

You should use well known patterns and maybe even architecture frameworks to reduce the what-ifs.

It is relatively easy to see architecture errors when project are over, but that lies in the nature of what we are doing.

I believe it is good practice to continuously do architecture reviews. It's not a step you just 'complete'.

Answer 2

For important project one thing we do is a solution options document. You do brainstorming, gather existing information, talk with SMEs, talk with whoever required and create a table for various options with pros, cons, rough cost and estimates. Yes this exercise is an overhead but a lot of those issues that you describe will be known if you do this.

At the end recommends a solution to management with reasons and possibly a high level architecture diagram to visualise the solution.

Answer 3

Obviously there are a large number of books out there on the subject (E.G., 97 things an architect should know). You can find a comprehensive list of axioms here and I'd suggest that you cherry pick those that make sense to your projects for your checklist.

Answer 4

Additional items to add to your list, in no particular order:

• Performance - either latency, bandwidth, scaling or other factors related to your deliverable
• Supportability - You already have logging, but what about plumbing in other diagnostic measurements (Java-JMX, Windows-WMI/Performance counters or something custom)
• Flexibility - Difficulty in changing the architecture later (this is usually one of those things that is overly done and causes more problems than necessary, but the discussion should be present when evaluating a design)
• Threading model / locking model - Is it clear how data will be protected ? How will resource contention be handled ?
• Resource requirements - memory consumption at various levels of use. Does it fit into your constraints ?
• Error handling - When something in the product fails, does the architecture support clean handling and notification of problems ?
• Understandable - Overly complicated architectures tend to be forgotten during implementation. If the majority of the team, and in particular the leads, can't keep the architecture, it's philosophies and rules, in their heads, the architecture won't matter.
• Consistency. Does it try to use every possible pattern or focus on regular, repeated patterns. Not that picking the right pattern for each problem isn't a good thing, but having a lot of patterns can affect understandability and lead to implementation mistakes. An architect should be trying to demonstrate everything they know (or the latest cool thing) in every project.
• Testable - Does the design help or hurt testing (system and integration) efforts. Can the testing be automated or will you be reliant on an army of testers to continuously repeat regression testing so that you know your team hasn't broken the product ?
• Does the architecture actually address the problem you are trying to solve and within the scope of the problem ? Don't create a sky-scraper when duplex will be sufficient.

Answer 5

Change is constant,make sure your architecture is adaptable.
User Interface is what improves users experience.
Share you knowledge about the archotecture with all completely.
Try before you implement.
Don't over use design patterns.