Architecture Review
A scoped review of a system that has become hard to change, scale, or explain.
When This Helps
A review is useful when the team needs a clearer model of the system before making a major decision.
- Performance changes under load and the cause is unclear.
- Important state, queues, or failure paths are poorly understood.
- The team is planning a rewrite, migration, or major architecture change.
- Operational incidents point to repeated assumptions that need testing.
- Leadership needs a technical view that can be explained without hand-waving.
What the Review Can Include
Architecture Map
A practical map of the parts that matter: data flow, state ownership, runtime boundaries, and operational dependencies.
Runtime Observations
Review of logs, metrics, traces, profiling data, or code paths where they are available and relevant.
Risk Summary
A short list of risks, weak assumptions, and constraints that should shape the next decision.
Recommended Next Steps
Prioritized options that may include refactoring, measurement, team changes, training, or leaving some parts alone.
Scope
The review is scoped after a short conversation about the system, access, urgency, and expected output. Some reviews are small and advisory. Others include deeper code reading, profiling, or follow-up workshops.
Compliance-specific work is included only when it is explicitly part of the scope. The default output is technical clarity. Formal audit certificates need separate scope.
