From Conceptual Data Models to Ontology-Driven Architecture: An Engineering Blueprint
Part 2 of 4 — Rethinking Enterprise Architecture: From Data Structures to Business Meaning
In the first article, I argued that business meaning should have a stronger place in enterprise architecture. That leads to a practical question ‘If we already use conceptual data models, why do we need ontology?’
It is a fair challenge.
Conceptual data modelling is an established discipline. It helps us understand the business without becoming distracted by technology. I would not replace it. Instead, I would use conceptual models and ontologies together.
Start with the conceptual data model
Imagine we are designing a Customer Financial Exposure solution for a financial services organisation. The business wants to understand how customers are connected to accounts, products and legal entities.
Before discussing source tables, we identify the main concepts: Party, Customer, Account, Financial Product, Legal Entity and Financial Exposure.
We then discuss their relationships.
A Party may be a Person or Organisation.
A Party may act as a Customer.
A Customer may hold one or more Accounts.
An Account may be associated with Financial Products.
A Party may have an ownership or control relationship with a Legal Entity.
This gives us a useful business view. It also helps expose disagreements early.
For example, is Customer a separate type of entity, or is it a role played by a Party?
There is no benefit in leaving that decision until the engineering team starts joining tables.
What does the ontology add?
A conceptual model explains the main business entities and relationships.
An ontology goes further by describing their meaning in a more formal way.
For example, we could define:
Party: A person or organisation recognised within the business domain.
Customer: A role played by a Party under agreed business conditions.
Account Holder: A Party with a defined relationship to an Account.
Beneficial Owner: A Party that meets the relevant ownership or control definition.
These definitions can then be linked to classifications, relationships and constraints. Where appropriate, ontology languages such as OWL and RDF Schema can express formal semantics. SHACL can be used to validate graph data against specified shapes and constraints. These technologies serve different purposes, and not every solution needs all of them.
The main architectural value is that the business definitions are explicit and can be reused.
An important modelling example
Consider the difference between Account Holder and Beneficial Owner.
A simple customer-account model might show that a Customer owns an Account. That may be sufficient for basic reporting but it may be misleading for a regulatory or risk use case.
An Account Holder could be an organisation.
The Beneficial Owner could be a person who controls that organisation through one or more ownership relationships.
If our model treats those roles as interchangeable, we could produce incorrect results.
An ontology can help us represent the distinctions more clearly.
However, the ontology does not determine the actual beneficial owner on its own.
We still need reliable ownership data and the relevant legal or regulatory rules.
This example shows why I believe modelling should start with the business meaning rather than the available tables.
How the models fit together
I would use the following architecture flow:
Business requirements → Conceptual data model → Ontology → Logical models and mappings → Physical implementation → Data products and applications
This is a useful way to show the responsibilities, although real delivery is iterative.
The conceptual model helps us agree on the domain.
The ontology formalises the concepts and relationships that need shared meaning.
The logical model describes the information structures needed for a solution.
The physical model determines how those structures are implemented.
Mappings connect source-system representations to the governed business concepts. Governance, testing and change management apply throughout.
Get Khathiravan Raj Maadhaven’s stories in your inbox
Join Medium for free to get updates from this writer.
There is no need to complete the entire ontology before starting implementation.
The models can evolve together as the team learns more about the domain.
The above diagram shows how I would connect business understanding with technical implementation.
I would start with the business requirements and a conceptual data model, then use an ontology to establish shared definitions and relationships. From there, logical models and mappings guide how we build data products and applications.
This is not intended to be a strict step-by-step process. The models will evolve as we learn more about the business and the available data.
From the business model to the data platform
Let us return to our financial exposure example. The organisation has three systems.
A CRM platform holds customer information.
A banking platform holds accounts and transactions.
A compliance platform holds ownership and legal entity relationships.
Each system has its own identifiers and structures. Our logical model needs to describe how the required information will be organised.
We might create Party, Account and Financial Exposure structures, along with relationship tables. The physical implementation could use Delta tables in a lakehouse.
The ontology provides the shared definitions to which those structures map. This creates a useful separation. We can change the physical implementation without changing the meaning of Party. And we can introduce another data source without redefining the entire business domain; Of course, mappings still need validation.
Two records referring to the same business concept are not necessarily the same real-world entity. Identity matching remains a separate engineering problem.
What about Power BI semantic models?
A Power BI semantic model and an ontology have different roles.
A Power BI semantic model is designed for analytics. It defines relationships, measures, calculations and the structures used by reporting tools.
An ontology can represent a wider business domain, including concepts and relationships that are not directly related to reporting.
For example, a semantic model may define Total Financial Exposure as a measure. The ontology can describe what Financial Exposure means and how it relates to Party, Account and Financial Product.
The two models should agree where they overlap, they do not need to be identical.
Governance matters more than the modelling tool
One risk with ontology programmes is that they become modelling exercises disconnected from delivery.
A team creates a detailed model, publishes it and moves on. Meanwhile, engineers continue building pipelines and data products using different definitions.
I would avoid that.
Each important business concept should have an owner.
Changes should be reviewed.
Mappings should be tested.
Data product contracts should reference approved definitions where relevant.
If the definition of Financial Exposure changes, we should be able to identify the affected products and analytical measures. That is a practical reason to maintain the ontology.
How I would introduce this in an organisation
I would begin with one domain and a small group of stakeholders.
Choose a business problem where different systems use overlapping concepts.
Create the conceptual model.
Agree on the important definitions.
Formalise the concepts that need to be shared.
Map them to a real data product.
Then test whether the approach helps the team understand and deliver the solution more consistently.
I would not start by trying to model the entire organisation.
That would create a lot of work before proving any value.
Closing thought
Conceptual data modelling already gives us a good starting point for understanding a business.
Ontology gives us a way to make some of that understanding more formal and reusable.
The two approaches are complementary. For me, the important measure is whether they help engineers make better design decisions and reduce confusion between systems.
If they do, they have earned their place in the architecture.
