Solution Architecture Document (SAD)

Purpose

The SAD serves as the definitive reference for how a solution is structured and why. It communicates the architecture to all stakeholders, guides implementation teams, and provides a baseline for architecture governance and change management.

When to Use

Create a SAD at the start of the alpha phase once the solution approach is agreed. Update it throughout beta and into live as the architecture evolves. It should be a living document that reflects the current state of the system.

How to Build

Begin with an executive summary that explains what the solution does, who it serves, and what business problem it solves. Keep this to one page — it should be readable by non-technical stakeholders.

Document the architecture principles that guided your design decisions. These should align with your organisation's enterprise architecture principles and the Technology Code of Practice.

Create the views: start with a context diagram showing the solution boundary and external actors/systems. Then produce a logical architecture showing the major components and their responsibilities. Add integration views showing how data flows between systems. Include a deployment view showing the infrastructure topology.

For each significant component, document its responsibility, technology choice, and key design decisions. Reference ADRs for detailed decision rationale.

Finish with a section on risks, assumptions, issues, and dependencies (RAID). Include a technology stack summary table and a glossary of terms.

Tips

Use diagrams extensively — a picture is worth a thousand words. Follow C4 model conventions for consistency.
Keep the document modular so sections can be updated independently.
Include a version history and change log.
Write for your audience — executive summary for leadership, detailed views for developers.
Cross-reference ADRs rather than duplicating decision rationale.
Include a How to Read This Document section for large SADs.

Common Mistakes

Writing the SAD once and never updating it, so it becomes stale and untrustworthy.
Including too much implementation detail that belongs in low-level design documents.
Omitting the why — describing what the architecture is without explaining why.
Not including non-functional requirements and how the architecture addresses them.
Making it so long that nobody reads it — aim for 20-40 pages maximum.

Government Context

In UK government, the SAD is a key artefact for GDS service assessments (particularly points 8 and 11 of the Service Standard). It demonstrates compliance with the Technology Code of Practice and supports spend control submissions to CDDO. For OFFICIAL and above classifications, the SAD should reference the security architecture. Cross-government shared platforms (GOV.UK Notify, Pay, PaaS) should be referenced where used.