Your Platform Is Not an Island: Building for Your Ecosystem
- Daniel Bryant
- Apr 8
- 9 min read
Updated: 1 day ago
In a recent Syntasso webinar, Rachael Wonnacott, Head of Cloud Engineering at Fidelity International, explored a simple but powerful idea: your platform is not an island. Platform teams do not operate in a vacuum. They sit within a broader organisational ecosystem shaped by people, team structures, legacy technology, established processes, and varying levels of engineering maturity.
Rachel used a biological analogy to make the point. Organisations grow organically over time, and as they do, teams, processes, and relationships evolve in ways that are not always intentional. In smaller companies, that may not matter as much. In an enterprise, though, the shape of the organisation has a huge impact on how software gets delivered. A platform can be technically sound yet struggle if it has not been designed with the wider ecosystem in mind.
That framing is especially relevant in large enterprises, where years of historical ways of working continue to influence modern engineering practices. Structures built around on-premises infrastructure, rigid team boundaries, and inherited process dependencies do not disappear overnight just because a company adopts cloud native technologies. As Rachel explained, this creates an environment where friction is almost inevitable unless it is addressed deliberately.
DevOps solved some problems, but not all of them
One of the most interesting threads in the webinar was Rachel’s reflection on the limits of DevOps at enterprise scale. DevOps has undoubtedly improved collaboration inside teams, but in large organisations, it has not removed complexity so much as redistributed it. Instead of tension between “dev” and “ops”, there are now many teams, each running their own services, tooling, and ways of working, all of which still need to collaborate.
That means enterprises often end up with a hybrid reality. Some teams may work in a modern product-oriented way, while others still operate through more traditional structures. Some applications may be cloud native, while others still depend on on-premises systems. Teams may be told to own more end-to-end responsibility, but still rely on multiple other teams to get anything done.
The result is a familiar set of challenges: duplicated effort, inconsistent delivery models, hard-to-audit variation, and a growing number of interaction points between teams. Rachel’s point was not that DevOps has failed, but that it does not, on its own, solve the ecosystem problem. Once you reach enterprise scale, the interactions between teams become a major source of friction in their own right.
Platform engineering is about removing friction
From there, Rachel reframed platform engineering in very practical terms. At its core, platform engineering is about reducing friction. That friction exists at multiple levels.
At the organisational level, the business wants software delivered more frequently and at a lower cost. At the team level, people want to avoid being blocked by other teams or trapped in cumbersome processes. And at the individual level, developers want to feel effective. There is nothing more frustrating than working hard and still being unable to make progress because of organisational obstacles.
That last point is particularly important. Platform conversations often focus on standardisation, tooling, and control, but Rachel emphasised that developer experience matters because it directly affects whether people can do meaningful work. A platform that increases cognitive load or creates more handoffs is not really helping, no matter how elegant the architecture looks on paper.
A case study from Fidelity’s platform journey
Rachel grounded the session in Fidelity International’s own platform journey. Long before “platform engineering” became the industry term, Fidelity had already been building internal platforms, including an internal Cloud Foundry-based platform running on physical infrastructure. That platform was successful in many ways. It reduced cognitive load for developers and offered a strong developer experience by abstracting much of the underlying complexity.
As Fidelity pushed further into the cloud, the organisation wanted to give teams more autonomy and make use of public cloud economics and flexibility. To support that, the platform team automated the provisioning of cloud accounts, effectively giving product teams their own “mini data centres” in the cloud. A shared responsibility model emerged: the platform team handled core infrastructure and connectivity concerns, while workload teams took responsibility for their applications and the services they chose to run.
This worked well for some teams but not for all. That became a recurring theme in the webinar: one size does not fit all. In an enterprise, different teams have different levels of maturity, different needs, and different appetites for infrastructure ownership. Some teams are comfortable with deeper operational responsibility. Others simply want a reliable service that lets them focus on business logic.
The return of a platform-as-a-service mindset
One of the most compelling insights from the webinar was Rachel’s reflection that, in some ways, the industry has come full circle. Cloud Foundry succeeded because it let developers focus primarily on applications and data. It reduced the amount of infrastructure knowledge they needed and provided a highly opinionated, managed experience.
Kubernetes, by contrast, is often assumed to be a platform in itself, but it is not. Out of the box, it is a control plane, not a complete internal developer platform. That distinction matters because it creates an expectation gap. Leaders may see Cloud Foundry and Kubernetes as broadly equivalent because both are container-oriented technologies, but the developer experiences they offer differ significantly.
Rachel described how this became clear during Fidelity’s Kubernetes journey. Early enthusiasm led to inflated expectations: Kubernetes was going to solve everything. But once the minimum viable platform was released, reality set in. Developers still needed infrastructure knowledge, integrations with surrounding services were clunky, and the broader application lifecycle remained fragmented. The issue was not Kubernetes alone. The issue was everything around it.
Your platform is only as strong as the lifecycle around it
This is where the title of the talk really came into focus. If a platform team defines its responsibility too narrowly, it can end up thinking only about the runtime layer: “our job is to run the container.” But that treats the platform as an isolated system.
Rachel instead encouraged platform teams to look across the full application lifecycle: commit code, test code, build image, store image, deploy image, run image. Cloud Foundry handled much more of that lifecycle out of the box than Kubernetes does. So if teams move to Kubernetes without considering what happens in the surrounding stages, adoption becomes harder, and developer experience suffers.
At Fidelity, the challenge was compounded by organisational boundaries. Different tools across the lifecycle were owned by different teams, each with distinct expectations, operating models, and levels of self-service. Even if the Kubernetes platform itself was solid, developers could still be slowed down or blocked elsewhere in the flow. That is why platform design has to extend beyond the runtime and into the full ecosystem of services and teams that support delivery.
The golden path matters — but so does how you build it
Rachel described the goal as creating a smoother, more consistent path through that lifecycle: a golden path. In practice, that means reducing the number of handoffs developers have to make and standardising interactions where handoffs remain necessary.
At Fidelity, one way this was achieved was through a GitOps-based approach, with pull requests as the entry point. Developers specify desired state declaratively, and the platform orchestrates what needs to happen behind the scenes. That helps create a more consistent interface even when the underlying services are delivered by different teams.
Rachel gave the example of database provisioning. From the developer’s perspective, requesting a database can be as simple as declaring the requirement in configuration. Behind the scenes, that request may trigger a pipeline owned by a completely different team in a different AWS account. But because the interaction is standardised and the networking, security, and access controls are handled for them, the service feels integrated. This is a powerful example of how a platform can stitch together multiple parts of the ecosystem without exposing all of that complexity to the user.
Collaboration first, service later
That model also connects neatly to Team Topologies. Rachel explained that the right approach is often to begin with close collaboration between teams and then move toward a service relationship once the boundaries and interfaces are understood.
That is especially useful when platform teams depend on specialist domains; they should not try to own their own domains. A platform team does not need to become an expert in every business domain or every technical niche. In some cases, another team is genuinely better placed to deliver a capability, such as a database service, than the platform team would be. The platform team's job is then to collaborate long enough to make that capability consumable in a simple, consistent way, before stepping back and letting it run as a service.
This is a useful reminder that platform teams do not have to build everything themselves. In large organisations, that would be neither realistic nor desirable. The more important task is to create coherent interfaces across a fragmented environment.
The challenge of MVP and the thinnest viable platform
Another valuable part of the webinar was Rachel’s honesty about releasing a minimum viable platform. The question many platform teams ask themselves is whether they released too early. Her answer was nuanced. The real challenge is not usually that the platform was released too soon, but that defining the “minimum” in minimum viable platform is extremely hard.
Release too much, and you risk building things nobody needs. Release too little, and users may see the platform as underwhelming or incomplete. Rachel joked that although you may sell the vision of a hotel, version one may feel more like a motel.
That tension does not really go away. It continues as the platform evolves, which is why Rachel emphasised the importance of aiming for the thinnest viable platform. That means being disciplined about what belongs in the platform and what does not. Not every request should become a platform feature. Not every application is a good fit for the platform. In fact, if a platform can handle absolutely every workload in the organisation, it may have become too broad and too complex.
Rachel shared a practical example from Fidelity’s own experience. Early on, the platform adopted Grafana because it was a widely used CNCF tool and made sense for the initial build. But over time, it became clear that many users preferred an existing centralised dashboarding tool that was already well understood elsewhere in the organisation. Supporting both increased cognitive load for the platform team, without delivering enough value to justify it. In that case, the right decision was not to preserve the newer, shinier option, but to simplify in line with how customers actually worked.
Saying no is part of the job
That naturally leads to one of the hardest responsibilities of platform leadership: saying no. Rachel was candid about the fact that this is uncomfortable. Platform teams want to help. Product owners want to be liked. But if every team’s bespoke requirement becomes a core platform feature, the result is platform sprawl and increasing cognitive load for both builders and users.
The way to handle this well is to ground the decision in business value. If a request serves only a small corner of the organisation, it may not belong on the core platform. That does not mean the requesting team is ignored. They may still be supported through signposting, enablement, or inner sourcing. But the shared platform itself should focus on serving the broadest common needs.
This is one of the clearest markers of a product mindset. A platform is not successful because it says yes to everything. It is successful because it makes careful choices about what to standardise, what to abstract, and where to draw boundaries.
Start with onboarding
When Paula Kennedy asked what one action platform leaders should take in the next month to make their platform more successful, Rachel’s answer was immediate: review the onboarding process.
That is a strong takeaway. It is easy for platform teams to focus on runtime resilience, technical elegance, or the next feature in the roadmap. But if teams cannot successfully onboard, none of that matters. In regulated environments, especially, onboarding often involves not only technical setup but also data, security, and compliance processes. If those are fragmented or difficult to navigate, the platform will feel hard to use regardless of its underlying quality.
Rachel’s suggestion was also refreshingly practical: if you want to understand how good your platform experience really is, try deploying an application to it yourself. Dogfooding the platform is one of the fastest ways to uncover friction that metrics or architecture diagrams will not reveal.
Final thoughts
Rachel’s webinar was a timely reminder that platform engineering is not just a technical discipline. It is an organisational one. The real work is not only in building a runtime or exposing self-service APIs, but in understanding how teams interact, where friction arises, and how to create a more coherent path through the wider delivery lifecycle.
That is what it means to say your platform is not an island. A platform succeeds when it recognises the ecosystem around it and is designed accordingly. It succeeds when it reduces cognitive load rather than adding to it. It succeeds when it standardises where it should, collaborates where it must, and stays disciplined about how much it tries to become.
For enterprise platform teams, that is both the challenge and the opportunity
Comments