The aim for all software developer team leaders is to find a happy place where developers spend their day developing and deploying code. The platform team supports the work of those software developers, observing and responding to their needs.
However, the job of a software developer today is about more than just writing code. Thanks to the prevalence of DevOps, software developers tend to have a huge responsibility: they own the feature development, bug fixes, deployment pipeline, performance monitoring, cloud infrastructure and security of their code.
Software development trends are constantly adapting to help software teams keep pace with the growing requirements of an increasingly digital society, and business leaders are recognising the value of software-powered business initiatives.
Providing a self-service internal developer portal (IDP) is seen as a way to offer a good experience for software developers, who want the freedom to choose from a curated set of tools and technologies to help them write code. The key point is that these tools are “curated”. There are guide rails to self-service and these curated tools meet corporate standards for cyber security and best practices.
Analyst Gartner has forecast that by 2028, 85% of organisations with platform engineering teams will provide IDPs to improve developer experience and accelerate product innovation. Gartner defines internal developer portals as tools that enable self-service discovery, automation and access to reusable components, tools, platform services and knowledge assets in modern software development environments.
The analyst firm noted that these portals help improve developer experience and service reliability while enabling centralised governance and shared visibility across multiple teams.
Gartner’s definition of an IDP for developer self-service covers features such as software catalogues and their ownership, quality and security metrics; scaffolding templates; product- and tool-related documentation; links to curated tools and packages; and self-service actions, such as provisioning environments and executing data pipelines.
Gartner says the IDP should provide a single go-to place for multiple teams and the various job roles within those teams, to help them understand the current state of engineering activity spanning infrastructure, applications, environments and platform components, and their ownership across the organisation.
Such organisation of the assets needed to develop software quickly, efficiently and securely seems like a logical step in the right direction. But as Mandi Walls, DevOps advocate at PagerDuty, notes, making it work is not straightforward. With every iteration of the software development model, there will be teething problems, where the new tools rub up against traditional methods, management and cultural practices.
“Teams on the journey to full-service development models must carefully navigate the transition from the ops-driven ‘we deploy’ to a developer-led ‘you deploy, we observe’,” she says.
In her experience of watching businesses of all sizes and types make the transition, Walls notes that platform and reliability engineering need to evolve together to empower developers while ensuring uptime and trust at all costs.
In fact, Gartner sees platform engineering teams taking responsibility for providing the developer self-service portal to product development teams. It may be made available either as a standalone platform or as integral components of DevOps platforms and broader internal developer platforms.
While some voices in the industry claim platform engineering adds unnecessary complexity or recentralises control, for Walls, the real issue is balance.
“Developers shouldn’t be shielded from operational context and deployment environments. Understanding production realities leads to better, more resilient software. Think of it like designing a car without ever seeing a road – that would make it hard to anticipate performance, wear, or real-life safety,” she says.
According to Walls, platform engineering done right enables productive autonomy, not ignorance. “A productive and resilient team needs knowledge of production environments to make use of all the available resources and features they offer,” she says.
Reliability must be designed in, not added on later
For Walls, the goal of self-service should not just be faster delivery – it should be sustainable delivery. She sees reliability as a team sport where developers own their code in production and platform engineers provide the tools, guardrails and telemetry. Reliability engineers ensure the whole system meets service-level objectives and agreements. Without embedded reliability practices, Wall warns that self-service can quickly lead to operational overload and alert fatigue.
As developer self-service becomes the norm, reliability can no longer live only in an operations silo. The most successful organisations will be those that make operational readiness and continuous uptime part of the developer experience itself Mandi Walls, PagerDuty
“The point is for true self-service to include observability, alerting and incident workflows from day one,” she says.
Walls believes reliability is everyone’s job. “As developer self-service becomes the norm, reliability can no longer live only in an operations silo. The most successful organisations will be those that make operational readiness and continuous uptime part of the developer experience itself,” she says.
Reliability has implications for developer self-service, which, according to Walls, should not be taken to mean “everyone for themselves”. She says: “A shared responsibility is backed by a strong, clear process. Governance and readiness can coexist with developer freedom.”
As Walls notes, this means clearly defined ownership, who is on call and who maintains what, layer by layer. She recommends that blameless postmortems, reliability retrospectives and the like are shared across all teams.
PagerDuty proposes a model for developer self-service platforms where IT operations and platform teams shift focus from performing deployments to observing and supporting them. Walls says this requires:
Centralised observability dashboards for unified situational awareness.
Automated alert routing based on service ownership.
Real-time incident visibility and response orchestration.
Coordinated best practices across the organisation for alerts, log messages and telemetry to enhance observability across services.
“If you really want to empower developers to own their services without isolating them, then collaboration must be built into observability,” she adds.
Emphasising procedural change
Along with the changes to IT operations and the platform engineering teams, Matt Saunders, vice-president of DevOps at Adaptavist, says software developer self-service also requires an organisational and cultural change.
Even the best developer tooling won’t have the impact you want it to without careful cultural and procedural changes Matt Saunders, Adaptavist
“For self-servicing tools to succeed, development teams have to want to use them. Similarly, the teams that are successfully building developer tooling are conducting proper user research, prioritising features and offering ongoing support,” he says.
“Successful platform teams use a continuously iterative approach, treating developers as proper customers and refusing to let this work be a side project. They also measure adoption carefully, retire unused features and make intentional improvements based on observed behaviour, not assumptions.”
For Saunders, the shared knowledge base that is available through internal developer platforms becomes a living asset that scales far better than ad hoc support or undocumented tribal knowledge. But change management is key.
“Even the best developer tooling won’t have the impact you want it to without careful cultural and procedural changes. Ensuring there’s cultural alignment, and adjusting workflows and decision-making working processes to enable that, is as important as the tools in building a successful platform,” he adds.
Enterprise AI driving adoption
Given all the industry hype around the use of artificial intelligence (AI) in the enterprise, software development teams are wary of the complexity AI adds to building enterprise applications.
A Gartner study suggests software developers are concerned that building AI capabilities into applications is a top challenge. This, according to Gartner, is why there is a lot of interest in IDPs in large enterprises, which use them to deliver curated tools, reusable components and standard workflow recommendations.
By enabling self-service discovery and access to AI models, orchestration frameworks, observability tools and ModelOps platforms, Gartner notes that these capabilities mean an IDP can help multiple teams navigate the technical complexity of building GenAI capabilities.
Nevertheless, according to Gartner’s Technology adoption roadmap for large enterprises for 2025, technical incompatibility or architecture complexity is the primary risk factor affecting the successful adoption of internal developer portals.
This implies that self-service in software development, through an IDP, is likely to become more prevalent with the growth of enterprise AI and the need for software teams to AI-infuse corporate IT systems. But, putting the complexity of building AI applications to one side, rolling out an IDP for software developer self-service is the first stumbling block many enterprise IT leaders are likely to face.
Jonathan is a tech enthusiast and the mind behind Tech AI Verse. With a passion for artificial intelligence, consumer tech, and emerging innovations, he deliver clear, insightful content to keep readers informed. From cutting-edge gadgets to AI advancements and cryptocurrency trends, Jonathan breaks down complex topics to make technology accessible to all.
