Solution Architecture Document (SAD) & Governance Alignment

A Solution Architecture Document (SAD) packages the scope, design, quality targets, and risks of an initiative into one artifact that governance can review before build starts.

At a glance

• What it is: A standard-format document that ties together the outputs of scoping, options analysis, NFRs, component design, and risk management, submitted for review against enterprise-wide standards and policies.
• Why it matters: it catches problems like “this breaks our data residency policy” during a design review, instead of after the system is already in production.
• For developers: this is usually the document a design review board or security team actually reads before approving a project to move to build — if you’re asked for “the architecture doc,” this is what’s meant.
• When to use it: once the design has a chosen option, defined components, and known NFRs and risks — the SAD is an assembly step, not a from-scratch writing exercise.
• When not to use it: as a substitute for the earlier steps — a SAD with no real options analysis or risk register behind it is just paperwork.
• Prerequisites: outputs from Solution Options Analysis, Non-Functional Requirements, Component & Integration Design, and Risk & Constraint Management.

Mental model

flowchart TD
    A[Scope] --> F[Solution Architecture Document]
    B[Chosen option / ADR] --> F
    C[NFRs] --> F
    D[Component & integration design] --> F
    E[Risks & constraints] --> F
    F --> G[Governance / Architecture Review Board]
    G --> H{Approved?}
    H -- Yes --> I[Proceed to build]
    H -- No --> J[Revise and resubmit]

The SAD isn’t new content — it’s the assembly of everything already decided, put in front of governance for a sign-off before implementation begins.

Step-by-step walkthrough

1. Assemble the scoping statement, chosen option and ADR, NFR targets, component/integration diagram, and risk register into one document, using the organization’s standard SAD template if one exists — or arc42, a free, widely-adopted 12-section template (Introduction & Goals, Constraints, Context & Scope, Solution Strategy, Building Block View, Runtime View, Deployment View, Crosscutting Concepts, Architectural Decisions, Quality Requirements, Risks & Technical Debt, Glossary) if the organization has no template of its own.
2. Check the design against enterprise standards (security architecture, data policies, approved technology lists) — see Architecture Governance.
3. Submit the SAD to the relevant review body (an Architecture Review Board or equivalent) before build begins.
4. Address feedback and any required waivers for standards the design can’t yet meet.
5. Keep the SAD updated if the design changes materially during build — it’s a living reference, not a one-time gate.

Worked example

A fintech app is adding a new payment provider alongside its existing one.

• Input: a scoped initiative, a chosen integration option (sync call to the new provider’s API, per Component & Integration Design), NFRs including PCI-DSS-relevant handling of card data, and a risk register noting the new provider’s uptime history.
• Process: the SAD packages all of this into one document and is submitted to the security architecture team for review, since it touches payment card data.
• Output: governance sign-off is granted with one condition — card data must be tokenized before it reaches the new provider’s logs — which is added to the design before build starts.

Common use cases

Use case	When to use	Notes
Security or compliance-sensitive initiative	Design touches regulated data or systems	Expect a formal review; build in time for it in the project plan
Standardizing architecture practice across teams	Multiple teams produce inconsistent design docs	Adopt one SAD template so reviewers know where to find each section
Requesting a standards exception	Design can’t yet meet an enterprise standard	Document the gap and request a tracked, time-boxed waiver rather than silently deviating

Advanced details

• The SAD is an assembly artifact, not a first draft: if writing the SAD is the first time NFRs or risks are being thought through, the earlier steps were skipped.
• Governance review takes time — plan for it: build this into the project timeline rather than treating it as a late surprise.
• Waivers must be tracked: an approved exception to a standard should have an owner and an expiry, not stand forever undocumented.
• This is an “architecture description” in the formal sense: ISO/IEC/IEEE 42010 defines the vocabulary a SAD is built from — a stakeholder (anyone with a concern, i.e. an interest or issue to be addressed), a viewpoint (a set of conventions for describing one class of concern, e.g. “how does this run in production”), and a view (the actual diagram or section produced from a viewpoint, e.g. the component diagram is the output of a deployment viewpoint). Naming a section’s viewpoint explicitly (not just drawing a diagram) makes it clear which stakeholder concern it’s answering.
• arc42 sections map onto this section’s earlier topics: arc42’s Building Block View, Runtime View, and Deployment View correspond to Component & Integration Design; its Quality Requirements section corresponds to Non-Functional Requirements; its Architectural Decisions section corresponds to the ADRs from Solution Options Analysis — adopting arc42 means the SAD template is mostly already filled in by the earlier steps.

Quick reference

Term	Meaning
SAD (Solution Architecture Document)	The artifact packaging scope, design, NFRs, and risk for governance review
Architecture Review Board (ARB)	The recurring forum that checks proposed designs against enterprise standards
Waiver	A tracked, time-boxed, justified exception to a standard
Tokenization	Replacing sensitive data (like card numbers) with a non-sensitive placeholder before it’s stored or transmitted further
arc42	A free, widely-used 12-section template for structuring an architecture document, from Introduction & Goals through Glossary
ISO/IEC/IEEE 42010	The international standard defining the formal vocabulary (stakeholder, concern, viewpoint, view) behind any architecture description

Troubleshooting

Symptom	Likely cause	Fix
Governance review rejects a design late in the project	SAD wasn’t submitted until after build started	Submit the SAD as soon as scope, option, NFRs, and risks are known — before build begins
SAD feels like a paperwork exercise	It was written without real options analysis or risk management behind it	Complete the earlier steps first; the SAD should summarize real decisions, not invent them
Same policy exception keeps needing re-approval	Waiver wasn’t tracked with an owner and expiry	Record waivers formally so they’re visible and reviewed on schedule

Check your understanding

• Why is the SAD described as an assembly step rather than new content?
• Take a project you’ve worked on and check whether its architecture doc actually reflects a real options and risk analysis, or was written after the fact.

Related pages

Part of Introduction to Solution Architecture. Follows Technology Selection and Risk & Constraint Management. See also Architecture Governance and the Glossary.