An Internal Developer Platform (IDP) has the potential to dramatically improve developer productivity. It does so by reducing cognitive load on developers via abstractions, killing waiting times by enabling self service. This seems like a win all round, and it is in the vast majority of setups and for most applications. But there are some apps where an IDP might also not be particularly helpful. This article will give you a clear overview on where an IDP makes sense and where it does not.
As with any transformation project, there are upfront costs associated which need to be paid (investment) in order to gain benefits (return). The Return on Investment (ROI) of an IDP varies greatly depending on the types of teams being served, the technology stack the application runs on and the maturity of the applications themselves. Any reasonably mature enterprise will have applications and teams that cover the full spectrum of modern stacks and cloud native all the way to legacy and on-prem or bare metal. Some apps will be actively developed and some simply in maintenance mode. The ROI of an IDP will therefore be very different across the possible combinations of applications (actively developed vs maintenance) and tech stack (cloud native vs legacy).
Where does an IDP have the biggest impact?
IDPs make the biggest impact where there is a high degree of change both in software and the infrastructure that it depends on, as well as for applications that are complex to operate.
Provisioning and managing infrastructure is normally a large source of cognitive load for development teams. This, combined with signoff and review processes common with traditional infrastructure management, leads to slow cycle times and reduced developer velocity.
Modern cloud native applications often promote loosely coupled, microservice based architectures. These encourage fast interaction on small components but tend to result in a large number of moving parts. This complexity also increases the cognitive load of developers working on such applications.
IDPs therefore have the biggest impact on actively developed cloud native applications. The ROI is high because the initial work to train developers on the new IDP, onboard applications and bring in infrastructure is more than paid for by the reduced cognitive load of developers.
Where does an IDP have the least impact?
Conversely, applications that change very little will not generally have great ROI from using an IDP. A good example is legacy applications that are in "maintenance mode". That is, they only receive bug fixes and security updates, not new features.
The main reason for low impact is that the investment to train up developers working on these apps, onboard applications and bring in infrastructure is high and developers will tend to not have much need to make use of many of the features of the IDP.
Developers working on legacy applications are usually very familiar with the processes required to update and work on their applications. Infrastructure tends to be static and for older applications it’s usually not managed via modern methodologies such as Infrastructure as Code (IaC). This means that work required to bring these applications onto an IDP is often much higher than for modern cloud applications. The developers will have to learn a new system without gaining much of the benefit, which leads to low ROI.
How can you decide: ROI-based rollout
The quadrants below summarize what I have described above and can be a helpful guide to think through which applications you want to onboard to your Internal Developer Platform.
The differences are of course sometimes not as marked, for example when an application is running on legacy systems but it’s still actively developed, yet not as much as other newer ones. So you’ll have to always weight all different factors on an app by app basis.
There is also something very pleasing about having a common platform that can be used by all developers in an entire organisation. However, if the ROI does not work out, it might be worth excluding low ROI apps from the platform initiative.
Given different apps will have different ROI it probably makes sense to base the order that they are onboarded onto the IDP based on highest ROI first. This means that the IDP delivers the highest value first and then more marginal apps can be added over time. At some point, the ROI might also no longer pay off.
Using shared metrics and established frameworks such as our Minimum Viable Platform (MVP) approach can be very helpful in guiding your decision making and rollout plans. If you have any questions or want to design an adoption plan for your IDP, speak to our Platform Architects.
