Platform engineering has emerged as a discipline to centralize configurations and standardize the DevOps process. As part of this practice, internal developer platforms (IDPs) are a key ingredient to establishing a paved road or “golden path” for developer users. But how do we ensure these IDPs are designed and rolled out correctly?

Well, the IDP concept is still relatively new, but some best practices are beginning to emerge. For example, treating the platform as a product helps encourage proper feedback. Reference architectures can guide initial designs. And testing first iterations with a single team can encourage buy-in around a proof of concept.

I recently chatted with internal developer platform experts, including Luca Galante, product and growth, Humanitec, and Markus Eisele, senior principal product marketing manager, Red Hat, to gather insights on how to best manage IDPs. Below, we’ll consider how to create golden paths that help optimize developer productivity and happiness and consider how these techniques affect the bottom line.

Start With a Reference Architecture

First, it’s a good idea to begin with a reference architecture when creating an IDP. This can help frame the initial infrastructure and its constituent components. For example, McKinsey recently debuted a sample IDP architecture, which has been reinterpreted for Azure and GCP. Platform engineering also maintains a tooling landscape that lists tool options for the various planes.

It’s good to note that an IDP is not a single product, like a platform-as-a-service. “An IDP is not a turnkey solution,” said Galante. “You can’t buy an IDP.” Therefore, there is not a one-size-fits-all enterprise-grade option that covers the entire stack. An IDP will most likely be a combination of open source and proprietary components.

According to Eisele, these new reference architectures are a good step in the right direction. “These IDP reference architectures are developer-centered views about modern application development platforms,” he said. “They shift the perspective from a sheer infrastructure perspective into what matters most for the developer.” And while a one-size-fits-all platform may not exist, the tools to build them do, such as Spotify’s Backstage or Red Hat’s Developer Hub, a platform for building developer portals.

Treat the Platform as a Product

Treating the platform as a product is another commonly shared best practice in platform engineering circles. “This is something that will make or break an IDP initiative,” said Galante. According to Galante, this platform shouldn’t be architected and then taught to developers in a top-down fashion—this can result in lengthy onboarding, broken functionality and ShadowOps.

Instead, successful platform teams take an existing team’s work and restructure it around a product manager to evangelize, said Galante. Another option is to keep your infrastructure team and develop a separate product team to start from scratch. Regardless of the exact organizational makeup, the product mindset is crucial for kickstarting and maintaining IDPs.

Have a Tight Feedback Loop

Part and parcel of retaining a product mindset is conducting research and having a tight feedback loop with stakeholders. For IDPs, this means understanding what developers need and not building on assumptions alone. According to Galante, all stakeholders should be given a voice, including DevOps teams, developer senior backend developers, junior front-end developers and even executives. Listen to these groups to understand their needs to frame the IDP correctly and sell them on the value of a platform. This is where the skillset of a PM is crucial to navigate these kinds of dynamics, he added.

“IDPs are about enabling developers,” said Eisele. While these tools should make them more efficient, they should also help them love their job more despite the cognitive load, he said.

First Attempt With a Lighthouse Team

Before rolling out a standardized internal development platform company-wide, it’s good to validate it in practice with a smaller group. Galante calls this a “lighthouse team.” Ideally, this team is more advanced with their deployment pipelines and is well-versed with cloud-native technologies, he said. This should help establish the right golden path with minimum friction and stress test it under real-world scenarios. After an IDP is validated in practice, rolling it out across other teams will be much easier.

Centralize the Platform Team Itself

Another facet to consider is the organizational makeup. Who will architect and support the IDP? Galante believes the platform team should be centralized instead of having various platform teams alongside each department or division, and such a team should consult various stakeholders throughout the application lifecycle. He also references Team Toplogies as a helpful resource for implementing platform teams.

At the same time, Galante admitted that at scale, large enterprises might spin up multiple platform teams simultaneously. Sometimes, this is done intentionally and could even bring positive competition to improve operations, he said.

Plan For Flexibility

Lastly, the big takeaway is that IDPs are not a silver bullet, and a reference architecture that works great for small agile teams might not transition well into a complex enterprise with much brownfield development. Furthermore, you run the risk of over-specificity, too, which could step on people’s toes.

Therefore, the platform must be flexible enough to adapt to new situations. Galante recommends first looking at your configuration management to see where the most time is wasted and ensuring you standardize the most common configurations.

Setting Golden Paths For IDP Success

Developer productivity practices have emerged as a response to exploding complexity in the last ten years, said Eisele. The old days are gone, and a brand new execution stack is required to architect and deploy applications. “All this led to a point where developers just want to get back to coding,” he said.

The golden path, or paved road as Netflix calls it, is like an approved path for traveling through the software development lifecycle. As Eisele puts it, it’s a form of best practices and a new way to replicate development knowledge across an organization.

“IDPs seem to be natural partners to cloud/standardized developer environments (CDE/SDEs),” said Ivan Burazin, CEO and co-founder at Daytona. He pointed out how Uber’s developer satisfaction increased dramatically upon adopting a platform called DevPod, an integral part of their IDP. He also cites successful CDE implementations at AirBnb as further proof of the power of internal developer platforms.

But to create these golden paths, IDP architects have their work cut out for them. They must juggle the input from multiple stakeholders and simultaneously balance complexity and abstraction effectively. The platform itself must be specific enough to reduce developer cognitive load yet generic enough to be flexible for outliers.

Thankfully, the aforementioned tools and best practices should help efforts toward designing golden paths​​ for your internal developers. The next step will be testing the platform and measuring the success of these initiatives.