Internal Developer Platform Charter Template (CNCF Platforms)

Internal Developer Platform Charter: [Platform name]

Charter for a platform team and the internal developer platform (IDP) it builds and runs: mission and outcomes, users and their jobs to be done, the platform-as-a-product operating model, scope mapped to the 13 platform capabilities and 7 platform attributes of the CNCF Platforms White Paper (v1.0, TAG App Delivery, April 2023), the interfaces users touch (portal, API, CLI, golden paths), team topology and funding, platform SLOs, adoption and developer experience metrics, roadmap, governance and review. Structure aligned with the CNCF Platforms White Paper, 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. Mission, outcomes and boundaries
2. Users and jobs to be done
3. Platform as a product
4. Scope: platform capabilities
5. Platform attributes as design principles
6. Interfaces
7. Team topology, responsibilities and funding
8. Platform SLOs and support
9. Adoption and developer experience metrics
10. Roadmap
11. Governance and decision making
12. Risks and dependencies
13. Glossary and references

1. Mission, outcomes and boundaries

Mission: [Example: Nest lets Corvid Commerce product teams take a change from idea to production safely and quickly, without tickets, by offering self-service capabilities that are secure and compliant by default.]

Problem statement: [Example: In the last engineering survey, product teams reported that 30% of their time goes to infrastructure, pipeline and access work that is repeated in every team. Creating a new service takes four weeks and nine tickets. Security findings recur across services because each team configures its own baseline.]

The platform exists to reduce the cognitive load that product teams carry, to make the secure and compliant way the easiest way, and to let the organisation make consistent investments once instead of many times. It is an internal product: product teams are its customers and choose to use it because it serves them better than the alternatives.

1.1 Outcomes

1.2 Boundaries

2. Users and jobs to be done

Describe each user group, what it is trying to get done and the pain it reports today. Platform features are justified by these jobs, and the metrics in section 9 test whether the jobs got easier.

2.1 Job stories

Write each job as a short job story: when [situation], I want to [motivation], so I can [expected outcome]. Keep a register and link each roadmap item in section 10 to at least one job.

3. Platform as a product

The CNCF Platforms White Paper names platform as a product as the first platform attribute, and lists developing the platform together with its users as one of the main challenges of platform work. This charter commits the platform team to the following product practices.

Treat adoption as a signal of value, not as an objective in itself. When a team chooses not to use a capability, record why in the feedback register: it is often the cheapest source of roadmap input.

4. Scope: platform capabilities

The CNCF Platforms White Paper lists 13 capability areas that a platform may offer. The table maps each one to this platform. The capability names follow the white paper as published; check the current version at tag-app-delivery.cncf.io before relying on them.

Status values: Provided (built and run by the platform team), Curated (a third-party or provider service offered through platform interfaces with platform defaults), Planned (on the roadmap with a quarter), Out of scope (teams use another route, named in the notes).

4.1 Foundations the platform builds on

List what the platform depends on but does not own, so that ownership gaps are visible.

5. Platform attributes as design principles

The white paper describes 7 attributes of a successful platform. The platform team adopts them as design principles and checks every new capability against the test in the last column.

6. Interfaces

The API is the source of truth. The portal and CLI are clients of the same API, so that anything a user can do by hand can also be automated.

The sequence below shows the default self-service flow for a new database, with no ticket and no manual approval.

7. Team topology, responsibilities and funding

7.1 Team structure and interaction modes

Team types and interaction modes below use the vocabulary of the book Team Topologies (Skelton and Pais). Each platform team also publishes a Team API (architecture/team-api).

7.2 Responsibilities (RACI)

R = responsible, A = accountable, C = consulted, I = informed.

7.3 Funding model

Choose central funding while adoption is growing, so that teams are not discouraged from using the platform by a charge. Move to showback once allocation is reliable and to chargeback only when finance requires it and teams can influence their consumption.

8. Platform SLOs and support

Each generally available capability has an SLO. Beta and alpha capabilities have no SLO and say so in the portal. Full SLO documents follow the SLO Document template (dev/slo-doc).

8.1 Support model

9. Adoption and developer experience metrics

The white paper groups platform measurement into three areas: user satisfaction and productivity, organisational efficiency, and product and feature delivery. Use at least one metric in each area. Survey design follows the Developer Experience Survey (dev/developer-experience-survey); delivery metrics come from the Delivery Performance Report (dev/delivery-performance-report), which uses the five DORA software delivery metrics.

Example calculation for MET-04: 189 tickets in a month for 450 engineers (the user groups in section 2: 240 + 35 + 12 + 30 + 8 + 125, platform teams excluded) gives 189 / (450 / 100) = 42 tickets per 100 engineers.

Report these metrics by platform capability and by product team, never as individual developer performance. Treat a fall in satisfaction with a rise in adoption as a warning that adoption is being forced.

10. Roadmap

Publish the roadmap in the portal and review it each quarter with the user forum. Strategic choices that affect the whole engineering organisation are recorded in the Engineering Strategy (dev/engineering-strategy) and in architecture decision records.

11. Governance and decision making

11.1 Guardrails versus defaults

11.2 Review of this charter

Review the charter at least yearly and after any change in funding, team structure or enforced guardrails. Use the Platform Maturity Assessment (architecture/platform-maturity-assessment) as input; it rates investment, adoption, interfaces, operations and measurement on the four levels of the CNCF maturity model.

12. Risks and dependencies

13. Glossary and references

13.1 Glossary

13.2 References

Standard and licence note

Structure aligned with the Platforms White Paper (v1.0) of the CNCF Technical Advisory Group for App Delivery, Platforms Working Group, https://tag-app-delivery.cncf.io/whitepapers/platforms/, © The CNCF Authors, licensed under Creative Commons Attribution 4.0 International (CC BY 4.0, https://creativecommons.org/licenses/by/4.0/). The 13 capability names and 7 attribute names are used with attribution; all descriptions, principles, tests and examples are original to this collection and are not the white paper's text. DORA metric names follow dora.dev. Team types and interaction modes are concepts from the book Team Topologies, cited only. Corvid Commerce and Nest are fictional. Check the current official version of each source before use. Template licence: MIT.