If in Doubt, Blame ‘Data Quality’

It doesn’t matter what you’re trying to build, what grand architectural strategy you’ve pitched to the board, or whether you even know what you’re doing in the first place. When a project implodes, there is one universal, infallible get-out-of-jail-free card: blame the quality of the data.

Long before the current obsession with artificial intelligence, data meshes, and hyper-scale analytics, there was a time when data quality was a genuinely massive, unavoidable impediment to business integration.

Back in the late eighties and early nineties, Executive Information Systems (EIS) promised the earth yet delivered very little. The reason was simple: storage was brutally expensive and required skills were as rare as hens teeth.

An 80-megabyte hard drive cost a small fortune, forcing engineers to use hyper-compressed, makeshift coding techniques just to save bytes:

0 meant Male; 1 meant Female.
r meant Red; g meant Green; w meant White.
USD, GBP, and DM were hacked into shorthand, alongside truncated dates and times.

Naturally, every system team invented their own unique dialect. System A’s definitions rarely agreed with System B’s. Integration wasn’t just difficult; it was a chaotic nightmare. When companies bought a new application, they simply bought a new physical box to run it on, creating a sprawling archipelago of disconnected, conflicting databases.

Then came the turning point; or so we thought.

Engineers developed clever tools designed to clean, match, de-duplicate, and reconcile data. ETL complements entered the market, promising to balance the data books once and for all. Believers in data governance cheered. Progress had arrived.

Except it hadn’t.

What actually happened was a classic exercise in corporate theater. Enterprises bought the tools, stored them in their software libraries, ticked the box for “doing something about data quality,” and then… did absolutely nothing.

It was activity without purpose, acquisitions without goals, and gestures without value.

Very few teams possessed the actual will, budget, or patience to integrate data quality checks into their pipelines. Data quality for enterprise data warehouses and analytics remained stagnant. Instead of solving the issue, organizations created a widening chasm between IT hyperbole and business reality.

Everyone claimed data quality was a “top strategic priority,” but look at almost any agile backlog or project plan today: how many sprint boards explicitly allocate real time, budget, and engineering capacity to fix root-cause data issues?

Very few, if any.

When push comes to shove, IT departments, well-intentioned as they may be, frequently act like boys in short trousers. They buy the fancy gear, but lack the discipline or mandate to do the dirty work.

Fast forward to today, and the playbook hasn’t changed an inch.

When Big Data initiatives stalled? Bad data quality.

When the Data Mesh failed to deliver its decentralized utopian vision? Data quality issues.

When multi-million-dollar AI and advanced analytics models hallucinate or collapse under their own weight? Blame the data quality.

The clowns leading these implementations possess only one consistency: their fickle, predictable stupidity. Paying lip service to data quality while refusing to fund, test, or build actual data pipelines is an absolute menace to the industry.

Blaming bad data for the failure of a data-centric project is like an incompetent writer complaining that dictionaries render their work meaningless, that pens have a mind of their own, or that computers are for wimps.

As Bertrand Russell famously observed: “A stupid man’s report of what a clever man says can never be accurate, because he unconsciously translates what he hears into something he can understand.”

He could easily have been describing the modern hype cycle surrounding enterprise data architecture.

When all else fails, the last refuge of the analytically clueless will always be to blame the data. It’s harsh, yes, but entirely valid.