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

What are you looking for?

Standard : Teams are trusted to sunset their own systems and services

Purpose and Strategic Importance

This standard ensures teams have the autonomy to decommission their own systems and services when they no longer add value. It prevents accumulation of legacy platforms and drives continuous improvement in architecture.

Aligned to our "Decentralised Decision-Making" policy, this standard promotes ownership, agility, and efficient resource use. Without it, outdated systems linger, slowing progress and increasing maintenance overhead.

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: Decommissioning is rare, informal, or avoided. Systems persist long after their value has diminished, often due to fear, inertia, or lack of clarity on ownership.

  • Level 2 – Managed: Some teams begin retiring unused systems, but decisions are inconsistent and not tied to formal processes or governance.

  • Level 3 – Defined: A clear process exists for decommissioning systems, and teams are empowered to apply it. Ownership is explicit, and technical debt from unused systems is actively addressed.

  • Level 4 – Quantitatively Managed: Decommissioning is routinely monitored. Metrics on system usage, cost, and technical debt inform decisions, and outcomes are reviewed post-retirement.

  • Level 5 – Optimising: System retirement is embedded in lifecycle thinking. Teams proactively identify candidates for decommissioning as part of continuous improvement, freeing up capacity and improving architectural agility.


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
  • Decentralised Decision-Making
Associated Practices
  • Error Budget Policies
  • Architecture Decision Forums
  • Domain-Driven Design (DDD)

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

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