Plenty of organisations have done the IDP work, and done it well. Templates, scorecards, ownership data, deployment metadata, real automation underneath. Developers using it. Engineering teams faster, happier, less blocked. The platform engineering investment is paying off for the people it was built for. But there's more value still to unlock.
The work isn't done yet.
In the same organisation, there's almost always a second sentence waiting to be said in a different room: "We have a CMDB." It sits on the operations and service management side of the organisation, doing its job — tracking services, mapping dependencies, supporting audit, governance, security, and finance. Doing it well within its scope. But also working with a picture of the IT environment that the developer side has moved on from.
Two systems. Two views of the same thing. Each side has a partial picture, and each side has been told to trust their picture as the truth. The leadership team can reasonably look at either one and conclude that the work is complete. But the picture is only complete when the two are connected. Making the relevant connections will create value for all involved.
And the gap gets worse, not better, as each side succeeds independently.
Two Truths, Both Working
When the IDP works well, it works very well — for developers. It reflects how engineering teams operate: fast, self-service, close to the code, updated as a natural by-product of delivery. Templates, ownership within the developer domain, deployment history, immediate dependencies — it's all there, and it's all current, because the people maintaining it are the people using it.
The CMDB sits on the operations and service management side, and it reflects how that side of the organisation operates: service-oriented, change-controlled, audit-aware. It tracks the wider IT environment — including the systems, integrations, and dependencies the developer domain consumes from but doesn't own. It's structured for governance, audit, compliance, and operational reporting.
Two solutions, each correct for its audience. Each one also incomplete on its own. That's fine — they exist for good reasons and serve different needs. But there's a bigger picture that only comes into view when the information from both sides is brought together.
Developers need to know what depends on their service before they change it — and a lot of those dependencies live outside the developer domain. Ops needs to know who owns a developer-built service before they can act on an incident — and that ownership lives in the IDP. Security needs to trace dependencies across the whole environment, not just half of it. Finance needs cost allocation that maps developer-built services to wider business context. And developers need to find owners of upstream integrations they consume but don't operate.
Every one of these is a request for information that exists somewhere in the organisation — just not in the system the asker has access to.
The portal isn't broken. The CMDB isn't broken. The boundary between them is where everyone is working with half a picture — developers included.
What Happens at the Boundary
The gap stays invisible most of the time. It becomes visible at moments when someone — on either side — needs information that lives in the other system. The same patterns repeat across most organisations:
They can see what depends on their service inside the developer domain. They can't see the integrations, regulated systems, or customer-facing components downstream that the CMDB knows about. The breaking change ships. The incident follows.
The dependency map is wrong. The CMDB shows what was recorded; the developer side has moved on. The incident commander is reconstructing context from Slack and tribal knowledge while the clock runs.
Their service consumes an integration owned by another team. Who maintains it? What's the SLA? When is it planned for change? The CMDB tracks this. The IDP can't see it. The developer asks around in Slack.
The baseline is stale. The change advisory board is approving a change against a picture of the IT environment that the developer side stopped agreeing with months ago.
The answers don't reconcile. The portal says one thing about ownership; the CMDB says another; both are partially right; neither is complete. The audit response becomes a manual reconstruction exercise.
The trail goes cold. A service is under investigation; the CMDB record points to a team that no longer exists; the IDP would have known but security doesn't have access to it.
The picture is incomplete. Cloud spend is real and growing; the mapping from infrastructure to service to owner is partial; allocation becomes a spreadsheet exercise with educated guesses.
Each one of these is recognisable to anyone who's been on the receiving end — developer or operator. Each one is the moment the boundary becomes visible, and almost always too late to be useful. The information existed somewhere. It just lived on the other side of a gap that nobody had been paid to close.
It Isn't a Tooling Problem
The instinct in this situation is to look for a better tool. A better portal. A better CMDB. A better integration platform that promises to bridge the two.
That instinct is misleading. The gap isn't a tooling gap. Either tool, working at its best, only covers one side of the boundary. Even excellent tools, well-configured and well-adopted, won't close it on their own — because the gap isn't inside either system. It's between them.
The questions that actually decide the outcome are operating-model questions: Who masters which entities? Where does the shared reference between the two registries sit? When a developer team deploys a new service, how does that fact appear in the CMDB — automatically, manually, or not at all? When ops needs to find the owner of a service the developer side built, do they query a system or send an email?
Most enterprises already have the systems they need to answer these questions. What they don't have is an answer. Buying more tooling doesn't produce one; defining the operating model does.
If you replaced your portal tomorrow, would the gap close? If you replaced your CMDB tomorrow, would the gap close? If neither would close it on its own, the gap isn't in the tools. It's in the boundary between them — and that's where the work is.
What Good Looks Like
The reconciled state isn't a single registry. It isn't the CMDB absorbing the portal, or the portal replacing the CMDB. It's both, kept in defined relationship:
- The portal remains the source of truth for what developers are building, deploying, and owning. It stays close to the code and updates as a natural by-product of delivery.
- The CMDB remains the source of truth for what's recorded, governed, and reportable to the rest of the organisation. It stays close to ITSM and updates as a natural by-product of operations.
- A defined boundary specifies which system masters which entities, where shared references sit, and how data moves between them.
- The handshake is automatic. Developer-owned services appear in the CMDB because deploying them populates the record — not because someone manually registered them after the fact.
- Governance becomes part of the flow. Ownership, change history, and dependency information are available to incident response, audit, security, and finance without requiring an interview with the developer team that built the service.
The portal is still the portal. The CMDB is still the CMDB. The difference is that the rest of the organisation can answer the questions it needs to answer without having to find the right developer at the right moment. Risk gets seen before it has to be acted on.
The question every senior IT leader should be able to answer: do we actually know what's running, who owns it, and what depends on it? The boundary between the portal and the CMDB is one of the places that answer breaks down. Closing the gap is mostly good old-fashioned work — recognising the boundary, modelling the data, and integrating the systems that already exist.
Where to Start
Two diagnostic prompts. The honest answers reveal where your boundary sits:
If you handed your incident commander a developer-owned service mid-incident, could they get a current dependency map in seconds — or would they have to find someone who knows? The answer tells you how much of your governance is in systems and how much is in people's heads.
If your auditor asked you to demonstrate ownership and change control for a developer-owned service, would the evidence come from systems or from interviews? The answer tells you how much of your audit posture would survive losing the people who currently hold the picture together.
Closing the gap doesn't require new tools. It requires defining the boundary — who masters what, where the shared reference sits, how the handshake works — and then wiring the systems you already have to that definition. Most of the work is operating-model work. The technology mostly follows from a clear answer to the operating-model question.
Find the boundary. Close the gap.
Our Service Model Alignment Assessment is built specifically for this question. A focused 3–5 day engagement, a clear findings report on where the boundary sits and what it's costing you, a recommended ownership model, and a prioritised integration roadmap that leadership can fund with confidence.