Architecture Artifacts
A reference guide to the documents, diagrams, and deliverables that Solution Architects produce. What they are, when to use them, and which phase they belong to.
A note on proportionality: Not every project needs every artifact. The right set of documents depends on the complexity of the solution, the phase of delivery, and the governance requirements. Producing documents nobody reads is waste. Produce what's needed to make good decisions and enable the team.
Architecture
Solution Architecture Document (SAD)
The primary architecture deliverable. Describes the solution's components, their interactions, technology choices, and how they meet requirements. A living document that evolves throughout delivery.
Architecture Decision Record (ADR)
A short document capturing a single architecture decision — the context, the options considered, the decision made, and the consequences. Lightweight, version-controlled, and invaluable for future teams.
Solution Options Paper
Presents 2-4 solution approaches with trade-offs across cost, time, risk, and alignment with standards. Used to support governance decisions. Should include a clear recommendation.
Architecture Principles
A set of guiding statements that shape architecture decisions for a programme or department. Should be specific enough to be useful and few enough to be remembered.
Context Diagram (C4 Level 1)
Shows the system in context — who uses it and what other systems it interacts with. The most important diagram for communicating with non-technical stakeholders.
Container Diagram (C4 Level 2)
Shows the high-level technical building blocks — applications, databases, message queues, file stores — and how they communicate. The primary technical architecture view.
Governance
Architecture Review Board Submission
A structured submission for architecture governance review. Typically includes the solution overview, key decisions, risks, alignment with standards, and any exceptions requested.
Technical Design Authority Paper
A paper seeking approval for a specific technical approach from the department's design authority. More detailed than an options paper, focused on implementation approach.
Risk Register (Architecture Risks)
Documents identified architecture risks with likelihood, impact, mitigations, and owners. Should be actively managed, not filed and forgotten.
Delivery
Integration Specification
Defines how two systems will integrate — protocols, data formats, authentication, error handling, and SLAs. Essential when working with other teams or external systems.
Non-Functional Requirements (NFRs)
Specifies quality attributes — performance targets, availability requirements, scalability expectations, and capacity needs. Should be measurable and testable.
Operational Readiness Checklist
Confirms the service is ready for live operation — monitoring in place, runbooks written, incident process defined, support model agreed, disaster recovery tested.
Security
Security Architecture Document
Describes the security controls, threat model, trust boundaries, and security patterns for the solution. May be a section of the SAD or a standalone document for complex services.
Threat Model
Identifies potential threats to the system, assesses their likelihood and impact, and defines mitigations. STRIDE or similar methodology. Should be revisited when the architecture changes.
Data Protection Impact Assessment (DPIA)
Required when processing personal data in ways that pose high risk to individuals. The Solution Architect contributes the technical description of data flows, storage, and access controls.
Data
Data Flow Diagram
Shows how data moves through the system — where it enters, how it's processed, where it's stored, and where it exits. Essential for security review and data protection compliance.
Data Model
Defines the logical structure of data in the system — entities, relationships, and key attributes. Not necessarily a full physical database schema, but enough to understand the data landscape.
Information Asset Register Entry
Documents what data the service holds, its classification, who owns it, retention periods, and disposal approach. Required for information governance compliance.