Service Catalog Implementation — @service-catalog

Past a certain service count, the expensive questions stop being technical: who owns this? what breaks if it goes down? where are its docs, dashboards, and on-call? During incidents, those answers are paged for; during audits, they are reconstructed. The Service Catalog Implementation builds the registry that answers them permanently — every service with an owner, dependencies, documentation links, and operational metadata, searchable by anyone.

The catalog is populated from code and systems, not by survey: metadata files in repos, enriched from CI/CD, cloud, and monitoring integrations, so it stays current because staying current is automatic. The finish state is coverage of the in-scope estate with ownership at 100% — no orphaned services — and the catalog in daily use by engineers and incident response.

Service Registry & Ownership

Every in-scope service registered with owner, team, tier, lifecycle status, and links to repo, docs, dashboards, and on-call — the incident-time answer sheet.

Dependency Mapping

Service-to-service and service-to-infrastructure dependencies captured and visualized, from declared metadata and discovered signals where available.

Metadata-as-Code Pipeline

Catalog entries sourced from metadata files in each repo, validated in CI, and enriched automatically — with drift checks that flag services missing or stale.

Scorecards & Operational Views

Standards scorecards — production-readiness, security posture, docs completeness — per service and team, turning the catalog into a lever for raising the baseline.

1. Scope — Fix the catalog platform, the metadata schema, and the estate in scope; agree the ownership rules.
2. Build — Stand up the catalog, seed it by automated discovery, and drive per-repo metadata adoption with the teams.
3. Handover — Hand over the platform, the CI validation, and the scorecard framework — with ownership complete for the in-scope estate.

The Service Catalog Implementation is a menu item on the Scrums.com delivery catalog, available at every plan tier. Add it to your plan backlog and your delivery team schedules it like any other item — scoped, tracked, and reported through the SEOP. See Delivery Plan Tiers.

Backstage or something lighter?

Depends on estate size and appetite to operate a portal. Backstage suits larger estates with platform investment; lighter registry tools or a structured internal build fit smaller ones. Scoping recommends against your constraints, not a default.

How does it stay accurate?

Because entries live as code next to the services they describe, validated in CI and enriched from live systems. The catalog that goes stale is the one maintained by spreadsheet and goodwill — this one is maintained by pipeline.

What does the catalog enable next?

It is the backbone other platform work hangs off: the Internal Developer Platform Starter registers what it provisions, and scorecards give reliability work like the Service Level Objective Implementation a per-service home.