I have come to realise that one of the biggest data problems organisations face isn't necessarily a lack of data. In fact, most organisations have more data than they know what to do with. The real problem is that, over time, they end up creating too many versions of the truth.

It rarely happens intentionally. As an organisation grows, new systems are introduced to solve new problems. One team implements a CRM, another builds an operational platform, another introduces a data warehouse, while another creates reporting pipelines to bring information from different systems together. Each decision makes sense on its own. Each system serves a purpose. But as these systems multiply, so do the places where data is stored, transformed, interpreted and ultimately consumed.

When meaning doesn't survive the journey

I have experienced this first-hand. One of the most difficult parts of working across different systems is not necessarily getting them to communicate technically. Modern technologies make it relatively easy to move data from one place to another — APIs, event streams, integration platforms and data pipelines can connect almost anything. The harder problem is making sure that the meaning and context of that data survive the journey.

A piece of information can pass successfully from one system to another and still become less useful along the way. A field may be renamed. A business rule may change. A transformation may be introduced without the downstream team fully understanding why. One team may interpret a particular value differently from another, and apply another layer of logic before it reaches a dashboard or report. Technically, everything may be working exactly as designed, yet the organisation can still end up with data that no longer represents the same thing it represented at the source.

We spend a tremendous amount of effort thinking about how data moves, but far less effort thinking about how its meaning moves with it.

Data on its own is not knowledge. A database can contain millions of records and still tell us very little unless we understand the context behind those records. The journey from raw data to something that can actually support a decision requires interpretation — where the data came from, what it represents, how it has been transformed, what assumptions have been applied to it and, ultimately, what it means to the person consuming it.

The same word, several meanings

This becomes particularly difficult when different teams have different perspectives of the same information. An engineer may look at a customer as a collection of records, identifiers and events. A product manager may see that same customer as a user moving through a product journey. Operations may see an active account that requires support, while Finance may see a revenue-generating relationship. Leadership may simply see a number representing customer growth.

All of these perspectives can be valid. The problem begins when the organisation doesn't have a common underlying definition.

Take something as simple as the word "customer." Does it mean someone who has created an account? Someone who has completed a transaction? Someone with an active subscription? Someone who purchased something in the last twelve months? Different teams can legitimately answer that question differently. But if each team builds its own definition into its systems and reports, the organisation eventually ends up with several different customer counts, all of which can appear correct depending on how they were calculated.

The same thing happens with revenue, active users, churn, retention, conversion, engagement and countless other metrics. Over time, organisations build an entire vocabulary of business terms that appear to have a shared meaning but actually represent different things to different teams. At that point, the problem is no longer simply technical. It becomes organisational.

Data debt

One of the lessons I have taken from this is that maintaining data integrity and defining what data actually means often takes a backseat when teams are under pressure to deliver systems and features. The focus naturally shifts towards getting the application live, moving the data, building the pipeline or producing the dashboard. The deeper questions around ownership, definitions, quality and downstream impact are often left for later — and later usually becomes much more expensive.

Once multiple systems have been built around different assumptions, changing those assumptions becomes difficult. A simple change to the definition of a metric can affect pipelines, reports, dashboards, applications and decisions across the organisation. What looked like a small data change can suddenly become an enterprise-wide problem.

A data-first culture doesn't simply mean having a data team or investing in modern data technology. It means treating data as a first-class part of how the organisation designs and operates its systems. When a new system is being built, the conversation shouldn't stop at what the system needs to do. There should also be a conversation about what data it creates, who owns that data, what it means, where it becomes authoritative, how it will be consumed and what happens when its definition changes.

Without that mindset, organisations tend to accumulate what I would describe as data debt. Just like technical debt, it may not be immediately visible. The system works. The reports are produced. The numbers are available. But underneath the surface, there are undocumented transformations, duplicated datasets, inconsistent definitions and manual processes slowly building up — until someone asks a simple business question and discovers there isn't a simple answer.

Shadow sources of truth

That is often the moment when the real cost of fragmented data becomes visible. Instead of asking what the data is telling us, teams start asking which dataset they should trust. Instead of analysing a business problem, analysts spend time reconciling numbers between systems. Instead of discussing what action should be taken, meetings become conversations about why one dashboard doesn't match another.

And once people stop trusting the data, something even more problematic happens: they start creating their own versions of it. Someone downloads a report into Excel because they don't completely trust the dashboard. Someone else creates a SQL query and saves it locally because they need a slightly different definition. Another team maintains its own dataset because the official source doesn't contain the information they need. Manual adjustments begin appearing in reporting processes. Spreadsheets become part of critical business workflows.

