What the Data Pyramid Is Missing

Imagine you are working on a data warehouse project. It launches on schedule. The architecture diagram is beautiful, and leadership celebrates with a huge party. Now wake up to reality. Most warehouse projects run over budget, the data is incorrect or missing, and the code is held together with layers of confusing notebooks or sloppy stored procedures. A few years later someone is asking for budget to rebuild the whole thing from scratch.

If that sounds familiar, you are in good company. In a 2024 Gartner survey of more than 1,200 data management leaders, 63% said their organizations either lacked the right data management practices for AI or weren’t sure they had them. Gartner now predicts that through 2026, organizations will abandon 60% of AI projects that aren’t supported by AI-ready data.

Bad data is expensive too. Gartner estimates that poor data quality costs organizations an average of $12.9 million every year. An advanced enterprise warehouse can run past $1 million, and that’s before licensing fees. A 2021 survey by Wakefield Research for Dremio found that only 22% of data leaders had fully realized a return on their data investments over the previous two years.

So why do we keep building new data warehouses on the classic data pyramid?

You’d probably say it’s the most logical approach. You collect the data, organize it, structure it and make it reliable with proper governance. That paves the way for a suite of fun AI models. I fully agree, which is why I almost deleted this article more than once before deciding this conversation needs to happen in the data community.

So what’s my issue with the data pyramid?

In a perfect world, it truly is the gold standard. However, nothing in the data world is perfect. Deadlines are unrealistic and bureaucracy is slow. Most importantly, the business doesn’t really know what it wants.

Sure, they may email you hundreds of old Excel reports and ask you to rebuild them in Power BI or Tableau. Ask them to narrow those down to a handful of KPIs, and they’re lost.

When a warehouse has to be rebuilt, management may blame a bad consulting company or incompetent developers. The truth is usually a lack of planning.

I have never seen a bad data warehouse in the first month or two of the project. But I have inherited warehouses that would make you curse in three languages. Even the best architectures fall into the same trap, including ones that follow strict standards for modular, decoupled code with proper error handling. That trap is business confusion.

One day Tom asks you to build something. Two weeks later you need to add a field. A month later come a few more tweaks. Over time your code becomes unrecognizable, patched together with CTEs, CASE statements, duct tape and bubble gum.

I once worked at a company where Data Factory pipelines were nested inside other pipelines four layers deep. First, you had to find the core of the code. Then you slowly traced it back and tried to decipher the logic. The original developers were long gone. Our project manager described it with an old Russian proverb, “В тихом омуте черти водятся,” which loosely means “devils live in still waters.” Each pipeline seemed simple on its own, but the product was failing under its own weight, and underneath was a mess nobody could untangle. The reality was that it needed to be simplified and completely rewritten. Instead, the CTO demanded that we blindly build a marketing dashboard without even letting me interview the marketing team. My list of clarifying questions was completely ignored. In desperation, I quickly tacked on more sloppy code and spent my evenings applying for new roles on LinkedIn.

So what should you do?

It’s time to add a new layer to the bottom of the data pyramid. Call it the proof of concept (POC) layer. This isn’t a new idea. Agile BI practitioners have preached it for years. But it’s still rarely done.

Build small, isolated dashboards directly in Power BI. Don’t worry if they’re slow and disorganized. Add whatever the business asks for. Then, once everyone is worn out after a few months, sit down and ask the key questions.

• Who is actually using this dashboard?

• What can be removed?

• How do we simplify this?

• Can we combine several charts into one?

  
  

Then retire what nobody uses and polish the few dashboards that survive. They should give you exactly what you need and make sense to a new employee on day one. Give them a proper UX design and a consistent color theme, and include a data dictionary.

Keeping the POC layer from becoming permanent

I can already hear the governance team groaning. Messy dashboards built by analysts sound like a recipe for Power BI sprawl and shadow IT. They can be, if nobody sets boundaries. A few simple guardrails keep this layer honest.

Give it an expiration date. Every POC dashboard gets a review date, usually 60 to 90 days out. If it hasn’t earned a spot in the real build by then, it gets retired.

Fence it off. Keep POC work in its own clearly labeled workspace, and give each dashboard a named owner. Nothing in it should ever be called “certified” or “official.”

Let usage decide. Power BI’s usage metrics show who is actually opening each report. A dashboard nobody has viewed in 30 days is a requirement nobody needs.

Write down every decision. Keep a running log of each KPI, its definition and who asked for it. That log is the real deliverable. Most of the dashboards are disposable, but the requirements they uncover become your warehouse blueprint.

The goal isn’t to replace the warehouse with a pile of Power BI files. It’s to make every mistake while mistakes are still cheap.

How this saves you money

These early dashboards may be slow, clunky and burn unnecessary CPU, but you now have clear business buy-in and metrics people actually use. When it’s time to build a proper data warehouse, you can hand this plan to your developers. You have a real blueprint instead of a “figure it out as we go” plan.

A consultant friend walked me through this idea about a month ago. His firm works with smaller companies on limited budgets and starts by proposing simple reports in Power BI. They might land a modest $30,000 or $50,000 contract. By the end, the customer is thrilled with the results and gives them several more. Senior leadership sees a clear return on investment, and the firm builds a strong relationship with the client.

He called it a win-win. The firm gets more work, and when the client is ready for a real warehouse, there’s already a plan. It cuts down on the back-and-forth that slows projects down and avoids messy rework. Because management has already seen the end product, they’re more forgiving of unexpected delays. Nobody rushes bad code to hit a deadline.

Putting it all together

So no, I don’t think the data pyramid is wrong. It’s just missing its foundation, which is the requirements layer.

In a perfect world, the business would gather every requirement and hand it over in a neat notebook with clean diagrams. In that data heaven, processes would never change and money would grow on trees.

Since most of us still live on Earth, a citizen developer approach at the start actually works. Empower your junior analysts to build reports and ask the business better questions. Let them build flows in Power Automate or test tools like Zapier and SyncHub. Your resident tech genius will cringe, but everyone’s data knowledge will improve.

Odds are your first warehouse won’t get everything right anyway. So let that first attempt be a cheap one. Build the dashboards first, learn what the business truly needs, and then build the warehouse right the first time.

References

1. Gartner. “Lack of AI-Ready Data Puts AI Projects at Risk.” Gartner Newsroom, February 26, 2025.

2. Chien, Melody. “How to Improve Your Data Quality.” Gartner, via CDOTrends, July 19, 2021.

3. ScienceSoft. “Data Warehouse Cost and Pricing Models Explained.” ScienceSoft, accessed October 2026.

4. Dremio. “Data Warehouse Costs Soar, ROI Still Not Realized.” Business Wire, August 12, 2021.