When you need an ontology, and when it is just overhead

The word “ontology” can end a conversation with a board before it starts. It sounds like a multi-year knowledge-modelling programme run by specialists who speak a language nobody else understands. And that version does usually fail.

For the person deciding the budget, though, the question is not “do we need an ontology”. It is: what does it cost us today that we do not agree on what the things the business runs on actually are — a customer, an order, a site, a contract. Sometimes the answer is “not much”, and then an ontology is overhead. Sometimes you are paying for the gap every month, just under budget lines that are not called that.

Signs you are already paying for the missing model

Two systems, two numbers. Sales and finance report the number of customers and get different results. Every meeting starts by settling whose number is “real”, and the reconciliation exists only in one analyst’s head.

Duplicates as a running cost. The same customer three times in the sales system and twice in billing, and somebody cleans it up by hand every month. That is not a one-off mess, it is a recurring operational cost.

Reports with footnotes. Every summary needs a sentence explaining which definition it used. The footnote is a symptom: the definition exists, but nowhere a machine could read it.

Consolidation or acquisition. Merging systems after a deal, or replacing a core system, forces a mapping whether or not anybody calls it an ontology. The only question is whether it is done once and properly, or again for every report.

AI that has to reason across systems. Retrieval or an agent that needs to know that a record in one system and a document in another are about the same thing. Without identity rules it guesses, and it guesses convincingly.

Infographic

From overhead to necessity

One systemFootnoted reportsDuplicate customersSystem consolidationAI across systems

OverheadNecessity

When it is overhead

One system, one definition. If one system runs the whole business and nobody argues about what words mean, an ontology adds work without return. A well-kept glossary is enough.

Nobody has the authority to settle a dispute. Without somebody senior enough, the model can only be described, not agreed. Then it is better to sort that out first than to spend the budget on a careful description of the disagreement.

A scope of “the whole enterprise, up front”. A project that wants to model everything before anything uses it has a well-documented failure mode. That is not too little need, it is too much scope.

What it costs you, not the supplier

The supplier’s fee is only part of the bill. On your side, two things are needed.

The first is time from the departments that disagree: a conversation with each one separately, an hour or two, and access to somebody who knows the data in practice. The agreed parts of the model take an afternoon; the work is in the disputes.

The second is more expensive and less often planned: somebody senior enough to decide which definition each system means. It is usually a handful of decisions rather than dozens, but without them the project stands still.

The work on a core model serving one or two real use cases is typically four to eight weeks including implementation. If somebody proposes years, they are proposing a different project.

What the return looks like

The case does not have to rest on a promise of “better data quality” that nobody can measure. It can rest on things that already cost money today and should cost less afterwards.

Less reconciliation. Numbers agree across systems because they derive from one model rather than five conventions. Meetings stop opening with an argument about whose number is real, and reports lose their footnotes.

Less manual cleaning. Identity rules recognise the same customer across systems, so duplicates stop being a monthly task for somebody’s team.

Better retrieval and better agents. Both fail mostly on ambiguity rather than on capability. Given a resolved entity and its relationships, a system can filter to what is genuinely relevant instead of guessing convincingly.

A test that takes one afternoon

Take one number the business argues about regularly — customers, active contracts, operating sites — and ask two departments separately how they count it.

If the answers differ and nobody can say which is right for what, you have an ontology problem, whatever you decide to call it. If they agree, you have saved a budget, which is also a good outcome.

That conversation is where ontology design and engineering starts: narrow, tied to one or two real use cases, and with something that begins using the model within weeks.