Starting Your Internal Developer Platform Journey
Starting Your Internal Developer Platform Journey
If you work in the Tech industry, whether you provide a service or deliver a product, you have probably heard of the new Internal Developer Platform or Platform Engineering trend. Platform Engineering revolves around enabling self-service for developers by providing tools and workflows and integrating them into an IDP. You might be one of the lucky ones who is adopting the trend in your organization and seeing first-hand the results of that adoption.
But what if you are not? How do you start? And is it necessary to adopt this new trend? This post aims to shed some light on how to start this journey and whether it makes sense to you and your organization.
What are IDPs?
I explained what constitutes an IDP in my previous blog post, so please read that for more information. But in short, an IDP (Internal Developer Platform) is a simplified interface that offers a specific set of tools and resources with ease and efficiency.
This trend, like any other in the tech world, has advantages and disadvantages, usually depending on your use case. This post can assist you in finding a path toward adopting an IDP — especially if you have no clear guardrails for development teams, high operational costs, and other pain points.
Know the problem before the solution
Since the rise of DevOps teams within organizations, many issues related to the rate of deployment, build automation, and time to market have been solved (to a certain extent). Organizations then transitioned to end-to-end development teams fully responsible for their applications from ideation to production.
This transition introduced a host of new problems that might resonate with you: the lack of unified tooling, no defined standards for security, monitoring, logging, documentation, and compliance. This has created a fragmented landscape, resulting in varied experiences for developers, higher barriers to entry for newcomers, elevated operational costs, and an underperforming organization that becomes slow to respond to any compliance or governance change.
If you face this at your organization, then an IDP might be the light at the end of the tunnel.
Start with the people, not the tools
Using and adopting new tools is usually filled with excitement. It is the same feeling you have when your favourite game drops. You are excited to try out all the latest features and different scenarios and progress as much as possible.
However, when starting with IDPs, do your research. Are you looking to build your own from scratch or buy a SaaS solution? With all that, you tend to forget the most important aspect of this change: the people. They should be your starting point. Your developers, who are your primary stakeholders, will shape your IDP.
Listen to them, collect their feedback on the current processes, and evaluate where the gaps are. Providing a quick win for developers by standardizing a long-term blocker will gain you a lot of momentum and buy-in from them.
For example, you could provide a standardized way for developers to run a security scan for their Docker images in their existing CI/CD pipelines without changing their way of working much at all. Offering this process as a self-service product where it is maintained, versioned, has clear documentation, and is always available could be your first step.
Afterward, start identifying enthusiasts in different development teams who can help create comparable products to make developers’ lives easier. Whenever you gain traction and your small team of enthusiasts is growing, look toward forming this central platform team that will start maturing your existing products and creating new ones.
By now, you might have noticed that I have used the word product multiple times. If you are wondering why, it is because you can increase the success rate of your IDP journey by treating the IDP as a product.
Make the developers your main stakeholders and use their feedback to shape your roadmap. If you follow this mindset, you will go a long way toward success.
Measure your successes (and your failures)
As with any high-quality product, having clear metrics is imperative to identify whether it is working, if you need to pivot, or if it is a complete disaster.
The metrics that make sense will depend on the product you publish to your developers, but common ones are deployment frequency and onboarding time (be it new or existing teams onboarding the platform), to name just a few. Another way to measure success is by surveying your customers and extracting the results to determine the success.
The assumption is that you have exposed one product and are starting small. The metrics relayed back decide where to go next and how to start scaling the IDP.
Cultivate your community
We now have a successful product that is being used and is enhancing the developer experience. You might be asking yourself: “What should I do next?” For more information on what developer experience means, please refer to this informative blog by my colleague Rene van Osnabrugge.
Next is raising the visibility of the IDP and its value so that you can refine the future vision. Publish the surveys and metrics you collected before to the organization and highlight these success stories. Recruit evangelists who help promote the IDP and continue gathering developers’ requirements to determine what your next product should be.
When you establish this process of a short feedback loop, understand what your main stakeholders require, and then cater to their needs, you are well on your way to increasing adoption and engagement and making this journey enjoyable and effective.
Be mindful of maintenance, however. You must stay on top of regular patches and updates for the components of your existing products. Being transparent regarding these updates and communicating the changes beforehand, with clear documentation on what is changing, provides confidence to the developers to keep using the products and prevents losing the momentum behind your transformation journey.
Expand your vision
The transformation train is roaring throughout the organization, the IDP is scaling well, and you are on top of your roadmap. Your primary stakeholders are happy, and the significant productivity and developer experience changes are visible throughout. Congrats on this outstanding achievement! But it does not stop here.
As with all products, your IDP will go through a lifecycle, so keep collecting metrics that give you clear insights into your IDP and plan accordingly. Having one eye on industry trends ensures that your IDP stays relevant and effective.
Building a community around your IDP where your stakeholders share their success stories, the challenges they face, and assist each other is a great sign that you have succeeded.
Conclusion
The journey described here is a massive undertaking, and being armed with all the necessary knowledge and tools enhances your chances of success. I highly recommend reading more about this topic, both success stories and failed attempts. Finally, here is some personal advice from me: Read Team Topologies by Matthew Skelton and Manuel Pais, which has a wealth of information on how to form your teams, and follow platformengineering.org, which also provides excellent content around Platform Engineering.