implementation of DevOps has been going on for ten years and shows no signs of slowing down. In Forrester's 2024 Developer Experience Survey, 87% of developers indicated that their organizations have already implemented DevOps practices or plan to do so in the next year.
But for many organizations, scaling DevOps practices has it was difficultcostly and ultimately insufficient to achieve the results leaders expect. These organizations are starting with a grassroots approach to DevOps adoption, where each team independently selects its own tool chain, creates its own best practices, and implements its own institutional knowledge.
Forrester clients tell us that this team approach doesn't work at scale. It creates as many problems as it solves, but does not produce the results that senior management expected.
For example, special toolkits create headaches. Organizations that have adopted this approach are now saddled with too many unique toolkits, each requiring support from the same developers who must build customer-facing products. These toolchains also require unique automation, create locked-in institutional knowledge, encourage tool sprawl, and limit any chance of mass pricing of DevOps tools.
All of these factors create headaches for IT managers trying to reduce overhead costs while increasing productivity and efficiency.
Many organizations now understand that improving the developer experience increases efficiency by removing bottlenecks from the development process. Prominent among these obstacles is unnecessary context switching, which disrupts developer concentration and reduces flow.
Disabled automation tools, multiple accounting systems, and multiple platforms slow down developers' work, forcing them to play hopscotch with multiple tools. Without a common platform as a foundation, when developers change projects, they may go through entirely new onboarding processes to access the repositories and commit to their first pull request.
The lack of standardized practices also causes management problems. Without a standard approach to software delivery, you end up with a system of ad-hoc management that is implemented differently depending on the tool set. This creates trust barriers between developers and enterprise management teams, can add manual oversight and bureaucratic red tape that slows down processes, and hinders efforts to improve productivity and efficiency at scale.
Another problem software developers face is that the traditional IT service catalog is a heavyweight solution. Many organizations have had service portals for many years, based on IT and enterprise service management practices and based on products such as ServiceNow, Atlassian Jira Service Management or BMC Helix.
These tools remain because they often serve non-technical users and can be used by traditional infrastructure organizations for ticketed offerings. However, developers believe that application processing is too slow and unresponsive, so a market for specialized internal developer platforms (IDP).
Scalable platform for services
IDPs provide the foundation for creating an IT platform on which services can be defined, automated, and delivered across the enterprise.
Examples of IT services that might be included in an IDP include provisioning a new piece of infrastructure, such as a new virtual machine, instantiating an automated continuous integration/continuous delivery (CI/CD) pipeline to build and deliver code, or scaffolding a new microservice project using the organization's best practices.
Internal developer platforms provide the foundation for building an IT platform on which services can be defined, automated, and delivered across the enterprise.
Forrester
IDPs make it easier to manage and access service automation by providing a framework for managing and unleashing automation at scale.
IDPs can provide visibility to tools and frameworks. One of the features of the IDP is scorecards that provide information on both the technical and commercial performance of technologies. This helps developers make smart choices when faced with multiple platforms and also gives executives insight into implementation.
Adopting new tools becomes clear to management, as does moving away from old technologies, allowing leaders to move away from legacy components and remove them when it makes business sense.
At a high level, IDPs can serve a role similar to a traditional platform as a service (PaaS), providing an abstraction layer for IT infrastructure services. However, while many PaaS implementations have opaque abstraction layers, IDPs offer a transparent layer through service definition files that allow developers and infrastructure engineers to view, reuse, and improve the underlying abstraction mechanisms.
Platform developers need to understand these differences to determine which abstraction model will best meet their needs.
Role behind the scenes
Behind the scenes, IDP who Spotify donated to the Cloud Computing Foundation (CNCF)was one of CNCF's most downloaded apps in 2024. The topic of Backstage implementation brought together a full day of presentations and user stories at CubeCon 2024.
There are several reasons for its adoption. Spotify has a reputation for being a revolutionary engineering process. Many organizations have adopted Spotify's now famous model of squads, tribes, and guilds. Having Backstage as part of the CNCF ensures governance and a healthy community of members and followers. An increasing number of commercial DevOps tool vendors support Backstage plugins. Best of all, because Backstage is open source, developers can download and try it out for free, further increasing interest in platforms in general.
Before deciding on an IDP, IT leaders must develop a compelling business case that describes what benefits an IDP will bring to the organization and how it will measure them.
Forrester
Many teams assumed or hoped that Backstage was a ready-to-use platform, but were soon overwhelmed by its complexity. This provided an opportunity for commercial software providers to differentiate their offerings from Backstage. These commercial tool providers say their products are easier to get started with, require less training, and offer Backstage technological advantages such as a level of service orchestration.
Spotify also offers Backstage as a paid commercial subscription that includes product support, additional plugins, and no-code capabilities that help businesses get started faster and with more confidence. Users see these commercial add-ons, such as Soundcheck (a plugin that helps teams visualize service quality, safety and reliability checks), as additional benefits.
Before embarking on an IDP, Forrester recommends that IT leaders develop a compelling business case that describes how an IDP will benefit the organization and how it will measure them. Developing a comprehensive business plan will ensure alignment between the stakeholders funding the platform initiative and those responsible for creating it.
Forrester found that almost every IDP company and end user that has successfully built an IDP started small, creating a proof of concept (PoC). The first implementation can take from several weeks to months.
Forrester recommends that IT leaders first identify a team that is willing to collaborate and sees the benefits of an IDP approach. Then build a PoC around the critical needs of multiple participants, while asking them for additional suggestions and even their own input to improve the IDP. This approach can be used as a springboard for other teams to further develop IDP sustainably.
