Platforms That Decay Often Fail to Architect for Sustainable Growth

Platforms are the next in a long line of solutions that aim to provide software engineers with the tools they need to create applications as efficiently as possible. Unfortunately, when the focus is solely on the outcome, i.e., the platform, it falls victim to the same challenge as past attempts. 

Despite all of the investment in portals, templates, and Kubernetes operators, organisations are realising that investing in tech implementation feels productive, while actually, they are just stuck on a treadmill of refactoring automation.

Organisational design continues to be the underpinning of any forward leaps in software delivery efficiency. The age-old Conway's Law and the more recent Team Topologies wisdom can be applied to design the socio-technical systems behind sustainable and scalable platforms. 

A platform is not just a set of features or an internal product catalogue. It is a way to reduce time, cost, and risk by turning bespoke internal requirements into commodities to be shared across your organisation. Platform Engineering is the socio-technical challenge aimed at optimising centralised delivery and avoiding centralised bottlenecks.

Modernising the Promise of Platforms

The promise of modern platforms is real enough. Platforms themselves are not a novel invention. Platforms are an iteration on the centralised ops experience where users, most typically software application teams, can offload certain dependencies and tasks to a centralised team, enabling an internal economy of scale for an organisation. Rather than having all teams manage their own databases, allow a centralised database expert team to design and manage the most secure and performant solution for all users in the organisation.

Diagram: A centralised platform enables faster and safer delivery of software by making sure the infrastructure dependencies are designed to be compliant by a collection of expert teams (not limited to security, storage and cloud) before being used by the consuming teams (also not limited to data, QA and application).

The innovation here is the platform engineering behind this centralised solution. Modern platforms are expected to be built on modern software principles applied to infrastructure, honed during the DevOps era. 

Centralised capabilities need to provide more than just automation. They need to provide self-service and on-demand access to company-approved resources for users. A platform's success depends on its ability to support the timely adoption of new capabilities and iteration on existing capabilities to meet the needs of its user base. In other words, delivering capabilities benefits from the same techniques applied to any software delivery, such as agile planning, DevOps delivery culture, and XP engineering principles.

Platforms As The Sum of Their Capability Parts

Capabilities are at their most impactful when they encode compliant tools into reusable building blocks for the organisation to compose and build on top of. Designing, building, and integrating these building blocks is where things most commonly start to break down. These capabilities, and in turn the wider platform, only succeed when users move faster while maintaining safety and enabling operational efficiency.

Diagram: Platforms provide different capabilities as services (i.e. they offer infrastructure and tools of different types). The power of a platform is applying company specific requirements to the tools including configuration, policies, processes, and on-going maintenance requirements. But when these company specific rules live in different systems and are copy pasted across multiple capabilities they become unmanageable to keep consistent and up-to-date.

A key outcome of platforms built with clear APIs is that consumers and producers can work independently, trusting their shared contract. This means consumers don't need to know or interact with the different Infrastructure as Code tools used by the producers. And producers can reduce migration costs by not requiring any user action when the contract is maintained. Without these principles, software fails to scale efficiently to support more users.

Not All Contribution Models Are Created Equally

While many platforms today encode a plug-in-like system to enable contributions, those plugins are treated as part of a monolithic deliverable rather than an independent solution. 

For a contribution model to be successful, producers should be able to package their own work, in their own languages and tools, into something that can be delivered and managed without dependency on other teams. In other words, the experience that platform users demand.

Any platform architecture that requires producers to commit changes to a centralised code base removes autonomy by demanding adherence to specific languages and introducing a dependency on external teams for change management. 

In addition, architecture that separates business processes, such as manual approvals or security audits, from technical implementations fails to support the full spectrum of business requirements. And finally, any architecture that makes a capability deconstruct and package its offerings by implementation due to code language reasons rather than domain value hinders the ability to test changes that deliver complete value streams.

A common indicator that an architecture is falling victim to these limitations is when centralised platform teams are asked to own, or significantly guide, the building and updating of capabilities on behalf of specialists. This creates a centralised backlog of requests that outpaces centralised platform engineering capacity even when headcount is significantly increased. The return on investment slows as the congestion in a narrow surface area grows.

Platforms Must Scale in Impact, Not Just Capacity

This is the core point: platform teams do not scale by taking on more delivery work. They scale when the architecture allows specialist teams to build and evolve capabilities without depending on the platform team for every change. 

When that does not happen, the platform team becomes the choke point for the entire organisation. The bottleneck is structural, not procedural.

That is why these initiatives often feel productive while producing disappointing results. There is real output, but the output is concentrated in the wrong place. The tooling is usually not the limiting factor. The limiting factor is whether the platform has been designed as a central product that everyone depends on, or as a system of capabilities that can be extended and operated without collapsing into central control. 

If the operating model still centralises change, the platform will scale activity long before it scales outcomes.

Platforms need to design for both collaborative growth and coherent user experiences. This isn't easy, but it is also similar to the challenges software architectures have solved, and we can look at how platforms apply these in the next blog.