Skip to content

STD-GOV-138: Architecture Practice Charter

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

Purpose

Establish the Architecture Practice as a standing function at Simpaisa. The Practice is responsible for producing, maintaining, and governing the architectural artefacts that define how Simpaisa's platform is built, secured, operated, and evolved.

A payment gateway processing $1B+ across seven markets cannot operate on tribal knowledge. The Architecture Practice ensures that every architectural decision, standard, threat model, data model, and API specification is documented, reviewed, published, and discoverable.

What the Architecture Practice Is

The Architecture Practice is: - A body of work (the artefacts: standards, ADRs, schemas, threat models, specifications) - A governing body (the ARB: reviews, approves, enforces) - A publishing function (Confluence: the canonical repository for consumption) - A continuous process (artefacts are living documents, not one-time deliverables)

It is NOT a separate team. The Practice is a function of the CDO division, staffed by architects and senior engineers who also write code.

Artefact Taxonomy

Every artefact produced by the Architecture Practice falls into one of these categories:

ARCHITECTURE PRACTICE — ARTEFACT TAXONOMY
═══════════════════════════════════════════════════════════════

  GOVERNANCE                    ARCHITECTURE              SPECIFICATIONS
  ─────────                     ────────────              ──────────────
  Standards (STD-*)             System Context (C4-*)     OpenAPI Specs
  ADRs (ADR-*)                  Container Diagrams        Database Schemas
  Policies & Frameworks         Data Architecture         SDK Specifications
  Review Board Charter          Security Architecture     CLI Specifications
  Lifecycle Standards           Threat Models             Service Templates
  Decision Rights               Data Models

  OPERATIONAL                   REGULATORY                STRATEGY
  ───────────                   ──────────                ────────
  Incident Playbooks            Compliance Framework      Strategy Alignment
  Runbook Standards             Regulatory Playbooks      Technology Radar
  SLO Definitions               Vendor Register           Execution Plans
  Deployment Standards          Risk Matrices             Briefing Packs
  Workflow Definitions

Artefact Inventory (as of April 2026)

Category Count Examples
Standards (STD-*) 45+ Security, DevEx, Data, Governance, Infrastructure, Mobile, AI, API, Product
ADRs 90+ Platform, API, Security, Data, AI, Mobile, Infrastructure, Product, Observability
C4 Diagrams 8 System Context, Pay-In, Pay-Out, Remittance, Cards, Platform, Merchant Portal, Deployment
Data Models 5 Pay-In, Pay-Out, Remittance, Cards, Merchant
Threat Models 5 Pay-In, Pay-Out, Remittance, Cards, Merchant Portal
OpenAPI Specs 4 Pay-In, Pay-Out, Remittance, Cards
Database Schemas 6 Pay-In, Pay-Out, Remittance, Cards, Platform, Events
SDK Specs 7 TypeScript, Python, Go, PHP, Rust, C#, Java
Workflow Definitions 4 AML/KYC, Disbursement, FX Quote, Webhook Delivery
Regulatory Playbooks 6 PK, BD, NP, IQ, AE, KSA
Frameworks 8+ Security Architecture, Data Architecture, Cross-Border Compliance, Microservices, Microfrontends, SLA Management, etc.
Operational 6+ Incident Response, Deployment, Logging, PII Handling, Secret Management, Rate Limiting
Strategy 3 Strategy Alignment (Maerifa), Offsite Briefing Pack, CDO Execution Plan
Total ~220+

Authoring and Publishing Model

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   AUTHORING  │     │    REVIEW    │     │  PUBLISHING  │
│              │     │              │     │              │
│  Git Repo    │────▶│  ARB / PR    │────▶│  Confluence  │
│  (Markdown)  │     │  Review      │     │  (Canonical) │
│              │     │              │     │              │
│  sp-architecture   │  Standards:  │     │  Architecture│
│  on GitHub   │     │  ARB approval│     │  Space       │
│              │     │  ADRs:       │     │              │
│  Authors:    │     │  ARB approval│     │  Consumers:  │
│  Architects, │     │  Other:      │     │  All staff   │
│  Senior Eng  │     │  PR review   │     │  Maerifa     │
└──────────────┘     └──────────────┘     └──────────────┘

Git Repo (Authoring)

  • Repository: github.com/doreilly257/sp-architecture (to migrate to Bitbucket when workspace is available)
  • Format: Markdown. All artefacts written in markdown for version control, diffing, and CI/CD.
  • Branch model: main is the published branch. Feature branches for draft work. PRs for review.
  • Why Git, not Confluence-native: Architectural artefacts benefit from version control (who changed what, when, why), PR-based review, and CI validation (e.g. Spectral linting for OpenAPI specs). Confluence is the consumption layer, not the authoring layer.

Confluence (Publishing)

  • Space: Architecture (to be created)
  • Structure: Mirrors the Git repo directory structure
  • Sync: Artefacts published to Confluence after ARB approval or PR merge
  • Format: Markdown rendered in Confluence (native markdown support or Markdown Macro)
  • Source of truth: Git repo is the source of truth. Confluence is the rendered, searchable view. If they diverge, Git wins.
  • Maerifa integration: Maerifa ingests from both Git (direct connector) and Confluence (REST API connector). Confluence publication ensures artefacts are discoverable by both humans (browsing Confluence) and agents (querying Maerifa).

