Overview

The Architecture Description Standard (ADS) defines how to write a Solution Architecture Document (SAD) — the single document that describes how a technology solution is designed, built, and operated.

Purpose

This standard defines the required structure and content for Solution Architecture Documents (SADs). The architectural views and quality attributes within a SAD constitute the High Level Design (HLD) of the solution.

A Solution Architecture Document conforming to this standard serves the following functions:

1. Communication — Provides a shared understanding of the solution architecture across all stakeholders
2. Governance — Enables the architecture governance process to evaluate the design against quality criteria
3. Traceability — Establishes links between design decisions, business requirements, quality attributes, and applicable standards
4. Reference — Acts as a living document that accurately describes the current-state architecture
5. Evidence — Demonstrates that the solution is well-architected against industry-recognised frameworks

Scope

This standard applies to the documentation of any technology solution architecture, regardless of:

• Deployment model — cloud-native, on-premises, hybrid, multi-cloud, or SaaS
• Scale — from single applications to multi-application ecosystems
• Industry — the standard is organisation-agnostic and sector-neutral
• Lifecycle stage — new builds, migrations, modernisations, or incremental changes

The standard is extensible — organisations can add custom sections, map to internal tools and standards, and define governance gates without modifying the core structure. See Organisation Customisation for details.

Audience

This standard is intended for use by:

Role	Primary Sections
Solution Architects	All sections — primary authors of SADs
Enterprise Architects	Framework Alignment, Quality Attributes, Governance
Security Architects	Section 3.5 (Security View), Quality Attributes
Infrastructure Engineers	Section 3.3 (Physical View), Quality Attributes
Development Leads	Section 3.1 (Logical View), Section 5 (Lifecycle)
Architecture Governance	All sections — as a review and governance framework (e.g., ARB, design authority)

Document Structure

A Solution Architecture Document conforming to ADS is organised into three tiers:

Tier 1 — Architectural Views (Sections 3.1 – 3.6)

The architecture is described through complementary views, each addressing different stakeholder perspectives. These are based on Kruchten’s 4+1 Architectural View Model (a widely-used framework for organising architecture documentation), extended with dedicated Data and Security views.

Together, these views form the High Level Design (HLD) of the solution:

View	Viewpoint	Primary Stakeholders
3.1 Logical View	Application architecture, components, patterns	Architects, Developers
3.2 Integration & Data Flow View	Data flows, integrations, interfaces	Integrators, Architects
3.3 Physical View	Deployment, hosting, networking, environments	Infrastructure, DevOps
3.4 Data View	Data stores, classification, privacy, lifecycle	Data Architects, Compliance
3.5 Security View	IAM, encryption, monitoring, threat model	Security, CISO, Compliance
3.6 Scenarios	Key use cases, architecture decision records	All Stakeholders

No single view provides a complete description of the architecture. Together, the views provide a holistic picture addressable by all stakeholder concerns.

Tier 2 — Quality Attributes (cross-cutting)

Evaluate the cross-cutting quality attributes across all architectural views. These are derived from the cloud Well-Architected Frameworks:

Quality Attribute	Focus
4.1 Operational Excellence	Observability, monitoring, operational procedures
4.2 Reliability & Resilience	DR, scalability, fault tolerance, backup and recovery
4.3 Performance Efficiency	Performance requirements, resource optimisation
4.4 Cost Optimisation	Cost analysis, FinOps practices
4.5 Sustainability	Energy efficiency, carbon impact, resource efficiency

Tier 3 — Lifecycle & Governance

Lifecycle Management (Section 5)

Describes how the solution is developed, deployed, operated, and eventually retired — including CI/CD, migration strategy, resourcing, release management, and exit planning.

Decision Making & Governance (Section 6)

Captures the constraints, assumptions, risks, dependencies, and issues that shaped the design. Documents key architecture decisions (ADRs), guardrail exceptions, and compliance traceability.

How the Sections Relate

Reading order: A completed SAD tells a story. It begins with the business context and who cares about the solution (Sections 0-2). It then describes the architecture itself through multiple views (Section 3). It evaluates how well the architecture performs against quality attributes (Section 4). It explains how the solution is built, deployed, and operated (Section 5). Finally, it records the decisions, risks, and governance that shaped the design (Section 6).

The diagram below shows how the three tiers work together. Architectural views describe what the solution is. Quality attributes assess how well it performs. Lifecycle and governance cover how it is built, run, and governed.

Documentation Depths

This standard assigns each section a documentation depth — Minimum (SHALL), Recommended (SHOULD), or Comprehensive (MAY) — that defines when it must be completed. This enables progressive adoption: begin with Minimum for early-stage designs, expand to Comprehensive for critical and regulated systems.

See Conformance and Usage for the full depth table, terminology definitions, and governance gate mapping.

Conformance

A Solution Architecture Document conforms to this standard when:

1. All sections marked Minimum are completed
2. The document structure follows the section numbering and hierarchy defined herein
3. Architectural views address the stakeholder concerns identified in Section 2
4. Quality attributes are evaluated as cross-cutting lenses across the architectural views
5. The document is validated against the JSON Schema (ADS Schema v1.0.0) if machine-readable output is required

A document that additionally completes all Recommended sections achieves full conformance.

---

Ready to Start?

• Quickstart — create your first SAD in minutes
• Depth Cheat Sheet — see exactly what to fill in at each depth
• Download a template — Word, Markdown, YAML, or JSON
• See completed examples — four worked examples across different project types

Contributing

ADS is open-source and hosted on GitHub. Contributions are welcome — submit issues, suggest improvements, or open a pull request. The standard content is licensed under CC BY 4.0 and the source code under MIT.