The Real Cost of Data Architecture Technical Debt (And How It Spreads Across Your Business)

The cost of “good enough” data architecture won’t hit your business all at once. That’s what makes it so insidious.

When Brian Jones, Senior Director of Data Services at Papa Johns, joined the company, he inherited exactly this kind of system. There was an older Oracle Essbase implementation that franchises and corporate users had relied on for years. Alongside it sat a new enterprise data warehouse in Google BigQuery and a Tableau environment meant to modernize the data stack. In practice, the move created a fragmented architecture where metrics were defined inconsistently across tools and performance trade-offs meant constantly trimming data to keep dashboards responsive.

As Brian put it: “We had to constantly maintain those [Tableau extracts] to make sure the refreshes would actually finish when they were supposed to.” When performance suffered, the workaround was to remove data until the tool would load.

The Papa Johns leadership eventually reached a breaking point: “They never knew what the right answer was because everybody came with a different opinion on the same ask.” This pattern plays out across enterprises at every scale.

Yes, fragmented data architecture slows down your dashboards. But it also makes AI-powered analytics structurally impossible. By the time you feel that, you’ve already built an organization around the workarounds.

A semantic layer is an infrastructure decision that makes every other data and AI investment actually work.

Signs your data architecture is “good enough” (and costing you):

• Metrics don’t match across tools
• Dashboards require extracts or trimmed data
• Analysts spend more time reconciling than analyzing
• Business users export to Excel to get answers
• Performance depends on reducing data, not scaling it

As organizations move toward agentic analytics and AI-driven decision-making, “good enough” data architecture becomes a liability. AI systems depend on consistent definitions, complete context, and reliable performance. When those break, AI only amplifies the problem.

The 5 Ways “Good Enough” Data Architecture Slows Your Business Down

The costs associated with “good enough” show up in slower decisions, misallocated engineering time, and a steady erosion of trust in data.

Slow Data = Slower Decisions (and Missed Opportunities)

When query performance is inconsistent, teams either wait or work around it. The cost isn’t just time. It’s the decisions that get made on stale context, or the decisions that don’t get made at all because the data takes too long to surface. 

When Teams Argue Over Numbers Instead of Acting on Them

When the same metric is calculated in multiple tools, teams spend time aligning numbers instead of analyzing them. Data analysts spend approximately 80% of their time cleaning and preparing data, leaving only 20% for actual analysis. At Papa Johns, for example, Essbase and Tableau produced different answers because the metric logic was defined independently in each system, and the Essbase cubes reflected an older version of how the business operated. The company had no concept of delivery aggregators like DoorDash baked into its legacy cubes, yet those cubes remained the source of truth for a large segment of users.

Why You’re Making Decisions on Incomplete Data

To make Tableau perform reasonably, the team had to cut corners: fewer years of data, fewer attributes. These trade-off make a direct business impact. Poor data quality and incomplete analytical context cost organizations an average of $12.9 million annually, according to Gartner. When analysts are making decisions on trimmed data sets, they’re making decisions without full context. Further, AI models and agents trained on incomplete or trimmed data lose critical business context.

Engineering Time Is Wasted Keeping the System Alive

Fragile systems require constant attention. Brian’s team had someone check the Essbase environment every single morning just to make sure it was running. The tableau extract refreshes required constant monitoring. Every change to a dashboard risked breaking refresh completion times. This is engineering capacity spent on preservation rather than progress.

When Your “Modern Stack” Still Ends in Excel

When the official path is too slow or too inconsistent, users build their own. At Papa Johns, this meant a population of users downloading cross-tab exports from Tableau to paste into Excel, a multi-step manual process that introduced metric drift. Despite the availability of advanced BI tools, an overwhelming 76% of analysts still use spreadsheets as their primary tool for data preparation. When that happens inside a company with a modern data stack, it’s a signal that the official path isn’t working.

When Data Architecture Breaks Trust at the Executive Level

When executives stop trusting the data, one of two things happens: they make decisions by instinct anyway, or they demand reconciliation processes that consume more time than the decisions themselves are worth. A recent survey of finance and IT leaders found that 44% had used faulty data in decisions, and 12% said bad data cost their organization at least $10 million. The damage compounds.

AI systems trained in that same environment won’t produce a better answer either. They’ll produce faster disagreement.

Why Delaying Data Architecture Fixes Makes the Problem Exponentially Worse

When the system works well enough and migration is expensive, the instinct is often to defer. 

But every quarter the decision is deferred, the architecture gets harder to replace. More dashboards get built on top of inconsistent metrics. More users build workarounds that become load-bearing processes. More institutional knowledge calcifies around the limitations of the existing system.

By the time organizations decide to fix it, they’ve already built workflows around the constraints. The hidden tax is no longer just operational, it’s structural.

What Happens When You Eliminate Data Architecture Friction

When Papa Johns introduced AtScale as a semantic layer between BigQuery and its consumption tools, the first change was architectural: metric logic moved from individual Tableau data sets and Essbase cubes into a single, governed semantic model. The same definitions powered Excel connections, Tableau dashboards, and anything else connecting to the cube.

The extract refreshes went away. Row-based security that was previously duplicated in individual Tableau workbooks moved into the semantic layer. And for the first time, an analyst in Excel and an analyst in Tableau were guaranteed to see the same answer.

But the more revealing signal came from something unexpected: BigQuery costs went up.

“Our BigQuery cost has actually grown and gone up,” Brian noted. “It was actually much more cost than we actually forecasted… we did not anticipate this level of enthusiasm and adoption for AtScale.” The excitement is so high that Brian said, “We oftentimes will have users when they’re providing us requirements that they always start with: it must be AtScale.”

With the friction removed, Papa Johns’ leadership teams now receive daily AtScale-powered emails with week-to-date, period-to-date, quarter-to-date, and year-to-date metrics. Franchise users start their mornings with the data. Planning for high-volume sales days like Super Bowl, New Year’s, and Halloween begins with pulling comparable historical periods from AtScale.

Why the Semantic Layer Is Becoming Critical Data Infrastructure

The Papa Johns story is a compelling case for treating the semantic layer as infrastructure rather than as a reporting tool.

A centralized semantic layer does three things that a distributed architecture cannot:

1. It enforces consistent metric logic across every consumption surface and every AI system
2. It removes performance trade-offs that degrade both dashboards and AI outputs
3. It creates a governance layer that AI agents can reliably operate against

Gartner elevated the semantic layer to essential infrastructure in the 2026 top trends in D&A. That recognition reflects what enterprises are learning in practice. The problem was never which BI tool to use. It was whether there was a single, trusted source of business logic sitting underneath all of them.

The Real Cost of Data Architecture Technical Debt

The most expensive data problems in enterprise aren’t system outages or failed migrations. They’re the small inefficiencies that compound across every team, every day: slow queries, reconciliation meetings, manual exports, and decisions made on trimmed data sets.

You can run a business on “good enough” data architecture. But you’ll never run it at the speed your competitors will.

Brian Jones presented the full Papa Johns story at the Semantic Layer Summit 2026. Watch the session on demand here.