Architecture Governance

Architecture governance is the set of processes and structures that ensure technical decisions align with organizational strategy, quality standards, and risk appetite. An Architecture Review Board (ARB) is the formal body that reviews significant design decisions, approves architectural standards, and manages exception requests — typically meeting bi-weekly with rotating senior engineers and a permanent architecture team. Standards and guardrails encode organizational best practices into enforceable policy (Terraform sentinel policies, OPA admission controllers, SonarQube quality gates) rather than relying on manual review. The exception process is as important as the standards themselves — a clear, fast exception path prevents teams from circumventing governance by going dark.

Key Points

• ARB composition: CTO or VP Engineering (chair), principal/distinguished engineers, security architect, platform/SRE lead, and rotating tech leads from product engineering; typically 5–9 members
• What requires ARB review: new databases or data stores, changes to inter-service communication protocols, new external vendor integrations, security-boundary changes, and any decision affecting 3+ teams
• Architecture standards repository: a curated, versioned catalog of approved technology choices (supported languages, databases, messaging systems, CI/CD tools) with rationale and upgrade paths
• Guardrails via policy-as-code: AWS SCPs prevent creation of non-compliant resources; OPA Gatekeeper in Kubernetes enforces resource limits and label requirements; Terraform Sentinel validates IaC before apply
• RFC (Request for Comments) process: engineer writes a structured proposal (problem, context, options, recommendation, risks); distributed to ARB and affected teams for async feedback before synchronous review; captures decision history
• Exception process: teams submit exception requests with a time-bounded scope ("use MongoDB for this service for 18 months, then migrate to PostgreSQL"); ARB approves with conditions; exceptions are tracked in a registry and reviewed at expiry
• Governance anti-patterns: "ARB as a rubber stamp" (approvals without genuine review), "ARB as a bottleneck" (2-week review cycles blocking delivery), "standards without enforcement" (guidelines that teams ignore because there are no consequences)
• Governance maturity indicators: average time from RFC submission to decision (target < 5 business days), exception approval rate (too high = standards are wrong; too low = standards are blocking delivery), post-decision sentiment (teams feel heard, not dictated to)