An Architecture Review Board (ARB) is a forum where significant architecture changes are reviewed by senior technical leadership before commitment.
Purpose:
- Quality gate — catches bad designs early.
- Consistency — enforces standards across projects.
- Knowledge sharing — junior architects learn from senior.
- Risk identification — surface concerns.
- Decision traceability — formal record of significant choices.
Membership:
- Chair — senior architect (often the CTA / lead architect).
- Members — 3-6 senior technical roles spanning relevant domains.
- Optional: security architect, data architect, infrastructure architect.
Cadence:
- Weekly / bi-weekly meetings, depending on volume.
- 30-60 minutes per item.
- Items submitted in advance (template + diagrams).
What goes to ARB:
- New custom objects above a threshold.
- New integrations.
- Data model changes affecting many objects.
- Custom code beyond a certain scope (e.g., > 500 lines).
- New Salesforce clouds being adopted.
- Major sandbox / DevOps changes.
- Performance / scaling decisions.
What does NOT go to ARB:
- Routine config changes (validation rules, page layouts).
- Tactical bug fixes.
- Anything fitting an established reference architecture.
ARB process:
- Submitter prepares: design doc, diagrams, alternatives considered, key risks.
- Pre-read — board reviews 1-2 days before meeting.
- Presentation — submitter explains; ~10 min.
- Q&A — board challenges, probes; ~20 min.
- Decision — Approve / Approve with conditions / Reject / Defer.
- Documented — outcome and rationale captured.
Pitfalls:
- Too bureaucratic — every change waits weeks; teams bypass.
- Too lenient — rubber-stamps; no real value.
- Wrong members — senior in title but disengaged.
- No follow-through — approvals don't enforce; standards ignored.
Senior architects design ARB to be helpful, not punitive — engineers should leave with their design improved, not just approved.
A working ARB pays back through caught issues, shared learning, and consistent architecture. A broken ARB is theatre.