Skip to content

STD-GOV-124: Architecture Review Board Charter

Field Value
Standard STD-GOV-124
Title Architecture Review Board Charter
Status Draft
Owner CDO
Created 2026-04-03
Updated 2026-04-05
Review Annually
Related STD-GOV-138 (Architecture Practice Charter), STD-GOV-133 (ADR Lifecycle)

Purpose

Establish the Architecture Review Board (ARB) as the governing body for architectural decisions at Simpaisa. Operating a payment gateway with $1B+ in transaction volume across PK, BD, NP, IQ and EG, architectural decisions have outsized impact on reliability, compliance, scalability and cost. The ARB ensures these decisions are made deliberately and consistently.

Scope

All significant architectural decisions across Simpaisa's technology estate: Pay-Ins, Pay-Outs, Remittances, Cards, platform infrastructure, data architecture, security architecture and third-party integrations. The ARB governs Architecture Decision Records (ADRs) and grants exceptions to published standards.

Current State

  • Architectural decisions made informally between senior engineers and CDO.
  • ADRs exist in Standards/ADR/ but no formal review and approval process.
  • No structured forum for cross-cutting architectural concerns.
  • Standards exceptions granted ad-hoc without documentation.

Gaps

  1. No formal body responsible for architectural governance.
  2. ADRs not systematically reviewed before adoption.
  3. No mechanism for granting and tracking standards exceptions.
  4. Cross-team architectural alignment happens reactively, not proactively.
  5. No regular cadence for reviewing architectural health.

Target State

  • ARB meets monthly with clear authority over architectural decisions.
  • All significant ADRs reviewed and approved before implementation.
  • Standards exceptions formally granted, documented and time-bound.
  • Quarterly architectural health assessment.

Composition

Role Member Responsibility
Chair CDO (Daniel O'Reilly) Final authority, agenda setting
Platform Lead TBC Technical feasibility, standards
Security Lead TBC Security and compliance review
Data Lead TBC Data architecture and privacy
Rotating Product Engineer Rotates quarterly Implementation perspective

Quorum: Chair + 2 other members. The Chair may delegate to Platform Lead for routine reviews.

Cadence

Type Frequency Purpose
Scheduled Monthly (1st Tue) Review pending ADRs, standards, health
Ad-hoc As needed Urgent ADRs, significant incidents

Authority

The ARB has authority to:

  1. Approve or reject ADRs — ADRs require ARB approval before implementation begins.
  2. Grant standards exceptions — Time-bound exceptions with documented rationale and review date.
  3. Set architectural direction — Technology choices, patterns, migration priorities.
  4. Mandate remediation — Require teams to address architectural risks within defined timelines.
  5. Escalate — CDO has final authority on all architectural decisions.

ADR Submission Process

  1. Author writes ADR following template in Standards/ADR/.
  2. Submit — ADR pushed to repository at least 3 business days before scheduled ARB meeting.
  3. Pre-read — ARB members review asynchronously; comments via Bitbucket PR.
  4. Present — Author presents at ARB meeting (10 minutes max).
  5. Decision — Approve / Reject / Request changes. Recorded in ADR status.
  6. Track — Implementation tracked via Beads issue linked to ADR.

Standards Exception Process

  1. Request — Team creates Beads issue with tag arb-exception.
  2. Justification — Document: which standard, why exception needed, proposed duration, risk mitigation.
  3. Review — ARB reviews at next meeting (or ad-hoc for urgent).
  4. Decision — Approve with expiry date, or reject.
  5. Track — Exception logged in Standards/EXCEPTIONS.md. Auto-reminder at expiry.

Meeting Agenda Template

  1. Previous action items (5 min).
  2. ADR reviews (10 min each).
  3. Standards exception requests (5 min each).
  4. Architectural health review — SLO trends, tech debt, incident patterns (10 min).
  5. Open discussion (10 min).

Quarterly Activities

  • Review technology radar and update TECHNOLOGY-RADAR.md.
  • Assess technical debt dashboard (see STD-GOV-125).
  • Review PIR trend analysis (see STD-DEVEX-093).
  • Update compliance calendar (see STD-GOV-132).

Actions

# Action Owner Deadline
1 Appoint permanent ARB members CDO 2026-Q2
2 Schedule recurring monthly ARB meeting CDO 2026-Q2
3 Create Standards/EXCEPTIONS.md registry Platform Lead 2026-Q2
4 Backlog existing ADRs for ARB ratification Platform Lead 2026-Q2
5 Conduct first formal ARB meeting CDO 2026-Q2

Relationship to Architecture Practice

The ARB is the governing body of the Architecture Practice (STD-GOV-138). The Practice produces artefacts (standards, ADRs, specifications, threat models, etc.). The ARB reviews, approves, and enforces them.

The ARB does NOT author artefacts. Authors are architects and senior engineers. The ARB's role is quality gate, not content creation.

Publishing Authority

When the ARB approves a standard or ADR: 1. Status updated to Accepted in the Git repo. 2. Merged to main branch. 3. Published to the Confluence Architecture space. 4. Maerifa re-indexes automatically via git webhook.

The ARB Chair (CDO) may delegate publishing to the Architecture Lead.

References

  • STD-GOV-138-ARCHITECTURE-PRACTICE-CHARTER.md — the Practice this board governs
  • STD-GOV-133-ADR-LIFECYCLE-STANDARD.md — ADR lifecycle states and transitions
  • Standards/ADR/ — Architecture Decision Records
  • TECHNOLOGY-RADAR.md
  • STD-GOV-125-TECHNICAL-DEBT-MANAGEMENT.md
  • STD-DEVEX-093-POST-INCIDENT-REVIEW-STANDARDS.md