Overview
In this episode of The Dashboard Effect, Brick Thompson and Caleb Oaks clarify a distinction that gets blurred in many data projects: pipelines, data modeling, and reporting are not the same thing, and treating them as interchangeable or managing them as a single undifferentiated effort is one of the most reliable ways to make all three harder than they need to be. The episode walks through each layer, explains how they relate, and offers a practical framework for managing the complexity that builds up at the intersection of modeling and reporting.
For any team that has struggled to explain why a reporting change requires touching the model, or why a pipeline issue affects what users see in a dashboard, this episode provides the vocabulary and structure to make those relationships clear. See how Blue Margin’s Managed Data Service manages all three layers as distinct but coordinated disciplines, ensuring that data setup, modeling, and reporting work together without the technical debt that accumulates when the boundaries between them are left undefined.
What This Episode Covers
Data Setup and Pipelines (0:51 – 1:31)
Pipelines are the foundational engineering layer: pulling raw data from source systems, landing it in a data lake, and keeping it current through scheduling, delta loading, and error handling. This work is primarily a technical discipline concerned with reliability and efficiency. It is the prerequisite for everything that follows, but it is distinct from the modeling and reporting work that builds on top of it.
Data Modeling (1:32 – 3:05)
Modern data modeling is iterative rather than monolithic. The old aspiration of building a single, permanent, all-encompassing canonical model has given way to a more pragmatic approach: structure data specifically to support the business reporting needs at hand, and refine that structure as those needs evolve. The model is not a one-time deliverable. It is an ongoing translation layer between raw source data and the reporting layer that depends on it.
The Relationship Between Modeling and Reporting (3:06 – 4:45)
The purpose of a report directly shapes how the underlying model needs to be structured. A report tracking sales targets and a report calculating commissions may draw from similar source data but require meaningfully different modeling logic to produce accurate outputs. This interdependence is why modeling is often the most challenging part of a BI project: it requires translating data that was captured for operational purposes into a structure that serves analytical ones, and the business logic involved is rarely straightforward.
Balancing Model Complexity (7:50 – 9:30)
The hosts identify two failure modes at opposite ends of the complexity spectrum. Building a separate model for every individual report creates synchronization problems that compound over time. Forcing every use case into a single monolithic model produces something too bloated and rigid to serve any of them well. The hybrid approach they recommend maintains a primary model for core business metrics while allowing ancillary specialty models to handle unique scenarios, departmental edge cases, and one-off reporting requirements that would otherwise distort the main model.
Following Kimball Methodologies
The recommendation to follow Kimball methodologies, organizing data into star schemas with clearly defined fact and dimension tables, provides a scalable and well-understood framework for keeping the modeling layer organized as complexity grows. The methodology is not rigid doctrine but a proven structure that makes models easier to build, extend, and hand off to other developers.
Who It’s For
This episode is worth your time if you are a BI developer or data engineer trying to articulate to stakeholders why changes to a report sometimes require model changes and why that takes longer than adjusting a visual, a solutions architect designing a data environment that needs to support a range of reporting use cases without becoming unmanageable, a data team lead evaluating how to organize modeling work across a library of reports with varying complexity, or any organization that has experienced the frustration of a data project where pipelines, modeling, and reporting got conflated into a single workstream that proved difficult to manage or extend.
Why It’s Worth a Listen
The pipeline, modeling, reporting distinction sounds straightforward until a project is underway and the layers start bleeding into each other. This episode gives teams a clear conceptual framework for keeping those concerns separate in practice, which makes each layer easier to manage, debug, and improve independently.
The hybrid model approach is the most practically actionable part of the conversation. Most data teams that have been building for a while have already discovered that neither extreme works, but they often arrive at a hybrid approach through trial and error rather than deliberate design. Having a clear articulation of what that balance looks like and why it makes sense gives teams a better starting point for the next project.
And the emphasis on iterative modeling rather than canonical model perfection is worth reinforcing for any organization that has watched a modeling project stall because the team was trying to solve every possible future requirement before delivering anything useful. The value in a data model is in what it enables today, not in how comprehensively it anticipates tomorrow.
