Skip to content

Enterprise Ontologies and the AI Context Problem

Background

In 2025, Gartner, Forrester, and several platform vendors arrived at the same conclusion from different directions: AI agents need a semantic foundation to reason about an enterprise. Without one, they hallucinate — generating plausible-sounding answers about systems, capabilities, and dependencies that don't exist or are incorrectly connected.

The industry started calling this a "context graph" or "enterprise ontology." The terminology is new. The underlying work is not — EA teams have been building pieces of this for decades. What changed is that AI made the formalization urgent.

This article traces the evidence, shows who's already doing it, and explains where Linked.Archi fits.

The analyst convergence

Gartner IOC 2025

At the Gartner IOC Conference in 2025, enterprise ontologies emerged as a cross-cutting theme. The EA Principals Journal summarized the strongest message as: AI transformation requires semantic coherence. Knowledge graphs, semantic layers, and shared vocabularies were presented as necessary for AI trust, data governance, cross-domain queries, and digital product management.

Business capabilities were described as "the enterprise genome" — stable building blocks that underpin strategy execution and AI automation targeting.

Gartner Leadership Vision 2025

Gartner's five mistakes EA teams make included "falling behind on AI strategy" and "failure to modernize technology portfolios." Both require structured, queryable knowledge about what exists, who owns it, and what business capability it serves. Spreadsheets can't support this at scale.

Forrester — Context graphs as convergence

Forrester's April 2026 analysis made the most important point: what the market calls "context graphs" is not a new invention. It's a convergence of disciplines that have been building pieces of the enterprise knowledge graph for 40 years:

  • EA has maintained entity graphs (what exists, who owns it, what capability it serves) since Zachman (1987)
  • ITSM/CMDB built configuration item graphs in the 1990s
  • APM built runtime execution traces in the 2000s
  • Process mining reconstructed actual workflows from event logs
  • Architecture decisions document the "why" of the IT estate
  • FinOps mapped cost to services to capabilities

Forrester identified two layers that must converge: the entity graph (what exists) and the decision trace (why it exists). Neither works alone. Entity graphs without decision traces are inventories that can't answer "what should we do next?" Decision traces without entity grounding float unmoored.

The article also warned that calling something a "context graph" doesn't solve the fidelity problem — the map is always wrong, the CMDB is always stale. But AI agents need this unified view regardless.

Foundation Capital and the VC wave

Foundation Capital declared in December 2025 that the next major platforms will be "systems of record for decisions." This triggered VC investment in graph-based platforms (Glean, Graphlit, TrustGraph) and prompted ServiceNow to announce its Context Engine.

Forrester's response was measured: the opportunity is real, but it's not greenfield. Startups that ignore the 40 years of foundation built by EA, ITSM, and APM will fail at the entity-grounding problem.

Who's already doing it

Siemens — STAR

A knowledge graph of software architectural knowledge — design patterns, decisions, technology components — used in production by 200–300 architects at Siemens for exploring and reusing architectural knowledge across projects. The ontology defines concepts directly analogous to Linked.Archi's architecture decision extension.

Source

NASA JPL — IMCE

The Integrated Model-Centric Engineering Ontological Modeling Framework — OWL ontologies for systems engineering that map to UML and SysML. Used to manage spacecraft and deep-space communication system architectures. Demonstrates that ontology-based architecture description works at the highest levels of complexity and safety criticality.

Source

FIBO — Financial Industry

The Financial Industry Business Ontology (EDM Council) is the most mature industry-standard enterprise ontology in production. Defines instruments, parties, contracts, and regulatory requirements. Used by global banks for regulatory reporting, cross-system integration, and AI-driven compliance. Published as open-source RDF/OWL with SKOS classification and modular design — the same architectural patterns we use.

Source

Platform vendors

  • Google Cloud evolved Dataplex into a Knowledge Catalog — a "universal context engine" aggregating metadata with semantic relationships for AI agent retrieval. Source
  • Atlassian markets its Teamwork Graph as a knowledge graph extracting entities and decision traces from Jira, Confluence, and Bitbucket.
  • ServiceNow announced a Context Engine connecting CMDB items, incident histories, and service relationships into a queryable graph for AI decisions.
  • Palantir has an Ontology layer that Forrester identified as architecturally a general-purpose context graph.

