Millie Summary:
- Data ontology gives enterprises a shared operating language for data.
- Enterprise data challenges are increasingly about context, not access.
- The strongest ontology programs start with business decisions, not enterprise-wide modeling.
Written by Jordyn Geiger, Growth Development Analyst
Most enterprise data programs of the last fifteen years have solved a physical problem: where information sits, how it moves, and how fast users can get to it. Warehouses, data lakes, lakehouses, and cloud platforms delivered real value on that front. What they did not resolve is the harder problem underneath – different parts of the organization often disagree on what the same information means.
In practice, this shows up everywhere. CRM and Finance rarely share a single definition of customer. Product hierarchies diverge between ERP, service, and engineering. Revenue can mean booked, recognized, recurring, or net depending on who is in the room. The same physical asset carries different identifiers and ownership trees across maintenance, field service, and the ledger. Experienced employees navigate these gaps. Systems do not.
That gap was tolerable when the job of technology was to produce reports. It is not tolerable when AI is asked to interpret data, recommend actions, and sit inside operating workflows. More data access does not equal more business understanding. The constraint has shifted from connectivity to context. Ontology is how leading organizations are closing that gap.
From Structure to Meaning
Stripping away the academic packaging and ontology is a practical construct: a machine-readable model of the business – its entities, the relationships among them, and the rules that govern those relationships. The shift is from tables and application schemas to concepts the business already uses: Customer, Product, Contract, Device, Account, Trade, Facility, Asset, Supplier, Service Event, Revenue.
The leverage is in the links. A customer places an order; the order contains a product; the product draws from multiple suppliers; once installed, that product sits under a service agreement, generates quality events, and appears differently in revenue, margin, and cost-to-serve. People who run the business hold that map in their heads. The systems holding the records usually do not.
Classical data architecture answered where data lives and how to query it. Ontology answers what the data represents and how it connects to everything else the enterprise depends on. That matters because the questions boards and operating leaders care about – true customer profitability, products that destroy service margin, assets that create outsized operational exposure, technology spend that is duplicated, suppliers that concentrate risk – never live in one application. Pulling the data together is necessary. Establishing shared meaning is what makes the answer usable.
How This Plays Out in Complex Industries
Healthcare and medtech make the point clearly. A connected device carries a serial number, software version, bill of materials, manufacturing lot, service history, install base location, quality record, regulatory file, and telemetry stream. Each of those datasets has value on its own. The strategic value appears when the relationships are explicit. A software defect is not an isolated ticket; it maps to a device-population sharing a hardware revision, build date, configuration, or geography. A quality signal that looks local in one system can become a portfolio issue once it is connected across the product lifecycle. With that model in place, teams stop asking only what happened and start asking what else is exposed and where to intervene first.
Financial services face the same issue from another angle. Customer, legal entity, account, product, transaction, counterparty, exposure, and profitability cut across platforms built for different mandates. Commercial coverage may organize the relationship one way; Finance by legal entity; Risk by a third hierarchy. Each view can be correct in its lane. Without an explicit model linking them, institutions burn cycle time reconciling numbers and explaining why two accurate analyses disagree. Ontology does not force every system to look the same. It states how the perspectives relate – critical when the question spans business units rather than a single application.
Capital markets push the relationship density further. A security connects to an issuer, identifiers, venues, market-data feeds, orders, executions, portfolios, counterparties, risk engines, surveillance, clearing, and settlement. Market data illustrates the business consequences. A feed is not just a line item on a vendor invoice. It supports specific applications, desks, instruments, regulatory obligations, and client workflows. Deciding whether that feed is essential, redundant, or consolidative requires tracing consumption to workflow to business value to operational risk. Once those dependencies are modeled, technology cost, franchise value, and resilience can be evaluated in one frame.
Utilities are structurally suited to the same approach. Customer to premise to meter to feeder to transformer to substation – plus weather, vegetation, asset condition, demand, and field activity – forms a network, not a spreadsheet. Those signals historically sit in separate GIS, asset, outage, telemetry, billing, and field systems. Represent the relationships consistently, and a sensor anomaly stops being an isolated reading. It becomes an asset with history, a position in the network, a downstream customer set, and a defined response path. Observation turns into consequence – and that is where operating value moves.
Why AI Raises the Stakes
AI does not reduce the need for semantic discipline; it amplifies the cost of not having it. Connecting a model to enterprise data is getting easier. Ensuring the model applies the right business interpretation is not.
An agent can select the correct revenue field and still use the wrong revenue definition. It can name the right supplier and miss that the supplier sits under three components across five priority products. It can flag an asset anomaly and ignore the customer commitments, financial exposure, or regulatory obligations attached to it. In each case the answer can look polished and still be wrong for the business – which is a dangerous failure mode, because the output is persuasive.
As organizations move from copilots that answer questions to systems that shape decisions and execute steps in workflows, retrieval alone is insufficient. They need an explicit layer of entities, trusted metrics, relationships, definitional ownership, and source authority. Ontology is a core piece of that context stack. The operating sequence is no longer data >> report. It is data >> context >> reasoning >> decision >> action. The more authority AI receives further down that chain, the less optional the context layer becomes.
Start with the Decision, Not the Enterprise Model
The fastest way to stall an ontology effort is to treat it as a multi-year, enterprise-wide modeling program. Organizations do not need every entity defined before they create value. They need to start from a decision they care about improving.
Which customers are at risk? Which products inflate service cost? Which assets warrant intervention? Where is technology spend duplicated? Where does supplier concentration create material exposure? Where would an agent remove real friction from an existing process? Work backward from that question: entities, relationships, metrics, systems of record, and definition owners. That keeps the work tied to outcomes and forces a point that technical discussions often skip – systems cannot agree until the business agrees.
Where the Microsoft Stack Fits
For enterprises already deep in Microsoft, the pieces are converging into a single capability rather than a set of disconnected projects. Fabric covers data engineering, analytics, real-time intelligence, and semantic models. Fabric IQ adds the business ontology – entities, relationships, and operational context – over that foundation. Data Agents expose governed information through natural language. Purview wraps the estate with catalog, lineage, classification, and policy. That context can then surface into Microsoft 365, Foundry, Copilot Studio, and custom agents instead of staying trapped in the data platform. The architectural point is integration: foundation, semantic layer, governance, and AI interaction designed as one system.
How MILL5 Approaches the Work
We treat this as business architecture first, platform second. The goal is not another semantic layer, another lakehouse, or another AI interface in isolation. The goal is to connect those investments to how the enterprise truly runs and to the decisions technology is supposed to improve. We structure the work across Strategy, Build, and Operate.
Strategy starts with the operating questions that matter and the outcomes leadership wants to move. We identify priority use cases, map the critical entities and relationships, pressure-test the current data estate, surface conflicting definitions, clarify governance, and pin where analytics or AI will create measurable value. The deliverable is a sequenced roadmap from architecture to outcomes – not a technology diagram that floats free of the P&L.
Build converts that model into working capability: modernizing the data foundation where needed, connecting fragmented sources, standing up semantic models and ontologies, implementing lineage and access controls, delivering analytics, and putting Data Agents or other agent workflows into the tools people already use. This is also where demos and durable capability diverge. The quality of the experience is only as good as the definitions, permissions, relationships, and business logic underneath it.
Operate accepts that neither the business nor its semantic model is static. Products, customers, systems, metrics, and regulations change; AI use cases expand. The operating layer covers ongoing governance, monitoring, cost control, security, model hygiene, and continuous refinement of the data and semantic architecture. Firms that run this as a living capability compound their return. Firms that treat it as a one-time build do not.
The Question has Changed
For two decades, the dominant question was where information lived and how quickly it could be accessed. The next question is whether technology understands what that information means in the business – and how it connects to the rest of the operating model.
That question is the same whether the enterprise is running a medical-device portfolio, managing financial exposure, operating a capital-markets franchise, or keeping a utility network reliable. Most of these organizations already have more data than they can use. The next source of advantage is attaching that data to shared definitions, relationships, and operating context, so people and intelligent systems reason from the same model of the business.
Ontology, in that light, is not a modeling exercise. It is becoming the operating language of the enterprise – the layer that lets analytics, AI, and agentic systems understand not only what data they can reach, but why it matters.
That is the work MILL5 does with clients: define the business context, build the technology around it, and operate it as the enterprise evolves.
To discuss how ontology can create a stronger foundation for enterprise data, AI, and agentic systems, contact Jordyn Geiger and the MILL5 team at jordyng@mill5.com.
