Semantic models are the most underrated work in analytics

Ask a room of data people what they’re excited about and you’ll hear about streaming, lakehouses, LLMs. Nobody says “measure libraries.” I get it. And yet the highest-leverage thing I shipped last year was a Power BI semantic model.

Here’s what the before looked like. Weekly reporting ate about two days. Not because queries were slow, but because every report rebuilt the same logic from scratch. Four analysts, four definitions of “active customer.” Two of them handled refunds differently. The Monday meeting spent its first twenty minutes arguing about whose number was right, which is a spectacular way to burn executive attention.

The insight that changed my mind about this work: the arguing was not a people problem. It was an architecture problem. When metric logic lives inside each report, disagreement is the default state. You cannot align four copies of anything by asking people to be careful.

So the logic moved into one place. Shared semantic models on top of our warehouse layer, a DAX measure library where “active customer,” “net revenue,” and friends are defined exactly once, reports that consume measures instead of reimplementing them. Boring to describe. Genuinely hard to do well, because every definition you centralize is a small negotiation with everyone who had their own version.

Results, after the dust settled: the weekly cycle went from ~2 days to ~4 hours, and a new dashboard now takes under a day because it starts from working, agreed-upon parts. The Monday argument died. Not because anyone won it, but because there was nothing left to argue about.

The unsexy conclusion is that a semantic layer is a treaty, not a technology. The DAX is the easy part. Getting Product and Growth to sign the same definition of “active” was the actual engineering.

If your team argues about numbers in meetings, you don’t need a faster warehouse. You need the argument to happen once, in code, with a version history.