• Home
  • BVSSH
  • Engineering Enablement
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : Systems are documented in a way that reflects how they evolve

Purpose and Strategic Importance

This standard ensures systems are documented in ways that reflect their real-world evolution, not just their initial design. It helps teams onboard faster, make safer changes, and understand system intent over time.

Aligned to our "Architect for Change" policy, this standard reduces knowledge gaps, supports continuous improvement, and ensures documentation stays useful. Without it, teams risk misalignment, rework, and slower delivery.

Strategic Impact

  • Improved consistency and quality across teams
  • Reduced operational friction and delivery risks
  • Stronger ownership and autonomy in technical decision-making
  • More inclusive and sustainable engineering culture

Risks of Not Having This Standard

  • Slower time-to-value and increased rework
  • Accumulation of inconsistency and process debt
  • Reduced trust in engineering data, systems, or ownership
  • Loss of agility in the face of change or failure

CMMI Maturity Model

  • Level 1 – Initial: Documentation is missing, out-of-date, or only created at the start of a project. System knowledge is tribal and reliant on specific individuals.

  • Level 2 – Managed: Some teams maintain documentation, but it is updated sporadically. It may reflect intended architecture more than the current or evolving system state.

  • Level 3 – Defined: Documentation practices are standardised across teams. Living documents reflect system evolution, and updates are part of regular engineering workflows.

  • Level 4 – Quantitatively Managed: Documentation quality and coverage are tracked. Updates are linked to system changes through tooling and review processes, ensuring traceability and accuracy.

  • Level 5 – Optimising: Documentation continuously evolves through team feedback and automation. It reflects real-world use and change, accelerates onboarding, and supports architecture decision-making at scale.


Key Measures

  • Adoption rates and coverage across teams
  • Impact on delivery metrics, quality, or team health
  • Evidence of ownership, governance, or learning loops
Associated Policies
  • Architect for Change
Associated Practices
  • Architecture Decision Forums
  • Architecture Decision Records (ADRs)
  • Bounded Context Mapping
  • Onboarding Playbooks
Associated Measures
  • Onboarding Time
  • Time to First PR

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering