The Semantic Model Is the Product

There is a quiet pattern I have seen repeat itself across at least a dozen enterprise BI engagements, and I think it is worth naming. It goes like this.

The business asks for a dashboard. A team builds the dashboard. Six months later, three more dashboards exist that look adjacent to the first one but produce different numbers for the same KPI. A workshop is convened. Definitions are debated. The “source of truth” question gets asked, and answered with a SharePoint document that nobody updates. Two years in, the BI program is widely regarded as a disappointment, the dashboards are quietly bypassed in favor of Excel, and someone at the executive level starts using the word “rationalization.”

The dashboards are not the problem. The dashboards were never the problem. The problem is that nobody treated the semantic model as the product.

What a semantic model actually is

A semantic model is the contract between the messy reality of source systems and the language the business uses to describe itself. It is where a column called cust_acct_id_v2 becomes a dimension called Customer with an attribute called Account ID. It is where four different definitions of “Active Patient” — one from billing, one from clinical, one from marketing, one from the data warehouse — get reconciled into one definition that everyone has signed off on, with a clearly-named DAX measure to back it up.

This sounds prosaic. It is the most consequential layer in your entire analytics stack.

When the semantic model is good, dashboards are nearly disposable. A new business question shows up, someone builds a Power BI report against the model in a day, and it lands on an executive’s screen by Friday. When the semantic model is bad — or, more commonly, when there is no semantic model at all and every report is wired directly to Snowflake or Databricks tables with bespoke logic — every new dashboard is a new translation project. Definitions drift. Numbers stop reconciling. Trust evaporates.

The half-life of a Power BI report is two years. The half-life of a well-designed semantic model is closer to a decade.

The economic argument

I know architecture arguments lose to economic arguments inside enterprises, so let me put this in the language that wins meetings.

Suppose your organization has 30 active Power BI reports, each containing roughly 12 measures, and roughly half of those measures appear in some form in multiple reports. If those measures live inside each report — which is the default in Power BI — you have approximately 180 places where the definition of a KPI is encoded. When the finance team changes the definition of “Net Revenue” — and they will, this happens every fiscal year — somebody has to find and update every one of those 180 places. Some get missed. The numbers stop matching. Trust degrades.

Now suppose those measures live in a shared semantic model, used by all 30 reports. The same change is made in one place. Every report updates automatically. The cost of change drops by roughly 30x.

This is not a theoretical calculation. It is the difference between a BI program that scales and one that quietly becomes a maintenance nightmare. I have walked into engagements where the second-largest line item in the BI team’s quarterly capacity plan was, effectively, “fixing measures that drifted.” Those teams were not bad teams. They had been set up to lose by an architectural choice nobody made consciously.

Three rules that have not failed me

Over the years I have arrived at three rules for semantic model design. They are not novel. But I have watched programs ignore each of them and pay the price.

Rule one: build the model before the first dashboard, not after the third.

The instinct is to build a quick report to demonstrate value, then refactor into a model “when we have time.” There is never a moment when you have time. The first three reports calcify into the de facto definition of the business, and refactoring them later becomes a political act, not a technical one. Build the model first. Even a thin one. It is the cheapest political insurance you will ever buy.

Rule two: one model per business domain, not one model per report.

The Power BI default — every report owns its own dataset — is a shortcut that becomes a tax. You want shared semantic models that span a coherent business domain (Finance, Operations, Patient Journey, Revenue Cycle), and reports that consume them as live connections. This is what Microsoft Fabric’s direct-lake mode is genuinely good at, and it is the part of Fabric I would not give up.

Rule three: the model is owned by an architect, not a report developer.

This is uncomfortable to write because it sounds hierarchical. But the model is the contract. Contracts need stewardship. Distributed authorship of contracts produces the exact divergence-and-drift problem the model exists to solve. Have a designated owner. Have a change-control process. Have a measure-naming convention enforced in code review.

What this looks like in practice

In a recent healthcare engagement, we inherited a Power BI footprint with about 40 reports and roughly 200 distinct measure definitions across them — some of which were variants of the same KPI under different names. Our first six weeks were spent not building anything new, but building a single shared semantic model covering the Admissions domain: 14 dimensions, one fact, and 47 measures, all with documentation and tested reconciliation against source systems.

When we started rebuilding reports against this model, the per-report development time dropped from roughly two weeks to roughly two days. More importantly, the conversation with stakeholders changed. They stopped asking “is this number right?” and started asking “what does this number tell us?” That shift is the entire reason this profession exists.

If your BI program feels like it is bleeding velocity, the dashboards are almost certainly not where the bleeding is. Look at the model. Or rather, look for the model. The fact that you have to look is itself the diagnosis.

---

Next dispatch: I’ll write about the specific decisions in that semantic model — why we put audit columns in the dimension and not in the fact, why we used USERPRINCIPALNAME-based RLS instead of static security, and the one mistake I made with composite models that I would not repeat.