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
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.
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.
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.
Menu
514
