Architecture Readiness Pack

A practical decision and review template for architecture teams.

Version

v1.0

Date

DD Mon YYYY

Prepared by

Name / Team

Reviewed / Approved by

Name / Role

Confidentiality. This document is confidential and intended solely for the named recipients and the internal architecture review process. Do not distribute externally without approval.

›

Start Here

A two-minute orientation before you begin. This pack is a working document, not a deck — you complete the parts that match your review, then export and share.

Architecture is decision clarity

This pack is designed to make context, decisions, options, risks, ownership, and readiness visible before a review conversation — so the discussion is about the decision, not about finding the information.

Step 1 · Fill

Click any field or table cell and type. Entries save in your browser automatically.

Step 2 · Rate & tick

Click checkboxes to tick them, and severity / approval chips to cycle their value.

Step 3 · Add diagrams

Click a diagram box in Section 05 to upload, or drag an image straight onto it.

Step 4 · Export

Use the toolbar to Save as PDF or Download Word — your entries are included.

How to export to PDF or Word

PDF — click Save as PDF in the top toolbar (or press Ctrl/Cmd + P). Choose “Save as PDF”, set margins to Default and untick “Headers and footers” for the cleanest result.

Word — click Download Word to get an editable .doc file that opens in Microsoft Word with everything you've filled in, including uploaded diagrams.

Worked examples

Short illustrations of how completed sections read. A full completed ADR is shown in Section 06.

Example — Executive Summary (excerpt)

Problem statement

Synchronous service-to-service calls cause cascading failures under peak load; we need reliable asynchronous communication without standing up a platform team.

Current recommendation

Adopt a managed event bus (ADR-014). Seeking ARB approval to proceed to detailed design this quarter.

Example — Risk register entry

Risk	R-02 · Event ordering not guaranteed across partitions
Severity	High
Mitigation	Partition by aggregate key; make consumers idempotent.
Owner / status	Platform Architecture · Mitigating

Licence & use

This free pack is shared for personal learning, internal architecture preparation, and feedback. You may use and adapt it for your own work. Please do not resell, repackage, or publish it as your own.

This is a personal architecture-thinking tool. Views and templates are personal and not affiliated with any employer.

—

›Start HereOrientation, export & worked examples
01How to Use This PackWhen and how to apply each template
02Executive SummaryOne-page decision brief
03Architecture Context CanvasFrame the problem on one canvas
04Current State AssessmentGaps, impact and severity by area
05Target ArchitectureViews and a sample diagram
06Architecture Decision RecordADR template with example
07Options Comparison MatrixScore and recommend
08Risk & Mitigation RegisterRisks with heat-rated severity
09Security & Compliance ReviewControl checklists
10Non-Functional RequirementsNFR targets and gaps
11Cloud / Infrastructure ReadinessPlatform landing checklist
12Production ReadinessGo-live gate checklist
13Architecture Review Board SummaryARB-ready one-pager
14AppendixGlossary, assumptions, change log

How to Use This Pack

These templates are designed to be completed before you walk into a review. Fill in the relevant sections, attach your diagrams, and bring this document as the working artefact for the conversation.

Principle

You don't need every section every time. Pick the templates that match the gate you're preparing for, fill them honestly, and make decisions, risks and open points explicit rather than implied.

Choose the sections that fit your review.
Use it before…	Complete these sections
Architecture Review Board (ARB)	02 Executive Summary · 06 ADRs · 07 Options Matrix · 08 Risks · 13 ARB Summary
High-Level Design (HLD) review	03 Context Canvas · 04 Current State · 05 Target Architecture · 06 ADRs
Security review	03 Context Canvas · 08 Risks · 09 Security & Compliance
Cloud / platform approval	05 Target Architecture · 09 Security · 11 Cloud Readiness
Migration planning	04 Current State · 05 Target Architecture · 08 Risks · 11 Cloud Readiness
Vendor / tool evaluation	03 Context Canvas · 07 Options Matrix · 06 ADRs
Production readiness review	10 NFRs · 11 Cloud Readiness · 12 Production Readiness

Fill it in your browser

Click any field, cell or underline and type. Entries save automatically in this browser, then export cleanly with Save as PDF.

Make it yours

Add, remove or rename rows freely. Each section is commented in the HTML source so you can adapt the pack to your organisation's standards.

Executive Summary

A one-page brief for decision makers. Write this last, once the analysis below is done — but place it first.

Business context

Why now? The market, regulatory or operational pressure driving this work.

Problem statement

The specific problem to solve, in one or two sentences.

Proposed solution

The recommended approach at a high level — not the full design.

Key decisions required

What you need the review board or sponsor to decide or approve.

Expected benefits

Outcomes and value — quantified where possible.

Major risks

The few risks that could change the decision.

Current recommendation

