What a shared platform should standardise

The idea in brief

A platform that fixes every choice is easier to govern but can be harder to use. The question is which choices to make once, centrally, and which to leave with the teams building on it. The CNCF Platforms White Paper and DORA's 2024 research both offer a public starting point.

The capabilities CNCF lists

The CNCF Platforms White Paper names thirteen capability domains a platform may provide. Several match the shared list in this post:

The paper also describes these capabilities as optional and composable: product teams can use parts of the platform and provision their own capabilities where the platform doesn't cover them.

What DORA found about independence

DORA's 2024 report found that internal platforms were associated with higher individual productivity, but also with lower throughput and change stability. Developer independence, being able to finish work without waiting on an enabling team, was associated with a productivity gain of about 5%. The report's infographic notes larger downsides when the platform was mandated for the entire application lifecycle.

A practical split

Combining the two sources gives one reasonable reading:

• Standardise what is common and undifferentiated: identity, access, delivery paths, observability, security controls.
• Leave with the team what depends on the use case: agent framework, prompt and context design, orchestration, user experience and domain-specific evaluation.
• Keep the defaults optional, so a team with a good reason can step outside them.

@article{adam2026standardisetherightthings,
  title   = {What a shared platform should standardise},
  author  = {Adam, Ammar},
  journal = {www.ammaradam.dev},
  year    = {2026},
  month   = {Oct},
  url     = {https://www.ammaradam.dev/posts/standardise-the-right-things/}
}