Most business intelligence teams develop a rather expensive habit.
A report shows an odd number, or someone asks a perfectly reasonable question and the report can't answer it. The first reaction is usually to open the file, write another DAX measure, add a calculated column, or build yet another page with a handful of slicers.
The problem is solved. At least for now.
I've seen this happen enough times to know where it usually leads. A report that started out simple gradually becomes a collection of exceptions and workarounds. Six months later, nobody is quite sure why half the measures exist, but everyone is afraid to touch them.
At that point, the report isn't really the problem.
The real problem is usually further down the chain, in the semantic layer.
The trap of quick fixes
There's nothing inherently wrong with writing DAX or adding a report page. Sometimes that's exactly what you need to do.
The trouble starts when the report becomes the place where business logic gets invented.
Say the business needs a slightly different definition of revenue. It's tempting to solve that in the report. Then another team needs a variation, so they create their own measure. Someone else builds a separate report and implements the logic slightly differently.
Eventually, you have three reports showing three different versions of the same KPI.
I've seen variations of this many times. Nobody deliberately sets out to create conflicting numbers. Each individual workaround makes sense when you're looking at the immediate problem. It's the accumulation of those workarounds that creates the mess.
And once people stop trusting the numbers, adding another dashboard isn't going to fix the underlying problem.
Report pages should be interfaces for consuming business logic. They shouldn't be the place where that logic is negotiated and reinvented.
Your semantic layer is where the real work happens
A semantic model is easy to think of as the technical step you do before you start building charts.
I think that's underselling it.
The semantic layer is where you translate messy operational data into something the business can actually reason about. It's where definitions, relationships, calculations, and business context come together.
Treating it as a proper product changes how you approach it.
Instead of solving every new question inside a report, you establish the definition once, model the relationships properly, and make that logic available to everyone.
Get that part right and a lot of downstream work becomes surprisingly boring. And boring is good.
You start to get a few important benefits:
-
One definition of reality. If "active customer" has a specific business definition, that definition exists in one place rather than being recreated by every analyst.
-
Better self-service. Users can explore the model without having to understand every underlying table or accidentally create their own version of a relationship or calculation.
-
A better foundation for newer capabilities. Things like Direct Lake and conversational interfaces depend on having a well-structured model with clear definitions. If the model doesn't make sense to a human, expecting an AI system to reliably make sense of it is probably optimistic.
That last point is becoming increasingly important.
We're asking more and more tools to interpret our data for us. But AI doesn't magically turn a poorly modelled data environment into a good one. If your definitions are ambiguous and your relationships are questionable, automation is only going to make the ambiguity easier to scale.
Your semantic model can't rescue bad data
There's another part of this that often gets overlooked.
A good semantic layer doesn't compensate for fundamentally bad source data.
If you're spending half your modelling effort cleaning strings, fixing inconsistent keys, standardising dates, or trying to work around strange source-system structures, the model is doing work that belongs somewhere else.
That work should generally happen upstream in your warehouse or lakehouse.
The goal is to get clean, standardised data into the modelling layer so the semantic model can concentrate on what it is actually good at: relationships, definitions, context, and business logic.
Modern storage formats such as Delta Parquet make this architecture increasingly practical, but the underlying principle isn't really new. Keep the heavy data preparation upstream and keep the semantic layer focused on making the data understandable.
So what should you do when the numbers look wrong?
The next time someone tells you a metric looks wrong, don't immediately open the report and start writing DAX.
First ask why it's wrong.
Is the source data incorrect? Is the transformation logic wrong? Is the business definition unclear? Is the relationship in the model wrong? Or is the report simply asking the model to answer a question it wasn't designed to answer?
Those are very different problems.
Sometimes the answer really is a new measure. But if you're repeatedly solving the same type of problem in individual reports, that's a pretty good signal that the fix belongs somewhere more central.
The goal isn't to eliminate complexity. Data environments are complicated by nature.
The goal is to put that complexity in the right place.
Keep the heavy lifting in the pipelines. Put business definitions and relationships in the semantic layer. Keep the report itself as simple as possible.
When you do that, the next person who opens the report doesn't need to understand a fifty-line DAX measure just to work out why the number on the screen is what it is.
And that's probably a much better definition of a successful BI environment than having another impressive-looking dashboard.