The IT Management Graph — How an Enterprise Model Delivers What the CMDB Never Could

CMDB has a well-documented failure problem, and Forrester itself declared the term dead, proposing a named successor: the IT Management Graph. For decades, the configuration management database was the default answer to a real and persistent question: what does the enterprise actually have, and how does it fit together? That default answer failed often enough, and publicly enough, that industry analysts themselves are saying so directly.

Forrester’s argument is not that the underlying problem CMDB tried to solve has gone away. It is that CMDB was never built to solve it — not with the discipline, structure, or model the problem requires. What Forrester describes as the IT Management Graph is a different kind of answer. IF4IT has been building a broader version of that answer for years, under a different name: the Enterprise Model.

The CMDB Failure Pattern, Briefly

The scale of CMDB failure is not a matter of anecdote. Gartner-sourced research is widely cited across the industry as putting CMDB failure rates in the range of 70 to 80 percent, with some independent analyses placing the figure as high as 85 percent among organizations that attempt implementation. The same body of research attributes much of that failure to weak business alignment, inappropriate scope, and inadequate process rigor.

Other industry sources frame the same pattern differently but arrive at a similar conclusion: only a minority of organizations report getting meaningful, sustained value from their CMDB investment, and it is common for an organization to make several attempts before a CMDB effort succeeds, if it succeeds at all.

This is not a new or isolated complaint. It has been a persistent, widely documented pattern for long enough that Forrester’s recent position — that the CMDB concept itself, not just individual implementations, has failed — reflects an industry consensus that has been building for years. The statistics show how often CMDBs fail. The next two sections explain why, and the section after them turns to what Forrester proposes instead.

The Chasm Between Discoverable and Non-Discoverable Structures

The value a CMDB is supposed to deliver depends on a complete graph of relationships running from physical infrastructure all the way up, through, and across the non-discoverable, business-facing constructs built on top of it — Applications, Integrations, Capabilities, Value Streams, Technologies, Data and Information, and similar elements that leadership, management, and operations reason about day to day. The fact that those relationships are rarely established at that depth is the clearest evidence of why the envisioned value never materializes: the relationships leadership and operations actually need are overwhelmingly the ones a CMDB effort never gets around to building.

Much of that gap traces to a specific technical limitation that general failure statistics do not fully capture. Auto-discovery tools are genuinely effective at finding discoverable assets — servers, network devices, and other physical or technical components with a detectable signature — and at mapping the relationships between them. What auto-discovery cannot do is create relationships involving non-discoverable logical constructs, because an Application or a Capability has no network footprint for a scanning tool to find. Between what auto-discovery can see and what leadership and operations need to reason about sits a chasm — the gap between discoverable structures and non-discoverable structures that no amount of automated scanning closes on its own.

A second, more fundamental gap sits underneath the first. Before a relationship can connect a discovered server to a Capability or a Value Stream, that Capability and that Value Stream must exist as governed, maintained entities in the first place, along with the non-discoverable aspects of Applications, Data and Information, and Integrations that tie technology to the business. Creating and maintaining those entities is not a discovery problem. It is an inventory management discipline, and CMDB initiatives rarely establish it. Without those inventories there is no bridge to build, because a relationship needs something on both ends. Discovery supplies one end of the span; only disciplined inventory management supplies the other. That missing bridge between discovered assets and the business is the predominant reason CMDB implementations fail.

Even once those entities exist, the relationship gap matters more than it first appears. The relationships that give a CMDB its business value — which applications support which capabilities, which capabilities depend on which underlying applications and technologies, which value streams run through which integrations — all involve these logical constructs. Mapping them at enterprise scale means manually creating and maintaining anywhere from tens of thousands to millions of individual connections that have semantic meaning. Those connections span both logical-to-logical relationships and logical-to-physical relationships, and all of them change as the environment changes. That volume of manual relationship curation is logistically untenable as an afterthought, and it is almost always treated as one: an inconvenient task that IT organizations incorrectly assume can be handled later, well after the expensive and time-consuming auto-discovery phases are implemented.

