A framework for software development self-service | Computer Weekly

A Lego template for application development

To take the Lego analogy a bit further, there are instructions, templates and pathways developers can be encouraged to follow to build enterprise software that complies with corporate policies.

A developer self-service platform provides a way for organisations to offer their developers almost pre-authorised assets, artefacts and tools that they can use to develop code

Roy Illsley, chief analyst, IT operations, at Omdia, defines an internal developer platform (IDP) as a developer self-service portal to access the tools and environments that the IT strategy has defined the organisation should standardise on. “A developer self-service platform provides a way for organisations to offer their developers almost pre-authorised assets, artefacts and tools that they can use to develop code,” he says.

The basic idea is to provide a governance framework with a suite of compliant tools. Bola Rotibi, chief of enterprise research at CCS Insight, says: “A developer self-service platform is really about trying to get a governance path.”

Rotibi regards the platform as “a golden path”, which provides developers who are not as skilled as more experienced colleagues a way to fast-track their work within a governance structure that allows them a certain degree of flexibility and creativity.

As to why offering flexibility to developers is an important consideration falls under the umbrella of developer experience and productivity. SnapLogic effectively provides modern middleware. It is used in digital transformation projects to connect disparate systems, and is now being repositioned for the age of agentic AI.

SnapLogic’s chief technology officer, Jeremiah Stone, says quite a few of the companies it has spoken to that identify as leaders in business transformation regard a developer portal offering self-service as something that goes hand-in-hand with digital infrastructure and AI-powered initiatives.

SnapLogic’s platform offers API management and service management, which manages the lifecycle of services, version control and documentation through a developer portal called the Dev Hub.

Stone says the capabilities of this platform extend from software developers to business technologists, and now AI users, who, he says, may be looking for a Model Context Protocol (MCP) endpoint.

Such know-how captured in a self-service developer portal enables users – whether they are software developers, or business users using low-code or no-code tooling – to connect AI with existing enterprise IT systems.

Enter Backstage

One platform that seems to have captured the minds of the developer community when it comes to developer self-service is Backstage. Having begun life internally at audio streaming site Spotify, Backstage is now an open source project managed by the Cloud Native Computing Foundation (CNCF).

While many teams that implemented Backstage assumed that it would be an easy, free addition to their DevOps practices, that isn’t always the case. Backstage can be complex and requires engineering expertise to assemble, build and deploy

Pia Nilsson, senior director of engineering at the streaming service, says: “At Spotify, we’ve learned that enabling developer self-service begins with standardisation. Traditional centralised processes create bottlenecks, but complete decentralisation can lead to chaos. The key is finding the middle ground – standardisation through design, where automation and clear workflows replace manual oversight.”

Used by two million developers, Backstage is an open source framework for building internal developer portals. Nilsson says Backstage provides a single, consistent entry point for all development activities – tools, services, documentation and data. She says this means “developers can move quickly while staying aligned with organisational standards”.

Nilsson points out that standardising the fleet of components that comprise an enterprise technology stack is sometimes regarded as a large migration effort, moving everyone onto a single version or consolidating products into one. However, she says: “While that’s a critical part of standardising the fleet, it’s even more important to figure out the intrinsic motivator for the organisation to keep it streamlined and learn to ‘self-heal’ tech fragmentation.”

According to Nilsson, this is why it is important to integrate all in-house-built tools, as well as all the developer tools the business has purchased, in the same IDP. Doing so, she notes, makes it very easy to spot duplication. “Engineers will only use what they enjoy using, and we usually enjoy using the stuff we built ourselves because it’s exactly what we need,” she says.

The fact that Backstage is a framework is something IT leaders need to consider. In a recent blog post, Forrester analysts Christopher Condo and Lauren Alexander warned that most IDPs are frameworks that require assembly: “While many teams that implemented Backstage assumed that it would be an easy, free addition to their DevOps practices, that isn’t always the case. Backstage can be complex and requires engineering expertise to assemble, build and deploy.”

However, Forrester also notes that commercial IDP options are now available that include an orchestration layer on top of Backstage. These offer another option that may be a better fit for some organisations.

AI in an IDP

As well as the assembly organisations will need to carry out if they do not buy a commercial IDP, AI is revolutionising software development, and its impact needs to be taken into account in any decisions made around developer self-service and IDP.

Spotify’s Nilsson believes it is important for IT leaders to figure out how to support AI tooling usage in the most impactful way for their company.

“Today, there is both a risk to not leveraging enough AI tools or having it very unevenly spread across the company, as well as the risk that some teams give in to the vibes and release low-quality code to production,” she says.

According to Nilsson, this is why the IT team responsible for the IDP needs to drive up the adoption of these tools and evaluate the impact over time. “At Spotify, we drive broad AI adoption through education and hack weeks, which we promote through our product Skill Exchange. We also help engineers use context-aware agentic tools,” she adds.

Looking ahead

In terms of AI tooling, an example of how developer self-service could evolve is the direction of travel SAP looks to be taking with its Joule AI copilot tool.

When structure, automation and visibility are built into the developer experience, you replace bottlenecks with flow and create an environment where teams can innovate quickly, confidently and responsibly

CCS Insights’ Rotibi believes the trend to integrate AI into developer tools and platforms is an area of opportunity for developer self-service platforms. Among the interesting topics Rotibi saw at the recent SAP TechEd conference in Berlin was the use of AI in SAP Joule.

SAP announced new AI assistants in Joule, which it said are able to coordinate multiple agents across workflows, departments and applications. According to SAP, these assistants plan, initiate and complete complex tasks spanning finance, supply chain, HR and beyond. 

“SAP Joule is an AI interface. It’s a bit more than just a chatbot. It is also a workbench,” says Rotibi. Given that Joule has access to the SAP product suite, she notes that, as well as providing access, Joule understands the products. “It knows all the features and functions SAP has worked on, and, behind the scenes, uses the best data model to get the data points the user wants,” she says.

Recognising that enterprise software developers will want to build their own applications and create their own integration between different pieces of software, she says SAP Joule effectively plays the role of a developer self-service portal for the SAP product suite.

Besides what comes next with AI-powered functionality, there are numerous benefits in offering developer self-service to improve the overall developer experience, but there needs to be structure and standards.

Nilsson says: “When structure, automation and visibility are built into the developer experience, you replace bottlenecks with flow and create an environment where teams can innovate quickly, confidently and responsibly.”