We’ve Been Building The Foundation For 40 Years
A year ago, I wrote about the graphic future of IT management — IT management platforms converging on graph architectures to create a digital twin of the IT organization. The governance question I raised: Who owns this graph?
Nine months later, Foundation Capital declared that the next trillion-dollar platforms will be built on “systems of record for decisions” — what they call context graphs. VCs rushed in. Glean, Graphlit, Pixee, and TrustGraph all scrambled to position. This week, ServiceNow announced Context Engine: enterprise context for every AI decision.
ServiceNow framed this as a greenfield opportunity. It’s not. Many disciplines have been building pieces of this graph, in isolation, for decades.
Enterprise architecture (EA) has maintained entity graphs — what exists, who owns it, what business function it serves — since Zachman (1987).
Application performance monitoring (APM) built runtime execution traces starting in the early 2000s.
Process mining reconstructed actual workflows from event logs (Celonis, 2011).
ServiceNow accumulated the largest corpus of structured workflow data in most enterprises.
Atlassian is focused on its Teamwork Graph, one of the clearest implementations of the core thesis, with motivations and decisioning extracted from Jira records.
ChatOps (2013) moved operational decisions into logged, searchable channels. Incident analysis tools such as PagerDuty (with its 2019 Jeli acquisition) structured post-incident decision chains into escalation topology and AI-generated postmortems.
Organizational network analysis mapped informal communication structure from collaboration metadata (Microsoft Viva Insights, SWOOP Analytics).
FinOps and technology business management mapped cost to services to capabilities.
Software bill of materials mandates created component-level dependency graphs.
Nobody builds more than two or three of these layers. Dynatrace knows the service topology but has no idea what business capability it serves. Jeli knows why the incident was hard to resolve but can’t see the architectural decisions that made the system fragile. Celonis knows how work actually flows but has no visibility into service ownership. EA knows the capability map but couldn’t tell you what happened at 3 a.m. when the billing system went down.
Foundation Capital is right that these need to converge. But no startup will build this from scratch.
EA Is The Practice That Connects The Layers
Enterprise architecture is the only discipline that was ever responsible for cross-layer sensemaking.
EA was always supposed to maintain the interpretive overlay that connects technical reality to business meaning: capability maps, application-to-capability assignments, target-state architectures, technology standards, rationalization strategies. These aren’t runtime objects. In the old Buddhist saying, a finger pointing at the moon is not the moon. These are sensemaking abstractions that humans use to navigate a complex estate and decide what to do about it.
That’s what a context graph is: a queryable layer of sensemaking abstractions that connects entity state to decision rationale across systems and time.
EA and related disciplines have been building layer one — entity, ownership, capability — for 40 years. This is the foundation most context graph proposals skip, which is why their agents hallucinate: They’re trying to reason about decisions without solving the entity-grounding problem first.
What EA never captured is why decisions were made. Why was the migration deferred? Why do we have three CRM systems? The reasoning lived in architects’ heads and walked out the door when they left. Architecture decision records have started to surface this, but they’re still largely textual.
This is the new contribution that the context graph movement offers: layer two, the decision trace layer — the reasoning that shaped the estate, made queryable. “How did we handle this before?”
Neither layer works in isolation. Decision traces without entity grounding float unmoored: You know a decision was made but can’t connect it to a specific application or business capability. Entity graphs without decision traces are accurate enough as inventories but useless for figuring out what to do next. The context graph is the reunification: EA’s entity foundation plus the decision trace layer, in one queryable graph.
The Fidelity Problem Nobody Escapes
Every EA team knows: The map is always wrong. The configuration management database (CMDB) is stale. The capability model doesn’t match how the business operates. The application inventory misses the shadow IT. The dependency map was accurate last quarter.
Calling the map a “context graph” doesn’t change this. Adding decision traces makes it worse — now you have entity staleness and reasoning decay.
Our technical debt workbench research identified a reinforcing doom loop we call observability decay: Low investment in estate visibility leads to stale data, which leads to misallocated investment, which leads to debt in invisible corners, which leads to surprise incidents, which erodes trust in the data, which leads to less investment in maintaining it.
The context graph startups will hit this wall. Every CMDB vendor hit it. Every EA tooling initiative hit it. Fidelity requires sustained governance investment and people committed to maintaining the sensemaking layer. AI will help with some of the drudgework, and still, a person needs to look at it and say “this is good.”
Why “Context Graph,” Not “Digital Twin”
The industry also frames this as a “digital twin” — a perfect copy of reality you operate on instead of the original. That framing gets the problem wrong.
The copy is never perfect (that’s the fidelity problem above). But more important: The copy isn’t just a copy. Business capabilities, technology categories, rationalization strategies, decision traces — none of these are in the running systems. They’re human sensemaking imposed on the systems. The CMDB doesn’t “twin” the data center; it classifies the data center using abstractions that exist only in the CMDB. That sensemaking layer has no source of truth to sync from because it was never in the original.
“Context graph” is the more honest framing. Some of that context is derived from reality (apps, servers, dependencies). Some of it is created by humans doing EA work (capability maps, decision traces, target-state architectures). Maintaining that human sensemaking layer is what EA has always been for.
What This Means
For EA leaders: You’ve been building context graphs since before the term existed. Your entity graph is the foundation. Decision traces are the layer you need to add. The developer portals, AIOps platforms, and incident tools are building adjacent layers. Your job is to connect them.
For CIOs: The context graph is an organizational capability you build, the same way EA has always been built — through sustained investment, governance discipline, and people committed to maintaining the map. AI agents will be extraordinary but only if they have a high-fidelity graph to learn from.
For context graph startups: You’re building on top of 40 years of EA practice, APM infrastructure, IT service management workflow data, and organizational knowledge scattered across a dozen tools. If you can’t integrate with the existing EA foundation, your decision traces will float without grounding.
The context graph is a convergence whose time has come — because AI agents need the unified view that no single discipline provides. EA built the foundation. Now it’s time to complete the graph.
This is a follow-up to The Graphic Future Of IT Management (March 2025).