A concrete case shows how this plays out. Consider an enterprise whose discovery tools have cataloged thousands of servers, databases, and network devices and mapped how they connect. Leadership asks a simple question: “Which customer-facing value streams are exposed if this data center fails?” The CMDB can list the assets that auto-discovery tools found in the data center, but it cannot answer the question, because the Capabilities and Value Streams were never inventoried, the non-discoverable aspects of the Applications and Integrations were never captured, and the many required relationships among those entities, and between them and the auto-discovered assets, were never built. Closing that gap by hand is a large and very complicated undertaking: an enterprise with 1,500 applications and a very conservative average of just twenty relationships each to servers, data stores, integrations, capabilities, and vendors faces roughly 30,000 relationships before a single capability-to-value-stream link is counted. In practice, the number of relationships to be created and maintained is often much higher.

Auto-discovery’s early, visible progress compounds the problem. The first phase of a CMDB initiative, discovering and cataloging physical assets, genuinely looks productive, which is what makes deferring the harder work so tempting. By the time that work comes due, the easy, automatable phase is finished and the budget and momentum built around early success have begun to run out.

The CMDB Is an After-Deployment View of the Enterprise

A third limitation concerns time rather than discovery. ITSM practice does track the status of configuration items, but the states it commonly uses, such as ordered, received, in test, and live, begin only when something is being acquired or readied for deployment. They do not reach back to the months in which an application is proposed, funded, designed, and built. Throughout that time the application is already a real resource in the enterprise, with its own relationships to the capabilities it will support, the data it will use, the integrations it will depend on, and the infrastructure it will run on. Discovery tools, which feed so many CMDBs and are typically aimed at what runs in Production, see little of it.

That blind spot matters because leadership decisions are largely decisions about change: which projects to fund, which applications to retire, which dependencies a planned release will touch. An enterprise that can see only what is already live cannot reason about those decisions until after they have been executed. Managing and governing a resource has to begin when the resource begins to exist, which is well before deployment, and the relationships that govern it exist from that point as well.

What Forrester Says Should Replace It

In an October 2025 blog post titled “CMDB” Is Dead — Long Live The IT Management Graph, Forrester made the shift explicit, stating plainly that it is deprecating the term CMDB in its own research in favor of the IT Management Graph. The reasoning behind that shift is worth understanding in detail, because it points directly at what a successful replacement requires.

According to Forrester, the CMDB’s roots trace back to ITIL v1 guidance published in 1990, which itself drew heavily on military and aerospace configuration management. That heritage, built on documentation and repositories already in use in the 1980s, was ill suited from the start to support the fast-changing, widely distributed, software-centric reality of modern IT. The deeper issue, in Forrester’s own telling, is one of discipline rather than technology: CMDBs were built and managed by ITSM process experts rather than by people with genuine data-management training, and ITIL’s process-centric vocabulary never lined up with the schema design and data-quality discipline that trustworthy, governed data requires. The result, according to Forrester, was inconsistent data modeling, uneven governance, and organizations repeating the same failed approach — often three or four attempts — without ever closing that underlying skills gap.

Forrester’s proposed fix is explicitly graph-based. IT management data, the firm argues, is modest in volume but richly interconnected, and dependencies routinely run several layers deep rather than sitting in a single, flat relationship. Understanding exposure, impact, and lineage — tracing a technical resource up to the business capability it ultimately supports — calls for a model built to represent those layered relationships directly, not a flat database organized around configuration items. That is the structure Forrester now calls the IT Management Graph, with data governance, exception reporting, and continuous improvement as the ongoing discipline required to keep it trustworthy.

By putting “IT” in the name, Forrester implies an IT-only scope from the outset. On that reading, the graph reaches up to business capabilities to give technical resources context, while the data it holds and the purpose it serves stay IT’s.

