A recurring pattern in technology delivery: a team has been working on a solution for several months. Vendor selection is done. The budget is committed. The delivery timeline is fixed. Integration assumptions have been baked into the plan. And now — finally — someone has booked an architecture review.
The architects in the room ask reasonable questions. What alternatives were considered? How does this integrate with the identity platform? What is the data residency position? How does it fail? What does operations look like in twelve months? The team struggles to answer cleanly, because many of these questions were implicitly answered months ago — by decisions already made, contracts already signed, timelines already communicated.
The review becomes uncomfortable. Not because the architects are obstructing, but because the useful window for architecture guidance has already closed. The questions are right. The timing is wrong.
This is the most common failure mode in architecture governance. Not that review boards are too strict, but that teams engage them too late — after design, vendor, budget, and timeline are already locked.
The purpose of this article is to describe what architecture review looks like when it works properly: as a staged journey, not a single gate. Each stage has a different purpose. Each stage requires different preparation. And engaging early — even when the idea is rough — produces better outcomes than engaging late with a polished deck.
What is an Architecture Review Board?
An Architecture Review Board — ARB — is a group of architecture and technology stakeholders who review important decisions before they become expensive, risky, or irreversible.
A well-functioning ARB checks whether a proposed solution is aligned across several dimensions at once: business purpose, technology fit, security posture, data handling, integration approach, infrastructure model, compliance position, scalability, resilience, cost, and operational readiness. No one person can hold all of that simultaneously. The ARB is a structured way to bring the right perspectives together at the right moment.
The important word is "review," not "approve." Approval is the output. The value is in the review itself — the questions asked, the risks named, the alternatives surfaced, the assumptions tested. A decision that goes through serious review and gets approved is more trustworthy than one that was never challenged. That trust matters through delivery and operations, not just at the moment of sign-off.
ARB is not a blocker
The most damaging belief about architecture governance is that it exists to police decisions. Teams that hold this belief engage late, prepare defensively, and treat the review as an obstacle rather than a resource. The outcome is predictably poor on both sides: architects reviewing decisions they cannot meaningfully influence, and teams defending choices they know have weaknesses.
A well-designed ARB does not slow projects down. It prevents the kind of rework that slows projects down. A security concern identified during concept architecture costs a conversation and a diagram adjustment. The same concern identified during user acceptance testing costs weeks, sometimes months. An integration assumption caught at Stage 2 costs a whiteboard discussion. Caught at Stage 6, it costs a re-architecture.
The useful reframe: architecture review is risk reduction with a time dimension. The earlier it happens, the cheaper the risk reduction. The later it happens, the more expensive — until eventually the window closes and the risk simply stays in the system.
The architecture review journey
What follows is a description of the full staged journey — from the moment an idea surfaces to the period after it goes live. Not every project touches every stage. A small infrastructure enhancement may need only three of these. A strategic platform replacement may need all eight. The value is in understanding which stages apply, and why.
Architecture gates: the formal decision checkpoints
Stages describe the architecture engagement journey. Gates are the formal decision checkpoints within that journey — moments where a project is assessed before moving to the next major lifecycle step. A gate is not a bureaucratic hurdle. It is a structured pause to confirm that the project is ready to proceed, that risks are understood, and that the right people have been involved.
There are four gates in the standard ARB journey.
Purpose: Confirm whether the project idea is architecturally acceptable to proceed into deeper planning or design. This is not final solution approval — it is approval to continue exploration with the right architecture direction, stakeholders, and guardrails in place.
Typical questions:
Typical outcome: Approved to proceed into solution design, approved with early conditions, or redirected for more discovery.
Purpose: Confirm whether the proposed solution architecture is good enough to build or procure. This gate reviews the actual architecture direction before major implementation commitment.
Typical questions:
Typical outcome: Approved to build, approved with conditions, deferred for more information, or returned for rework.
Purpose: Confirm whether the implemented solution is ready to move into production safely. This gate checks whether delivery has stayed aligned with the approved architecture and whether the solution is operationally ready.
Typical questions:
Typical outcome: Approved for go-live, approved with known risks accepted, or held until readiness gaps are closed.
Purpose: Confirm whether architecture governance can be closed for the project, and what lessons, technical debt, or follow-up actions remain. This gate is not about stopping the project — it is about learning, closing architecture actions, recording deviations, and identifying reusable patterns.
Typical questions:
Typical outcome: Architecture closure, closure with follow-up actions, technical debt recorded, or further review scheduled.
In practice, gates and stages work together. A project may pass Gate 1 after triage and concept review, Gate 2 after solution and domain reviews, Gate 3 before production deployment, and Gate 4 after go-live. Small projects may combine gates. Large or high-risk projects may need more detailed reviews between gates.
The detailed journey: stage by stage
The stages below describe what happens within and between the gates — the work that enables each gate to produce a useful, informed decision.
Stage 0: Idea and demand intake
Every project starts as a business need, a problem statement, or a technology impulse. The purpose of Stage 0 is not to review architecture — it is to understand whether architecture involvement is needed, and at what level.
The questions worth asking at this stage are simple. What business problem are we solving? Is this a new system, a change to an existing system, an integration, a migration, a vendor product evaluation, a cloud workload, an AI use case, a data platform, or an infrastructure change? Who owns the business outcome?
The output of Stage 0 is not a design. It is an initial classification: does this need architecture engagement, and if so, what kind? Some requests can be handled with a brief conversation and a quick recommendation. Others warrant a full review journey. Getting this classification right early saves time for everyone.
Stage 1: Architecture triage
Not every project needs the same depth of review. Triage is the process of deciding which review path is appropriate — so that light-touch changes do not consume the same governance bandwidth as strategic platform decisions, and so that complex, high-risk changes do not slip through with a lightweight sign-off.
The factors that influence the triage decision include: business criticality, security sensitivity, data sensitivity, integration complexity, cloud or infrastructure impact, cost, regulatory exposure, deviation from technology standards, and operational risk. No single factor is determinative. The combination matters.
The output of triage is a recommended review path and the list of architect stakeholders — often called SPOCs, or single points of contact — who need to be involved. This prevents the common problem of a review reaching the ARB without the relevant domain experts having been consulted.
Stage 2: Concept architecture review
This is the most valuable stage in the journey, and the one most often skipped.
Before detailed design starts, before a vendor is selected, before delivery estimates are produced — there is a moment when the solution direction is still genuinely open. The concept architecture review happens at that moment. Its purpose is to test the direction, not the detail.
The questions at this stage are strategic. What are the main solution options? Build, buy, reuse, retire, or integrate? Is there an existing enterprise capability that could serve this need without introducing a new system? Does the proposed direction align with enterprise technology standards? What are the major risks and dependencies?
A concept architecture review rarely produces a final answer. It produces a recommended direction, a list of open decisions, and clarity about what needs to be resolved before detailed design begins. That is exactly what it should produce. The teams that skip this stage and jump straight to detailed design are the ones who arrive at Stage 3 needing to undo foundational choices.
Stage 3: Solution architecture review
Once a direction is confirmed and detailed design is underway, the solution architecture review examines the proposed design in full. This is the stage most people associate with "architecture review" — and it is important, but it is not the whole journey.
At this stage, the review covers: application architecture, integration architecture, data architecture, security architecture, infrastructure and cloud architecture, the operational model, scalability, availability, disaster recovery, observability, cost model, and vendor or product fit. A well-prepared solution architecture review brings all of these together in a single coherent picture.
The output is architecture review feedback — what is sound, what needs adjustment, what are the identified risks, and whether the design is conditionally approved or needs rework before the next stage. Conditional approval is common and appropriate. It means the direction is accepted, subject to specific concerns being resolved and evidenced.
Stage 4: Domain reviews
Domain reviews allow specialist architect groups to examine the areas within their responsibility. They can happen before the full ARB review, in parallel with it, or as a structured input to it. The important thing is that they happen — not that they follow a fixed sequence.
The typical domain reviews include: security review, data and privacy review, integration and API review, infrastructure and cloud review, network review, operations and reliability review, compliance and risk review, and — where the project involves AI — an AI governance review. Each domain has its own lens. A security architect will ask different questions to an infrastructure architect. Both sets of questions matter.
Domain reviews produce domain approvals, findings, required exceptions, and agreed mitigation actions. These feed directly into the full ARB review, so that the ARB does not have to cover every domain in depth — it can focus on the cross-domain considerations and confirm that the domain reviews have been completed satisfactorily.
Stage 5: ARB approval gate
The formal ARB review confirms that the solution is aligned, that risks are understood, that required domain architects have reviewed their areas, and that open issues have named owners and agreed timelines for resolution.
The outcomes are not binary. An ARB review can result in: approved, approved with conditions, returned for rework, deferred pending further information, or rejected with an alternative recommendation. Each outcome is useful. A conditional approval is not a failure — it is a precise statement of what still needs to be resolved. A return for rework is a signal that the design has gaps, not that the project is blocked.
The output of the ARB gate is a formal record: the decision, any conditions attached, the action owners, and the reference for future governance. This record matters not just for the current project but for the teams who inherit the system later.
Stage 6: Implementation governance
Approved architecture can drift during delivery. This is not unusual — requirements change, vendors adjust scope, integration assumptions evolve, timelines compress. Implementation governance ensures that significant changes are reviewed against the approved architecture rather than absorbed quietly into the delivery without reassessment.
The questions at this stage are about drift: Are design changes still aligned with what was approved? Have new risks appeared? Has the vendor changed scope in a way that affects the architecture? Are integrations, environments, security controls, and operational dependencies on track?
Implementation governance does not require a full ARB review for every change. It requires a lightweight mechanism for identifying which changes are significant enough to warrant re-review, and a named architect who has visibility of what is being built.
Stage 7: Go-live readiness review
Before a system moves into production, it is worth pausing to check whether it is ready to operate safely — not just whether it is ready to go live technically. These are different questions.
The go-live readiness review covers: production readiness, monitoring and alerting configuration, the support model and escalation path, security controls in the production environment, data migration completeness, rollback plan, disaster recovery and backup position, performance testing results, access management, known open risks, and whether a runbook exists for common operational scenarios.
Many of these items are owned by operations, not architecture. But architecture has a role in confirming that the system that is going live is the system that was designed and approved — and that the operational model matches what was described in the solution architecture.
Stage 8: Post-implementation review
The least-performed stage, and one of the most useful.
A post-implementation review asks: what worked, what changed from the approved design and why, what technical debt was accepted during delivery, and what should be done differently next time? It also asks which reusable patterns emerged from this project that could benefit other teams.
The output is a short record: lessons learned, identified architecture debt, a backlog of improvement actions, and any reusable patterns worth sharing. Teams that do this consistently get better at architecture. Teams that skip it repeat the same problems at scale.
Architecture review levels: not all projects are the same
The staged journey above describes the full path. The review level describes how much of that path a given project needs to travel. There are four levels worth distinguishing.
Applies to: Small changes, minor enhancements, low-risk configuration, no sensitive data, no major integration.
Reviewed by: Solution or domain architect.
Outcome: Quick recommendation or informal approval.
Applies to: Moderate projects impacting one or two domains — security, data, integration, infrastructure, cloud.
Reviewed by: Relevant domain architects.
Outcome: Domain sign-off and agreed actions.
Applies to: Projects with enterprise impact, critical systems, sensitive data, major integrations, significant cost, new platforms, cloud migration, vendor selection, or non-standard technology.
Reviewed by: Architecture Review Board with domain inputs.
Outcome: Formal ARB approval, conditional approval, or return for rework.
Applies to: Major transformation programmes, strategic platforms, high-cost decisions, regulatory impact, large technology shifts, or enterprise data and AI platforms.
Reviewed by: Enterprise Architecture leadership and senior stakeholders.
Outcome: Strategic decision and roadmap alignment.
What to prepare before an ARB meeting
The quality of an ARB review depends heavily on what is brought to it. A polished presentation of a poorly understood solution is less useful than a rough diagram that honestly represents the key decisions and open questions. Architects can work with uncertainty. What they cannot easily work with is a presentation designed to avoid scrutiny rather than invite it.
The following checklist covers the preparation that enables a productive ARB conversation. Not every item is relevant to every project — but missing one that is relevant will usually produce a question that interrupts the review.
Common mistakes teams make
Most ARB problems are not architectural. They are timing and preparation problems. The same mistakes appear repeatedly across different technology environments and different project types.
Arriving too late is the most common. By the time a team books the ARB, the architecture is already committed — the only remaining question is whether the ARB will acknowledge it or create friction. Neither outcome is useful.
Bringing a diagram without decision context is the second. A diagram shows structure. An ARB review needs to understand decisions: what was chosen, what was rejected, and why. A diagram that does not answer these questions is decoration, not documentation.
Treating security as a final checkbox is persistent and consistently costly. Security is not a layer applied at the end of a design. It is a property of the design itself — how data flows, how access is controlled, how the system authenticates, how it fails. Bringing security into the review late means the review will either approve a design with known gaps or require rework that the delivery team did not budget for.
Selecting a vendor before architecture review is a related problem. Vendor selection constrains every subsequent architecture decision. If a vendor is selected before the architecture is reviewed, the review becomes a process of fitting the architecture around the vendor rather than choosing the vendor that fits the architecture. The result is usually a mismatch that persists for years.
Other recurring patterns worth naming: not documenting alternatives, which makes the design appear arbitrary rather than considered; not identifying operational ownership before go-live, which creates support gaps that become incidents; and assuming that ARB approval means no further governance is needed, which leads to architecture drift during delivery.
When to contact the Enterprise Architecture team
If a project is unclear about scope, crosses multiple domains, involves significant budget, is strategically important, uses sensitive or regulated data, introduces technology that is new to the environment, impacts enterprise-wide standards, or creates genuine confusion about the right architecture path — these are all signals to contact the EA team early, not after design.
The useful test is not "do I need ARB?" That question often produces the wrong answer, because teams underestimate complexity from inside a project. The better question is: if this decision turns out to be wrong, how hard is it to fix, and how much would it cost? The harder the reversal and the higher the cost, the earlier architecture review should happen.
If there is uncertainty about which review level applies, which architects need to be involved, or which stage of the journey a project is in — reach out to an Enterprise Architecture colleague or the relevant architect SPOC. That conversation is free. Discovering the wrong answer in production is not.
A simple mental model
Three questions are enough to decide how much architecture review a decision needs.
First: what is the risk if this is wrong? A configuration change to a low-criticality system carries different risk than an architectural commitment to a new integration platform. The higher the risk, the more review it deserves.
Second: how hard is this to reverse? A decision that can be undone in a day requires less scrutiny than a decision that becomes load-bearing infrastructure for five years. Reversibility is a proxy for how much the decision matters.
Third: who else is affected? A decision that affects only one team is different from a decision that affects the enterprise data model, the security perimeter, or the integration layer. Cross-domain impact is a reliable signal that more architecture eyes are needed.
The higher the risk, the lower the reversibility, and the wider the impact — the earlier and more seriously architecture review should engage. Everything else follows from this.
ARB is a journey, not a single meeting
The teams that get the most from architecture governance are the ones who treat it as a continuous resource rather than a single approval ceremony. They engage at Stage 0 when the idea is rough. They hold a concept review before design starts. They bring domain architects into parallel reviews rather than stacking them at the end. They use the formal ARB gate to confirm, not to discover. They stay engaged through delivery. They reflect after go-live.
The goal is not more governance. It is governance applied at the right moments, at the right depth, by the right people. A small amount of architecture thinking early in a project is worth far more than an exhaustive review of a committed design.
Faster delivery with fewer surprises is what good architecture governance produces — not slower delivery with more checkboxes.
Architecture Review Readiness Before requesting an ARB slot, use the Architecture Review Readiness Checker to understand your current stage, expected review level, missing preparation items, and next recommended action.