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.
| 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
[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
| 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
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
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.
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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
| 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.