• Home
  • BVSSH
  • C4E
  • 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

  • Architectural agility through reduction of unnecessary complexity
  • Reduced technical debt and lower maintenance burden
  • Stronger team ownership and decision-making capability
  • More responsive delivery ecosystem that adapts to change
  • Greater clarity over system purpose, usage, and lifecycle

Risks of Not Having This Standard

  • Legacy systems persist beyond usefulness, draining time and money
  • Teams avoid decommissioning due to unclear process or risk
  • Confusion over ownership and support responsibilities
  • Infrastructure and tooling become cluttered and inefficient
  • Security and compliance risks from outdated or unused systems

CMMI Maturity Model

Level 1 – Initial

Category Description
People & Culture Teams lack confidence or authority to decommission.
Fear of breaking things discourages action.
Process & Governance No formal process exists for retiring systems.
Decisions are made reactively or not at all.
Technology & Tools No visibility into which systems are unused.
Tools do not support lifecycle tracking.
Measurement & Metrics No metrics on system age, usage, or retirement.
No accountability for tech debt cleanup.

Level 2 – Managed

Category Description
People & Culture Teams begin identifying systems that are no longer needed.
Decisions require managerial approval.
Process & Governance Early-stage decommissioning processes emerge.
Inconsistent application across teams.
Technology & Tools Some dashboards show system inventory and usage.
Manual effort required to assess deprecation.
Measurement & Metrics Basic metrics on infrastructure costs or runtime activity.
Retirement actions are not tracked consistently.

Level 3 – Defined

Category Description
People & Culture Teams are accountable for the full lifecycle of their services.
Decommissioning is part of normal delivery practice.
Process & Governance A clear, organisation-wide process for system retirement is documented and followed.
Roles and responsibilities are defined.
Technology & Tools Platforms support tagging, versioning, and sunset tracking.
Decommissioning is part of roadmap planning.
Measurement & Metrics System usage, cost, and tech debt are reported.
Retirement decisions are made based on objective data.

Level 4 – Quantitatively Managed

Category Description
People & Culture Teams proactively review systems for retirement as part of retros and planning.
Decommissioning is seen as a sign of maturity.
Process & Governance Retirement outcomes are reviewed post-decommission.
Lessons are used to improve future lifecycle decisions.
Technology & Tools Automation assists with identifying sunset candidates.
Tooling includes alerts for system dormancy or redundancy.
Measurement & Metrics % of decommissioned systems per year is tracked.
Technical debt reduction and reclaimed resources are reported.

Level 5 – Optimising

Category Description
People & Culture Lifecycle ownership is deeply embedded in engineering practice.
Sunsetting systems is normalised and celebrated.
Process & Governance Decommissioning is integrated into quarterly business planning.
Feedback loops drive continual improvement.
Technology & Tools System lifecycle is managed end-to-end via platform tooling.
Roadmaps integrate retirement, replacement, and refactoring.
Measurement & Metrics Business impact of system retirement (e.g., savings, improved flow) is quantified.
Organisation benchmarks against best-in-class lifecycle health.

Key Measures

  • % of systems decommissioned vs active per team
  • Average system age and maintenance cost across portfolios
  • Number of legacy systems identified and retired per quarter
  • Evidence of lifecycle planning in team roadmaps
  • Retrospective reviews completed after system sunset
Associated Policies
  • Decentralised Decision-Making
Associated Practices
  • Domain-Driven Design (DDD)
  • Architecture Decision Forums
  • Error Budget Policies

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

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