Skip to content

Depth Cheat Sheet

Use this table to see exactly which sections are required at your chosen documentation depth. Pick your column and fill in only the rows marked Yes.

SectionMinimumRecommendedComprehensive
0. Document Control — title, version, classification, sign-offs
Document metadataYesYesYes
Change historyYesYesYes
Contributors & approvalsNoYesYes
Purpose & scopeYesYesYes
1. Executive Summary — what the solution does and why
Solution overviewYesYesYes
Business context & driversYesYesYes
Strategic alignment & reuseNoYesYes
Scope (in/out)YesYesYes
Current state / As-IsNoYesYes
Key decisions & constraintsYesYesYes
Project detailsNoYesYes
Business criticalityNoYesYes
2. Stakeholders — who the design is for and what they care about
Stakeholder registerYesYesYes
Concerns matrixNoYesYes
Compliance & regulatoryNoYesYes
3.1 Logical View — components, capabilities, design patterns
Architecture diagramYesYesYes
Component decompositionYesYesYes
Design patternsNoYesYes
Service & capability mappingNoNoYes
Vendor lock-in assessmentNoYesYes
3.2 Integration & Data Flow — how components talk to each other and the outside world
Data flow diagramYesYesYes
Internal connectivityYesYesYes
External integrationsYesYesYes
API & interface contractsNoYesYes
3.3 Physical View — where it runs (cloud, regions, compute, networks)
Deployment diagramYesYesYes
Hosting & infrastructureYesYesYes
ComputeNoYesYes
User & admin accessNoYesYes
Network connectivityYesYesYes
EnvironmentsNoYesYes
End user compute & IoTNoNoYes
3.4 Data View — what data exists, how it’s classified, where it flows
Data storesYesYesYes
Data classificationYesYesYes
Data transfersNoYesYes
Data lifecycleNoNoYes
3.5 Security View — authentication, authorisation, encryption, monitoring
Business impact assessmentYesYesYes
AuthenticationYesYesYes
AuthorisationYesYesYes
Encryption at restYesYesYes
Secret managementNoYesYes
Security monitoringNoYesYes
Threat modelNoNoYes
Network securityNoYesYes
3.6 Scenarios — key use cases and the architecture decisions (ADRs) that shaped the design
Key use casesNoYesYes
Architecture decision recordsNoYesYes
4. Quality Attributes — operability, reliability, performance, cost, sustainability
Operational excellenceNoYesYes
Reliability & resilienceNoYesYes
Performance efficiencyNoYesYes
Cost optimisationNoYesYes
SustainabilityNoYesYes
Quality attribute tradeoffsNoYesYes
5. Lifecycle — how the solution is built, released, run, and eventually retired
CI/CD & developmentNoYesYes
Migration (if applicable)NoYesYes
Test strategyNoYesYes
Release managementNoYesYes
Operations & supportNoYesYes
Resourcing & skillsNoYesYes
Service startNoNoYes
MaintainabilityNoYesYes
DecommissioningNoYesYes
Exit planningNoYesYes
6. Decision Making & Governance — constraints, RAID (risks, assumptions, issues, dependencies), exceptions, sign-off
ConstraintsYesYesYes
AssumptionsYesYesYes
RisksYesYesYes
DependenciesYesYesYes
IssuesNoYesYes
Technical debt registerNoYesYes
Guardrail exceptionsNoYesYes
Architectural decisions logNoYesYes
Compliance traceabilityNoNoYes
Approval sign-offYesYesYes
7. Appendices — glossary, references, supporting standards
GlossaryNoYesYes
Reference documentsNoYesYes
Standards referencedNoYesYes
Compliance scoringNoYesYes
  1. Choose your depth based on your project’s criticality and governance requirements
  2. Fill in only the “Yes” rows for your chosen depth
  3. Skip everything else — do not include empty sections
DepthWhen to UseApprox. TimeTypical Gate
MinimumEarly-stage designs, proofs of concept, dev/test reviews15-30 minDevelopment review
RecommendedProduction-bound designs, formal governance1-2 hoursProduction approval
ComprehensiveCritical, regulated, or enterprise-scale systems1-2 daysEnterprise architecture review

Time estimates assume you already understand the solution and are drafting solo. Add 50–100% for collaborative drafting, and again for diagrams that need polishing for an external audience. Comprehensive timings include threat modelling, capacity planning, and full traceability — not just typing.