These workarounds often begin with good intentions — people are simply trying to get their jobs done. But collectively, they create shadow sources of truth. The organisation may still have an official data platform, but the real flow of information is now distributed across databases, dashboards, spreadsheets, scripts and individual knowledge. The question changes from "What does the data say?" to "Whose data should we believe?" That is a dangerous place for an organisation to be, because the ultimate value of data is not in collecting it — it's in being able to trust it enough to make decisions with it.

What a single source of truth actually means

This is why I believe the concept of a single source of truth is so important. And by single source of truth, I don't necessarily mean that every piece of data needs to live in one database or one technology platform. Modern organisations are too complex for that to be practical, and different systems will always have different purposes.

What matters is having a clear, authoritative source for important data and a shared understanding of what that data represents. There should be clarity around where a piece of information originates, who owns it, what it means, how it is transformed and where it is consumed. There should be a clear distinction between the system that owns the data and the systems that merely use a copy of it. Most importantly, there should be a traceable relationship between the information presented to a stakeholder and the underlying source from which it originated.

When that foundation exists, teams don't have to repeatedly recreate the same logic. Analysts don't need to maintain their own definitions of core metrics. Product and engineering can work from a shared understanding of important business entities. Finance and Operations can reconcile their processes against known sources rather than debating whose spreadsheet is correct. Leadership can look at a report with confidence that the numbers have a consistent meaning. The organisation moves from spending time establishing whether the data is trustworthy to actually using the data to understand what is happening — and that shift is incredibly important.

Why this matters more in the age of AI

The purpose of a mature data environment shouldn't be to produce more dashboards. It should be to create a reliable path from data to understanding, and from understanding to action. This is particularly important now, as organisations increasingly look towards analytics, automation and AI to make better decisions. All of these technologies depend on the quality, consistency and context of the underlying data. If an organisation cannot establish which data is authoritative or what that data actually means, adding another layer of technology doesn't solve the fundamental problem — it can simply make the problem faster, larger and more difficult to see.

AI doesn't remove the need for a source of truth. If anything, it makes one more important.

The more organisations automate decisions and generate insights from their data, the more important it becomes to understand where that data came from and whether it can be trusted. This is why I think the conversation around data needs to move beyond technology. It is easy to make the conversation about databases, warehouses, pipelines, platforms and tools — those things matter, but they are only part of the picture. The harder challenge is establishing the organisational behaviours that make data trustworthy in the first place.

Teams need to communicate when systems change. Business definitions need to be shared rather than assumed. Data ownership needs to be explicit. Transformations need to be understood. Quality needs to be measured. And, perhaps most importantly, people across the organisation need to understand that the data they produce today may become the foundation for someone else's decision tomorrow.

That creates a very different way of thinking about system design:

Those questions may seem small, but they can fundamentally change how an organisation builds its technology ecosystem. Ultimately, I don't think the goal should be to have less technology or fewer systems — organisations will always need specialised platforms, applications and data stores. The goal should be to have less ambiguity. One organisation can have hundreds of systems and still maintain a coherent data environment if there is clear ownership and a trusted foundation. Another can have only a handful of systems and still struggle if every team interprets and manages data differently. The difference is culture, governance and intentionality.

The real measure of data maturity

For me, the real measure of data maturity is therefore not how much data an organisation has or how sophisticated its data platform looks. It is how confidently someone can ask a business question and trace the answer back to a trusted source.

Can we explain where this number came from?

Can we explain what it means?

Can we explain who owns it?

Can we explain how it was transformed?

Can we explain why we should trust it?

If the answer to those questions is yes, then the organisation has something much more valuable than another dashboard or another data pipeline. It has confidence. And confidence is what allows data to move from being something an organisation stores to something an organisation can actually use.

That, ultimately, is why finding a single source of truth matters. It isn't about forcing everything into one system, centralising every dataset, or adding another layer of technology. It is about creating a shared foundation of trusted information from which the rest of the organisation can operate.

Because when everyone is working from the same trusted reality, the conversation changes. We stop asking, "Which number is right?" We start asking, "What is the data telling us?" And eventually, the most important question becomes: "What should we do about it?"

That is where data starts creating real value. Not when we collect it. Not when we move it. Not when we put it on a dashboard. But when people trust it enough to use it to make better decisions.