Your clear recommendation and the approval you are asking for today.

Architecture Context Canvas

Frame the whole problem on one canvas before designing. Fill each cell with a few short points.

Business objective

Current pain points

Scope

Out of scope

Users / consumers

Systems involved

Data involved

Security sensitivity

Operational impact

Timeline constraints

Budget / cost constraints

Known dependencies

Assumptions

Current State Assessment

Assess each area honestly. Severity drives where attention and investment should go.

Severity: Low Medium High Critical

Fill the cells; set severity per area (edit the chip text in the source).
Area	Current state	Pain / gap	Business impact	Severity	Notes
Application				Medium
Integration				Medium
Data				High
Security				High
Infrastructure				Medium
Network				Low
Operations				Medium
Monitoring				High
Backup / DR				Critical
Compliance				Medium
Cost				Low
Support model				Medium

Target Architecture

Summarise the target, then capture each architecture view. A clean sample logical diagram is included below — replace it with your own, or insert into the placeholder boxes.

Target architecture summary

The shape of the target state in a short paragraph — the key building blocks and how they fit together.

Figure 1 — Sample logical architecture (reference only). Replace with your project's diagram.

aLogical architecture view

Components, responsibilities and relationships — technology-agnostic.

Logical viewClick or drop an image to insert

bDeployment view

Where components run: zones, regions, environments and nodes.

Deployment viewClick or drop an image to insert

cIntegration view

Interfaces, protocols and contracts between systems.

Integration viewClick or drop an image to insert

dData flow view

How data moves, where it is stored and its classification.

Data flow viewClick or drop an image to insert

eSecurity view

Trust boundaries, controls, identity and key flows.

Security viewClick or drop an image to insert

fOperations view

Monitoring, alerting, support and run responsibilities.

Operations viewClick or drop an image to insert

Architecture Decision Record

One ADR per significant decision. Keep them short and durable — they explain why, not just what. A worked example follows the blank template.

ADR template — duplicate this table for each new decision.
Decision ID	ADR-001
Decision title
Context
Options considered
Selected option
Rationale
Trade-offs
Impact
Owner
Status	Proposed / Accepted / Superseded
Review date

Example — completed ADR

Decision ID	ADR-014
Decision title	Use a managed event bus for inter-service messaging
Context	Services currently call each other synchronously, creating tight coupling and cascading failures under load. We need reliable asynchronous communication.
Options considered	(A) Self-hosted message broker; (B) Managed cloud event bus; (C) Continue point-to-point REST.
Selected option	(B) Managed cloud event bus.
Rationale	Lowest operational burden, native scaling and built-in dead-letter handling; reduces coupling without a dedicated platform team.
Trade-offs	Vendor dependency and per-message cost at high volume; team must adopt idempotent consumer patterns.
Impact	Affects all back-end services; requires contract definitions and a schema registry.
Owner	Platform Architecture
Status	Accepted
Review date	Q4 2026

Options Comparison Matrix

Score each option 1–5 against the criteria (5 = best fit). Use it to make the recommendation defensible.

Scoring: 1 = poor · 3 = adequate · 5 = excellent. Click a score to edit; rename options in the source.
Criteria	Option A	Option B	Option C
Business fit	–	–	–
Security	–	–	–
Scalability	–	–	–
Reliability	–	–	–
Integration complexity	–	–	–
Operational complexity	–	–	–
Cost	–	–	–
Time to implement	–	–	–
Vendor dependency	–	–	–
Future flexibility	–	–	–
Total score	–	–	–

Recommendation summary

Risk & Mitigation Register

Severity is a function of impact and likelihood. Track who owns each risk and its current status.

Severity: Low Medium High Critical

One row per risk. Set impact, likelihood and the resulting severity.
Risk ID	Severity	Status
R-01	Critical	Open
R-02	High	Open
R-03	Medium	Mitigating
R-04	Low	Accepted
R-05	Medium	Open

Security & Compliance Review

Work through each control area. Click a box to tick what is in place; leave the rest as open actions.

Identity & access

Centralised identity provider in use
MFA enforced for privileged access
Role-based / least-privilege access
Joiner / mover / leaver process
Service / machine identities managed
Access reviews scheduled

Network security

Network segmentation / zoning defined
Ingress / egress controls in place
WAF / DDoS protection at the edge
Private connectivity where required

Data protection

Data classified by sensitivity
Data residency requirements met
Retention & disposal defined
PII / sensitive data minimised

Encryption

Encryption in transit (TLS)
Encryption at rest
Key management & rotation
Certificate lifecycle managed

Logging & audit

Security events logged centrally
Audit trail for privileged actions
Log retention meets policy
Alerting on suspicious activity

Secrets management

Secrets stored in a vault
No secrets in code or config
Automated rotation in place
Scoped access to secrets

