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

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

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

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

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?

The review “Typical” agenda Ground rules Recording methods

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

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

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

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

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

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