For application developers, it’s about the ability to get things done without having to create tickets and wait for days for someone else to attend to them. Self service for developers is supported through what we call golden paths or paved roads. A golden path is a pre-defined, opinionated, and supported way of building, deploying, and operating software. A golden path may not be the only way to get something done on the platform, but it certainly is the recommended, curated path of least resistance.
Platform engineers are often ignored when it comes to self service. Usually, they are just expected to build self-service capabilities for app developers but almost never considered as engineers who need to be served by the platform themselves. But as we discussed in the first principle of this article, an IDP should serve platform engineers too. Platform engineers are expected to provide consistent infrastructures, environments, pipelines, and so on. Just like city builders are expected to provide the same voltage of electricity to all parts of a city, the same water pressure to every household, so are platform engineers expected to provide the same consistent foundations for developers to build on.
This consistency can only be achieved via self-service golden paths that are available to platform engineers. Self service for platform engineers means giving the platform team itself a set of automated, composable building blocks that allows them to design, extend, and operate the IDP efficiently without having to manually stitch together infrastructure or re-invent patterns each time. These self-service golden paths need to have the right guardrails built-in (for handling risky actions such as removing environments, for example), as well as audit trails and proper governance at scale.
Self-service golden paths, for both developers and platform engineers are therefore a key principle in an IDP. Characteristics of such golden paths are:
- Opinionated, not restrictive: They encode best practices (tech stack choices, CI/CD templates, security policies) while leaving flexibility for edge cases.
- End-to-end workflow: They cover the full life cycle from scaffolding an app, provisioning infrastructure, and CI/CD to observability, monitoring, and incident response.
- Self-serviceable: They are exposed to developers through self-service tools, UI, or CLI commands in the IDP.
- Abstract away complexity: Developers and platform engineers don’t need to wire together Kubernetes, observability stacks, IAM, etc. The golden path bakes those in behind easy interfaces.
- Continuously maintained: Platform engineers evolve golden paths alongside organizational needs, security requirements, and new technologies.
Ops-driven, declarative and automated
Automation (obviously) is critical for an IDP. You cannot achieve the goals of an IDP without automation. But automation without discipline is just a recipe for chaos. That is why ops-driven automation is the way to go. Ops-driven automation is basically about following GitOps workflows for changes made on the IDP. Every action performed on the IDP has to be versioned, recorded, and reversible. All actions need to have audit trails.
It’s important for an IDP’s automations to be in declarative form. This is about declaring the desired state of the system instead of continuously monitoring and reacting to events and alerts. Think of a city’s street lights. Someone needs to turn on the lights at dusk and turn them off at dawn. If something goes wrong in the middle of the night and the lights go off, someone needs to attend to it and turn the lights back on. This is a cumbersome process and requires a lot of labour. However, imagine being able to declare the desired state as the “lights need to be on whenever there’s darkness.” If the system can automatically reconcile the state of the lights to this desired state, the operation of the city’s lights become much more efficient and smooth. No one needs to wake up in the middle of the night just because of a glitch in the system. The system automatically recovers by itself.
For a truly hands-off experience of operating an IDP, the platform’s automations need to work in a declarative manner. Declarative automations with ops-driven workflows are therefore a key principle to build an IDP on.
Intelligent and insightful
An IDP serves many stakeholders. While it may primarily cater to application developers and platform engineers, the benefits of an IDP can be realized by many parts of an organization. To make this possible, the IDP should expose relevant intelligence and insights to all parties. Here are some examples of different stakeholders and the relevant data and insights.
- For developers and operators: Insights needed for troubleshooting incidents. Primarly driven by observability data (i.e., logs, metrics, traces).
- For business stakeholders: Insights that showcase the impact of digital artifacts on the business. For example, data such as orders placed, user growth, order cancellations, etc. This basically involves converting technical data from an organization’s APIs to business insights.
- For engineering managers: Insights needed for assessing the organization’s speed and stability of delivering software. Primarily built on the well-known DORA metrics.
- For architects: Insights that help determine the ROI of digital artifacts, insights on the efficiency of resources, cost breakdowns, etc.
In our data-intensive era, insights without intelligence are insufficient. For many years, we’ve been accustomed to looking at all kinds of graphs, charts, and reports. We’ve had to undergo the hard task of analyzing these reports to understand areas of improvements. But now, many of these tasks can be offloaded to AI agents within the IDP. In addition to showing graphs, charts, and reports, these agents can help determine the causes of failures and other areas of improvements for our digital artifacts as well.
Intelligence of course applies across the board, not just for insights. An IDP should incorporate AI everywhere it makes sense. Think of compliance, governance, monitoring, etc. AI has become a tool that can assist many such areas of an IDP. It is therefore crucial to consider AI and insights as a key principle of an IDP.
Product orientation
An IDP should not be a one-off project. A project is something you do once and finish. It has a start date and an end date. An IDP is never a finished project. It is something that continues to live and evolve, forever.
Delivery of software never ends. Furthermore, the types of software that are delivered and the ways in which they are delivered inevitably change. What you deliver today is not the same thing that you will deliver tomorrow. If you treat your IDP as a one-off project, you will build for today’s requirements and stop, and your IDP will not cater to the needs of tomorrow. This is why you need a product mindset for your IDP. Your IDP should evolve to meet future needs, keeping pace with the tools and technologies of the modern industry and providing a platform to lift up and modernize your organization.
A product mindset for an IDP requires proper product management. This includes maintaining a clear roadmap, having regular release cadence, life-cycle management of features, issue tracking, and so on. It also requires paying attention to non-technical factors required for its success. You need to create sufficient awareness around the platform, increase its adoption, gather feedback from users, feed those learnings into the roadmap, and continue to iterate.
This product mindset is therefore a key principle of an IDP. It is critical for long-term success. Treating an IDP as a project will give you short-term benefits but eventually fail in the long term. Strong product management with a real commitment to evolve the IDP like a product is what will guarantee its overall success.
Closing thoughts
A great IDP is more than a collection of tools. It’s your “planned city” for software delivery, providing consistent abstractions, reliable guardrails, and golden paths that empower both developers and platform engineers.
Many IDPs, both home-grown and off-the-shelf solutions, tend to focus only on reducing the cognitive load of developers and delivering software faster. While this approach may deliver short-term wins, it creates inefficiencies and extra toil in the long run.
A successful IDP removes barriers to efficiency and puts both developers and platform engineers on self-service golden paths. It creates order, saves time, saves money, increases satisfaction, and significantly improves an organization’s ability to innovate.
—
New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.
