Internal Developer Platforms, or IDPs, are becoming increasingly integral as software development organizations come under more pressure to ensure their employees spend the majority of their time adding value to the company.
However, that’s not to say that your organization should be rushing to develop platform services of your own from scratch. If you don’t have a defined plan, goal, and ongoing commitment to support and maintenance, then your IDP project can easily end up resulting in the same busywork the platform was built to avoid.
Chris Ford and Cristóbal García from Thoughtworks joined us to talk about their eye-opening article, Mind the platform execution gap, and the things every business needs to consider before building an IDP.
Business value
The first step in building a successful IDP is ensuring that the business understands what value the project will bring to the wider organization. So, engineers planning such a project need to be able to argue the business value of the project. If they can’t, then Chris and Cristóbal argue that they shouldn’t be aiming to build a platform at all. Chris states:
“If you're committing to a platform, you're going to build it, you're going to maintain it, you're going to improve it, you're going to be there in a couple of years when there's a problem with it, and you've convinced your company to bet their future on it. If you're going to do that, you should have an argument in mind as to why the benefits outweigh the costs.”
It’s vital to bear the business value of this project in mind because the platform will not, and should not be expected to, deliver immediate value. In addition, it’s easy for platform engineers to get excited about the prospect of building an IDP, but they don’t always consider the need to maintain the product over an extended period, which is where the true value of the platform will lie.
Product thinking
Secondly, platform teams need to treat their IDP as a product and developers as their customers. Cristóbal explains:
“For the developers or the engineering teams to use our platform, they probably are going to need something more along the lines of a power grid. Instead of a new social network with shiny new features every day, they are going to favor stability and reliability over new buttons and features.”
However, it’s also important to understand that this methodology will always intersect with business value. It’s not just about creating a product that improves developer experience, but also a product that makes it easier to bring other products to market quicker.
Similarly, building a platform is less about what engineers want to build and more about what tools and features will be useful for developers. While platform engineers should understand the problem the platform is trying to solve, the platform will only be adopted within the organization if it offers benefits for developers.
Chris adds, “If you're genuinely using products and being led by the needs of the beneficiaries of your platform, that can sometimes lead you in surprising directions.” It’s this mentality that will drive the value that the platform brings because it will result in developing features that help adoption.
Operational excellence
Developers always need to be able to trust that the platform is reliable, no matter how the product changes over time or what services are connected. Cristóbal says:
“If my platform is super reliable, I can be super reliable, if my platform is not super reliable, I would need to be less ambitious. And many product decisions are also based on the assumption that whenever an incident happens, for instance, we are going to be able to manage it properly.”
Platform teams need to form realistic expectations for what their platform can do, both in terms of internal goals and in communications with stakeholders. Developers know that changing platforms and services is a risk, so platform teams need to know how to manage this risk to ensure the platform is adopted and generates value.
Chris adds “Where you’re doing something well, it’s a positive multiplier. But if you screw it up, your mistake becomes the whole company’s problem as well.”
With an IDP being a foundational part of an organization’s development cycle, platform engineers need to adopt Site Reliability Engineering (SRE) practices and define Service Level Objectives (SLOs) to ensure that they don’t break the trust of their stakeholders.
Software engineering excellence
With all of that being said, platforms need to go beyond operational capabilities. Even without custom applications, organizations need to expect that assets like scripts, configuration files, and templates will rapidly become more complex over time.
As part of this, Cristóbal talks about following Kief Morris’s Infrastructure as Code (IaC) principles - define everything as code, continuously test, and split everything into small pieces that can be changed independently. “That's something we advise to all interested groups. By following these guidelines, you can have shorter pipelines and faster feedback.”
Having excellent software engineers within the platform team is vital to ensure the platform meets its full potential. Not only that, but following these IaC principles will help those engineers get the platform infrastructure running and keep up with the changing needs of other development teams across the organization. Similarly, platform teams also need to understand that using internal products like an IDP places additional demand on product development teams.
Chris adds, “If your platform relies on ticket ops, it's probably going to struggle to look like an attractive option compared to direct usage of public clouds.” This won’t be a compelling experience for developers, so they’re more likely to look at external solutions.
Healthy platform teams
Finally, you need to take into account the health of the team building and maintaining this product. As concepts like cognitive load and psychological safety are becoming more understood and applied within engineering teams, these concepts must also be applied to platform engineering. Chris explains:
“When people quit, burn out, or have to take a holiday, the knowledge management of how to sustain this platform is lost. If the teams working to provide the platform aren’t sharing knowledge or preserving psychological safety, you aren't making room for junior or more junior people to learn the ropes.”
Even when organizations have a technically functional platform, the social operational cost of an IDP is something that can’t be ignored. Expertise across platform teams needs to be shared, not held within a handful of more senior individuals. Investing in onboarding, knowledge sharing, and documentation is a vital part of maintaining a healthy platform team.
5 steps to a better IDP
The first step to building a high-quality internal platform is understanding its business value for your organization, both in the short and long term. You also need to think of the IDP as a product so ongoing development and maintenance are always tailored to the customer - your organization’s developers.
Operational and software engineering excellence is vital to ensure that the platform is both widely adopted and delivers the value your organization set out to deliver. Finally, you need to strive to promote a healthy platform team by reducing their cognitive load and being aware of how burnout and stress can reduce the value your IDP brings to the business.
Thanks to Chris and Cristóbal for hosting this enlightening webinar. Make sure you check out their article here and watch the webinar recording for the full story. For more information on building a great IDP, take a look at our webinar with Alan Barr, Platform Product Owner at Veterans United Home Loans, as he walked us through how to build an IDP from scratch.
If you need assistance in building your platform, feel free to contact us at any time. We are happy to give you a demo on how an IDP can be built with Humanitec without any unnecessary detours.