What this means for EA

Forrester's most important insight: EA is the practice that connects these layers. EA has always maintained the "interpretive overlay" connecting technical reality to business meaning — capability maps, application-to-capability assignments, target-state architectures. These sensemaking abstractions exist only in the enterprise ontology, not in the running systems.

The problem is that most EA teams have built this knowledge in formats that aren't machine-readable: capability maps in PowerPoint, application inventories in Excel, models in proprietary tools, decisions in Confluence. The shift is about formalizing what EA already knows into something AI agents can query.

This is not a theoretical concern. Without entity grounding: - AI agents can't answer "which capabilities are at risk if we decommission this platform?" — that requires traversing from technology through application through business layers - Cross-domain queries are impossible without a shared semantic model - Governance stays manual — compliance checking depends on human memory - Decision traces remain disconnected text files

With a formalized ontology, these become SPARQL queries.

How Linked.Archi relates

We started building this before the analyst community converged on the same conclusion. The ecosystem addresses the layers Forrester identifies:

Entity graph — the core ontology and modeling language ontologies (ArchiMate, BPMN, C4, Backstage, LeanIX) provide the "what exists" layer. All elements share arch:core, enabling cross-source queries.

Decision trace — the architecture decisions extension provides the "why it exists" layer. Decisions link to affected elements via ad:relatedConcept, making the trace queryable.

Governance — SHACL shapes enforce constraints in CI/CD. Ownership, completeness, relationship validity — automated, not periodic.

AI access — the MCP server exposes the graph to AI agents. SPARQL for architects, natural language for everyone else.

The convergence diagram Forrester describes — EA + CMDB + APM + process mining + decisions + FinOps converging into a unified graph — is the architecture we've been building toward. The arch:core foundation is the semantic layer that gives meaning to entities from all these sources.

Honest caveats

  • "Mandatory" is analyst language. In practice, most organizations won't build a formal enterprise ontology. They'll adopt platform vendors' context graphs (ServiceNow, Atlassian) and get partial coverage without the full semantic richness. That's fine for many use cases.

  • The fidelity problem is real. Forrester is right that the map is always wrong. An enterprise ontology is only as good as the discipline to keep it current. SHACL validation helps (it catches staleness), but it doesn't solve the fundamental problem of someone needing to update the model.

  • Semantic web skills are a barrier. RDF, OWL, SPARQL, SHACL — these are not mainstream skills. The tooling is improving (AI agents can write SPARQL for you), but the learning curve is real.

  • Not every organization needs this. If your architecture fits in one person's head, or if a single tool (LeanIX, Ardoq) already serves all stakeholders, the overhead of a formal ontology isn't justified.

Differentiating from adjacent tools

vs CMDB: A CMDB is the operational entity graph — configuration items, service relationships. An enterprise ontology adds business meaning (capabilities, value streams), decision traces, and semantic constraints. The CMDB is one data source that feeds into the ontology.

vs Data Catalog: Data catalogs (Dataplex, Atlan, Collibra) focus on data assets — tables, schemas, lineage. Enterprise ontologies focus on architecture assets — systems, capabilities, processes, decisions. Complementary, not competing. Google's Knowledge Catalog is moving toward convergence.

vs Platform vendor context graphs: ServiceNow, Atlassian, and Palantir build context graphs from their own data (CMDB, Jira, incidents). They capture operational reality but lack the sensemaking layer that EA provides — capability maps, target-state architectures, decision rationale. An enterprise ontology provides the business meaning layer that grounds their operational data.

The core point

AI agents need entity grounding. EA has been building the entity layer for 40 years — capability maps, application inventories, technology standards, decision rationale. The missing step is formalization: moving this knowledge from PowerPoint and proprietary tools into a machine-readable, queryable, AI-accessible format.

That's what Linked.Archi provides. Not a new idea — a formalization of what EA already knows, in W3C standards, with validation and AI access built in.

References

Analyst research

Real-world deployments

Linked.Archi documentation

Standards

  • ISO/IEC/IEEE 42010:2022 — Architecture Description
  • W3C RDF 1.2, OWL 2, SHACL, SPARQL 1.1, SKOS