1. Architecture review methods
Assumptions
Types of reviews
Prework
The review
Follow-on activity
Value of architecture review
Other types of reviews

2. Assumptions
The architecture team believes that the review may be helpful to them
The review will be conducted by a small team of experienced architects from outside the project
There will be an opportunity to apply learning from the review to the software

3. Types of reviews Early Regular Quality attribute assessment
Architecture is just emerging
Focus is on assessing direction
Regular
Architecture is mostly done
Focus is on validating against requirements
Quality attribute assessment
Architecture has a problem or coming change
Focus is on how to fix or adapt

4. Types of pre-work Define review objectives Form review team Set agenda
Collect and excerpt existing documentation
Prepare talks (and possibly docs) specifically for the review
Checklists
Prototype and/or measure

5. Sample checklist questions - performance
Are the key scenarios defined?
Are frequencies for key scenarios known?
Has hardware been selected?
If not, is the economically-feasible range known?
Do budgets exist for shared resources (CPU, memory, disk space, disk accesses, etc)?
Do developers know their resource allocations?
Do developers have a way to check their resource utilization?

6. The review
“Typical” agenda
Ground rules
Recording methods

7. “Typical” agenda Introductions Purpose and objectives Requirements
Overall architecture
Architecture for critical subsystems
Quality attributes
Reviewers’ caucus
Reviewers’ feedback to the project team

8. Ground rules Do not design on the fly!!!
But it’s OK to suggest approaches or resources
Most aspects of the project have some connection with the architecture, so all types of questions are in order
But time is limited
All participants’ ideas may have value

9. Overuse of Singleton pattern – likely to limit scalability
Recording methods
Scribe(s)
“snow” cards
Overuse of Singleton pattern – likely to limit scalability
DES
Perf/Cap CR

10. Follow-on activity Written report
Communication with upper management and/or project sponsor
Project response to issues raised
Ongoing consulting

11. Value of architecture review
Decisions made as part of pre-work
Documentation written
Amplification of projects’ up-the-chain messages
Once in a while, uncovering a critical issue
Education for project team
Improved cross-project awareness
Identifying cross-project trends

12. Other types of reviews Business case Requirements Software design
UI design
Code reviews, code inspections
Test plans
Project management