Platform engineering is one of the most important software engineering trends right now. It was featured on Gartner’s Top 10 Strategic Technology Trends for 2023, landed on Gartner’s Hype Cycle for Software Engineering in 2022, and has a rapidly growing community of 15k practitioners and enthusiasts around the world. PlatformCon, the first-ever platform engineering conference by and for platform engineers, got over 22k attendees in its second year. 

Folks are excited about platform engineering because it promises to solve some of the biggest problems facing software engineering organizations in the cloud-native era: The high complexity of tech and tools which inhibits developer self-service and feeds ticket ops. This contributes to much frustration for developers and Ops and slow innovation for the organization. Platform teams can solve these problems with a platform as a product approach. 

What is platform engineering?

According to Luca Galante, platform engineering is “the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. Platform engineers provide an integrated product most often referred to as an ‘Internal Developer Platform’ (IDP) covering the operational necessities of the entire lifecycle of an application.”

According to Gartner VP Analyst Manjunath Bhat there are three key pillars that define how and why to build an IDP:

1. Improve developer experience (DevEx) by building IDPs to reduce cognitive load, developer toil and repetitive manual work.
2. Platforms don’t enforce a specific toolset or approach. It is about making it easy for developers to build and deliver software while not abstracting away useful and differentiated capabilities of the underlying core services.
3. Platform engineering teams treat platforms as a product (used by developers) and design the platform to be consumed in a self-service manner.

What does platform as a product mean?

A platform as a product approach sits at the core of platform engineering. As Manuel Pais, co-author of “Team Topologies,” explained in his keynote at PlatformCon 2022, successful platform teams treat their IDP like any other product. This approach ensures that a platform team builds an IDP developers actually want to use and that can deliver value to the organization.

All IDPs will look different, but those that are treated as a product will have some common characteristics.Thoughtworks’ Evan Bottcher shared some ideas in this article from 2017:

1. The platform is self-service for the overwhelming majority of use cases.
2. The platform is composable, containing discrete services that can be used independently.
3. The platform does not force an inflexible way of working on the delivery team.
4. The platform is quick and cheap to start using, with an easy on-ramp (Quickstart guides, documentation, code samples, etc.)
5. The platform has a rich internal user community for sharing.
6. The platform is secure and compliant by default.
7. The platform is up to date.

Following a product approach ensures that the platform team will build a compelling IDP. To this end, they must define the platform team, conduct user research, create a roadmap, and establish tight feedback loops between platform engineers and developers. 

Define the platform team

It is important for organizations to differentiate the platform team from the site reliability engineering or ops organization. In 2017, Thoughtworks Technology Radar pointed out that “organizations that consider establishing such a platform team should be very cautious not to accidentally create a separate DevOps team, nor should they simply relabel their existing hosting and operations structure as a platform.” The platform team should be considered its own product team, working to ship the IDP to its internal customers.

Defining the platform team’s mission statement can help differentiate it from other teams. Good mission statements are emotional and inspiring, simple but meaningful, match the longevity of the organization, and are informed by user research.

Original graphic inspired by Humanitec’s 2023 DevOps Benchmarking Report

Dedicated product managers are key to successful platform teams. Product managers do different work than developers or engineering managers. They dedicate most of their time to understanding developers’ workflows and pain points. They also build and maintain the relationships the platform team needs to receive valuable feedback from all stakeholder groups, not just developers.

Organizations sometimes hesitate to hire product managers or assign them to the platform team because of the cost. However, platform teams without product management capabilities have a higher risk of building based on assumptions instead of research. As OpenCredo’s CEO/CTO Nicki Watt discussed in her PlatformCon 2023 talk, it can be tempting to assume that platform teams automatically understand internal users’ needs better than they would external users. However, internal developers require the same consideration as external users. When platform teams make too many assumptions, they build an IDP that isn’t compelling to their developers and doesn’t meet their needs. Dedicating a product manager to the platform team is significantly cheaper than building an IDP developers don’t want to use. 

Conduct user research

Platform teams need to gain a comprehensive understanding of their developers’ unique pain points (and what is already being done to mitigate them) in order to build a compelling platform. They accomplish this by conducting user research as the foundation. Members of the platform engineering community shared a few examples of how they surveyed developers at their organizations. 

Platform teams should ask questions that provide insight into the full software delivery lifecycle, from the planning stages to debugging and testing. A platform product manager helps translate conflicting perspectives and feedback into an actionable set of priorities. 

Create a roadmap aligned with key priorities

Your roadmap should not be confused with a backlog of “nice to haves.” Instead, it should be aligned with your mission statement and supported by data gained from research.

Successful platform teams start small and strong by leveraging lighthouse teams. A lighthouse team is the first group of people for whom the platform team chooses to build the organization’s IDP. The platform team identifies then focuses on solving a common problem the lighthouse team shares with the rest of the organization. The platform team also cultivates ambassadors within the lighthouse team to evangelize the IDP to the rest of their team and organization. Once the IDP provides real value to the lighthouse team, the platform team can repeat this process with more teams.

