The platform model is an approach that we are seeing more and more in this space, stemming from the idea of a product team responsible for the end-to-end delivery of a product or service.
If applied to a single product, or several products, it works well. But if there are hundreds of products or services, it’s inefficient and expensive for each to have a single product team working on those products.
Imagine 10 teams, each with its own technology stack, tool chain, and process. Solving similar problems over and over again, spending too much time evaluating technology, integration, maintaining infrastructure, and so on. That time could be better spent building and improving the actual product the product team is responsible for.
The lack of standardized technologies and processes also creates other problems:
● Management becomes expensive and almost non-existent ● Standalone stacks reduce knowledge sharing across the organization ● Many product teams don’t actually have the capacity to run complete infrastructures and applications. Many developers see infrastructure operations as a distraction from their actual work, so they never really focus on it.
While having multiple end-to-end product teams doesn’t work well across large and complex environments, a platform model defined by clear goals, boundaries, and responsibilities can be a platform that users build in mind, greatly reducing the effort and overhead of a single product team.
Broadly speaking, platform teams provide the infrastructure, environment, deployment pipelines, and other internal services that enable internal customers (typically application development teams) to build, deploy, and run their applications. This is where Evan Bottcher’s definition of a digital platform can come in: “the foundation of self-service apis, tools, services, knowledge and support as a compelling in-house product. Autonomous delivery teams can leverage the platform to deliver product functionality faster and with less collaboration.”
Self-service is “a key feature of a good platform. Specifically, it should allow for self-service provisioning, self-service configuration, self-service management and operation of platform features and assets.”
The platform model is typically associated with the local cloud environment and applies to many other types of architectures throughout history. The main advantages are:
● Application teams can be more efficient. They don’t have to be an expert in infrastructure operations or have a deep understanding of every tool in the tool chain, so they can focus on the product. Application developers no longer have to wait for a centralized team to provide them with a test environment or cloud resources, and the resulting autonomy allows them to work faster.
● Improve management. If all your applications run on completely different infrastructure stacks and use different processes, you cannot effectively manage costs, compliance, and auditing. An effective platform enables efficient IT governance while empowering application teams to deliver quickly.
● End the environment switch. Constantly switching attention between application and infrastructure operations is a huge drain on productivity and creativity. Individual workers and teams are better off when they can focus on their particular environment.
● Continue to improve infrastructure. A common platform that provides customer-facing solutions, rather than just raw access to infrastructure, gives organizations greater flexibility. Consumers of the platform are not tied to the concrete implementation of the infrastructure stack, so the platform team can replace and upgrade components iteratively with minimal interaction with the application team.
Use of internal platforms
In the discussion of platforms, we use the term “internal platform” to refer to platforms built by and for organizations. We distinguish these platforms from those offered by external vendors — for example, many people think of AWS or other IaaS products as “platforms.” In our survey, we defined platform teams as those responsible for maintaining a self-service platform that other teams use to build and deliver applications or services.
We asked two questions to measure an organization’s use of internal platforms: • What percentage of your developers use self-service platforms?
• What services are available for self-service?
We found that platform use was very widespread among survey respondents. Sixty-three percent said they have at least one self-service in-house platform. Of those with internal platforms, 60% have between two and four. In almost a third of companies with an internal platform, between 26% and 50% of developers use the platform.