Overview
In this episode of The Dashboard Effect, Brick Thompson and Caleb Oaks introduce a framework for organizing BI implementations that addresses one of the most consistent sources of rework and technical debt in data projects: treating the data layer, the modeling layer, and the visualization layer as a single undifferentiated effort. Separating them into three distinct pillars does not slow the work down. It produces better outcomes at each stage and reduces the compounding costs of getting the sequence wrong.
For any team that has found itself rebuilding a model because the visualization requirements changed, or rebuilding a dashboard because the model underneath it was not structured correctly, this episode provides the framework that prevents both. See how Blue Margin’s Managed Data Service applies this three-pillar approach to deliver BI implementations that are built to last and built to extend.
What This Episode Covers
Pillar One: The Data Layer (1:08 – 4:04)
The data layer is the foundation of the entire framework, consolidating raw data from databases, APIs, and other source systems into a central data lake or warehouse. The hosts emphasize that building this layer independently creates an immediate and usable asset: analysts can begin discovery and exploration against the consolidated data even before modeling or reporting begins. That early value accelerates the overall project and surfaces data quality and coverage issues before they become blockers at a later stage.
Pillar Two: Data Modeling (4:07 – 6:04)
The modeling layer defines the business logic and structures that make reporting reliable and repeatable. Separating this work from visualization prevents the technical debt that accumulates when logic is embedded in the reporting layer rather than in a governed model that can serve multiple reports and use cases. Getting the modeling right before dashboards are built ensures that the visualizations on top of it accurately reflect the business rather than approximating it.
Pillar Three: Data Visualization (6:07 – 8:30)
The visualization layer is the user-facing output, the dashboards and reports that stakeholders actually interact with. This phase is where the team engages most directly with stakeholders to understand their specific goals and decision-making needs, ensuring that what is built is intuitive and actionable rather than technically complete but practically difficult to use. The user experience focus of this pillar is distinct from the engineering focus of the first two, and treating it as such produces better design outcomes.
Different Pillars Require Different Skill Sets (9:01 – 10:09)
The skills that make someone effective at backend data engineering are not the same skills that make someone effective at client-facing UI and UX design. Recognizing that distinction allows teams to staff each pillar appropriately rather than expecting a single generalist to execute all three well. Projects that are staffed to match the skill requirements of each pillar tend to produce higher quality outputs at each stage than those that rely on one person to cover the full range.
Synergy Between the Pillars (12:44 – 13:07)
While the three pillars are treated as distinct functions, they are not independent of each other. Information requirements flow from the visualization layer back through modeling to the data layer, which means the work is interconnected even when it is organized separately. That interconnection is a feature of the framework rather than a complication: clear interfaces between the pillars make it easier to identify and resolve dependencies than a monolithic approach where everything is tangled together.
Parallel Workflow Rather Than Strict Waterfall (12:06 – 12:40)
The three-pillar framework does not require a strict sequential approach where each layer is completed before the next begins. Teams can develop the pillars in parallel with coordinated handoffs, which allows for faster overall delivery while maintaining the separation that prevents the most costly forms of rework. The key is coordination rather than sequencing, and the framework provides enough structure to make that coordination manageable.
Who It’s For
This episode is worth your time if you are a BI project lead or data team manager trying to reduce the rework that comes from building visualization requirements into the modeling layer or modeling logic into the data layer, a solutions architect designing a BI engagement structure that needs to accommodate different skill sets and parallel workstreams without losing coherence, a business stakeholder who has experienced the frustration of receiving a dashboard that was technically functional but did not meet the actual decision-making needs it was built to serve, or any organization preparing to invest in a BI implementation and wanting to understand the structural approach that produces the most durable and extensible results.
Why It’s Worth a Listen
The three-pillar framework is valuable precisely because it is actionable rather than abstract. Most advice about avoiding technical debt in BI projects describes the problem without providing a structural solution. This episode provides the structure, explains why each separation matters, and addresses the practical questions about how the pillars interact and how teams can work on them in parallel rather than sequentially.
The skill set discussion is worth particular attention for teams that are staffing data projects. The assumption that a strong data engineer can also deliver a strong user experience, or that a skilled report builder can also architect a solid data model, leads to projects that are strong in one pillar and weak in others. Staffing to the specific requirements of each phase is a more reliable path to quality across the entire implementation.
And the synergy discussion is the most important counterbalance to the separation emphasis. The pillars are distinct but not isolated, and the information flow from visualization requirements back through modeling to the data layer is what makes the framework work as a cohesive whole rather than three disconnected work streams. Understanding how that flow works is what allows teams to coordinate effectively without collapsing the separations that prevent rework.
