Skip to content
Module
Module 6 of 6Lesson 1 of 2~18 min

Running the architecture review of your product

A well-run architecture review brings risks to light before the team commits, without the PM stepping into the engineers' role. You prepare and facilitate the review of your own product with a set of open questions, log the answers in a risk register and turn choices into recorded decisions.

Take this lesson: your first course is freeSee the full syllabus

Lesson objective

By the end of this lesson, you will be able to prepare and run an architecture review with ten open questions, without taking the engineers' place, record the answers in a risk register and turn decisions into explicit trade-offs and ADRs.

Topics covered

  • architecture review
  • risk register
  • questions to ask engineers
  • architecture workshop

In the glossary

Full glossary

Where it fits

Running the architecture review

How do you ask the team the right questions, without being an engineer, and turn them into risks and decisions?

Lessons in this module

  1. Running the architecture review of your product (this lesson)
  2. Exit kit and action plan

What you will learn in this module

This lesson is part of the course Read and challenge a technical architecture

  • Read an architecture diagram (context and container levels of the C4 model) and spot its components, flows, boundaries and gray areas.
  • Turn vague expectations ("fast", "reliable", "scalable") into measurable non-functional requirements, written as quality attribute scenarios.
  • Compare monolith, modular monolith and microservices, then synchronous calls and asynchronous processing, based on the team, the load and the consequences for the user.
  • Assess data choices (source of truth, transactions, replicas, consistency), scaling and caching, and spot the bottleneck of a user journey.
  • Assess dependencies on third-party services (composite availability, degraded mode, vendor lock-in) and a build or buy decision.
  • Frame an architecture trade-off, record it in an ADR and treat technical debt as a product decision.
  • Run an architecture review of your product or of a proposal, with ten questions, a risk register and explicit trade-offs.

Related courses