Service Maturity Scorecard

Scorecards replace the production readiness review meeting with a continuously evaluated check, and the shift matters: a review is a snapshot at the moment of launch, while the properties it examines decay immediately afterwards.

Checks that earn their place are the ones tied to real incidents: an owner exists and is reachable, alerts route to a rota with someone actually on it, a runbook exists and was updated this year, dependencies are declared, the service is on a supported base image and language runtime, backups are configured and restore has been tested, an SLO exists with error budget tracking.

Two design cautions. Scorecards drift into vanity metrics if they measure what is easy to check rather than what predicts failure, and every check should be defensible by pointing at an incident class it would have prevented. And publishing league tables across teams reliably produces gaming rather than improvement — teams optimise the checks, not the outcome.

Used well, the scorecard is a conversation between the platform and a team about specific gaps, and it gives the architecture function something it usually lacks: current, evidence-based visibility of operational risk across the estate without asking anyone to fill in a survey.