Our criteria for an effective IDP

Here at OpsLevel, we operate under the assumption that everyone wants to deliver good software, quickly. This is particularly true for organizations that are operating within (or aspiring to) a DevOps model. They know that to build good software, you need the people who build features to also be the people who deploy those features. However, one of the biggest challenges of a DevOps model is that it introduces complexity. 

So, how do you address this complexity so that it doesn’t get in the way of taking quality features to market faster? That’s exactly what we’re going to cover.

The need for an IDP

DevOps as a methodology is generally a good way to build and deploy software, though not without its own drawbacks.

For product teams building software for customers or other end users, there are two key challenges in a DevOps model. It’s harder to find the information they need across various sources and systems (and it’s not always clear who needs to be informed about each change or update they make). At the same time, it’s also more complicated to perform tasks because developers are responsible for a wider array of operational work and requirements. 

Platform teams—and by that I mean the teams responsible for enabling product developers to do their job better, including platform engineers and security teams—have their own set of challenges. Getting visibility into the operations of teams and systems, driving standards across a large distributed org, and having product teams lean on them for common operational asks are all barriers that can get in the way of platform teams moving quickly and effectively. 

Altogether, these complexities waste time, make software worse, and negatively impact developer experience—and they get worse as the organization scales. An internal developer portal(IDP) can help mitigate these challenges and get a team moving in the right direction.

In the simplest terms, an IDP helps everyone in a software development org find the information they need and get stuff done. For the smallest orgs , this can look like a spreadsheet paired with a battery of CLI commands. But this approach is bound to break when that team and the products scale. In my time at OpsLevel, I’ve had new customers come in with no IDP, a robust IDP that they can’t afford to manage themselves anymore, and everything in between. 

Based on my experience, here are the core elements that make a great IDP and how they help teams do more, faster. 

The building blocks of a great IDP

For starters, there are two key traits that define an effective IDP: integration and automation. An IDP should be integrated in the sense that it’s linked to existing systems, workflows, and processes, and it’s a critical component in shipping code. A team’s IDP should show up often in documentation and onboarding materials, and it should be the first stop when developers and platform engineers are trying to solve an issue.

The biggest cost of an IDP is the amount of time and toil it takes to build and maintain. In other words, you should be looking to automate everything you can. Any opportunity you have to introduce automation to reduce toil for everyone—without exposing your organization to risk—you should take. 

Beyond these traits, which should be core elements in any developer tooling, an IDP should empower teams to quickly deliver quality software by improving these three things: 

• Visibility 
• Standards
• Self-service

Let’s dive into what each of these components looks like in the context of an IDP.

Visibility: A comprehensive catalog

At its core, an extensive software catalog makes it easy for everyone to find the information they need to do their job. To be most effective, a catalog should be complete, up-to-date, discoverable, and searchable. 

When we talk about a catalog being complete, it doesn’t just mean that all the objects you are looking to track are present, but also that they have metadata people might be looking for. You can’t just have a list of entries—those entries also need to be filled with relevant data that supports developers in doing their job. In the OpsLevel catalog, for instance, we have data on ownership, maturity level, tier, dependencies, language, framework, tooling, deploys—the list goes on. The richness of this data means that when developers are looking to answer a question about their services and systems, they only need to look in one place. 

An up-to-date catalog reflects the actual state of the world, with reliable data that developers can take action on immediately. It’s easy to find and use, and it’s equipped with search mechanisms that can source what a user needs with limited inputs. 

Standards: A robust maturity tracking system

A maturity tracker lets platform teams drive changes across their engineering org and enables dev teams to understand what it means to own and operate a service. Platform teams can establish standards that need to be applied across the org, select the services that need to be changed, assign specific tasks for dev teams to make those changes, and track progress against those requirements. 

For a maturity tracker to be most effective, there needs to be alignment and buy-in across the engineering organization. Often, a platform team will have a huge list of things they want to do, but the org isn’t aligned on priorities—different teams take on different work, and some teams just accrue technical debt and do nothing at all. Having executive support can be useful here, so that the mandate is passed down from the top. 

If you’re looking for more guidance on effectively rolling out an IDP within your org, read our Champion’s Guide.

There also needs to be alignment among the different platform engineers and where they house their requirements. In practice, these teams (e.g., reliability engineers and security leads) should be housing all requirements within your IDP’s maturity tracker, so that devs have clear visibility into what needs to be done and when. Product teams should be able to focus on getting these requirements done, not tracking down what they need to do. 

Lastly, a maturity tracker should be prioritized. Devs should have clear insight into what they need to work on first—and why. This ensures that they take a progressive approach to their operational work, and teams don’t cherry pick what they find easiest or most interesting.

At OpsLevel, we’re helping teams drive operational work consistently and reliably, and that shows in our service maturity rubric. Every service has a scorecard and a prioritized list of activities that are sorted into bronze, silver, or gold levels. Behind the scenes, users get access to reporting so they can see how their services are performing overall, or per category (e.g., security, reliability).

Self-service: An action center that powers developer activities

Your product developers want to move quickly, right? The fact is, one of the worst things you can do as an engineering org is create barriers that slow your devs down. An IDP can help here with self-service capabilities that allows product teams to perform common operations tasks safely, efficiently, and (importantly) on their own. 

This action center should be: 

• Convenient: it should be close to where engineers live in their day-to-day work, so that they can pop in and use it whenever they need to.
• Documented: there should be clear descriptions of what a user needs to do to execute on an action, and what that action will result in. 
• Discoverable: it should be easy to find, search in, and use. 
• Auditable: in a DevOps model, it’s important to know who did what and when. An action center should log all these activities so that they can be easily reviewed in the future.

Within OpsLevel’s self-service hub, platform engineers can create service templates with specific guardrails built in, allowing developers to launch services that already adhere to org-wide standards without reinventing the wheel. Developers can also take certain predefined actions (e.g., deploy freeze, rollback, release), all from one place—reducing their reliance on the platform team and thereby alleviating platform engineers to focus on higher impact work. 

The role of an effective IDP

At OpsLevel, our mission is to give developers the tools and knowledge they need to quickly deliver quality software. That’s the role a leading-class IDP can play for an engineering org. Used effectively, an IDP can unleash the true power of your developers, ensuring you get better, more reliable products and features to market faster. 

‍Want to learn more about what a great IDP looks like in practice? I recently chatted with our CTO, Ken Rose, on the Level Up Podcast where I went into even more detail. You can watch the episode here.  

‍