Skip to content

Quickstart

This guide walks you through producing a minimal Solution Architecture Document. By the end, you will have a structured SAD covering the essential sections.

Download the Markdown template — or copy it to your clipboard for pasting into Confluence or a wiki.

Complete the metadata table at the top:

FieldWhat to Write
Document TitleA clear name — e.g., “Customer Portal SAD”
Solution NameThe name of the system or application
AuthorYour name
Version0.1
StatusDraft
ClassificationInternal (most common starting point)

Answer three questions in a short paragraph:

  1. What does the solution do? — 1-2 paragraphs
  2. What business problem does it solve? — 1-2 paragraphs
  3. What is the high-level approach? — 1-2 paragraphs

Then list what is in scope and out of scope as bullet points.

Complete the three core views at Minimum depth:

Logical View (Section 3.1) — List the main components:

ComponentTypeTechnologyStatus
FrontendWeb AppReactNew
APIAPI ServiceNode.jsNew
DatabaseDatabasePostgreSQLNew

Physical View (Section 3.3) — State where it runs:

FieldValue
HostingCloud (AWS / Azure / GCP)
Service ModelPaaS
RegionUK South

Security View (Section 3.5) — State how users authenticate and how data is protected:

FieldValue
AuthenticationSSO via Entra ID / Okta
Encryption at RestYes (provider-managed keys)
Encryption in TransitYes (TLS 1.2+)

Add at least one risk to the Decision Making section:

IDRiskSeverityLikelihoodMitigation
R-001Vendor lock-in to cloud providerMediumMediumUse managed services with open APIs where possible

You now have a structured SAD at Minimum depth. It should look something like this:

# Solution Architecture Document — Customer Portal
| Field | Value |
|-------|-------|
| Author | Jane Doe |
| Version | 0.1 |
| Status | Draft |
| Classification | Internal |
## 1. Executive Summary
The Customer Portal is a web application that allows customers
to view their account details and submit support requests.
It replaces a legacy PHP application that is end-of-life.
**In Scope:** Portal frontend, API backend, database.
**Out of Scope:** CRM integration (Phase 2), mobile app.
## 3.1 Logical View
| Component | Type | Technology | Status |
|-----------|------|-----------|--------|
| Frontend | Web App | React | New |
| API | API Service | Node.js | New |
| Database | Database | PostgreSQL | New |
## 3.3 Physical View
| Hosting | Cloud (AWS) |
| Service Model | PaaS |
| Region | eu-west-2 |
## 3.5 Security View
| Authentication | SSO via Okta |
| Encryption at Rest | Yes (AWS KMS) |
| Encryption in Transit | Yes (TLS 1.2+) |
## 6.3 Risks
| ID | Risk | Severity | Mitigation |
|----|------|----------|-----------|
| R-001 | Vendor lock-in | Medium | Use open APIs |

That is a valid Minimum-depth SAD. It covers the sections required for a development or test review.

  • See what’s needed for your depth — check the Depth Cheat Sheet for a single-page view of what to fill in
  • See a completed example — review the Employee Directory example to see what a full Recommended-depth SAD looks like
  • Expand to Recommended depth — add quality attributes (Section 4), lifecycle (Section 5), and scenarios (Section 3.6) before production approval
  • Use AI assistance — import a template into ChatGPT, Claude, or Copilot along with your project brief to generate a more detailed first draft