Overview
In this episode of The Dashboard Effect, Brick Thompson and Caleb Oaks take on a problem that derails more BI initiatives than bad data or poor tool selection: the data model that was not built to change. The conversation covers the specific architectural decisions that create brittle models, offering a clearer picture of what flexible, scalable BI design actually looks like underneath the surface.
For any team that has delivered a dashboard and then watched it become a source of confusion rather than clarity, or been told that a simple report change will take weeks, this episode provides the diagnostic for understanding what went wrong and how to approach it differently. See how Blue Margin’s Managed Analytics & Insights builds data models at the right level of granularity from the start, so that reports adapt to business changes without requiring a rebuild every time requirements evolve.
What This Episode Covers
The Problem with Bad Models (0:00 – 3:30)
The hosts open with a scenario that will be immediately recognizable to anyone who has worked inside a BI environment for more than a few months: an executive asks for a report to be updated with a new product category and is told it will take weeks. That timeline is not a function of the request being complicated. It is a function of a data model that was not built to accommodate change without significant rework.
The Importance of Transactional-Level Data (3:31 – 5:16)
Scalable reports are built on granular, transactional-level data. When data is stored at its lowest level of detail, new categories, products, regions, and dimensions surface automatically as the underlying data changes. The model does not need to be manually updated every time the business adds something new. That flexibility is only possible when the foundation preserves the raw detail rather than collapsing it into summarized structures upfront.
Why Developers Take Shortcuts (5:17 – 7:17)
Summarizing data before it reaches the model is a common shortcut, and the motivations behind it are understandable. Smaller file sizes, simpler queries, and a lack of familiarity with how tools like Power BI handle granular data through features like Matrix visuals all push developers toward pre-aggregation. The problem is that those shortcuts trade short-term convenience for long-term rigidity, and the cost of that trade-off grows with every report built on top of the compromised model.
Redundant Data (7:18 – 10:52)
One of the most common structural mistakes is placing the same information in multiple locations within a model, storing totals in both a header dimension and a detail fact table, for example. Redundancy creates inconsistency the moment the two copies fall out of sync, which they inevitably do, and it forces report developers to make judgment calls about which version of the truth to use.
Inflexible Structures and the Value of Star Schema Design
Models designed around a solid star schema handle growth automatically. When new data arrives, visuals update without requiring custom code for every new category or dimension. The difference between a model that scales gracefully and one that requires manual intervention every time the business changes is almost always traceable to whether the underlying structure was designed with that growth in mind from the beginning.
Who It’s For
This episode is worth your time if you are a BI developer or data engineer who has inherited a model that is difficult to extend and wants a clearer picture of what went wrong architecturally, a technical lead responsible for setting standards for how data models are built across your team, a business stakeholder who has been frustrated by how long report changes take and wants to understand the technical reasons behind those delays, or any organization preparing to invest in a new BI initiative and wanting to build on a foundation that will not require a rebuild eighteen months later.
Why It’s Worth a Listen
The weeks-long report change is one of the most visible symptoms of technical debt in a BI environment, and it is one that erodes trust between data teams and the business users they support. This episode connects that symptom directly to its root causes in a way that is actionable for developers and comprehensible for the non-technical stakeholders who experience the consequences.
The discussion of why shortcuts happen is particularly useful. Understanding that pre-aggregation is often a product of inexperience with specific tool capabilities, rather than a deliberate architectural choice, reframes it as a training and standards problem rather than a judgment call that cannot be undone. Teams that invest in getting the model right from the start spend less time explaining why changes take longer than they should.
For anyone who has sat in a meeting where a simple-sounding request became a multi-week project, this episode is a useful explanation of the architectural decisions that created that situation and what it would take to build something that does not work that way.
