Dispersed, lifecycle-based data ownership sounds ideal. It promises clarity: data is maintained close to where it’s used, each domain owns the data it cares about, responsibilities shift smoothly from creation to maintenance, blocking, and archiving, and shared attributes are carefully guarded. On paper, it’s elegant and mature. In practice? It rarely works the way we imagine.

This post reflects on the gap between how governance models describe the world and how organisations actually behave when systems, scale, and human behaviour come into play.

Lifecycle Ownership: Elegant Theory, Weak Accountability

Lifecycle-based ownership assumes organisations experience data as neat, linear stages. In reality, that almost never happens. People navigate systems, tickets, deadlines, and exceptions, not orderly lifecycles. When ownership shifts at each stage, accountability blurs. Rather than closing responsibility gaps, lifecycle ownership often creates them. It becomes a machine for plausible deniability.

“Who Suffers If the Data Is Wrong?” A Broken Heuristic

A common rule in data governance states, “The one who suffers operationally owns the data.”

At first glance, it sounds reasonable. But reality is different.

Consider a wrong customer address:

• Sales cannot complete the order
• Logistics cannot deliver the shipment
• Finance cannot issue the invoice
• Compliance risks fines

Who owns the data in this situation? In practice, the answer often defaults to shared attributes managed by central guardians. The logic of the heuristic collapses when multiple functions are affected, showing the limits of using operational pain as a guide for ownership.

Scale Kills Governance Fantasies, and ruins the easy sell

Dispersed, lifecycle-based ownership can work at a small scale, but as soon as the volume grows, it breaks down. Add multiple systems and silos into the mix, and the problem grows exponentially. SAP S/4 will block certain changes when materials, vendors, or customers are already in use. Other technical siloed systems often have rigid change management processes, making it difficult to keep data in sync across the landscape.

Yet we keep trying this approach, mainly because it is easier to sell. It avoids hard conversations, spreads discomfort instead of concentrating it, and is accepted for the sake of consensus rather than effectiveness.

The reality is that we are trying to solve organisational politics with conceptual models. When we do that, failure is inevitable.

The Uncomfortable Conclusion

Here it is: data ownership does not want to be dispersed. It wants to be centralised, boring, enforced, and slightly unpopular. Organisations often say they want empowerment, but what they actually need is constraint. This is not because people are incompetent, but because data is shared, reused, and repurposed far beyond the intent of any single domain.

If I strip away the political reality and design purely for outcomes, I end up here:

• One accountable owner per master data object
• Clear, policy-driven lifecycle rules
• Central execution of blocking and archiving
• Domains influence the rules, but do not execute them
• Quality is measured, not negotiated

Yes, it upsets people. Yes, it feels less democratic. Yes, it works.