Forrester: The role of internal developer platforms in DevOps | Computer Weekly

DevOps adoption has been going on for a decade and shows no signs of slowing. In Forrester’s 2024 developer experience survey, 87% of developers indicated that their organisation had already adopted DevOps practices or planned to do so in the coming year.

But for many organisations, scaling their DevOps practice has been complicated, expensive and, in the end, insufficient in delivering the value leaders had expected. These organisations start with a grassroots approach to DevOps adoption, with each team self-selecting its toolchain, creating its best practices and infusing its institutional knowledge.

Forrester clients tell us this team-based approach breaks down at scale. It creates as many problems as it solves and does not deliver the results the C-suite was expecting.

For instance, bespoke toolchains create headaches. Organisations that took this approach are now saddled with too many unique toolchains, each requiring nurturing by the same developers who are supposed to be building customer-focused products. These toolchains also require unique automation, create trapped institutional knowledge, contribute to tool sprawl and limit any chance for volume DevOps tool pricing.

All these factors create headaches for IT leaders trying to reduce overheads while improving productivity and efficiency.

Many organisations now understand that improving the developer experience increases efficiency by removing impediments to the development process. High among those impediments is unnecessary context switching, which breaks the concentration of developers and decreases flow.

Disconnected automation tools, multiple systems of record and multiple platforms slow developers down by forcing them to play hopscotch with numerous tools. Without a common platform as the backbone, when developers change projects, they may go through entirely new onboarding procedures to get access to repositories and commit their first pull request.

The lack of standardised practices causes governance issues as well. Without a standard approach to software delivery, you end up with ad hoc governance implemented differently depending on the toolchain. This creates trust barriers between developers and enterprise governance teams, can add manual oversight and red tape that slows processes down, and works against efforts to improve productivity and efficiency at scale.

Another issue software developers face is that the traditional IT service catalogue is a heavyweight solution. Many organisations have had service portals for years, grounded in IT and enterprise service management practices and based on products such as ServiceNow, Atlassian’s Jira Service Management or BMC Helix.

These tools remain because they often serve non-technical users and may be leveraged by traditional infrastructure organisations for ticketed offerings. However, developers find ticket ops to be too slow and unresponsive, which is why a market emerged for dedicated internal developer platforms (IDPs).

A scaled platform for services

IDPs provide a framework for creating an IT platform where services can be defined, automated and exposed across the enterprise.

Examples of IT services that can be incorporated into an IDP include allocating 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 creating the scaffolding for a new microservice project using organisational best practices.

Internal developer platforms provide a framework for creating an IT platform where services can be defined, automated and exposed across the enterprise

IDPs facilitate management and access to service automations by providing a framework to manage and expose automation at scale.

IDPs can provide visibility into tools and frameworks. One feature of IDPs is scorecards, which provide information about both the technical and business performance of technologies. This helps developers make the right choice when faced with multiple frameworks, and also gives leaders insight into adoption.

New tool adoption becomes apparent to leadership, as does abandonment of older technologies, enabling leaders to deprecate and remove older components when it makes sense for the business.

At a high level, IDPs can serve a similar role to traditional platform as a service (PaaS) by providing an abstraction layer to IT infrastructure services. However, whereas many PaaS implementations have opaque abstraction layers, IDPs offer a transparent layer via service definition files that enable developers and infrastructure engineers to view, reuse and improve upon the underlying abstraction mechanisms.

Platform builders need to understand these differences to determine which abstraction model will serve their needs best.

The role of Backstage

Backstage, the IDP that Spotify donated to the Cloud Native Computing Foundation (CNCF), was one of the most downloaded apps from the CNCF in 2024. The topic of Backstage adoption garnered a full day of presentations and user stories at KubeCon 2024.

There are several reasons for its adoption. Spotify has a reputation for transformational engineering processes. Many organisations have adopted the now-famous Spotify model, featuring squads, tribes and guilds. Having Backstage reside in the CNCF ensures governance and a healthy community of contributors and adopters. A growing number of commercial DevOps tool suppliers support Backstage plug-ins. And most importantly, because it’s open source, Backstage is free for developers to download and try, further accelerating interest in platforms in general.

Before committing to an IDP, IT leaders should build a compelling business case outlining which benefits the IDP will bring to the organisation and how it will measure these

Many teams had assumed, or hoped, that Backstage was a ready-to-use platform, but soon became overwhelmed by its complexity. This has created an opportunity for commercial software providers to differentiate their offerings from Backstage. These commercial tools providers claim their products are easier to get started with, have a lower learning curve and offer technological advantages to Backstage, such as providing a service orchestration layer.

Spotify also offers Backstage as a paid commercial subscription that includes product support, additional plugins and no-code capabilities to help companies get started faster with greater confidence. Users see these commercial add-ons, such as Soundcheck (a plug-in that helps teams visualise quality, security and reliability checks on services), as value-adds.

Before committing to an IDP, Forrester recommends IT leaders build a compelling business case outlining which benefits the IDP will bring to the organisation and how it will measure these. Developing a comprehensive business plan will ensure alignment between the stakeholders funding the platform initiative and those responsible for its creation.

Forrester has found that nearly every IDP company and end user who has successfully built an IDP started small by building a proof of concept (PoC). The first implementation can take several weeks to months.

Forrester recommends that IT leaders first identify a team that is collaborative and sees the benefit of an IDP approach. Then, build the PoC around a few of members’ crucial needs while engaging with them for additional suggestions and even their own contributions to improve the IDP. This approach can be built upon and used as a springboard for other teams to continue to grow the IDP in a sustainable way.

This article is based on an excerpt of Forrester’s “Originated by Spotify, Backstage sparks a platform revolution” report. Andrew Cornwall is a senior analyst at Forrester.