Over the years, I’ve had hundreds of conversations that started something like this: “Our data is pretty good.”
Sometimes the statement is made with confidence. Sometimes it’s accompanied by a shrug. Occasionally it’s followed by, “Sure, we have a few duplicate records, some missing values, and a little inconsistency here and there, but nothing serious.”
Then I ask a few questions.
- Do different departments produce different numbers for the same business metric?
- Does anyone spend hours reconciling reports before executive meetings?
- Are there multiple copies of the same data scattered across warehouses, lakes, marts, and cloud platforms?
- Can you explain where a particular value originated?
- Who owns that data?
At this point, things usually get very quiet. In truth, most organizations don’t have bad data. They have something almost as dangerous. They have data that is “good enough.”
That’s what inspired me to write my latest book, The Cost of “Good Enough” Data. The biggest risks facing modern enterprises aren’t usually dramatic database failures or catastrophic outages. They’re the countless small compromises organizations make every day that gradually erode confidence in their information.
We’ve Been Here Before
As database professionals, we’ve always understood that shortcuts eventually become expensive. Poor normalization creates redundancy. Missing indexes become performance problems. Applications that ignore referential integrity eventually corrupt data.
I’ve spent decades tuning Db2 systems, and one lesson has remained remarkably consistent: most performance problems aren’t hardware problems. They’re design problems.
The same principle applies to enterprise data. Adding more storage doesn’t fix poor governance. Adding more processors doesn’t eliminate inconsistent business definitions. Moving data to the cloud doesn’t magically improve data quality.
Poor architecture simply becomes poor architecture at a larger scale.
The New Cost of Data Debt
For years we’ve talked about technical debt. Today we need to recognize another form of debt: data debt.
Data debt accumulates when organizations postpone cleaning data, documenting metadata, establishing ownership, or eliminating redundant data movement.
Like financial debt, the interest compounds. Projects take longer because no one trusts the underlying information. Developers duplicate existing data because they can’t locate authoritative sources. Analysts spend more time validating reports than analyzing them. Infrastructure grows because duplicate data consumes unnecessary storage and compute resources.
The organization becomes increasingly complex while becoming no more informed.
AI Has Changed the Stakes
Artificial intelligence has forced executives to pay attention to problems database professionals have been discussing for years.
Many organizations assume successful AI begins by selecting the right model. I believe it begins somewhere entirely different. It begins with trusted data.
LLMs (Large Language Models) don’t understand your customers. They don’t know your products. They don’t understand your business rules. They learn those things only from the information you provide.
If enterprise data is inconsistent, incomplete, duplicated, or poorly documented, AI doesn’t correct those shortcomings. Instead, it amplifies them.
Garbage in still produces garbage out. The difference is that AI can now produce garbage at remarkable speed. And that means garbage in produces amplified garbage out!
Governance Isn’t the Enemy
Few topics generate more resistance than data governance. Mention governance and many people immediately envision endless committees, excessive documentation, and bureaucratic delays.
That isn’t governance. Good governance answers practical questions such as:
- Who owns this data?
- What does this field actually mean?
- Where did this information originate?
- How is it validated?
- Who is responsible for correcting errors?
Without those answers, organizations waste enormous amounts of time rediscovering information they should already know.
One of the approaches I discuss in my book is Robert S. Seiner’s Non-Invasive Data Governance methodology. I appreciate its practicality because it doesn’t require creating an entirely new bureaucracy. Instead, it recognizes that people already perform many governance activities—they simply aren’t recognized, coordinated, or managed consistently.
That’s a much more realistic path toward improving enterprise information.
Metadata Deserves a Promotion
Metadata has often been treated as an afterthought. It shouldn’t be. Metadata provides context, it establishes lineage, it documents transformations, it enables reproducibility, and it supports compliance.
Perhaps most importantly, it allows people to understand what enterprise data actually represents. And now it does the same thing for AI systems.
Without metadata, organizations eventually lose institutional knowledge. Experienced employees retire, applications evolve, systems migrate, and before long no one remembers why a particular calculation exists or where a critical data element originated.
Metadata preserves that knowledge.
What This Means for DBAs
Some people suggest the role of the DBA is shrinking but I do not agree. The responsibilities are expanding. Performance tuning, backup/recovery, security, availability, and capacity planning all continue to be essential.
DBAs possess knowledge that organizations desperately need as they modernize their architectures and deploy AI. They can help to document workload patterns, where operational data originates, and how applications actually use business information.
The title may evolve. The responsibilities certainly will. But the need for experienced database professionals isn’t disappearing, it’s becoming more strategic.
Start with the Fundamentals
One message I hope readers take away from the book is that organizations don’t need another revolutionary technology. They need disciplined data management. You know, the core fundamentals including maintaining an inventory of critical data, reducing unnecessary copies, improving metadata, documenting business definitions, continuously measuring data quality, and simplifying data pipelines.
And it is always a good idea to review your existing architecture before buying more infrastructure.
Those recommendations aren’t exciting. Neither are indexes, referential integrity, or well-designed SQL. Yet those fundamentals have delivered reliable systems for decades.
The same is true for enterprise data.
Technology trends will continue to come and go. AI will undoubtedly evolve. New platforms will emerge. Vendors will introduce new architectures promising to solve every problem.
Through all that change, one truth remains remarkably stable: Organizations that trust their data make better decisions. And organizations that merely hope their data is “good enough” eventually pay the price.
And in my experience, that bill is always much larger than anyone expected.