What the Ontology truly is
The cleanest framing: the Ontology is a decision and action layer, not a data model. Traditional in-house platforms (warehouse, lake, semantic/metrics layer) model data for storage and query. The Ontology models the operational reality of the business — objects (nouns), links (relationships), actions (verbs that write back), and functions (logic) — so that decisions and operations can run on it directly.
The distinguishing feature is the kinetic element: actions that write back to source systems. A metrics layer or data catalog is read-only — it describes. The Ontology is closed-loop — you observe, decide, and act, and the act propagates. That’s the line between “another semantic layer” and the Ontology.
How you actually integrate legacy systems
You don’t rip and replace. The pattern:
-
Pipelines ingest from each source (ERP, CRM, MES, support) into datasets — sources stay where they are.
-
Datasets are mapped to object types via backing pipelines; links connect objects across sources.
-
The “unified” part is entity resolution — the same customer in three systems collapses into one object. This is the hard, valuable part, not the ingestion.
The architectural shift: apps, automations, and AIP agents talk to objects, never to tables. The physical layer underneath can change without breaking anything above it.
Why it must be the Ontology
-
Decoupling. The decision layer is insulated from physical data. Swap a pipeline, the apps don’t break.
-
One definition. “Shipment,” “customer,” “order” are defined once and reused everywhere — kills the metric-drift problem where every team has its own version.
-
Write-back / closed loop. BI tells you what happened. The Ontology lets you do something about it and have it land in the system of record.
-
It’s the substrate AIP reasons over. Agents get typed, governed, permissioned access to the business — not raw tables.
-
Compounding reuse. The second and third use cases are cheap because the core objects already exist.
On your skepticism — you’re half right
“Just start building” is wrong if it means modeling to a single workshop demo. But “model the whole enterprise upfront” (waterfall ontology) is how these projects die. The disciplined middle: identify the durable core objects multiple decisions depend on, model those at the right grain, and let use cases accrete decoration around them. Start with a real decision — but pick a decision whose objects you’ll reuse. The “feel” senior devs talk about is mostly grain selection and what belongs in the shared core vs. the use-case edge.
The tangible payoff, stated plainly: simulate before you commit (branching), govern at the object level, and turn read-only analytics into operations that close the loop.