The case against a Platform?

Everyone seems to be aware of the benefits of a platform team. Having people focused on improving the experience of those creating software in a business makes sense. But often the idea doesn't move beyond the concept of producing a technical platform. There is so much more behind this!

In speaking to people in the software world about platforms we generally end up with three interpretations of the word platform that are usually conflated:

1. An opinionated technical platform providing a fabric for software to be developed on top of.Mulesoft's AnyPoint Platform is great example of this. As is Kubernetes. They are thick, opinionated platforms that abstract away the underlying building blocks.
2. A generic builder platform of low level services that can be combined to implement software solutions. Our public cloud providers are flexible, modular, and generic platforms of services. However, as higher level services are provided that become more opinionated they also fall into the above technical platform.and
3. A platform product where there is an ecosystem that encourages 3rd parties to invest in your product and improve it's feature set. The Apple AppStore. And yes, this usually comes with some form technical or builder platform in support of it!

What product is a platform team supposed to be delivering?

To help make sense of this I sat down with some engineers (a platform team's customers) and we started mapping out the needs we identified and the dependencies in meeting those needs.

Disclaimer: All maps are wrong. Maps are a view on the current state of play according to those compiling it. This is the exact thing that makes them so useful - they get differing viewpoints into a form where we can encourage discussion and debate.

A simple map as this was the first foray into mapping for many, but effective at demonstrating the following points:

• We identified grouping of needs that we labeled with the themes Autonomy, Operations, Platform Engineering, Enablement,
• There was a defined reliance on Platform Engineering to meet the needs of Autonomy and Operations excellence,
• Platform Engineering is dependent on Enablement to deliver, and
• Needs like a distributed architecture, modifiability, and consistency were on the boundary between platform engineering and the high level needs of engineering teams.

After discussing this grouping we concluded that producing a thick technical platform to meet the needs of engineers was not needed. It was meeting the practice based needs within the Platform Engineering theme that were crucial. We had so much more emphasis on enabling teams with knowledge, guidance, and context than we had anticipated.

This is confirmed by Matthew Skelton and Manuel Pais in the book Team Topologies - a highly recommended read. They talk about a Minimum Viable Platform which I totally agree with. Provide only what is needed, don't abstract and obfuscate the engineering away. You are doing your engineers a disservice.

Ultimately we came to the consensus that (for us) Platform Engineering was more of a way of working (DevOps anyone?) and providing an ecosystem of support to meet the needs of engineering teams. It entails so much more than a technical platform. It's providing for all the needs above, quite likely some shared services as products, some tooling, but it is entirely focused on the engineering teams and their experience as customers.