# Architecture Review Request: [Initiative or solution name]

> Submission to the Architecture Review Board (ARB) for a new solution or a
> significant change: summary, business context, scope, proposed
> architecture, alternatives, quality attributes, principles compliance,
> security, privacy and data flags, costs, risks, the decisions requested,
> and a reviewer checklist with the outcome record. Based on common
> enterprise architecture governance practice. Replace every `[bracketed]`
> value and every row marked *Example*.

<!--
Guidance: How to use this template
- Submit early, when the design can still change. A review held after the
  contract is signed or the code is written can only record exceptions.
- Keep the submission short enough to read in 20 minutes. Link detailed
  designs, TCO analyses and threat models instead of pasting them.
- Section 10 is the heart of the request: state exactly what you want the
  board to decide. Requests without a clear question come back unreviewed.
- The board fills in section 11 and 12. The submitter fills in the rest.
-->

| Field | Value |
|---|---|
| Request ID | [ARB-YYYY-NNN] |
| Initiative | [Name] |
| Submitter | [@solution-architect] |
| Sponsor | [@business-sponsor] |
| Delivery team | [Team name] |
| Review type | [Concept / Design / Pre-production / Exception] |
| Requested board date | YYYY-MM-DD |
| Status | [Draft / Submitted / Under review / Decided] |
| Related | [Solution architecture], [ADRs], [Threat model], [TCO analysis] |

## 1. Executive summary

<!-- Guidance: Five sentences maximum: what is proposed, why, for whom, at what cost, and what you ask of the board. Write it last. -->

[Summary.] *Example:* We propose replacing the self-built customer
notification service with a managed messaging platform to support SMS,
email and push from one API. The change serves 2.1 million customers and
removes a service that caused four Sev-2 incidents last year. Estimated
3-year cost is USD 380,000 against USD 520,000 to keep the current
service. We ask the board to approve the target architecture and an
exception to principle AP-07 (single cloud region) for the SMS gateway.

## 2. Business context

<!-- Guidance: Link the request to strategy. Answer: what business outcome does this enable, what happens if we do nothing, and what deadlines are fixed. -->

| Item | Detail |
|---|---|
| Business driver | *Example:* Reduce missed-delivery complaints by 30% through timely notifications |
| Strategic objective | [Objective or OKR reference] |
| Fixed dates | *Example:* Current SMS contract ends YYYY-MM-DD |
| Cost of doing nothing | *Example:* Two engineers maintaining legacy service; rising incident count |
| Stakeholders | [Business owner, operations, customer service, legal] |

## 3. Scope

<!-- Guidance: State what is in and out of scope, which systems change, and which teams are affected. Out-of-scope items prevent scope creep in the review. -->

In scope: [list]. *Example:* notification API, template management,
delivery status webhooks, migration of 14 notification types.

Out of scope: [list]. *Example:* marketing campaigns (owned by the CRM
platform), in-app inbox.

| System | Change | Owner team |
|---|---|---|
| *Example:* Notification service (legacy) | Retired after migration | Platform |
| *Example:* Order service | Calls new notification API | Checkout |
| *Example:* Managed messaging platform | New | Platform |
| [System] | [New / Changed / Retired] | [Team] |

## 4. Proposed architecture

<!-- Guidance: Show the solution at the level the board needs: main components, external systems, data flows and trust boundaries. Link the detailed design for anything deeper. Give the diagram a short caption explaining the flow. -->

The diagram shows the target state. Business services publish
notification requests to an internal API, which applies templates and
consent rules and forwards messages to the managed platform; delivery
status returns through webhooks.

```mermaid
flowchart LR
    OS["Order service"] --> NA["Notification API"]
    CS["Customer service app"] --> NA
    NA --> TPL["Template and consent store"]
    NA --> MP["Managed messaging platform"]
    MP --> SMS["SMS carriers"]
    MP --> EM["Email delivery"]
    MP --> PUSH["Push services"]
    MP -- "delivery status webhook" --> NA
    NA --> DW["Analytics warehouse"]
```

| Component | Responsibility | Technology | Hosting |
|---|---|---|---|
| *Example:* Notification API | Validation, templating, consent, routing | [Language / framework] | Kubernetes, EU region |
| *Example:* Template and consent store | Templates, opt-in records | Managed PostgreSQL | EU region |
| *Example:* Managed messaging platform | Channel delivery, retries | [Vendor] | Vendor EU region |
| [Component] | [Responsibility] | [Technology] | [Hosting] |

## 5. Alternatives considered

<!-- Guidance: Show at least two alternatives, including "do nothing", and why each was rejected. Link the technology selection if one exists. -->

| Option | Summary | Why not chosen |
|---|---|---|
| Do nothing | *Example:* Keep legacy service | Incident trend, contract end date |
| *Example:* Rebuild in-house | New service on our message broker | 9 months of effort; no carrier relationships |
| *Example:* Two separate vendors (SMS, email) | Best-of-breed per channel | Two integrations and two status models |
| [Option] | [Summary] | [Reason] |

## 6. Quality attributes

<!-- Guidance: Give measurable targets and say how the design meets them. Reviewers look for numbers, not adjectives. -->