Forrester’s declaration is a significant first step. As the post describes it, however, the graph appears to fall short in two ways. The first is the IT-only scope just described: it addresses what the IT organization needs, not what the broader enterprise needs. The second is method. The post names starting points — an inventory that begins with IT asset management, and telemetry, observability integrations, and agent-assisted curation for dependency data — but all of them sit on the technical side. It does not say how to design, build, and use a graph that reaches the business: where the business-side nodes are sourced, and how they are related to the technical ones.

The Enterprise Model Is That Graph, Extended to the Business

Read closely, Forrester’s description of what the IT Management Graph requires reads less like a new specification and more like a description of the core structure of the IF4IT Enterprise Model, built independently and under a different name. The Enterprise Model is a superset of that graph: a data graph that holds enterprise Business data together with IT data and serves both the Business and IT. It also answers what the post leaves open: its governed inventories are where the nodes come from, business-side nodes included, and its semantic relationships are how those nodes are related and what gives them meaningful context.

Where Forrester says the CMDB’s failure traces back to a discipline gap — process experts managing what should have been a data-management responsibility — the Enterprise Model starts from data-management discipline as a first principle. It is built on governed inventories, each one populated with instances of a defined Noun Type, a category of thing the enterprise governs, such as Applications or Vendors, with clear ownership, defined attributes, and consistent structure across every instance. This is the same governance discipline Forrester says CMDB efforts lacked, applied from the outset rather than retrofitted after repeated failed attempts.

Where Forrester says IT management data is richly interconnected, with dependencies running several layers deep, the Enterprise Model answers with its own defining structure: inventories connected to one another through semantic relationships, built the way relational data has long connected records, pairing primary and foreign keys with descriptive attributes. This is precisely the graph structure Forrester describes as necessary — instances as nodes, relationships as edges, with traversal spanning as many hops as the underlying question requires.

Where Forrester argues that the word configuration misleads, implying a store of configurations that a CMDB never was, the Enterprise Model was never scoped to configuration items in the first place. Its Inventory of Inventories, the catalog of every inventory the enterprise governs, spans Applications, Vendors, Capabilities, Contracts, People, Processes, and dozens of other Noun Types — the full breadth of what an enterprise needs to know about itself, not just the technical elements a traditional CMDB was built to track.

That breadth is what makes the Enterprise Model a superset. Inventories such as Contracts, Vendors, People, and Processes hold Business data, inventories such as servers, network devices, and other technical assets hold IT data, and inventories such as Capabilities, Value Streams, Applications, Integrations, and Data and Information form the bridge between the two. In the Enterprise Model they live in one connected data graph, so the same model answers a CIO’s question about technical dependencies and a business leader’s question about which capabilities and contracts those dependencies put at risk. A graph scoped to IT can reach the Business only as far as its technical edge; the Enterprise Model holds both sides and the bridge between them.

Where Forrester notes that generative AI and graph-based retrieval have moved graph databases to center stage for IT management, the Enterprise Model was designed from the outset to be queryable and AI-consumable — a connected representation an organization, and increasingly its own AI systems, can reason over directly.

And where CMDB efforts default to auto-discovery and treat the missing business-facing entities and relationships as a problem to solve later, the Enterprise Model treats both as a governed, owned discipline from the start. Capabilities, Value Streams, and the non-discoverable aspects of Applications, Data and Information, and Integrations each have their own inventory in the Inventory of Inventories, and because every inventory has an assigned owner, as the Enterprise Inventory Management Best Practices document requires, those entities exist and stay current. Connecting an Application to the Capability it supports, or a Vendor to the Contract that governs it, then becomes a defined responsibility rather than a task nobody owns until an incident forces the question.

The Enterprise Model also sees what an after-deployment view cannot. The Lifecycle Status of an application in the Applications Inventory begins at Proposed, and the Integrations Inventory works the same way, so an application or integration is a governed record, with its relationships to the capabilities it will support, from the moment it is proposed, not the day it reaches Production. That lets leadership ask what is changing, not only what is running.

