Design Authority
How an ARB should decide, what it should not review, and how it avoids becoming a queue.
5 to work through
-
advanced
An enterprise software vendor of SAP's shape runs a central design authority: a board of nine meeting fortnightly, 40 product teams, a median of 19 days from submission to decision. Leadership wants it replaced with federated decision-making without losing the ability to say what the company's architecture is. Give the sequence.
3 min answer -
advanced
An interviewer says — you run architecture governance at a travel marketplace with four consumer brands acquired over a decade, each with its own stack and its own engineering leadership. The executive team wants one design authority. Where do you take this?
3 min answer -
advanced
How would you structure a design review function that improves decisions without becoming a bottleneck?
2 min answer -
advanced
Review this design authority. Every change above £50,000 or touching customer data goes to a board of seven that meets fortnightly. Lead time to a decision averages three weeks. Last year it reviewed 94 submissions and rejected two. Teams have started splitting work to stay under the threshold. What would you change, and what would you keep?
2 min answer -
advanced
What makes an architecture design authority useful rather than an obstacle?
1 min answer
2 terms in this topic
Design Authority
The body or role that approves significant designs — valuable when it improves decisions, harmful when it becomes a queue.
practiceReview Scope Discipline
Stating what an architecture board does not review, which is what determines whether it stays useful or becomes a queue.
1 artifact you would hand over
Neighbouring topics
Assurance, Audit & Model Risk
General material on assurance, architectural governance and risk oversight.
Control Design vs Operation
A control that is well designed and never runs fails exactly like one that is absent.
Audit Evidence
Producing durable, tamper-evident proof as a by-product rather than as a project.
Certification Impact on Architecture
What SOC 2 and ISO 27001 actually require of a design, and what they do not.
Continuous Controls Monitoring
Testing controls continuously instead of sampling them once a year.
Segregation of Duties
Splitting authority so no single actor can both make and approve a change.
Change Advisory vs Automated Gates
Replacing a weekly board with evidence a machine produces on every change.
Risk Appetite
The stated tolerance that tells you which risks you are allowed to accept.
Risk Assessment Methods
Qualitative matrices, FAIR and scenario analysis, and the illusion of a precise score.
Security Design Review
Reviewing an architecture for security while changing it is still cheap.
Architecture Compliance Checks
Automating conformance to standards so review effort goes to the genuinely novel.
Exception & Waiver Management
Time-boxed, owned deviations with a remediation date, rather than permanent silence.
Three Lines Model
Ownership, oversight and independent assurance, and where architecture sits in it.
Model Risk Management
Inventory, validation, monitoring and challenge for models that make consequential decisions.
AI Risk Tiering
Classifying a use case by potential harm, and the obligations each tier triggers.
Model Documentation
Model cards, intended use, limitations, and the record a regulator will ask for.
Model Evaluation & Red-Teaming
Adversarial testing of a probabilistic system with no fixed expected output.
Bias & Fairness Controls
Measuring disparate outcomes, choosing a fairness definition, and living with the trade-off.
Human-in-the-Loop Design
Meaningful review rather than a rubber stamp, and designing against automation bias.