TL;DR: What is platform engineering? Isn’t that just old Dev vs Ops thinking? What is the Platform Operating Model?
A platform operating model is:
“a business model that creates value by facilitating exchanges between two or more interdependent groups, usually consumers and producers.”
Applying DevOps thinking, we can adopt that model internally to organisations, by considering a platform team as the producers of the platform service to a range of consumers – the value-stream oriented product teams.
Value stream-aligned teams focus on a single value (or revenue) stream, because that singular laser focus on the success of their product maximises the return on investment. However, it’s not efficient or effective for each stream-aligned team to use and maintain all the underlying technology beneath it.
In the old days, we might have addressed this with a separate Ops team who provided the infrastructure, but that (as we know) caused inefficiencies, bottlenecks, and created “walls of confusion” when applications were thrown over from Dev to Ops in order to run in production. Instead, modern platforms allow stream-aligned teams to consume platform services in order to run their own workloads. The stream-aligned team “pull” services from the platform team, instead of “pushing” the application over to an operations team.
An effective platform engineering capability achieves an economy of scale by allowing multiple stream aligned teams to consume the same platform, but primarily aims to improve *flow*, and reduce the cognitive load of developers using the platform.
So, what is a platform?
“A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.”
From Evan Bottcher, 2018
https://martinfowler.com/articles/talk-about-platforms.html
And what is a product?
A product simplifies something for the consumer, solves a market problem and/or addresses a customer’s need or desire. In the case of an internal platform, the market is an internal market, and the customer is the stream aligned team(s). This is also why an organisation may create multiple platforms and platform engineering teams: different stream aligned teams have different needs, and to meet all those needs, a platform would end up being too large, cumbersome and bulky, like a huge swiss army knife with a hundred features when you only need a knife.
Amazon’s founder, Jeff Bezos, once said, “Your goal should be to create value for everyone you interact with.”
A product is:
- Coherent
- Evolving
- Long lived
- Supported
- Owned
- Designed with the user (customer) in mind
- And it’s worth noting that all products also have *names*
In most organisations, a product also requires a Product Owner, who is responsible for translating business strategy, product vision, customer needs and preferences, and balancing these priorities against non-functional requirements, proactive preventative maintenance etc. A platform should be no different in this respect: without a product owner, the platform may drift away from what is most valuable for the business and the users of the platform, costs of running it may increase beyond the ROI of its utility, and it may suffer from feature sprawl, technical debt, poor reliability and unplanned work.
Let’s draw out some of those words from Evan’s definition.
APIs, tools and services:
This means that it’s not just “one” technology. A single platform may possess multiple options for use, multiple optional features and functions. One user may use a completely different suite of features than another, but they’re both consuming the same product.
Knowledge and support:
A product doesn’t just get given to the consumer without any support or guidance about how to use it. Of course, it should be as usable and fit for purpose as possible without extra instructions or guidance, but just as you should be able to get into a modern car and drive it without referring to a manual, it still comes with a manual to help you realise the maximum benefit of the product. And more than that, a product come with a support team – who you can reach out to for help when you need it. A support team isn’t just there to process support tickets – they work with users of the product to help them make the most of it *and* gain essential and valuable feedback to drive the evolution of the product.
A “compelling internal product”
A platform is “A curated experience for engineers.”
Thanks to Matthew Skelton and Manuel Pais for this term.
There are two key points to make here – one is that the product consists, as we described above, of tools, APIs, documentation, services, alongside support and advice on how to use it. It consists, essentially, of everything required to make that experience as positive as possible for engineers to get their job done.
One of the primary goals of platform engineering is to reduce the cognitive load of the engineers and developers using it. Users of the platform are solving complex problems, and the more that any of their attention is taken in working out how to access something, how a feature works, what the API specification shows, or anything else, the less of that cognitive capacity is spent on addressing the business problems that they’re tasked to solve. The more that the platform can allow people to maximise their *germane* cognition, reducing extraneous cognitive load, the better the end result. The safest cars are also those that are easiest to drive, because we can spend more of our attention on the actual task of driving safely.
The best platform therefore, provides just what the stream aligned team needs, nothing more, and reduces the cognitive load of the people using it. It evolves according to feedback from the users of the platform, “competes” with other platforms in the organisation to be the best one to use (the compelling internal product), is owned by the platform team, and has a cool name.
Funding Models:
Funding for platform engineering typically falls into two categories: operational funding and project funding. Operational funding is used to maintain the existing platform and deliver continuous service to users. This includes the costs of hosting, licensing, monitoring, and supporting the platform. Project funding, on the other hand, is used for new developments and expansions of the platform. This could include the development of new features, integrations, or scaling efforts.
In many organizations, funding is often allocated based on the value a platform brings to the business. This means that a platform that supports high-value or high-revenue generating teams might receive a larger slice of the budget. However, it’s crucial to ensure that funding decisions consider the long-term sustainability and evolution of the platform, rather than just immediate revenue potential.
Organisation Structure:
In terms of organisation structure, platform engineering usually sits at the intersection of technology and business, providing a bridge between technical and non-technical teams. The platform team is often composed of cross-functional roles such as product owners, engineers, architects, and designers, each with their own specialities but sharing a common goal – to build and maintain a robust, efficient, and user-friendly platform.
This team often works closely with other teams in the organization, known as the stream-aligned teams, to understand their needs, deliver the necessary platform services, and gather feedback for future improvements.
Overall, the organization structure, governance, management, and funding models for platform engineering all aim to foster a collaborative, customer-centric environment. The goal is to provide an effective platform that reduces the cognitive load on its users, allowing them to focus on delivering value to the business, and evolves in response to feedback and changes in the business environment. It’s a dynamic, ever-evolving process that requires a commitment to continuous improvement and customer satisfaction.
Summary
Platform engineering, under the guidance of a strategic leadership team, functions as a bridge between technology and business in an organisation, aiming to provide robust, efficient, and user-friendly platforms. This is achieved by a cross-functional team, including a product owner, who is responsible for the platform’s evolution, balancing operational maintenance, and prioritising feature development. Funding is typically bifurcated into operational and project-based categories, with allocation decisions influenced by the value a platform brings to the business and its long-term sustainability. The organizational structure promotes a collaborative environment, with platform teams working closely with stream-aligned teams to understand their needs and provide necessary platform services. The ultimate goal is to reduce cognitive load on users and allow them to focus on delivering value to the business while ensuring the platform evolves responsively to feedback and business environment changes.