Vulnerability management

Dependency / image scanning
Patching SLAs defined
Penetration testing planned
SAST / DAST in pipeline

Compliance requirements

Applicable regulations identified
Controls mapped to requirements
Evidence collection in place
Audit readiness confirmed

Third-party / vendor risk

Vendor security assessed
Data processing agreements in place
SLAs & exit plan defined
Sub-processor visibility

Incident response

Incident response plan exists
Roles & escalation defined
Runbooks for key scenarios
Response tested / rehearsed

Non-Functional Requirements

Define a measurable target for each NFR, record the current status, and flag the gap.

Set concrete target values; "Current status" and "Gap" are filled during assessment.
NFR area	Requirement	Target value	Current status	Gap	Owner
Availability	Uptime / SLA
Scalability	Peak load handled
Performance	Throughput
Latency	Response time (p95)
Resilience	Failure tolerance
Backup	Backup frequency
Disaster recovery	DR strategy
RTO / RPO	Recovery objectives
Observability	Metrics / logs / traces
Maintainability	Change effort
Supportability	Operability
Security	Control coverage
Compliance	Regulatory targets
Cost efficiency	Unit economics
Accessibility	Standard (e.g. WCAG)
Usability	Task success

Cloud / Infrastructure Readiness

Confirm the platform foundations are in place before deploying workloads.

Environment readiness — dev / test / staging / prod provisioned and isolated
Network readiness — VPC / subnets / routing / connectivity established
IAM readiness — roles, policies and least-privilege baseline applied
Landing zone readiness — account structure, guardrails and baselines
Monitoring readiness — metrics, dashboards and log aggregation
Backup readiness — backup policy configured and verified
DR readiness — recovery region / strategy validated
Cost tagging — tagging standard applied for cost allocation
Automation — repeatable provisioning and configuration
Infrastructure as Code — environments defined in version control
CI/CD — pipelines for build, test and deploy
Support model — ownership and on-call defined
Runbook availability — operational runbooks documented

Production Readiness

The go-live gate. Every item should be ticked — or explicitly accepted as a known risk — before release.

Design approved
Security approved
Monitoring configured
Alerts configured
Backup tested
DR tested
Rollback plan available
Runbook ready
Support team identified
Change approval completed
Stakeholders informed
Known risks accepted

Architecture Review Board Summary

The single page to put in front of the ARB. Everything they need to make a decision.

Project name

Review date

Architecture owner

Decision requested

Summary of solution

Key risks

Key open points

Required approvals

Security · Data · Platform · Finance · Business sponsor — list who must sign off.

Final recommendation

Approval status — record each decision and sign-off.
Approver / role	Decision	Date	Status
			Pending
			Pending
			Pending

Overall approval status: Approved Approved with conditions Deferred Rejected

Appendix

Glossary

Term	Definition
ARB	Architecture Review Board — governance forum that reviews and approves significant architecture decisions.
ADR	Architecture Decision Record — a short document capturing one decision, its context and consequences.
HLD	High-Level Design — the architecture-level design preceding detailed design.
NFR	Non-Functional Requirement — quality attributes such as availability, performance and security.
RTO / RPO	Recovery Time / Point Objective — maximum tolerable downtime and data loss.
IaC	Infrastructure as Code — managing infrastructure through version-controlled definitions.

Assumptions

Assumption 1
Assumption 2
Assumption 3

Dependencies

#	Dependency	Owner	Needed by
D-01
D-02
D-03

Open questions

#	Question	Owner	Status
Q-01			Open
Q-02			Open
Q-03			Open

Reference links

Standards / policy reference
Related design document
Runbook / operations guide

Change log

Version	Date	Author	Summary of changes
v1.0			Initial version

End of document · Architecture Readiness Pack · Confidential

Simple Infrastructure Thinking by Subhakanta Kar

A free, practical architecture tool — shared for learning, preparation and feedback. Please don't resell or republish it as your own. This is a personal architecture-thinking tool; views and templates are personal and not affiliated with any employer.

Architecture Readiness Pack

Start Here

Worked examples

Contents

How to Use This Pack

Fill it in your browser

Make it yours

Executive Summary

Architecture Context Canvas

Current State Assessment

Target Architecture

aLogical architecture view

bDeployment view

cIntegration view

dData flow view

eSecurity view

fOperations view

Architecture Decision Record

Options Comparison Matrix

Risk & Mitigation Register

Security & Compliance Review

Identity & access

Network security

Data protection

Encryption

Logging & audit

Secrets management

Vulnerability management

Compliance requirements

Third-party / vendor risk

Incident response

Non-Functional Requirements

Cloud / Infrastructure Readiness

Production Readiness

Architecture Review Board Summary

Appendix

Glossary

Assumptions

Dependencies

Open questions

Reference links

Change log