When organisations begin defining a data strategy, the conversations usually sound remarkably similar, even though formal bodies such as DAMA frame data management as a set of connected disciplines rather than a single platform choice.
Who owns customer data?
Which system becomes the source of truth?
How should schemas evolve?
Who approves structural changes?
Which platform should analytical teams use?
These appear to be technical questions.
Most of them aren’t.
They’re questions about agreement.
A data strategy isn’t simply a plan for storing or analysing information.
It’s an attempt to establish a shared understanding of how different parts of an organisation describe the same business.
That sounds straightforward.
Production systems have a habit of proving otherwise, particularly when shared entities drift into master data management failure modes.
Every Data Strategy Assumes Agreement
Every analytical platform, governance framework and integration architecture depends on assumptions that are rarely written down.
Teams agree on what constitutes a customer.
Applications agree on what an order looks like.
Reports assume everyone measures revenue the same way.
Integrations assume timestamps have the same meaning regardless of where they originated.
Most of the time those assumptions remain invisible because they aren’t challenged.
As organisations grow, they eventually are.
The sales team begins collecting information that finance doesn’t require.
Marketing introduces a new customer segmentation model.
Support records relationships that don’t exist anywhere else.
Compliance introduces additional validation rules.
None of these teams are behaving incorrectly.
They’re solving different business problems.
The difficulty begins when every system attempts to describe the same entity in different ways.
Organisations Drift Naturally
One of the recurring themes in enterprise architecture is that technology changes much more slowly than organisations.
Teams are reorganised.
Products evolve.
Regulations change.
Acquisitions introduce entirely new systems.
Departments redefine terminology to suit changing business priorities.
The software reflects those decisions.
Over time, applications that once agreed about the structure and meaning of their data begin to diverge.
This isn’t usually the result of poor engineering.
It’s a consequence of independent evolution.
Each system continues optimising for its own responsibilities.
The organisation gradually loses its shared understanding of the information flowing between them.
Organisational Drift
Organisation Begins
Customer
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Sales Finance Support
Shared Definition
Shared Ownership
Shared Meaning
────────────────────────────────────
Several Years Later
Sales Finance Support
Customer Customer Customer
Prospect Account Entitlement
Pipeline Billing Case History
Each definition is correct.
They are no longer identical.This drift isn’t a failure of governance.
It’s the normal outcome of different teams solving different problems over time.
Technology Doesn’t Create Agreement
When organisations recognise this divergence, the first instinct is often to centralise it.
Introduce a governance platform.
Deploy Master Data Management.
Publish canonical schemas.
Create an enterprise data catalogue.
Require architectural approval before structural changes are introduced.
These initiatives are valuable.
They improve visibility.
They establish accountability.
They provide mechanisms for coordinating change.
What they don’t do is eliminate disagreement.
A catalogue can document that two systems define “customer” differently.
It cannot make those definitions identical.
A governance policy can specify which team owns a field.
It cannot prevent another team from needing additional information that falls outside the approved model.
Technology records agreement, much as catalogs such as DataHub record ownership, lineage and metadata.
It rarely creates it.
Data Is Where Organisational Differences Become Visible
One of the reasons data strategy feels so difficult is that data is where every organisational difference eventually surfaces.
When two teams disagree about a business concept, the disagreement eventually appears as incompatible schemas.
When systems operate on different timelines, the disagreement appears as freshness problems.
When ownership becomes unclear, duplicate records emerge.
When business processes evolve independently, validation rules begin rejecting legitimate changes.
The platform isn’t introducing these problems, just as data swamps emerge when meaning and ownership decay.
It’s revealing them.
This changes how successful data strategies should be evaluated.
The goal isn’t to eliminate every inconsistency.
The goal is to understand which inconsistencies matter, who has authority to resolve them, and how the organisation will continue operating while those disagreements exist.
That’s a fundamentally different problem from simply selecting a data platform.
Schemas Rarely Diverge by Accident
Schema evolution is often described as a technical challenge.
In reality, it’s usually an organisational one.
Very few teams change a schema simply because they can.
They change it because the business changed first.
A new product introduces additional pricing information.
Compliance requires a previously optional field.
Marketing needs campaign attribution that didn’t exist six months ago.
Finance introduces new tax reporting requirements.
Each change is reasonable when viewed from the perspective of the team making it.
The difficulty appears when every other system continues assuming yesterday’s definition.
Schema evolution is therefore less about changing structures than it is about coordinating understanding.
The database only reflects a disagreement that already exists elsewhere in the organisation.
Schema Evolution Reflects Business Evolution
Business Changes
│
▼
New Business Requirement
│
▼
Application Changes
│
▼
Schema Changes
│
▼
Downstream Consumers Break
The schema wasn't the cause.
It was the consequence.This explains why versioning alone rarely solves the problem, even when schemas are described with standards such as JSON Schema.
Version numbers describe that something changed.
They don’t explain why it changed or whether every consumer interprets the change in the same way.
Central Governance Doesn’t Scale Forever
One response to increasing complexity is to centralise decision-making.
A governance board approves schema changes.
An architecture team reviews integrations.
Every new dataset is registered before publication.
Initially, this works well.
Standards improve.
Documentation becomes more consistent.
Ownership is clearer.
As organisations grow, however, the cost of coordination begins to increase.
Every change requires another meeting.
Every approval introduces another dependency.
Release schedules become tied together.
Eventually, teams stop waiting.
Shadow integrations appear.
Copies of datasets are created outside the governed platform.
Business units build their own reporting databases because obtaining access to the official one takes too long.
The governance model still exists.
It simply governs a progressively smaller proportion of the organisation’s data.
This isn’t usually an act of defiance.
It’s a response to operational pressure.
People optimise for delivering work.
If governance becomes the slowest part of delivery, the organisation will eventually find ways around it.
Coordination Under Growth
Small Organisation
Teams
│
▼
Governance
│
▼
Shared Platform
✓ Coordination Scales
────────────────────────────────
Growing Organisation
Team A ─┐
Team B ─┤
Team C ─┤
Team D ─┤
Team E ─┘
│
▼
Governance Queue
│
▼
Delivery Delays
│
▼
Shadow Pipelines
Local Databases
Spreadsheet ExportsThe failure isn’t governance itself.
The failure is assuming coordination costs remain constant as the organisation grows.
Decentralisation Doesn’t Eliminate Coordination
Recognising these problems, many organisations move towards decentralised ownership.
Individual teams become responsible for their own data.
The people closest to the business define the schema.
They publish data for others to consume.
This solves several problems.
Teams move faster.
Ownership becomes clearer.
Local optimisation becomes easier.
It also introduces new challenges.
Each team evolves independently.
Different naming conventions emerge.
Reference data changes on different schedules.
Identifiers stop matching across systems.
Consumers now integrate with multiple independently evolving domains instead of one centrally managed platform.
Coordination hasn’t disappeared.
It’s simply moved.
Instead of coordinating before publication, organisations coordinate during integration.
The engineering work changes.
The need for agreement doesn’t.
Data Contracts Are Agreements, Not Validation
This is where data contracts become valuable, alongside the API boundary thinking in contract testing vs integration testing.
They’re often described as schema validation.
That’s only part of their purpose.
A data contract is an agreement between a producer and a consumer.
It defines:
- the structure of the data
- its meaning
- ownership
- compatibility expectations
- acceptable changes
- service-level expectations
Validation is simply the mechanism used to enforce that agreement.
This distinction matters because contracts don’t exist to guarantee perfect data.
They exist to make assumptions explicit.
If a producer wishes to remove a field, the contract makes the impact visible before downstream systems fail.
If a consumer begins depending on undocumented behaviour, the contract exposes that dependency.
The contract doesn’t eliminate disagreement.
It provides a structured way of negotiating change before incompatible assumptions reach production.
Contracts Create Explicit Expectations
Producer
│
▼
Data Contract
│
┌─────────┴─────────┐
▼ ▼
Compatible Breaking Change
│ │
▼ ▼
Publish Reject + Notify
The contract doesn't stop change.
It makes change visible.This is one of the reasons modern data platforms increasingly treat contracts as part of the architecture rather than simply another validation framework.
The contract records the assumptions two systems have agreed to share.
Without that agreement, every integration becomes an independent interpretation of the same business reality.
Agreement Doesn’t Stay Still
One of the assumptions hidden inside many data strategies is that agreement, once established, remains stable.
Production systems don’t work that way.
Applications are deployed independently.
Teams release features on different schedules.
Reference data changes.
Business rules evolve.
New regulations appear.
Acquisitions introduce entirely different operating models.
None of these changes are exceptional.
They’re evidence that the organisation is still evolving.
The challenge for a data strategy isn’t establishing agreement once.
It’s preserving enough agreement that independent systems can continue working together while everything around them changes.
That is a considerably harder problem.
Freshness Is Really About Different Versions of Reality
Data freshness is usually described in terms of latency.
Five minutes.
Fifteen minutes.
One hour.
Those measurements are useful.
They aren’t the real problem.
The real problem is that every system eventually begins making decisions using a different version of reality.
A customer updates their address.
The operational application reflects the change immediately.
The analytical platform receives it several minutes later.
A reporting warehouse updates overnight.
Archived reports remain unchanged.
None of these systems are malfunctioning.
They’re simply operating with different information.
That distinction matters because people naturally assume every report is describing the same business.
Often they aren’t.
They’re describing the business at different moments in time.
Diverging Timelines
Customer Updates Address
│
▼
Operational System ───────────────► Immediate
Operational API ──────────────────► Seconds
Data Platform ────────────────────► Minutes
Warehouse ────────────────────────► Hours
Monthly Report ───────────────────► Days
Every system is correct.
Each is correct at a different point in time.This is why freshness guarantees become increasingly difficult to explain.
The question isn’t simply how old the data is.
It’s which version of reality the data represents.
Observability Is More Valuable Than Perfect Consistency
Many organisations attempt to solve these problems by making every platform consistent.
In practice, that rarely scales.
Distributed systems naturally diverge.
Temporary inconsistency is often an acceptable trade-off for availability, throughput or operational independence.
The important question becomes knowing when that divergence exceeds acceptable limits.
This is where observability changes the discussion, with lineage standards such as OpenLineage making downstream relationships easier to see.
Instead of asking:
“Can we prevent every inconsistency?”
The platform asks:
“Can we detect when disagreement becomes operationally significant?”
That might mean monitoring:
- freshness lag
- failed contract validation
- schema evolution
- missing lineage
- unexpected volume changes
- duplicate entities
- ownership conflicts
Observability doesn’t eliminate disagreement; it makes disagreement visible in the same spirit as production telemetry.
It makes disagreement measurable.
Once something can be measured, it can be prioritised.
That’s usually a far more realistic objective than attempting to prevent every divergence from occurring.
Governance Through Observation
Production Systems
│
▼
Data Contracts
│
▼
Observability
│
┌───────────┼───────────┐
▼ ▼ ▼
Freshness Lineage Quality
Lag Changes Drift
▼
Engineering ResponseGovernance becomes significantly more effective when it responds to observable behaviour rather than assuming every standard will always be followed.
Ownership Without Authority Doesn’t Last
Many data strategies place considerable emphasis on assigning ownership.
Ownership is important.
It isn’t sufficient.
Imagine a customer domain owned by one team.
Another team needs an additional attribute.
The owning team declines because the field doesn’t belong in the shared model.
The requesting team escalates.
Leadership approves the change.
The schema grows.
The ownership documentation remains unchanged.
Over time this pattern repeats.
The documented owner continues approving very little.
The organisation continues changing everything anyway.
Eventually ownership becomes descriptive rather than authoritative.
The documentation still identifies an owner.
The architecture no longer reflects one.
This is one of the more subtle reasons governance initiatives gradually lose credibility.
The policies still exist.
The decisions are being made somewhere else.
Authority Is More Important Than Ownership
This distinction often goes unnoticed.
Ownership answers:
“Who is responsible?”
Authority answers:
“Who is allowed to decide?”
Those are very different questions.
A data owner may be responsible for maintaining customer information.
If other teams can bypass their decisions through organisational escalation, emergency releases or independent integrations, ownership exists without authority.
The architecture now reflects organisational power rather than documented governance.
Successful data strategies recognise this explicitly.
Authority is defined alongside ownership.
Decision boundaries become visible.
Exceptions are documented rather than quietly normalised.
The goal isn’t eliminating disagreement.
It’s ensuring everyone understands where the final decision is made.
Without authority, governance becomes guidance.
With authority, governance becomes architecture, which is why data protection strategy also depends on who can decide during an incident.
The Best Data Strategies Expect Disagreement
It’s tempting to think that a successful data strategy creates consistency across an organisation.
In practice, consistency is rarely permanent.
Businesses expand into new markets.
Teams reorganise.
Products evolve.
Regulations change.
Systems are replaced.
New acquisitions introduce entirely different operating models.
Every one of these changes creates new interpretations of the business.
The strategy isn’t failing when that happens.
The organisation is simply continuing to evolve.
The challenge is ensuring those changes don’t quietly undermine every system that depends on them.
That requires architecture that expects disagreement rather than pretending it can be eliminated.
Strategy Is Really About Decision Making
When organisations describe a data strategy, they often focus on technology.
Should we adopt a lakehouse?
Do we need Master Data Management?
Should every dataset have a contract?
Do we centralise governance?
Should domains own their own data?
These are important questions.
None of them are the strategy.
The strategy exists to answer something much more fundamental.
When two systems disagree…
Who decides?
When a producer changes a schema…
Who approves?
When two reports produce different numbers…
Which result is authoritative?
When a customer exists differently in two domains…
Who resolves the conflict?
Technology can record those decisions.
Only the organisation can make them.
Governance Should Reduce Negotiation
One of the common misunderstandings about governance is that it exists to enforce rules.
In reality, effective governance reduces the number of conversations teams need to have.
If ownership is clear, people know who to ask.
If contracts are explicit, breaking changes become visible before deployment.
If metadata is accurate, consumers understand what they’re integrating with.
If lineage is complete, reports can be traced back to their origin.
Governance isn’t valuable because it creates bureaucracy.
It’s valuable because it reduces uncertainty.
The less time teams spend debating what data means, the more time they spend solving business problems and applying data analysis strategies to information they can actually trust.
Governance as Organisational Memory
Business Decision
│
▼
Governance Rules
│
▼
Contracts • Metadata • Lineage
│
▼
Future Teams Understand Why
Governance isn't documentation.
It's institutional memory.This is one of the reasons mature organisations invest heavily in metadata, lineage and documentation.
They aren’t documenting systems.
They’re preserving decisions.
Platforms Should Optimise for Adaptation
Production systems rarely remain unchanged for long.
The question isn’t whether requirements will evolve.
It’s whether the architecture allows them to evolve safely.
That means accepting that:
- schemas will change
- ownership will move
- consumers will appear unexpectedly
- producers will disappear
- definitions will evolve
- governance policies will be challenged
None of these represent architectural failures.
They represent organisational change.
A resilient data platform doesn’t prevent those changes.
It makes them visible.
It limits their impact.
It provides mechanisms for negotiation rather than forcing every team into permanent agreement.
The Real Purpose of a Data Strategy
Data strategies are often presented as plans for organising information.
After working with production systems, I don’t think that’s their primary purpose.
Their real purpose is to help organisations continue making decisions together after they have stopped thinking the same way.
Every schema captures an interpretation.
Every contract records an agreement.
Every lineage graph explains how that agreement propagated through the platform.
Every governance policy identifies where authority ultimately resides.
None of those artefacts eliminate disagreement.
They make disagreement understandable.
That’s the difference between a platform that survives organisational growth and one that gradually fragments into isolated systems that happen to exchange data.
Final Thoughts
The most successful data strategies don’t create perfect consistency.
They create confidence.
Confidence that ownership is understood.
Confidence that changes are visible.
Confidence that disagreements can be resolved without disrupting the business.
Confidence that people can explain where information came from, who changed it and why.
Technology contributes to that confidence.
Governance strengthens it.
Architecture preserves it.
Ultimately, however, a data strategy isn’t judged by how well it organises data.
It’s judged by how well it helps an organisation continue working together as the organisation itself continues to change.
