CNCF Platforms White Paper

What the white paper is

"Platform engineering" gets used for everything from a Terraform module to a full developer portal, which makes conversations about it vague. The Platforms White Paper, published by the Cloud Native Computing Foundation's TAG App Delivery and its Platforms Working Group, is an attempt at a shared, vendor-neutral definition. It describes a platform as an integrated collection of capabilities defined and presented according to the needs of the platform's users, a layer that gives product teams a consistent experience for infrastructure and services.

What it covers

• Why platforms: reducing the cognitive load on product teams and letting them deliver faster without each team rebuilding the same infrastructure.
• What a platform is: the definition above, and how platforms mature from a collection of documents and scripts to self-service products.
• Attributes of good platforms: treating the platform as a product, a focus on user experience, documentation and onboarding, self service, and secure defaults.
• Attributes of platform teams: researching user needs, working with product teams, and measuring what the platform actually changes.
• Challenges and measuring success: common reasons platforms fail and how to judge whether one is working.
• Capability domains: 13 areas such as web portals, APIs, application and infrastructure provisioning, data services, security, observability and artifact storage, each mapped to CNCF and other open source projects that can provide them.

The Platform Engineering Maturity Model

The same TAG publishes a companion Platform Engineering Maturity Model, released after the white paper. It scores an organisation on five aspects (investment, adoption, interfaces, operations and measurement) across four levels: provisional, operationalized, scalable and optimizing. Read it straight after the white paper: the paper tells you what a platform is, the model helps you say honestly where yours stands and what to improve next.

Is it worth reading?

Yes, precisely because it is short and neutral. It does not sell a product, so it is a safe reference to share with a team or a manager when you are arguing for, or scoping, a platform. The capability map is also a useful checklist when you are asked which open source tools could fill a gap.

Prerequisites and time

You will get most from it if you understand containers, Kubernetes at a basic level, CI/CD and infrastructure as code, because the capability domains refer to them. Reading it takes an hour or two; the maturity model takes another hour.

What you can do after it

• Define an internal developer platform in one sentence that your team agrees with.
• Map your organisation's existing tools to the capability domains and spot the gaps.
• Place your platform on the maturity model and write a realistic next step.

Common questions

Is it a tutorial? No. It is a concept paper. Pair it with hands-on docs such as Backstage, Argo CD or Crossplane to build something.

Is it tied to Kubernetes? It is written from a cloud native viewpoint and maps capabilities to CNCF projects, but the ideas apply to any platform.

Best for: engineers moving into platform engineering and anyone who needs a shared vocabulary before a platform project starts.