From Control to Coherence: Rethinking Platform Architecture

The relatively recent move towards more centralised platforms stems from a desire to exert greater control following an era of sprawl introduced by DevOps. 

Organisations have a desire to control cloud spend, infrastructure compliance, data security, and control the cost and compliance of the tools software engineers use. While these needs are often begrudgingly understood, the word "control" has become a curse word and elicits pushback even before people see how that control will be enforced. 

Yet on reflection, using the word “control” is likely not only unnecessary but also wrong. In the end, control is one solution that can be applied towards the cost and risk reduction outcome organisations are most concerned with, which can be better summarised as coherence.

Note: This is Part 2 of a three-part blog series. You can read part 1 here.

Coherence as an Enabler

Coherence is the property that lets many independent capabilities feel like a single system while helping that system encode and enforce guardrails. 

From an end-user perspective, a coherent platform experience is one in which users can learn to self-serve their specific needs in the moment, and, in doing so, generate reusable skills that further speed up future self-serve experiences when future requirements arise. From a platform engineer's perspective, a coherent platform allows the catalog of platform capabilities to expand without an exponential increase in bespoke work, including integrations and maintenance. And from a platform capability provider's perspective, a coherent platform enables a fast time-to-first capability release while achieving cross-functional requirements such as discoverability, access, and operability with low effort and from day one.

When a system focuses on control, users feel trapped, fight back, and more often resort to shadow IT. In a system that achieves their goals with coherence, users are provided support, but always with the focus on outcomes over adherence to strict rules enabling more flexibility to manage emerging cases while still delivering speed, safety, and efficiency.

That distinction matters because platform architectures often fail when they optimise the implementation before the operating model. Tooling-first platforms can look impressive early on. They have portals, pipelines, templates, operators, and approval flows. But if those pieces do not produce a coherent experience across teams, the platform still behaves like a set of disconnected mechanisms. The result is a lot of activity and not much scale.

Platform coherence creates an opportunity to create high-leverage compositions at all levels where a capability provider can depend on peer capabilities in a way that is transparent to the user. A database capability can depend on a networking rule capability. Platform engineers can compose golden-path abstractions from the underlying capability building blocks. Users can diverge from those paths while still staying within the company's platform by designing their own composition from a different set of building blocks. The point is not uniformity of implementation; the point is uniformity of packaging. This creates a system where the parts fit together cleanly enough for variation to be safe.

Coherence is what enables each capability to encode their full lifecycle in the tools of their choice while still treating collaboration and composition with other capabilities as a first class feature. Capabilities such as databases and deployments need to interact, but may not share all implementation details. But where they do, for example in policy in this image, they can leverage shared implementations.

Intentional Architecture Can Turn Simple Outputs into Powerful Outcomes 

When platforms are built from a tooling-first perspective, they often result in architectures that do not support necessary coherence outcomes. 

In contrast, starting from outcomes makes it easier to architect for unleashing growth from a single centralised team. Allowing specialist teams, such as security, to deliver scanning and compliance capabilities, or data to deliver storage capabilities. This focuses the platform teams on governing the system by providing tooling and guidance.

Those rules matter. What is the minimum rule set that enables all capabilities to integrate smoothly? How do we enable an effective inner loop for developing a capability? How do capabilities validate changes in light of this loose coupling? These are governance questions, but not the kind that require a board, a queue, or a manual gate at every turn.

Platform Engineers as Enablers, Not (Even Unintentional) Gatekeepers

The operating principle should be guardrails over gates. Guardrails give teams enough structure to move independently without drifting out of bounds. Gates, by contrast, concentrates risk management along a narrow review path and encourages everyone to treat the platform as a dependency rather than as a system they participate in. If the platform team has to approve every meaningful change, then the platform has not really enabled decentralisation. It has simply moved the bottleneck.

The role of platform engineering shifts from building every end-user capability to enabling experts to build safely within a coherent experience for both users and producers. While the scope of work for platform engineers may appear smaller, it can have a far wider impact. If multiple teams are building capabilities independently, this is the work that avoids chaos.

The platform focuses on providing an API that provides guidance and support through guardrails. Encoding policy and procedure requirements in early feedback to contributors allowing them to adhere to company requirements through shared tooling or, in the event that isn't suitable, in their own way.

Rather than historical solutions that slow progress, such as forcing all changes through a review board, this approach builds a platform ecosystem with guardrails rather than gates. More specifically, codified governance checks replace change advisory boards. Isolated and verifiable changes replace pull requests in high-blast-radius codebases. Coherence is not a slogan for central control, and it is not a license for everyone to do whatever they want. It is a design choice that makes decentralised contribution safe.

That is the shift worth making. Not more control, but better coherence.

The challenge though is, as always, in designing and implementing this system alongside all of the business as usual work to be done. That is why being able to lean on shared resources that are improved through community contribution can make a big difference. The CNCF is leading the way here and in the next blog we will look at what is in the works and how you can get involved.