An organisation should fund an internal platform only after it can name a recurring problem shared by several teams and the outcome expected to improve. Platform engineering is not a programme to centralise every technology choice. It is a product operating model: a platform team offers supported self-service paths and measures their value through the work of its users.
This principle prevents an expensive failure mode. A portal may attract regular visits and its catalogue may keep growing while a developer still opens a ticket to launch or diagnose a service. Platform activity is not evidence of better delivery, lower cognitive load or reduced operational risk.
Choose a user journey before choosing the architecture
The first artefact should describe a user and a job, not a target technology diagram. A team producing conventional APIs has different needs from analysts running batch workloads or engineers operating a regulated system. A platform may serve several personas, but it needs to distinguish their constraints rather than reduce them to a generic developer.
Combine interviews with observation of a real journey. Follow service creation, environment access, deployment, log access and incident response. Record active work and waiting time, handoffs, manual steps and knowledge that is absent from documentation. Ask where the user must understand an implementation detail purely because the current interface is incomplete.
A problem is a strong platform candidate when it is frequent, shared across teams, governed by similar constraints and serviceable through a common contract. The exceptional requirement of the organisation’s most complex system should not define the first experience for every delivery team.
Build the thinnest useful platform
The CNCF Platforms White Paper presents platforms as curated capabilities and experiences between users and capability providers. The practical implication is that a platform does not have to own all underlying infrastructure. It should integrate the smallest set of services required to complete a job without forcing users to understand every provider interface.
An initial platform may support one service type and runtime with a standard build, immutable artefact publication, secrets, observability, deployment and deletion. Completing the lifecycle matters more than offering many choices. A template that creates a repository but leaves upgrades, diagnosis and retirement undefined only postpones the complexity.
Abstractions have a cost. If a team must debug generated infrastructure without appropriate visibility or documentation, the platform has hidden information required for ownership. A good interface simplifies the common path while exposing state, events, responsible teams and the boundary between application and platform faults.
Publish a service contract and legitimate escape paths
Each platform capability needs a contract: supported use cases, required inputs, expected result, service objectives, support model, version policy, deprecation period and responsibilities on both sides. The statement “the platform handles infrastructure” is too broad to resolve an outage or prioritise a defect.
A golden path should not become a prison. A product team may need an exception for latency, regulation, protocol behaviour or provider constraints. The escape path should capture the need, maintenance owner, risk review and reconsideration date. The platform need not promise full support for arbitrary configurations, but it should retain visibility of material exceptions.
Versioning belongs in the contract. Changing a base image, network policy or secret mechanism can affect many consumers. Provide migration guidance, compatibility checks, a transition window and a way to identify workloads using the old version. Silent global changes turn a platform convenience into a correlated failure risk.
Operate the platform as a product
The team needs product ownership for problem selection, not merely a coordinator for component delivery. Its backlog should combine user research, usage evidence, incidents, support cost and organisational priorities. The next investment should address the journey creating the most repeated cost, not the feature that looks best in a demonstration.
Adoption should remain voluntary while the team is discovering value. A pilot across several distinct application teams tests whether the path works beyond its original builders. Once the capability has a stable contract, reliable support and demonstrably better outcomes, the organisation can consider making it the default.
The 2024 DORA report found broad internal-platform usage but mixed relationships with software delivery performance. It emphasises user-centred design, developer independence and product orientation. Platform adoption should therefore be treated as a hypothesis to test, not a guaranteed performance improvement.
Embed controls without recreating a ticket queue
The platform can encode repeated requirements in safe defaults: least privilege, approved images, encryption, logging, network policy and artefact checks. A control is most useful when it runs inside the self-service path and gives actionable feedback before deployment, rather than adding a manual approval after the work is complete.
Security engineers should co-own modules and acceptance criteria instead of reviewing every generated environment. Each rule needs an owner, rationale, severity, remediation path and exception process. A blocking control without practical support drives teams to find paths around the platform.
The platform itself concentrates risk. A control-plane outage, compromised pipeline or faulty template release may affect many services at once. Separate privileges, test platform changes, roll them out progressively, audit privileged operations and maintain a documented way to operate critical services when the portal is unavailable.
Measure completed work and total operating cost
Measures should correspond to the product hypothesis. For onboarding, use elapsed time to the first working deployment and the number of manual dependencies. For deployment, use change lead time, failure rate, recovery time and the share of changes requiring assistance. For security, examine coverage of safe defaults, exception age and remediation time.
Usage measures such as services created are necessary but insufficient. Compare them with task completion time, user satisfaction, infrastructure cost, support demand and reliability outcomes. Platform cost includes the team, external products, integration maintenance and migrations caused by platform decisions.
The CNCF Platform Engineering Maturity Model can help describe current and desired characteristics, but its authors explicitly caution against blindly pursuing the highest level. Maturity is not completeness. The investment is justified where the cost of transition and operation is lower than the friction and risk it removes.
Sources
- CNCF Platforms White Paper — CNCF TAG App Delivery, 11 April 2023.
- Platform Engineering Maturity Model — CNCF Platforms Working Group, 20 November 2023.
- 2024 Accelerate State of DevOps Report — DORA, 22 October 2024.