Define the problem space

As you head towards defining your internal developer platform, it's critical to define thinnest viable platform (TVP) first. This is a variation of the idea of a minimum viable product (MVP) in classic product management.

In Plan and prioritize, you can learn more about defining (or enhancing) your TVP. But before we get there, this diagram can help you orient your thinking on how you can evolve over time. Keep in mind that your organization's top problem may cause you to deviate from what is described here due to your existing investments or organizational needs. Critically, you don’t need to move on to the next stage unless your organization needs it.

If you are starting from scratch, this represents a common progression. In the early stages, focus on discovery of needed capabilities, fit-gap analysis of shrink-wrapped products, and creating the minimal number tools or platform capabilities. Next, as you scale, you'll likely begin to focus on reusability and guiding people down predefined paved paths with reusable assets. Finally, you move towards a consumer-like "digital store" model to make it easier to build and maintain applications. You should follow a product mindset throughout, so we don't recommend jumping to the end and your specific journey vary. These final stages most resemble shrink-wrapped “product” in the traditional sense, but this is a destination, not a starting point.

Given the sheer size of this topic, we recommend breaking down how you talk about platform engineering into four topic areas. Categorizing your thinking this way can simplify how you establish and communicate a plan for your investments over time. These areas are:

• Engineering systems: A curated mix of DevOps suites such as GitHub and Azure DevOps and other developer tools and services. Beyond critical DevOps tools and services like CI/CD or package management, this area also includes capabilities used directly during the coding process like cloud-based coding environments, code scanners and liters, and AI assistants like GitHub Copilot.
• Application platform: A curated selection of services (such as IaaS, PaaS, and observability) that target each "app stack" (class of application, app model, languages) that an organization wants to use to deliver business value. This includes a mix of app stack specific services along with common services used throughout. An example of an application platform could include Azure Container Apps, Cosmos DB for storage, Azure Key Vault for secrets, for identity and role-based access control, Azure Policy for compliance and auditing, observability through Grafana, and a related network topology.
• Application templates: A set of well-defined, organization created, quick start templates that encapsulate start right and stay right guidance for a given application platform, language, and set of engineering systems. They can reference other centralized templates and provide starter code, API and SDK references, CI/CD pipelines, tooling configuration, and more.
• Developer self-service capabilities: This is the glue for your platform engineering effort. It's a combination of APIs, orchestrators, a catalog, templates, and user experiences designed to reduce developer toil and allow development teams to self-serve and be more autonomous, while still adhering to selections and guidance/governance from the previous three areas.

Plan and prioritize