Platform Engineering Maturity Assessment Template (CNCF)

Platform Maturity Assessment: [Platform or organisation name] [YYYY]

Self-assessment of a platform engineering practice against the CNCF Platform Engineering Maturity Model (v1.0, TAG App Delivery, announced November 2023): five aspects (Investment, Adoption, Interfaces, Operations, Measurement) rated on four levels (Provisional, Operational, Scalable, Optimizing). For each aspect the assessment records evidence, the current level, the target level and the gap, then turns the gaps into an improvement backlog with owners and a re-assessment date. Structure aligned with the CNCF model, published under CC BY 4.0. Replace every [bracketed] value and every row marked Example. Worked examples use the fictional SaaS company "Corvid Commerce" and its platform "Nest".

Document control

Approvals

Revision history

Contents

1. Executive summary
2. Scope and method
3. Rating scale and evidence rules
4. Maturity model overview
5. Assessment by aspect
6. Results profile and gaps
7. Improvement backlog
8. Re-assessment cadence and triggers
9. Glossary and references

1. Executive summary

Overall picture: [Example: Nest is an operational platform with a funded team and standard tooling, moving towards a scalable, product-led platform. Interfaces and Investment are closest to level 3; Measurement is the weakest and limits every investment decision.]

Top findings:

1. [Example: No regular measurement of user satisfaction or platform value: decisions rely on anecdotes (Measurement, level 1).]
2. [Example: Adoption relies on mandates for new services; teams with existing pipelines stay off the platform (Adoption, level 2).]
3. [Example: Self-service exists for databases and pipelines but not for environments or messaging (Interfaces, level 3 partly met).]

Decisions requested: [Example: Fund one product manager and one analyst for platform measurement; approve the target levels above; accept Operations staying at level 2 for twelve months.]

2. Scope and method

2.1 Scope

2.2 Assessment panel

2.3 Method

The assessment follows five steps.

1. Prepare. Agree scope, panel and the evidence request list two weeks before the first interview.
2. Collect. Interview each sampled team for 45 minutes with the same questions; run a short user survey; collect artefacts (roadmap, budgets, SLO reports, documentation, adoption data).
3. Rate. Each panellist rates each aspect independently against section 4, citing evidence IDs.
4. Calibrate. Discuss every aspect where ratings differ by one level or more. Agree a rating and a confidence. Record dissent in the aspect notes.
5. Plan. Set the target level per aspect, describe the gap and create backlog items.

Sampling rule: [Example: At least 20% of product teams, at least one team per business unit, and at least two teams that do not use the platform today.]

3. Rating scale and evidence rules

Rating rule: an aspect is at a level when the organisation shows the characteristics of that level across most of the scope, with evidence of at least grade E2. When the characteristics of the next level are met only in part, record the lower level with "(next level partly met)". Never round up.

Confidence: High (E3 evidence and panel agreement), Medium (E2 evidence or one dissent), Low (E1 evidence only). Low confidence ratings must be re-checked before the next steering review.

Record each piece of evidence once and reference it by ID.

4. Maturity model overview

The CNCF Platform Engineering Maturity Model rates five aspects on four levels. The model's summary table labels the levels Provisional, Operational, Scalable and Optimizing; its detailed text calls level 2 "Operationalized". The cell labels below follow the model as published; the descriptions in section 5 are original. Check the current version at tag-app-delivery.cncf.io before use.

The levels in short, in this template's words:

• Level 1 Provisional: shared capabilities exist because someone needed them; they are built and kept alive by spare or temporary effort.
• Level 2 Operational: a funded team provides common capabilities, usually in response to requests.
• Level 3 Scalable: the platform is run as a product with a roadmap, attention to user experience and investment guided by data.
• Level 4 Optimizing: product teams and specialists extend the platform themselves; capabilities are composable building blocks and the platform team enables an ecosystem.

5. Assessment by aspect

5.1 Investment

Guiding question: how are people and money allocated to platform capabilities, and who decides?

5.2 Adoption

Guiding question: why and how do users start and keep using the platform?

5.3 Interfaces

Guiding question: how do users discover and consume platform capabilities?

5.4 Operations

Guiding question: how are platform capabilities planned, run, updated and retired over their lifecycle?

5.5 Measurement

Guiding question: how does the organisation collect and use feedback and data about the platform?

Useful sources for Measurement evidence are the Developer Experience Survey (dev/developer-experience-survey) and the Delivery Performance Report (dev/delivery-performance-report).

6. Results profile and gaps

Example summary: four of five aspects have a gap of one level; the sum of gaps is 1 + 1 + 1 + 0 + 1 = 4 levels. Use the count only to size the backlog, never as a score to compare with other organisations.

6.1 Gap statements

7. Improvement backlog

Track the items in the platform backlog and report their status at each platform product review. Items that change platform scope or funding go to the platform steering group through the charter.

8. Re-assessment cadence and triggers

Triggers for an early assessment:

• a change in platform funding model or a reorganisation of platform teams;
• a merger, acquisition or new business unit joining the platform;
• a major platform incident that exposed operating gaps;
• a target level reached early, so that a new target can be set.

Keep the questions, sampling rule and evidence grades unchanged between runs unless the revision history explains the change; otherwise trends in section 6 are not comparable.

9. Glossary and references

9.1 Glossary

9.2 References

Standard and licence note

Structure aligned with the Platform Engineering Maturity Model (v1.0) of the CNCF Technical Advisory Group for App Delivery, Platforms Working Group, https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/, © The CNCF Authors, licensed under Creative Commons Attribution 4.0 International (CC BY 4.0, https://creativecommons.org/licenses/by/4.0/). The aspect names, level names and short cell labels in section 4 are taken from the model with attribution; the guiding questions in section 5 are adapted from the model's own questions; the level summaries, indicators, rating rules, evidence grades and examples are original to this collection and are not the model's text. Corvid Commerce and Nest are fictional. Check the current official version of the model before use. Template licence: MIT.