Skip to content

0. Document Control

Minimum ISO 42010

This section captures the administrative metadata for the Solution Architecture Document, ensuring it is versioned, traceable, and governed appropriately.

Minimum
FieldDescription
Document TitleThe formal title of this Solution Architecture Document
Application / Solution NameThe name of the system being documented
Application IDUnique identifier (e.g., from a CMDB or portfolio tool)
Author(s)Primary author(s) of the document
OwnerThe accountable architect for this document
VersionCurrent document version (use semantic versioning)
StatusDraft / In Review / Approved / Superseded
Created DateDate the document was first created
Last UpdatedDate of the most recent update
ClassificationDocument security classification
Minimum

Track all significant changes to the document:

VersionDateAuthor / EditorDescription of Change
0.1[date][name]Initial draft

Guidance

  • Use semantic versioning: MAJOR.MINOR (e.g., 1.0 for first approved version, 1.1 for minor updates, 2.0 for significant redesign)
  • Record who made each change and why
  • This is a living document - it should be updated whenever architecturally significant changes are made to the solution
Recommended

Tracking contributors and their roles ensures accountability and provides an audit trail for governance.

NameRoleContribution Type
[name][role]Author / Reviewer / Approver
Minimum

Describe the purpose of this specific Solution Architecture Document:

  • State which solution or application this document describes.
  • Define the scope boundary.
  • What is explicitly out of scope?
  • What other documents does it relate to (e.g., detailed designs, operational runbooks)?

Guidance

The Solution Architecture Document serves as:

  • A reference document describing the current-state solution architecture
  • Evidence that the solution is well-architected
  • Input to architecture governance and review processes
  • A living artefact that must be updated when architecturally significant changes are made

It should contain design details that are relatively static. Dynamic or frequently changing information belongs in operational documentation.