Engineering Ontology-Driven Data Products in Microsoft Fabric: From Business Concepts to Agentic AI

Part 3 of 4 — Rethinking Enterprise Architecture: From Data Structures to Business Meaning

In the previous articles, we looked at why business meaning matters and how conceptual models and ontologies can work together.

Now, I want to bring those ideas into a data platform. Microsoft Fabric is an interesting place to explore this because it brings data engineering, storage, analytics and semantic capabilities into one environment.

Fabric IQ also introduces native ontology capabilities. Having looked at these, we need to be clear about the responsibilities of each component.

A lakehouse does not automatically understand the business concepts represented by its tables and an ontology does not automatically create a reliable data product.

We still need good engineering.

A practical use case

Let us use a Customer Financial Exposure data product.

The business wants to understand customer exposure across accounts, financial products and connected legal entities.

The information comes from several systems.

CRM contains customer records.

Core banking contains accounts and transactions.

Compliance systems contain ownership and legal entity information.

Risk systems may contain classifications and exposure assessments.

The challenge is to bring this information together without losing the differences in business meaning.

Start with the business concepts

I would begin with the conceptual model.

The important concepts include Party, Customer, Account, Financial Product, Legal Entity and Financial Exposure. We agree on the relationships and definitions.

For example,

A Party can be a person or organisation.

A Customer is a role played by a Party.

An Account Holder is not necessarily the same as a Beneficial Owner.

These distinctions matter when we calculate exposure or analyse ownership relationships.

The ontology can formalise the shared concepts. It then becomes a reference that data products and analytical models can use.

Build the data foundation in OneLake

For the engineering implementation, I would use a lakehouse-based approach where it fits the workload.

The bronze layer holds source-aligned data.

The silver layer contains standardised, validated and reconciled information.

The gold layer provides curated data products.

For our example, the gold product might include:

• dim_party
• dim_account
• bridge_party_account
• bridge_entity_ownership
• fact_financial_exposure

These are example structures, not mandatory Fabric designs.

The correct model depends on the reporting requirements, data volumes, update patterns and business rules. The key point is that each structure should have a clear mapping to the business concepts.

For example, dim_party implements part of the Party concept.

The relationship tables implement specific connections between business entities.

Those mappings should be documented and validated.

Where Fabric IQ ontology fits

Fabric IQ provides ontology capabilities for defining business entity types, properties and relationships, with bindings to supported data sources. This gives us a way to connect business concepts to information held in Fabric.

For example,

Party could be represented as an ontology entity type.

Account could be another.

The party-holds-Account relationship could be linked to curated relationship data.

This is useful because consumers can work with shared business concepts rather than relying entirely on individual table structures.

However, Fabric IQ ontology capabilities are still evolving. Architects should confirm the current feature support, APIs, lifecycle management and production suitability before relying on them.

I would also avoid assuming that every ontology-driven requirement can be implemented natively in Fabric. Some use cases may still need additional semantic tooling or custom engineering.

Keep Power BI semantic models

I would not replace Power BI semantic models with an ontology. They solve different problems.

A Power BI semantic model provides trusted analytical measures, relationships and reporting structures.

For our example, it might define Total Financial Exposure, Exposure by Product and Exposure by Customer Segment.

The ontology describes the wider business meaning of those concepts.

The semantic model implements the calculations required for analytics.

Both should use agreed business definitions. If the definition of Financial Exposure changes, the relevant analytical measures should be reviewed.

Get Khathiravan Raj Maadhaven’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

That connection between business meaning and analytical implementation is where I see practical value.

Where a knowledge graph could help

Some questions are difficult to answer using simple table joins.

Consider:

“Which customers are indirectly connected to a high-risk legal entity through several ownership relationships?”

A graph representation may help us explore those connections.

For example:

Party → controls → Legal Entity

Legal Entity → owns → Account

Account → associated with → Financial Exposure

A graph can make relationship traversal easier, it does not automatically establish whether an ownership relationship meets a regulatory threshold. Those calculations and decisions still need the appropriate business rules.

I would introduce graph capabilities when the relationship complexity justifies them, rather than making them a requirement for every data product.

Connecting the data product to Agentic AI

Now imagine a risk analyst asking an AI assistant:

“Which customers have significant exposure to high-risk organisations, and why?”

I would not want the AI model to guess the meaning of exposure from table names. Instead, the solution should provide the agent with approved business context and access to trusted data services.

The process could work like this.

• The agent interprets the question.
• It identifies the relevant concepts such as Customer, Financial Exposure, and Legal Entity.
• Agent then discovers the approved data product or analytical service.
• It retrieves the required information through the set of authorised tools.
• Finally, it presents the consolidated findings with the relevant relationships, calculations and source context.

Any sensitive operational action remains subject to the organisation’s approval process.

• The ontology helps with interpretation.
• The data product supplies reliable information.
• The analytical model or governed service performs trusted calculations.
• The agent coordinates the interaction.

Keeping these responsibilities clear is important.

What about Fabric data agents?

Fabric data agents can provide natural-language access to supported Fabric data sources and can be integrated with other AI applications through supported interfaces.

They are useful building blocks for this type of architecture. But an agent integration protocol does not replace authentication, authorisation or data governance. I would validate the current supported sources, ontology integration and security behaviour before selecting the implementation approach.

For regulated workloads, I would also test how the agent handles incomplete data, ambiguous questions and requests outside the user’s permissions.

Make the data product contract part of the design

The data product should have a clear contract.

For Customer Financial Exposure, I would capture:

• Business owner: Financial Risk.
• Grain: One exposure assessment per agreed Party, Product and Assessment Date.
• Refresh: Daily, subject to the source availability requirements.
• Quality: Valid identifiers, accepted currency codes, reconciled values and required assessment dates.
• Security: Confidential financial information.
• Semantic references: Party, Account, Financial Product and Financial Exposure.
• Consumption: Approved SQL and analytical interfaces.

This gives the engineering team a clear set of requirements. It also provides a basis for automated validation.

A schema change is not the only change that matters. If the business changes the calculation of Financial Exposure, that could affect reports and AI applications even when the table structure stays the same.

How I would implement the first version

I would keep the first implementation small.

• Choose one data product.
• Agree on the conceptual model.
• Build the required source mappings and curated data structures.
• Introduce the ontology definitions.
• Connect them to the supported Fabric data sources.
• Create the analytical model and data contract.
• Then test a small number of realistic business questions.

I would measure whether the approach improves clarity, reuse and reliability. If it works, extend it to another product.

If it introduces more complexity than value, simplify the design.

Closing thought

Microsoft Fabric gives us useful building blocks for bringing data engineering, analytics and business semantics closer together. The quality of the architecture still depends on the decisions we make.

We need clear definitions, reliable mappings, good data products and controlled AI access.

An ontology can help connect these elements.

The real test is whether that connection makes the solution easier to understand, maintain and extend.

Next in the series: Building an Ontology-Driven Data Product Factory in Microsoft Fabric.