| Attribute | Target | How the design meets it | Evidence |
|---|---|---|---|
| Availability | *Example:* 99.9% monthly for the API | Two zones; vendor SLA 99.95% | Vendor SLA document |
| Latency | *Example:* p95 API response <= 150 ms | Async hand-off; request queued | Load test plan |
| Throughput | *Example:* 400 messages per second peak | Vendor rate limit 1,000 per second | Vendor quote |
| Recoverability | *Example:* RPO 5 min, RTO 1 h | Point-in-time restore of store | DR runbook |
| [Attribute] | [Target] | [Approach] | [Link] |

## 7. Principles compliance checklist

<!-- Guidance: Assess the design against each relevant architecture principle. Every "No" must have either a remediation or an exception request in section 10. -->

| Principle | Compliant? | Comment |
|---|---|---|
| *Example:* AP-01 Buy before build for non-differentiating capabilities | Yes | Managed platform adopted |
| *Example:* AP-03 APIs first, documented in OpenAPI | Yes | Spec in repo |
| *Example:* AP-07 Single primary cloud region | No | Vendor routes SMS through a second region; exception requested |
| *Example:* AP-10 Observability by default | Partial | Traces end at vendor boundary; status events logged |
| [Principle] | [Yes / Partial / No / N/A] | [Comment] |

## 8. Security, privacy and data review flags

<!-- Guidance: Flag what specialist reviewers must look at. A "Yes" here usually triggers a separate review (security, privacy impact, data governance) before final approval. -->

| Question | Answer | Detail or link |
|---|---|---|
| Processes personal data? | *Example:* Yes | Phone numbers, email addresses |
| Special category or sensitive data? | No | |
| New third-party processor? | Yes | DPA in negotiation |
| Data leaves approved regions? | Yes | SMS routing; see exception |
| New internet-facing endpoint? | Yes | Webhook receiver; signed requests |
| Changes to authentication or authorisation? | No | |
| Threat model completed? | In progress | [Link] |
| Privacy impact assessment needed? | Yes | [Link] |
| Retention and deletion defined? | Yes | Delivery logs 90 days |
| [Question] | [Answer] | [Detail] |

## 9. Costs and risks

<!-- Guidance: Summarise cost and the top risks; link the TCO analysis and the full risk register. -->

| Cost item | One-off | Annual run |
|---|---|---|
| *Example:* Implementation | 120,000 | 0 |
| *Example:* Platform subscription | 0 | 70,000 |
| *Example:* Run and support | 0 | 16,700 |
| **Total (3 years)** | | **380,100** |

| ID | Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
| R-01 | *Example:* Vendor outage blocks order confirmations | Low | High | Queue and retry for 24 h; fallback email relay | [@name] |
| R-02 | *Example:* Migration misses a notification type | Medium | Medium | Inventory from logs; shadow sending for 2 weeks | [@name] |
| [R-nn] | [Risk] | [L/M/H] | [L/M/H] | [Mitigation] | [@name] |

## 10. Decisions requested

<!-- Guidance: List each decision you need as a yes/no or choose-one question. Include exceptions to principles or standards with their duration. -->

| ID | Decision requested | Options | Submitter recommendation |
|---|---|---|---|
| D-01 | *Example:* Approve the target architecture in section 4 | Approve / Approve with conditions / Reject | Approve |
| D-02 | *Example:* Grant exception to AP-07 for SMS routing for 24 months | Grant / Refuse | Grant, with review at renewal |
| [D-nn] | [Question] | [Options] | [Recommendation] |

## 11. Reviewer checklist

<!-- Guidance: Completed by reviewers. Each item is answered Yes, No or N/A with a comment when not Yes. -->

| Check | Result | Comment |
|---|---|---|
| Business need and scope are clear | [Yes / No / N/A] | |
| Alternatives were genuinely considered | | |
| Quality attribute targets are measurable and met | | |
| Principles compliance assessed; exceptions justified | | |
| Security and privacy reviews triggered where flagged | | |
| Data ownership, retention and residency defined | | |
| Integration and API standards followed | | |
| Operability: monitoring, runbooks, support model | | |
| Cost estimate credible and funded | | |
| Exit or reversibility considered | | |
| Risks have owners and mitigations | | |

## 12. Outcome record

<!-- Guidance: Completed by the board secretary at the meeting. Conditions must have owners and due dates, and the record is linked from the ADR. -->

| Field | Value |
|---|---|
| Board meeting date | YYYY-MM-DD |
| Attendees | [Names] |
| Outcome | [Approved / Approved with conditions / Deferred / Rejected] |
| Decisions | *Example:* D-01 approved with conditions; D-02 granted for 24 months |
| Exceptions register entry | [EXC-NNN] |
| Next review | [Pre-production review, YYYY-MM-DD] |

| ID | Condition | Owner | Due | Status |
|---|---|---|---|---|
| CND-01 | *Example:* Complete privacy impact assessment before go-live | [@name] | YYYY-MM-DD | Open |
| CND-02 | *Example:* Add trace correlation ID to vendor requests | [@name] | YYYY-MM-DD | Open |
| [CND-nn] | [Condition] | [@name] | YYYY-MM-DD | [Open / Closed] |

## Standard and licence note

Based on common industry practice for architecture governance and
architecture review board submissions. Original text written for this
collection; example content is illustrative. Template licence: MIT.