None of this means the Enterprise Model is a rebranded CMDB successor built in response to Forrester’s post. It means that two independent efforts — one from an industry analyst firm diagnosing why CMDB failed, and one from a vendor-neutral foundation building an alternative from first principles — converged on the same core structure, and the Enterprise Model carries it further, to the Business as well as IT. That convergence is itself a form of validation neither effort could have produced alone.

Why This Isn’t Just a Naming Exercise

The practical difference between a failed CMDB and a working Enterprise Model shows up in the questions each one can actually answer. The data-center question earlier in this article is a typical case. A CMDB built around isolated configuration items can tell you what a given server or application looks like in isolation. It generally cannot tell you what breaks elsewhere if that server goes down, which business capabilities depend on it, or which vendor contract governs the service running on it — because those are cross-domain questions, and a flat, narrowly scoped database was never built to answer them.

A connected Enterprise Model answers that kind of question, because its inventories are linked by design rather than bolted together after the fact. Asked which customer-facing value streams are exposed if a data center fails, it follows relationships from the data center’s assets up through the applications they host, the capabilities those applications support, and the value streams those capabilities enable. Impact and blast-radius analysis, of the kind Forrester specifically calls out as a reason the graph model matters, becomes a traversal across existing relationships rather than a manual investigation assembled under pressure during an incident.

Forrester’s own piece names technical debt as one of the harder problems a working graph finally makes solvable. That is not a coincidental example. Technical debt is meaningful only in relation to the applications, capabilities, and business outcomes it affects — exactly the kind of cross-inventory reasoning a connected Enterprise Model is built to support, and exactly the kind of question a CMDB, scoped narrowly to configuration items, was never positioned to answer.

A Starting Path for IT and EA Leaders

IT and EA leaders sitting on a struggling or failed CMDB effort do not need to start over from nothing. Much of what a CMDB effort already captured is valid raw material for a governed Enterprise Model — the gap is usually in structure, ownership, and connection, not in the underlying data itself.

• Inventory what the current CMDB or configuration effort actually captures today, and identify which of that content maps to a defined, governed Noun Type rather than a loosely scoped configuration item.

• Establish governed inventories first for the non-discoverable entities that bridge discovered assets to the business — Capabilities, Value Streams, and the non-discoverable aspects of Applications, Data and Information, and Integrations. Relationships cannot be built to entities that do not yet exist, so resource that work from day one rather than leaving it as an afterthought that auto-discovery’s early progress can paper over.

• Assign clear ownership for each inventory to address some of the governance discipline Forrester says CMDB efforts lacked.

• Bring business-side leaders, such as business architects and data owners, into the effort, since the entities that bridge to the business, such as Capabilities and Value Streams, cannot be defined by IT alone.

• Identify the relationships between inventories that matter most to the organization — which applications depend on which vendors, which capabilities depend on which applications — and begin connecting them deliberately, rather than leaving those relationships undocumented.

• Treat data quality as an ongoing discipline, not a one-time cleanup, with the same continuous-improvement expectation Forrester places on a working IT Management Graph.

• Involve people with genuine data-management expertise and experience designing and delivering complex systems, along with process experts from across the enterprise rather than only ITSM process owners, to more directly address the skills gap Forrester identifies behind CMDB failure.

• Expand scope deliberately, beyond configuration items, toward the fuller Inventory of Inventories an Enterprise Model is built to support.

None of these steps require replacing existing tools overnight. They require treating configuration and dependency data as a governed, connected asset from the start, rather than repeating the same narrowly scoped effort a fourth time and expecting a different result.

Learn More

IT and EA leaders ready to build a governed, connected model of their enterprise should start with the IF4IT Enterprise Model and Modeling Best Practices document, which defines the Inventory of Inventories and the semantic relationships that make cross-domain reasoning possible.

For the governance practices — ownership, quality, and lifecycle — that keep the inventories underlying that model current and trustworthy, see the Enterprise Inventory Management Best Practices document. And for more on how a connected Enterprise Model makes a specific, high-stakes problem like technical debt traceable across the applications and capabilities it affects, see Governing Technical Debt as an Enterprise Discipline.