Part 0 · 1 chapters · ~8 min

Service Ownership and Catalogues

Why unowned services become incidents, ownership by teams, catalogues as code (Backstage), declared dependencies, scorecards for standards, orphan detection, and handing over ownership when teams reorganise.

1

Every component has an owner

code
# catalog-info.yaml (Backstage) in the payouts-api repo
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payouts-api
  annotations: { pagerduty.com/service-id: P8X2Q1, github.com/project-slug: acme/payouts-api }
  links: [{ url: https://runbooks.acme.dev/payouts, title: Runbook }]
spec:
  type: service
  lifecycle: production
  owner: group:team-payouts
  system: money-movement
  dependsOn: [component:ledger-api, component:rail-adapter, resource:payouts-db]
  providesApis: [payouts-v1]

Orphans: run a weekly job that lists components whose owning group no longer exists or has no members, and resources (queues, buckets, databases) with no catalogue entry. Reorganisations create orphans silently; the job makes them visible before an incident does.

A SERVICE CATALOGUE ENTRY
the record that answers "who owns this?"
payouts-apicomponentowner: team-payoutson-call: payouts-primarydepends on: ledger-api, rail-adapterrunbooks, ADRs, dashboardsscorecard: 7/9 checks
swipe the figure sideways, or tap expand for full screen
1/4
one record per component
Each service, library, topic and database has a catalogue entry in its repo (catalog-info.yaml in Backstage), so ownership changes with the code.
ownership as codelives in the repo