Publishing Workflow

  Author writes/updates artefact in Git
         │
         ▼
  Push to feature branch
         │
         ▼
  Create PR for review
         │
    ┌────┴─────────────────┐
    │ Standards/ADRs?       │
    │                       │
    │ Yes: ARB review       │
    │ No: Peer PR review    │
    └────┬─────────────────┘
         │
         ▼
  Merge to main
         │
         ▼
  Publish to Confluence
  (manual initially, automated via CI later)
         │
         ▼
  Maerifa re-indexes automatically (git webhook)

Confluence Space Structure

Architecture (Space)
├── Standards/
│   ├── Governance (STD-GOV-*)
│   ├── Security (STD-SECURITY-*)
│   ├── DevEx (STD-DEVEX-*)
│   ├── Data (STD-DATA-*)
│   ├── Infrastructure (STD-INFRA-*)
│   ├── Product (STD-PRODUCT-*)
│   ├── Mobile (STD-MOBILE-*)
│   ├── AI (STD-AI-*)
│   └── API (STD-API-*)
├── ADRs/
│   ├── Platform
│   ├── API
│   ├── Security
│   ├── Data
│   ├── AI
│   ├── Mobile
│   ├── Infrastructure
│   ├── Product
│   └── Observability
├── Architecture/
│   ├── System Context (C4)
│   ├── Container Diagrams
│   ├── Security Architecture
│   ├── Data Architecture
│   ├── Threat Models
│   └── Data Models
├── Specifications/
│   ├── OpenAPI Specs
│   ├── Database Schemas
│   ├── SDK Specs
│   └── Service Templates
├── Regulatory/
│   ├── Cross-Border Compliance Framework
│   └── Per-Market Playbooks (PK, BD, NP, IQ, AE, KSA)
├── Operational/
│   ├── Incident Response
│   ├── Deployment
│   ├── Runbooks
│   └── Workflows
└── Strategy/
    ├── Strategy Alignment
    ├── Execution Plans
    └── Technology Radar

Artefact Lifecycle

Every artefact follows a lifecycle:

  Draft ──▶ Review ──▶ Published ──▶ Active
                                       │
                              ┌────────┴────────┐
                              ▼                  ▼
                         Deprecated          Superseded
                              │                  │
                              ▼                  ▼
                          Archived           Archived
State Meaning Where
Draft Being written. Not authoritative. Git feature branch
Review Under ARB or PR review. Git PR
Published Approved and published. Authoritative. Git main + Confluence
Active In use. Teams must follow. Confluence
Deprecated No longer recommended. Alternative identified. Confluence (flagged)
Superseded Replaced by newer version. Link to replacement. Confluence (flagged)
Archived Historical reference only. Confluence archive section

Quality Standards for Artefacts

Every artefact published by the Architecture Practice must meet these standards:

Criterion Requirement
UK English British English spelling throughout (colour, authorisation, behaviour)
Metadata Standard header table with: ID, Title, Status, Owner, Created, Review date
Current State Document the current state before describing the target
Gaps Explicitly list gaps between current and target
Target State Concrete, measurable target
Diagrams ASCII art for any non-trivial flow. C4 diagrams for system architecture.
Ownership Named owner (person, not team)
Review date Scheduled review frequency (quarterly, semi-annually, or annually)
Cross-references Links to related standards, ADRs, and upstream strategy
Actionable Every document ends with concrete actions or next steps

Roles

Role Person Responsibility
Practice Lead CDO (Daniel O'Reilly) Overall accountability. Sets direction. Chairs ARB.
Architecture Lead TBD Day-to-day practice management. Artefact quality. Confluence publishing.
Domain Architects TBD (per domain) Own artefacts in their domain (Security, Data, Platform, API).
Contributing Engineers All senior engineers Author ADRs and standards within their areas.

Maturity Model

Track the Architecture Practice's own maturity:

Level Description Where We Are
1 — Initial Ad-hoc. No formal practice. Knowledge in people's heads. Was here (pre-2026)
2 — Documented Artefacts exist in a repo. Standards written but not enforced. Here now (April 2026)
3 — Governed ARB operational. Artefacts reviewed and approved. Confluence published. Target Q3 2026
4 — Measured Compliance tracked. Standards adoption measured. Health dashboard. Target Q4 2026
5 — Optimised Continuous improvement. Architecture informs strategy. Maerifa-powered discovery. Target 2027

Roadmap

Phase Timeline Deliverables
1. Foundation (DONE) Q1 2026 220+ artefacts authored. Git repo established. Pushed to GitHub.
2. Governance Q2 2026 ARB operational. First formal meeting. ADR backlog ratified.
3. Publishing Q2 2026 Confluence Architecture space created. Initial batch published. Publishing workflow documented.
4. Discovery Q2-Q3 2026 Maerifa deployed. All artefacts indexed and queryable.
5. Enforcement Q3 2026 Standards compliance tracked. Exception registry active.
6. Measurement Q4 2026 Architecture health dashboard. Quarterly review cadence embedded.

Relationship to Other Governance

Standard Relationship
STD-GOV-124 (ARB Charter) The ARB is the governing body OF the Architecture Practice. The Practice produces artefacts; the ARB governs them.
STD-GOV-133 (ADR Lifecycle) Defines how ADRs (one artefact type) move through their lifecycle.
STD-GOV-135 (Execution Framework) Strategic initiatives that produce architectural artefacts flow through the execution framework.
STD-GOV-136 (Performance Management) Architecture health metrics feed the performance dashboard.
STD-GOV-137 (Department Mandates) CDO's mandate includes ownership of the Architecture Practice.
Maerifa Maerifa is the discovery layer. The Practice produces knowledge; Maerifa makes it findable.