Thinnest Viable Platform

Thinnest Viable Platform is a scoping principle: provide enough capability to help users perform their work without unnecessary implementation or coordination. Team Topologies uses it to direct attention to user flow rather than platform breadth.

The CNCF white paper similarly recommends a thin layer over suitable implementations that meets the organization’s requirements and provides a consistent experience.

Thin in what, exactly

Consider implementation effort and user burden separately. They are not automatic opposites: a small wrapper can still leave users with difficult integration work, while an existing managed service may reduce work for both groups.

The platform team can own the interface, integration and support contract while external providers or infrastructure teams operate the implementation. Choose reuse where it meets requirements, and make escalation and operating responsibilities visible.

Even a documented procedure can be a viable early offering if it makes the supported task reliable and easier. Compare its total cost with other interfaces before adding a portal.

Why thin, beyond taste

Two reasons support keeping the platform thin, beyond preference.

More customers can increase total support work even while each customer benefits. Compare support effort per team against a baseline at a stated scope and quality. A thin implementation can reduce maintenance, but it does not replace staffing and capacity planning.

DORA warns against building an all-encompassing platform before testing it with users. Start with a useful workflow and extend it from evidence. Define extension and contribution paths where central implementation would otherwise create a queue.

Five questions that settle the scope

Given a capability someone wants the platform to provide, these are the questions worth asking in order.

1. Is the need shared or strategically important? Frequent, common work is a useful candidate, but non-differentiating technology can still have different performance, cost or location requirements. Validate the actual fit.
2. Is a suitable implementation available? Prefer reuse where it meets the required functionality, controls and operating contract. Existing software that fails those requirements does not settle the choice.
3. Which arrangement meets the need at the lowest total lifecycle burden? Compare documentation, templates, scripts, APIs and portals by construction, maintenance, user effort and failure costs. They have no universal cost order.
4. Who operates, responds and decides for each kind of failure? A supplier may maintain the engine while the platform coordinates support and users diagnose their own queries. First response can follow a symptom rather than ownership. Agree the route to someone with authority to resolve provider-side failures, without requiring unsupported users to perform that work themselves.
5. What choices and exceptions are supported? A platform can be composable or mandated while still requiring a clear process for needs it does not meet. State who approves alternatives and who supports them.

Too thin is also a failure

A thin arrangement still needs to be usable. Two failure patterns are worth checking.

Instructions that preserve the burden. A procedure can be a useful platform interface, but assess its effort, error rate and consistency against the previous path. Neither the presence of a wiki nor a particular number of steps decides whether it helps.

No consistency to sell. A platform’s product is that things are done the same way — the white paper’s phrase is a layer “that provides consistency across provided implementations.” But be careful about what has to be identical, because the strong version of this claim is false: teams can run different implementations and still be consolidated, as long as they share the contracts that the consistency is for. Identity, observability output, policy enforcement and the shape of the interface are the things governance actually rests on; which database engine sits behind them frequently is not. So the question is not how much customization exists but what is still shared. If teams differ in implementation while meeting one identity model, emitting comparable telemetry and passing the same policy checks, the platform has consolidated the part that matters. If each team’s setup answers “who may access this” and “how do we know it is healthy” differently, those access and health contracts were not consolidated, whatever the template looked like on day one. Which shared contracts a platform needs depends on its requirements and on who owns control of each.

Give users enough feedback to understand their task’s outcome. DORA associates this capability with a positive experience. Test failure diagnosis as well as success; hiding implementation can make an unexplained failure harder to resolve.

Track delivery outcomes alongside user experience. DORA reports that productivity gains can coexist with lower throughput or stability. A leaking abstraction is one possible cause to investigate, not a mechanism established for every platform.

How platforms get thick

Thickness is rarely decided. It accumulates, usually along one of four paths.

• A one-team pilot or critical requirement may justify investment. Reassess continuing maintenance when its expected reuse or strategic value does not materialize.
• Wrapping what did not need wrapping. An interface over a provider’s service that adds no consistency and no policy adds a version to maintain and a failure mode to debug.
• Absorbing what should have gone back. A workaround can become continuing maintenance if its owner and retirement condition are never agreed.
• Building to a roadmap instead of to demand. The “big bang” pattern, where breadth is committed before any of it has users.

One clarification to close, because “thin” is easy to hear as “minimal”. Thinness is not about offering few capabilities — a mature platform can offer many. It is about how much of each one the platform team builds and runs with its own hands, and the goal it serves is the one Skelton and Pais name: a platform should make its users faster and “not generate more dependencies to manage.” Every layer you own is a dependency your users now have. For what that means for the responsibility boundary, see The Load Has to Land Somewhere; for the load it protects the platform team from, toil and cognitive load; and for the route users actually take through a platform, golden path.

References

• Matthew Skelton and Manuel Pais, Team Topologies: Key Concepts
• CNCF TAG App Delivery: Platforms White Paper
• DORA: Platform engineering