We often celebrate the individual hero or heroine who (purportedly) creates something ingenious alone – the maverick innovator. But this doesn't align with reality, which tells us time and again that most innovation takes a team. And this is true when it comes to designing an internal developer platform as well. The internal platform can deliver exceptional value, but to reach its full potential, it makes sense to move away from developing platforms in single-player mode and go multiplayer mode to supercharge your internal platform. But what exactly does this mean?
While many organisations go full steam ahead with building an internal platform, they don’t always make use of all the resources and expertise they already have in-house. Instead, there are often various, often siloed, teams building platforms that solve their problems – but they aren’t communicating with other teams that could use and enhance the platform they are building. If it’s not multiple teams with competing or duplicative platforms, organisations sometimes pile the responsibility for developing a platform squarely on platform teams. But do these approaches address the pains organisations face and the challenges they aim to solve by adopting an internal platform?
A quick history: From DevOps to platform engineering
Historically, developers used to spend a lot of time waiting on operators to provide services or tools for them. This led to friction, delays and frustration. Developers and operators were isolated from each other and didn’t have a way to break down the silos that kept them from getting to productivity faster. Enter DevOps, which aims to empower teams to build and run everything for themselves.
DevOps works – and works well – until the point at which organisations scale and dual problems arise: first, DevOps teams end up grappling with repetitive and duplicative problems again and again, and second, the DevOps workload increases and accelerates as the business scales. This means that DevOps teams not only have a lot more work on their hands in the day-to-day but also have to manage considerably more complexity in trying to build and run everything from infrastructure to networking to CI/CD to observability. At the same time, DevOps teams navigate a host of internal processes and concerns, such as security and compliance. Naturally, cognitive overload is inevitable.
Slaying the DevOps dragon: Enter platform engineering
To solve the mounting DevOps challenges, platform engineering has emerged with a primary focus on providing a better developer experience. What does developer experience mean in this context? Reducing developer cognitive load and enabling devs to focus on their core work – which is delivering value to their customers. But to get there, it would be critical to also reduce the cognitive load and literal workload facing DevOps teams and streamline their work. Enter platform engineering and the introduction of platform teams.
This shift, however, hasn’t completely solved the problem. The cognitive load has just been transferred to platform teams, which are tasked with providing a customised internal developer platform that meets developer needs and offers tooling and services on demand. Yet platform teams end up supporting an already vast and ballooning set of tools and services and feeling the pressure of having to provide a delightful user experience for developers at the same time. The entire industry echoes the importance of the developer experience and developer flow when they build their software. And if this is true, how is it possible to get the most value and best experience from these internal platforms … without burning out the entire platform team or adding massively to their numbers?
Playing as a team
To get to greater and potentially faster value with the internal platform, start by considering how teams are organised and asking who should do what? We’ve seen in the experience of developers, DevOps and platform teams that no one individual or team should (or can) do everything. In the seminal book Team Topologies, four team types are described: stream-aligned (application teams), enabling teams, complicated subsystem teams and platform teams.
Where the internal platform idea starts to unravel is where stream-aligned teams have too much cognitive load and DIY as a part of their work. At the same time, with platform engineering, too much of the groundwork and maintenance shifts to platform teams, which in turn bulks up their workload.
Understanding these team types and dynamics, we can start to ask: How can we share the load and even involve other teams in the internal platform building work? How can we distribute the responsibility both more equitably and in a way that delivers maximum value?
Gaming the platform with the multiplayer approach
This is where the value of a multiplayer approach to platform building shines. While developers and platform teams hold a lot of the expertise needed to build an effective internal platform, the onus isn’t entirely on either one to create a useful platform that can garner near-universal buy-in and adoption. In fact, other teams in organisations can have a huge influence on platform development by injecting their own special skills, expertise and knowledge into the platform to benefit the entire organisation.
Ready player one
One example of injecting special skills and expertise into a platform includes, for example, cases where multiple application teams need to have access to a database. In an ideal world, developers would have on-demand access to, for example, a Postgres database as a service. They could provision one whenever they need to. Many organisations have a specialist database team internally that knows exactly how Postgres works, how it should be configured, and how those stream-aligned teams should consume it.
There is no reason why a company’s developers or platform teams should be required to have in-depth database knowledge when a subsystem team of subject-matter experts can easily offer this database-as-a-service option within the platform. Offloading the burden lets application teams get what they need from the platform, and platform teams can easily use the database-as-a-service option as a building block within the platform that they can package up with other services – all relying on the expertise of the database team.
Ready player two
A second example deals with a specialist requirement rather than a specialist tool. Security processes, for example, are requirements that must be built into many software delivery workloads – but it is likely that there won’t be enough security resources to embed in application and platform teams. Instead, the multiplayer approach lets security teams save the day by defining processes and embedding these within the internal platform.
Again development and platform teams do not need to understand all the ins and outs of security but can follow the steps and guardrails set by the security team as they are built into the workloads of the platform.
Everyone can play to make the internal platform more powerful
Taking specialist skills and knowledge bases from across the organisation and incorporating them in the internal platform in an easy-to-use way is an effective strategy for reducing cognitive load across teams.
We have seen this approach, sometimes called innersourcing or platform democratisation, be very successful. The key factor is making the most of the talents, skills and knowledge you already have within your organisation. This not only relieves cognitive load and prevents having to build a massive team or overwhelming a small team with too much information, but it also provides pathways to organisation-wide buy-in to and ownership of the platform.
How to get started with the multiplayer approach
As platform engineering is considered a sociotechnical practice, involving both people and technology, it is important to consider both. Consider again Team Topologies and the three interaction modes the book describes: Collaboration, X-as-a-Service and Facilitating.
Collaboration: Play nice together
To understand what a multiplayer internal platform could look like, teams should focus on collaboration to start with. They need to understand each other, build empathy and align. Collaboration is the best interaction type to understand requirements, such as what the application teams need, how they would like to consume the platform, and whether and how application teams might like to contribute tools and services they have developed themselves back into the platform.
The platform team should also collaborate with the other teams, in particular, the specialists who are providing specific tools and services. This helps build an understanding of what those services are, how they can be produced and contributed to the platform, and what those teams themselves need to consume from other teams. To facilitate this work, a short-lived enabling team focused on facilitation across the organisation might be useful for mapping connections and collaborations.
X-as-a-Service: Where multiplayer mode comes alive
Multiplayer mode really comes alive when the ability for teams across the organisation to contribute their expertise to the platform is activated. The platform team can help to make this happen. The end goal is getting collaboration to lead to expertise becoming X-as-a-service, on-demand tools and services.
Using the example from before, we can see that the Postgres database is being offered as a service within the platform, and it has security expertise contributed by the security team built into the platform. The consumers of the platform are now interacting with the platform in the X-as-a-service mode, which means that they are getting the tool they need on demand with enhanced security already embedded.
From a technical perspective, the platform team needs to consider how easy it is for other teams to contribute to the platform. Is it a black box that no one understands or is it easy for other teams to contribute? What is that process for contributing, and not only as a one-off upfront interaction but in an ongoing way to ensure that the platform remains up to date and fit for purpose? Is that process understood and documented?
This is one of the areas where a platform framework can support this multiplayer model and even enable multiplayer mode out of the box. If your platform is made up of composable building blocks that are contributed and maintained by expert teams, this further empowers the platform team to use these building blocks to compose paved roads or golden paths that can then be consumed by application teams to give them an even easier, smoother developer experience. And ultimately, potentially, the internal platform ends up being greater than the sum of its parts and becomes a driver for innovation.
Game not over: Switch to multiplayer for more tokens
Enabling a better developer experience and reducing cognitive load for developers and platform teams is at the heart of shifting to multiplayer mode. And while these teams stand to benefit most on the surface, a multiplayer-inspired internal platform can benefit from the entire organisation playing along.
By switching from a single-player to multiplayer mode, everyone can become an internal platform hero.
Comments