What can you learn from a software architecture review?

2 Types of reviews

Different types of software architecture reviews exist, depending on the purpose, scope, and format of the evaluation. For instance, the Architecture Trade-off Analysis Method (ATAM) is a structured and quantitative approach that evaluates the trade-offs among the quality attributes of the system, such as performance, availability, modifiability, and security. Alternatively, Scenario-Based Architecture Analysis Method (SAAM) is a qualitative method that assesses how well the architecture supports a set of scenarios that represent the system's functionality, usage, and evolution. Active Design Reviews (ADR) involve architects and developers in creating and reviewing the architecture using predefined checklists, questions, and exercises. Finally, Lightweight Architecture Evaluation (LAE) is a fast and informal method that focuses on the most critical aspects of the architecture and uses a simple rating scale to measure stakeholder satisfaction.

3 Review process

The software architecture review process typically consists of four phases: preparation, execution, analysis, and reporting. During preparation, the review team must define goals, scope, criteria, and schedule as well as collect and review relevant architectural documentation and artifacts. Execution involves conducting review sessions with the chosen method and tools to gather architectural information from architects, developers, and other stakeholders. Analysis requires synthesizing the results of the review sessions into issues, risks, strengths, weaknesses, opportunities, and recommendations that are prioritized and categorized. Lastly, reporting involves documenting findings and outcomes for stakeholders as well as suggesting improvements to address identified issues and risks.

4 Review team

The software architecture review team is a group of people that are responsible for planning, conducting, and reporting the review. This team should have a balanced and diverse composition, including a review leader who coordinates and facilitates the review process, reviewers who evaluate and provide feedback on the architecture, and a reviewee who presents and explains the architecture to the reviewers. The reviewers can be internal or external to the system development team and can have different roles such as architects, developers, testers, users, customers or experts. The reviewee is usually the lead architect or a representative of the system development team.

5 Review challenges

Conducting a software architecture review is a valuable and useful practice that can help you learn and improve your software system. It can identify and address architectural issues and risks, verify and validate architectural requirements and constraints, improve architectural communication and collaboration, enhance architectural quality and consistency, as well as learn from architectural best practices and feedback. However, there are some challenges to be aware of when conducting a software architecture review, such as lack of time or resources for a thorough review, resistance or reluctance from stakeholders to participate in or accept the results, conflicts or disagreements among reviewers, ambiguity or incompleteness of architectural documentation, and bias or subjectivity of the reviewers.

6 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?