Architecture Review Board (ARB) Prep

---

1. Purpose

Secure approval for significant architectural changes. The ARB process exists to prevent fragmentation, manage technical debt, and ensure security/compliance standards are met. This workflow guides the preparation of materials to ensure a smooth review, focusing on "Why" and "Trade-offs" rather than deep implementation details.

---

2. When to Use / When Not to Use

Use This Workflow When

• Introducing a new language, database, or major framework.
• Changing the system's "High Level Design" (e.g., Mono to Microservices).
• Making changes with significant cost implications (> $1k/mo).

Do NOT Use This Workflow When

• Refactoring internal code within a single service boundary.
• Upgrading a library minor version.
• Adding a routine endpoint or table.

---

3. Inputs

Required Inputs

• [[DESIGN_DOC_RFC]]: Link to the detailed technical spec (RFC).
• [[TRADE_OFF_ANALYSIS]]: Comparison of at least 3 options (e.g., Postgres vs Mongo vs Dynamo).
• [[COST_ESTIMATION]]: Projected infrastructure spend.

---

4. Outputs

• ARB Material: Concise presentation (max 5 slides or 2-page brief).
• Risk Assessment: "What happens if we're wrong?"
• Compliance Check: Security/Legal/Privacy approvals.

---

5. Preconditions

• The RFC has been peer-reviewed by the immediate team.
• A prototype (PoC) exists if the tech is novel to the org.

---

6. Procedure

Phase 1: Artifact Consolidation

1. Action: Summarize the RFC.

   • Expected Output: An "Executive Summary" stating Problem, Solution, and Cost.
   • Notes: ARB members are busy. They need the 2-minute version first.

2. Action: Finalize Trade-off Matrix.

   • Expected Output: Table comparing Options A, B, C against criteria (Cost, Complexity, Scalability).
   • Notes: Be honest. "No Drawbacks" is a red flag.

Phase 2: Compliance & Cross-Functional Check

3. Action: Security Review.

   • Expected Output: Sign-off from SecOps on authentication/encryption plans.

4. Action: Operational Readiness.

   • Expected Output: Plan for monitoring, backups, and DR.

Phase 3: Presentation

5. Action: Draft the "Ask".
   • Expected Output: Clear statement: "We are asking for approval to deploy X to Prod by Date Y."

---

7. Quality Gates

• [ ] Alternatives considered: At least one alternative was seriously evaluated.
• [ ] Exit Strategy: If this tech fails, how do we migrate off?
• [ ] Sponsor: A Director/VP is aware and supportive of the business case.

---

8. Failure Handling

"Not Enough Info"

• Symptoms: ARB defers decision.
• Recovery: Ask specifically which data point is missing (Cost? Latency?). Gathering it is the only way forward.

"Too Risky"

• Symptoms: Rejection due to stability concerns.
• Recovery: Propose a smaller blast radius pilot (e.g., 1% traffic) instead of full rollout.

---

9. Paste Prompt

TIP

One-Click Agent Invocation Copy the prompt below, replace placeholders, and paste into your agent.

Role: Act as a Staff Architect.
Task: Execute the ARB Prep workflow.

## Objective
Prepare [[PROJECT_NAME]] for ARB Review.

## Inputs
- **RFC**: [[DESIGN_DOC_RFC]]
- **Cost**: [[COST_ESTIMATION]]

## Procedure
Execute the following phases:

1. **Summary**:
   - create Exec Summary (Problem/Solution/Cost).
   - Verify Trade-off Matrix (3 Options).

2. **Risks**:
   - Define "Exit Strategy" (Vendor Lock-in mitigation).
   - Confirm Security Sign-off.

3. **Presentation**:
   - Draft the Slide Deck outline.
   - Explicitly state the "Ask".

## Quality Gates
- [ ] Trade-offs honest.
- [ ] Security reviewed.
- [ ] Exit strategy defined.

## Constraints
- Output: Markdown Brief.
- Focus: Strategic alignment, not code style.

## Command
Start by summarizing the Problem Statement and Proposed Architecture.