Platform teams should also architect their IDP in a way that drives standardization by design across the entire software development lifecycle. The best way to do this is by building the IDP around a Platform Orchestrator. The Platform Orchestrator enables Dynamic Configuration Management (DCM) to standardize configuration, provide a clear separation of concerns, and improve DevEx. Only after this should platform teams invest in the abstraction layers exposed to developers. As Aaron Erickson writes, “while it might be a good idea to provide developers with their own dedicated portal to unify developer experience, a UI by itself doesn’t actually improve your delivery setup and just doesn’t deliver much value to your org, if any at all.” Successful roadmaps prioritize the IDP’s core functionalities over interfaces.

Invest in tight feedback loops

Initial user research is not a substitute for sustained user feedback. Platform teams should ensure that users find the product compelling and useful by creating tight feedback loops from the very beginning.

In her PlatformCon 2022 talk, SuperAwesome’s Olga Sermon shared how her team used Requests for Comments (RFCs) to gather feedback from developers. An RFC is a document that states the problem the platform team would like to solve, the goals and use cases for the solution, and a list of possible solutions. Only at this point would the platform team ask developers for feedback. If the problem, use cases, and solutions were confirmed to be viable, then the platform team would research and deploy one of the proposed solutions.

Platform teams can also leverage established concepts in product management, like the Net Promoter Score (NPS). 

Build or buy?

If an IDP is a product, can organizations just buy one instead of building it? The short answer is no. An important part of a platform as a product approach is that successful IDPs cannot be bought and have to be built (although not necessarily from scratch). 

Unlike an IDP, a Platform-as-a-Service (PaaS) can be bought, and is what some organizations choose instead of building an IDP. PasS describes one tool that covers parts of CI, CD, environments, infrastructure, and developer interfaces (UI or CLI). Its feature set also covers several of the planes that make up an IDP. This approach might offer lower upfront costs and time savings. But it also comes with some hefty limitations such as lack of customization, vendor lock-in, and potential legacy technology integration headaches.

Whether an organization benefits more from buying a PaaS or building an IDP depends on context. A small startup that wants to deliver an MVP but lacks the resources for a DevOps team might benefit from a PaaS. A stable organization with no DevOps issues, less than 30 developers, and no need to scale can also consider a PaaS.

However, for larger organizations and especially for enterprises, it’s extremely unlikely that any one-size-fits-all solution will fully integrate with legacy tech. Enterprises inevitably learn that building an IDP using a platform as a product approach is better than buying a PaaS.

Building an IDP ensures that the platform works with a brownfield setup, offers more freedom and flexibility over infrastructure, helps save money in the long run, and avoids vendor lock-in. However, enterprises do not need to (nor should they) try to build their IDP entirely from scratch. According to results from Humanitec’s 2023 DevOps Benchmarking Study, top engineering organizations leverage a combination of open source and vendor tools to create their platform.

The IDP reference architecture developed by the team at McKinsey illustrates what this might look like. The diagram below is an example of an AWS-based setup, but all of the tools included are interchangeable. Similar reference architectures can be implemented for GCP, Azure, OpenShift, or any hybrid setup. Most importantly, platform teams should prioritize incorporating whatever components their organization’s setup already has in place.

For more information about the build vs. buy question, check out this blog post.

Key features of an enterprise-grade Internal Developer Platform

Based on our research of hundreds of enterprise organizations, IDPs should provide these key features:

1. Automatic documentation of configuration changes 
2. Full version history of all app and infrastructure config changes
3. Integration with UIs and service catalogs 

Without these capabilities, an IDP Most likely cannot scale to meet the needs of enterprise.

A Platform Orchestrator is the core of any enterprise-grade IDP and should be another key feature for your platform. It enables Dynamic Configuration Management (DCM), which allows developers to deploy workloads to multiple environments without needing to maintain or manage environment-specific configurations. 

The Orchestrator follows a “Read”-”Match”-”Create”-”Deploy” pattern. It reads the description of the workload and its dependent resource (workload specification or Score file) from the CI pipeline. Then, it identifies the context and matches the correct rules provided by the platform team. After matching the workload specification from the developer to the rules and defaults provided by the platform team, the Orchestrator generates the app- and infrastructure configs. In the last step, the Orchestrator creates or updates the resources and deploys the workload. 

An IDP built with Humanitec’s Platform Orchestrator provides organizations with the flexibility they need to integrate with UIs or support git-based workflows. A service catalog can be easily integrated on top of the platform to provide more specialized UIs for dedicated user groups. 

Conclusion

Platform engineering is continuously evolving. However, following a platform as a product approach will always be a core component of a successful IDP. By investing in user research, building out a product roadmap, defining a clear mission, and establishing continuous feedback loops, platform teams can avoid the pitfalls of faulty DevOps implementations and meaningfully improve DevEx.

For more insights on the platform tooling landscape and best practices, check out the State of Platform Engineering Report.

‍