TOGAF is the most widely used enterprise architecture framework, and architecture reviews are central to it. You don't need to adopt all of TOGAF to run reviews the way it intends.
TOGAF treats review as a continuous obligation rather than a single gate. Architecture Compliance Reviews appear as a formal activity, and Phase G — Implementation Governance — exists specifically to ensure what gets built matches what was agreed.
The underlying idea is straightforward: an architecture that is agreed and then not enforced is a document, not an architecture. Reviews are the mechanism that closes the loop between decision and delivery.
Usefully, none of this requires adopting all of TOGAF. The review approach is one of the more portable parts of the framework and works perfectly well on top of a homegrown method — see frameworks compared for the wider picture.
| Phase | Review focus |
|---|---|
| A — Architecture Vision | Is the scope and outcome agreed, and is it worth doing? |
| B / C / D — Business, Information Systems, Technology | Are the domain architectures internally consistent and aligned to principles? |
| E / F — Opportunities, Migration Planning | Is the transition sequence viable and adequately resourced? |
| G — Implementation Governance | Does what is being built match what was agreed? This is the compliance review proper |
| H — Change Management | Has anything changed enough to require rework of the architecture? |
Most organisations that say they "do TOGAF reviews" are doing Phase G and little else. That is not wrong, but reviewing only at implementation means the review can catch divergence and cannot influence the design that produced it.
TOGAF describes an Architecture Board — in most organisations this is the design authority. It owns compliance, resolves disputes, and holds the authority to approve or reject.
TOGAF is deliberately light on how to run it, which is where most implementations struggle. The framework tells you the body should exist and what it is responsible for; it does not tell you the quorum, the cadence, the submission lead time or the escalation route. Those have to be decided locally and written down, and skipping that step is why many TOGAF-aligned governance models never function.
TOGAF frames it as compliance against the agreed architecture — principles, standards, target state and any constraints set in earlier phases. In practice a workable review covers the same ground as any good architecture review: business fit, design integrity, data, integration, security, compliance, non-functional targets, operability, cost and risk. The architecture review checklist covers this in depth.
The distinctly TOGAF emphasis is traceability — can you show that this design decision follows from an agreed principle or requirement, and that a deviation was consciously accepted? That emphasis is genuinely valuable and is worth keeping even if you use nothing else from the framework.
TOGAF distinguishes degrees rather than a binary pass or fail, which is more useful than it first appears: fully conformant, compliant with agreed deviations, and non-conformant. The middle category is where most real solutions land, and naming it explicitly stops reviews collapsing into an unwinnable argument about whether something "passes".
Where deviations are accepted, they should become recorded, time-boxed exceptions rather than notes in a minute. An accepted deviation without an expiry is how a temporary compromise becomes permanent architecture.
The most common failure of TOGAF-based review is procedural weight — templates nobody completes properly, artefacts produced because the content framework lists them, and reviews that take three weeks to schedule.
Three adjustments keep it workable. Review at the points where the decision can still change, not only at Phase G. Tailor the depth to the type of review rather than applying one checklist identically. And produce a decision with owned, dated conditions, because a compliance finding with no owner changes nothing.
You do not need TOGAF certification across the team to run reviews this way. You need an agreed checklist, a body with authority, and the discipline to follow up — see the solution architecture review.
The Architecture Review Kit is TOGAF-aligned and deliberately lightweight — checklist, scorecard, NFRs, risks, decisions and report, with three worked examples.
