In the late 90s, my friend Sean handed me a battered copy of Daniel Quinn’s Ishmael that had been passed from person to person across the country, a common practice for Quinn’s philosophical novels. As a 90s kid, I found the novel incredibly influential, and it helped shape my worldview. His work did not read like the abstract philosophy I was accustomed to in academic settings; it felt like a lens that revealed how much of what we call normal is simply inherited belief, reinforced until it becomes invisible. It stuck so deeply that I marked it permanently: a tattoo of Cain and Abel, not as theology but as Quinn framed them — Leavers and Takers. Competing visions of how humans relate to the world. One oriented toward participation and continuity. The other is toward control and exception.

Ishmael introduced that idea. The Story of B, a companion novel, clarified it. The argument wasn’t that civilization is malicious or misguided, but that it operates within a cultural vision so dominant that it no longer seems like a choice. We don’t question it. We design within it.

That distinction — between vision and programs — stuck with me long before I had the language to apply it to my professional life.

At the time, I didn’t connect that worldview to data. Then, during my doctoral research, I returned to The Story of B, and this time the parallels were impossible to ignore.

Vision Comes Before Programs

One of Quinn’s core ideas is that programs do not create change on their own. They are a response to existing behavior. They are corrective, not generative. Vision, by contrast, defines what feels natural, reasonable, and inevitable.

Programs follow vision. They never lead it.

That distinction is important to understand because data governance, as practiced today, is almost entirely programmatic. We talk about frameworks, operating models, policies, councils, tooling, and maturity levels. As I’ve discussed ad nauseam in my recent articles, my research shows that most organizations already have extensive governance structures. What they lack is shared meaning.

Practitioners describe environments where governance exists on paper but not in practice. Roles are defined, yet unclear. Policies exist (maybe) but are inconsistently enforced. Data Governance capabilities are operational but lack resilience and collapse under organizational change.

From a program-centric view, this looks like an execution failure.
From a vision-centric view, it looks like misalignment.

The Unspoken Data Vision We Already Live With

Every organization already operates under a data vision—even if it’s never articulated.

It’s embedded in incentives, workflows, and organizational design. It shows up in assumptions like:

• data is produced for local use first,

• speed outweighs coherence,

• ownership is contextual,

• quality is situational,

• governance is something added after the fact.

This vision is not malicious, but it is dangerous, nonetheless. It quietly shapes behavior long before any governance program is introduced.

Governance initiatives then arrive not as expressions of that vision, but as correctives — attempts to counteract outcomes the vision produces. That is why governance so often feels heavy, fragile, or oppositional. It is asking people to behave differently without changing the story that tells them what “normal” work looks like.

Note: I am intentionally calling out a data vision detached from the organizational vision. We’ll come back to this.

What the Research Actually Points To

The most important finding in my research is that effective data governance relies primarily on social architecture. It is about understanding.

Structure alone does not produce desired behavior. Policy and enforcement help, but only when people understand why data governance exists and how it connects to their decisions.

Across hundreds of practitioners and dozens of industries, most organizations report that data governance structures are in place. The problem is coherence. Organizations that view data governance as successful consistently focus their programs on culture and literacy, establish accountability for communicating about data governance, and view their programs as sustainable. Compared to value non-believers, characterized by:

• limited understanding of data governance,

• weak alignment between policy and day-to-day decisions,

• inconsistent enforcement,

• and vulnerability to organizational change.

These negative characteristics are the symptoms of running data governance as a program layered on top of an unchanged worldview.

Organizations with stronger data governance outcomes are those where people can explain — simply and consistently — what data governance is for, how it affects decisions, and why it exists.

Programs explain what to do.
Vision explains why behavior makes sense in the first place.

Without vision, data governance remains effortful.
With vision, programs become almost invisible.

Governance as an Expression of Vision

The argument here is not that programs are unnecessary. Quinn is clear on this point: programs are not forbidden. They are provisional. They exist to support vision, not substitute for it.

Data governance becomes resilient when it stops trying to manufacture behavior through structure alone and instead reflects a shared understanding of data as a critical resource, a decision surface, and a source of responsibility.

That shift — from program-first to vision-first — is what enables data governance to survive reorganizations, technological change, and new waves of innovation, such as AI.

You cannot program your way into that.
You have to see it first. With the vision comes the stories and the beliefs.

In my experience, I can now see that I’ve had programs fail because I confused them with vision. Those early programs never had a chance. And almost all data governance today is run as a program.

This isn’t a new idea. It comes from a much older idea: programs are what societies build when their underlying vision produces outcomes they don’t like. Programs react. Vision leads.

Programs Are Reactive by Design

In The Story of B, programs are described as corrective mechanisms. They exist to counteract behavior that emerges naturally from a dominant worldview. Programs don’t shape reality; they attempt to compensate for it. They require constant reinforcement, justification, and energy because they are always pushing against the current.

That framing maps uncomfortably well to how data governance operates in practice.

Organizations rarely introduce data governance as a proactive design choice. More often, data governance arises in response to failure — when existing data practices begin to fall apart.

Note: I have written extensively on this point, and I doubt most readers will need convincing, so I won’t elaborate. If you are unconvinced, I suggest stopping here and catching up on my other posts.

This matters because programs that exist primarily to correct behavior are inherently fragile. They don’t persist on belief. They persist on effort.

If we don’t accept this, we will keep mistaking effort for progress — and calling it data governance.

Why Governance Programs Don’t Become Resilient

We operate in a dynamic world. Change is constant for everyone, but for those working with data, the effects are more pronounced. Rapid technological shifts, evolving regulatory demands, and ongoing economic and geopolitical uncertainty collide directly with how data is produced, managed, and used. In that environment, resilience is not optional.

Resilience is about what survives change. Data Governance rarely has the resilience to survive organizational restructuring, executive turnover, shifting priorities, or major technology transitions, even when formal programs exist — complete with operating budgets, skilled practitioners, and defined structures

Observed from a programs-versus-vision perspective, this is expected.

Programs are provisional. They depend on sponsorship, enforcement, and continual explanation. When pressure increases, programs are the first thing to be cut — not because they’re unimportant, but because they are not foundational.

Programs cannot compensate indefinitely for a misaligned vision.

Vision, by contrast, survives disruption. It travels through people, not org charts.

On Vision and Data Governance

A data vision is a shared belief system about how data fits into the organization’s way of working. Here’s the kicker, though: it is not, nor can it be, a separate vision from the organization’s vision.

To put it bluntly, the broadly accepted idea of a Data Strategy in its current form, which includes programmatic data governance, is a dangerous myth.

Okay, Tony, nice dramatic effect — way to be a rebel.

You can come at me on this, folks — maybe I am being dramatic — but consider that it is logically inconsistent to run data governance programs that require constant justification for why rules should be followed, while senior leaders simultaneously claim the organization is — or aspires to be — data-driven.

Our organizations’ visions must assume that:

• data is a shared, enduring asset,

• decisions about data have enterprise consequences,

• stewardship is part of normal work,

• quality, risk, and value are inseparable,

• governance exists to coordinate decisions, not to police behavior.

People wouldn’t need to be sold on data governance if it reflected how they already understand their responsibilities.

With a corrected vision, data governance won’t feel like a heavy lift. It will feel boring — and most things that are resilient tend to be, well… boring.

The Core Reframe

Here is the uncomfortable conclusion that ties the philosophy to the research:

Data governance does not fail because programs are poorly designed.
It fails because programs are trying to correct outcomes produced by a vision that never changed.

That’s why organizations keep rebuilding data governance. The cycles of failure focus on the mechanisms, without touching meaning.

The organizations that will survive and thrive in the years to come won’t be the ones with the most elaborate governance programs. It will be the ones whose vision of data already supports coordination, accountability, and learning. You cannot program your way into that, either.

The data governance capability is resilient when it stops fighting the river and supports the flow. The stark reality is that if your data governance capability is still fighting the river, it is not resilient, and if it's not resilient, neither is your organization, because its vision is unfit for the AI revolution.

This is the impetus to stop being polite, to stop ignoring the cracks we have learned to work around, and to finally confront the reality that after everything collapses, all that remains is a tattered banner of data governance standing alone in the ruins of our organizations — raised too late, asked to symbolize order only once coherence has already been lost.

On Vision and Data Governance was originally published in My Column Has NULLs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Designing Data Governance to Learn: What practitioner-reported goals reveal about value, coordination, and resilience

Being a data governance leader requires a certain tolerance for disruption and uncertainty. It’s the kind of role where even planning a family vacation feels risky. You never quite know when work will spike, because governance tends to surface precisely when something else has gone wrong.

In large organizations — and, honestly, probably most — you cycle through a familiar pattern. Sometimes, no one knows you exist. Sometimes people are quietly hoping you don’t show up. And then, usually without much warning, something breaks, a regulator asks a question, or a major initiative hits friction — and suddenly data governance is the most important thing in the room. Everyone wants time on your calendar. We’re the cool kids again.

Data governance can feel invisible, unwelcome, or briefly indispensable depending on what the organization is dealing with at the moment. That swing isn’t a sign that governance lacks purpose. It’s a reflection of what data governance actually is: a corporate governance capability intended to improve the data management function, operating across many roles, systems, and perspectives simultaneously.

Like all forms of corporate governance, data governance exists to set direction, establish accountability, and enable oversight. What makes it challenging is not its mandate, but the complex thing it governs. Data cuts across every function, every process, and every level of the organization, and is intangible and characteristically and behaviorally complex. As a result, the performance of data management — and the value it creates — is evaluated differently depending on where you sit.

We have concluded that this makes learning, not definition or control, the central design challenge for data governance.

The Many Goals of Data Governance

The findings in this article are from my dissertation research, Towards Resilient Data Governance, which draws on responses from 348 practitioners across 46 countries.

First, Participants were asked to identify their organization’s data governance goals, allowing multiple selections.

The results did not cluster around a single objective. They were broadly and consistently distributed. Most respondents selected multiple goals rather than one. On average, respondents endorsed more than five of the seven possible goals, and more than one-third selected all seven.

The most frequently endorsed goals included: Managing data quality (62%), Managing risk and compliance (57%), Supporting data strategy and transformation (52%), Building data culture and literacy (59%), and Defining and managing metadata (56%).

This reflects a practical reality that aligning and measuring data governance goals: improving the data management function requires progress across multiple dimensions at the same time:

Executives focus on decision quality, speed, and strategic return
Risk and compliance functions focus on control, defensibility, and exposure
Operations focuses on reliability and consistency
Analytics and AI teams focus on access, quality, and enablement
Business users focus on usability and trust

Each perspective is legitimate, but they are typically measured very differently — and although they generally want the same thing, that’s a tough story to tell. The challenge is not deciding which of these goals counts; rather, it is a coordination challenge — how the organization learns and acts across all of them.

The problem arises when these perspectives are evaluated in isolation. When learning remains local to each function, data governance becomes the place where tensions surface but are resolved only after impact occurs. That is why governance can feel alternately invisible or overwhelming: it is often engaged late, when consequences are already visible. Once the problem is addressed, that knowledge is usually retained locally.

This is not a failure of intent. It is a limitation of coordination.

Where Coordination Breaks Down

Some governance goals align naturally.

Data quality, risk management, and compliance all depend on consistent definitions, clear ownership, and reliable metadata. Strategic initiatives depend on quality because poor data undermines analytics, decision-making, and AI outcomes. Culture and literacy make governance expectations understandable to people doing the work.

Data quality illustrates this pretty well.

Data Quality teams monitor signals — rules, thresholds, exceptions, and trends.
Risk teams respond to incidents — loss events, findings, and escalations.
Leadership acts when consequences are visible — in dollars, regulators, or headlines.

When these learning cycles are not connected, organizations learn late. Signals exist, but action is triggered only after impact. Someone inevitably says, “How did we miss this?”

Well, the short answer is that we’ve created static and reactive data governance capabilities that lack mechanisms to translate early information into timely decisions.

Why does this matter? Late learning is expensive.

Motivations and the Influence of the Macro-environment

Respondents were also asked what factors had increased their organization’s focus on data governance over the past two years. The results validate that changes in the macroenvironment can (and have) materially increased the impetus for data governance in respondent organizations.

As with goals, no single motivation dominated. Instead, respondents pointed to multiple, concurrent drivers: the need to better manage data quality (62%), emerging risks, including privacy and security (54%), digital transformation initiatives (51%, AI transformation initiatives (50%), and New or evolving regulations (40%). Only about 5% of respondents reported no recent increased focus at all — business as usual for these guys, apparently.

The significance of these results lies not in any individual driver, but in their simultaneity. Quality, risk, digital transformation, AI, and regulatory change all intensified at roughly the same time—and all depend on the same foundational capabilities: ownership, human- and machine-interpretable knowledge (metadata), controls, and feedback loops.

These endorsements indicate that data governance became more visible and more heavily relied upon because multiple parts of the organization simultaneously recognized the exact needs from different perspectives.

Without integrated learning and coordination mechanisms, data governance becomes the point where competing pressures surface, often late in the process, resulting in escalation, delay, or reactive (often localized) intervention rather than early adjustment or incremental scaling.

Considered circumstantially, it could be viewed as a temporary surge; the natural eb and flow of data governance sentiment. I used to think that it was that way; I no longer do. This is a structural signal that we have been ignoring. We now understand that Data governance operates under sustained macro-environmental pressure and must be designed accordingly.

A Simple Learning Loop for Data Governance

The coordination challenges described so far are often framed as execution problems. They are not. They are learning problems.

Organizations learn in different ways depending on the signals they recognize and the changes they permit. In organizational learning theory, this distinction is captured through single-loop and double-loop learning.

While most data governance operates in a single-loop mode — focusing on correcting immediate defects — true resilience depends on the depth of learning. Whether an organization simply fixes a data error or adapts the underlying governance intent depends on where that learning is allowed to occur.

Single-loop learning asks: Are we doing things right? It corrects execution without changing assumptions.
Double-loop learning asks: Are we doing the right things? It allows operational signals to modify governance intent, including policies, thresholds, and decision rights.

Most data governance activity operates in a single-loop mode.

Data governance operates through PDCA cycles, but whether organizations merely correct defects or adapt governance intent depends on where learning is allowed to occur.

How to read this diagram

This diagram shows how data governance operates and how organizations learn from it.

Start with the square loop in the center. This is the familiar Plan–Do–Check–Act (PDCA) cycle. It represents the operating rhythm of data governance: intent is set, work is executed, results are observed, and responses are made. Most organizations already run this cycle, whether they label it or not.

The distinction appears at CHECK.

CHECK is where signals emerge — data quality trends, metadata drift, usage patterns, and exceptions. Detecting these signals is necessary, but it is not learning by itself. Learning depends on what happens next.

At ACT, the organization makes a choice.

If ACT focuses on fixing defects and restoring operations, the system follows the single-loop learning path. Execution improves, but underlying assumptions — policies, thresholds, ownership, decision rights — remain unchanged.

If ACT leads to revisiting those assumptions, the system enters double-loop learning. The governance intent is updated in the PLAN, and future execution changes accordingly.

Both paths are valid. The difference is depth.

Single-loop learning keeps the system running.
Double-loop learning makes it resilient.

The diagram highlights that governance adds value not by detecting issues, but by enabling signals to change decisions before incidents force escalation.

Data quality issues are detected and corrected. Controls are adjusted. Incidents are remediated. Reports are fixed. These actions matter, but they do not change the assumptions that shape how data is governed in the first place.

Double-loop learning occurs when signals from operations lead to changes in intent—when policies, thresholds, ownership, escalation paths, or decision rights are revisited in light of what the organization has learned.

When learning remains single-loop, signals lead to fixes, but not to changed expectations. As a result, the organization learns late. Governance becomes involved only after impact occurs, not when early indicators first appear.

This distinction explains why governance can feel busy but remain reactive.

Quality teams live in signals
Risk teams often live in incidents
Leadership lives in outcomes
Governance exists to connect them

When the loop works, governance feels anticipatory.
When it doesn’t, governance feels punitive or slow.

Why does it matter? Late learning increases cost, amplifies risk, and undermines confidence in governance, even when teams are doing competent work.

Data Governance Goals and Perception of Value

If learning is the constraint, value should appear where learning improves.

The dissertation compared practitioners who reported that data governance was worth the time and investment with those who did not.

Practitioners who perceived governance as valuable endorsed more goals overall — an average of 5.1, compared to 4.0 among those who did not.

More importantly, not all goals contributed equally to that perception.

After controlling for multiple comparisons, three goals showed a meaningful association with perceived value:

- Building data culture and literacy

- Supporting data strategy and transformation

- Defining and managing metadata

Other goals—data quality, risk management, and compliance — were present in both groups. They are foundational, but non-differentiating. They are necessary for operation, but insufficient to explain why governance is valuable. It’s important to note that the dataset size constrained the model performance, and these results should be interpreted as directional.

Culture and metadata as learning infrastructure

When the goals were evaluated together, data culture and data literacy emerged as the strongest independent predictors of perceptions of the value of data governance.

This does not mean culture replaces control. It means that shared understanding enables the transfer of governance expectations and trade-offs across roles without constant escalation.

Metadata shows a similar pattern. While quality improvements drive better outcomes, metadata is what actually enables coordination.

Metadata connects ownership, definitions, quality rules, risk interpretation, analytics enablement, and AI readiness. When metadata is well managed, shared context enables shared learning—both human- and machine-interpretable— which will be increasingly important as organizations pursue agentic AI systems. When it is not, data governance operations result in only local optimizations.

We need to ask ourselves: will we ever achieve value and efficiency in our investments in data quality and risk management functions if we do not also invest in the infrastructure that enables learning across these functions?

Designing Data Governance to Learn

Resilient data governance is not governance without plurality of purpose or operational tension. It is governance that can foster learning across perspectives, integrate feedback, and adapt before pressure turns into failure.

This requires leaders to focus less on coverage and more on learning mechanics.

Following my research, I jotted down the following questions we need to consider in designing data governance to learn:

• Where do early signals about data issues surface, and who is expected to act on them?

• How are quality indicators translated into risk awareness — or are they noticed only after incidents occur?

• Which artifacts actually travel across functions, and which remain local?

• Do managers responsible for execution understand which trade-offs they are meant to optimize for?

• Is data governance staffed to coordinate learning, or only to enforce rules?

These questions matter because, without clear answers, data governance performance and value will continue to be evaluated only after something goes wrong.

What leaders should do now?

Organizations need to rethink data governance. It should be conceptualized as a dynamic, adaptive capability for coordination and organizational learning, rather than as a static control function.

Data Governance must be designed to learn across the many legitimate ways data management is evaluated—by executives, risk functions, operators, and users alike —and to embed learning and the dissemination of knowledge in operations.

That starts with leadership. Leaders need to understand stakeholder goals, motivations, and perspectives on value, and where those perspectives align or conflict. Shared purpose does not eliminate tension, but it does make trade-offs visible and manageable.

Leaders must also evaluate whether data governance is effective—and for whom. That means asking not only whether data governance supports today’s priorities, but whether it has the learning mechanisms required to adapt as expectations shift. In practice, this includes ensuring early signals about data quality, risk, and usage are visible beyond local teams; clarifying who is expected to act on those signals; and reinforcing decisions so the organization learns before incidents force escalation.

The research shows that programs perceived as valuable are not narrower in focus. They are better networked. They invest in shared understanding, clear communication about governance expectations, and feedback loops that turn signals into action.

Design data governance to learn — and it can sustain everything it is already being asked to do, and whatever the future holds.

Designing Data Governance to Learn: What practitioner-reported goals reveal about value… was originally published in My Column Has NULLs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why a generation of progress still hasn’t produced a shared meaning — and why that matters more than ever.

Note: The content of this article is a synthesis of a methodical, theme-based literature review that informed the research. Most topics were not directly examined in the quantitative analysis.

Ask ten data professionals what “data governance” means, and you’ll get twelve answers, each delivered with confidence, sometimes enthusiasm, and occasionally a hint of existential dread. This isn’t because the field is confused or unserious. It’s because data governance grew up backwards — emerging from decades of practical necessity, organizational dysfunction, regulatory panic, and technology shifts long before anyone paused to ask the fundamental question: What is this thing we keep building?

Everyone claims to “have governance,” yet very few organizations can describe it clearly, execute it consistently, or sustain it when things change.

This isn’t a surprise.
Data governance evolved quickly, reactively, and under pressure.
It wasn’t designed — it was assembled.

And as digital transformation and AI raise the stakes, the gaps in definition, practice, and resilience are becoming too costly to ignore.

To understand why data governance remains so amorphous, we need to understand how governance got here in the first place.

Before Data Governance Had a Name: Borrowing From IT Governance

In the 1960s and 70s, governments and large organizations were wrestling with a new problem: electronic data. With the rise of mainframes and early databases, managing data became both essential and chaotic. Agencies in the US and UK collaborated with universities, corporations, and technology manufacturers to create some of the first data governance-like structures — data dictionaries, access controls, quality checks, and reporting standards.

None of this was called “data governance.”
It was simply the work required to keep early systems from collapsing.

By the 1990s, data warehousing and business intelligence created new pressures. Organizations wanted integrated data for decision-making, but inconsistent definitions, quality issues, and siloed ownership created new problems. Regulations such as HIPAA (1996) and the EU Data Protection Directive (1995) required organizations to improve control over personal data. Still, governance remained informal, implicit, and inconsistent across industries.

The need for governance existed.
The language to describe it did not.

The Mid-2000s: Dragging Data Governance Into the Light

The mid-2000s didn’t define what data governance is, but they did mark the era when the term “data governance” entered our professional lexicon, at least amongst data nerds.

Authors like Gwen Thomas, John Ladley, and Sunil Soares were among the first to publish books, articles, and guidance that used the phrase “data governance” explicitly. Their influence wasn’t in defining the discipline but in giving organizations a vocabulary for problems they already recognized:

• unclear accountability,

• inconsistent practices,

• siloed authority,

• decision-making driven by personalities rather than process.

Their work named the dysfunction and helped the term “data governance” take root.

Author’s note: If you’re looking for books on Data Governance, Ladley’s book has been my ‘Bible’ for the majority of my career, and in my opinion, it is the most comprehensive. Thomas’s “Alpha Males and Data Disasters” is my favorite — a 222-page mic-drop moment for practitioners. The latter is sadly out of print and very difficult to get. If you find or have one, I will pay a hefty ransom for a copy. I had considered stealing it from an Oklahoma University Library, where I borrowed it, but ethics prevailed.

Around this time, the industry began codifying data governance ideas into actionable frameworks, giving them legitimacy. The first edition of the DAMA DMBoK positioned data governance as a central component of data management, formally embedding the term into a widely adopted industry reference model. It didn’t define governance universally, but it anchored the term inside the profession. The Data Governance Institute (DGI) offered an early definition focused on decision rights and accountabilities, along with templates and guidance. It helped practitioners articulate governance, even if the definitions reflected a specific organizational lens. IBM’s introduction of a Data Governance Maturity Model in 2006 demonstrated that data governance was moving beyond practitioner intuition and that organizations were now seeking formal, repeatable methods.

As data problems became more visible — quality issues, uncontrolled access, inconsistent reporting, regulatory pressure — vendors, consultants, and technology providers began producing services, glossaries, and frameworks using the same terminology. Data Governance could be profitable.

The mid-2000s brought linguistic convergence, not conceptual clarity. But that convergence mattered: the field now had a shared label, even if meaning lagged.

2008 Changed Everything: Governance Becomes Compliance

The 2008 financial crisis revealed that major institutions couldn’t reconcile their own data — a catastrophic failure when billions hinged on reporting accuracy. Organizations’ inability to manage data (and the harm it could cause) was thrust into the spotlight, just as cloud computing, “Big Data”, and an era of accelerated digital transformation were starting to materialize. Regulators responded with regulation (as they do).

In a matter of a few years, amid the hangover of the “Great Recession” and increased concerns about privacy and data subject rights, organizations faced an onslaught of regulations, including Dodd-Frank, Basel III, EMIR, MiFID II, and GDPR. These frameworks required the core tenets of data governance, such as transparency and accountability, and a situational focus on foundational data management capabilities, including metadata, lineage, and data quality management, but only for some processes. Data governance became synonymous with compliance.

This fundamentally changed data governance:

From: a coordination mechanism focused on clarity, quality, and decision rights.

To: a compliance mechanism focused on control, defensibility, and risk mitigation.

The term solidified.
The definition and intent skewed.

2010s–2020s: The Era of Infinite Variations

The explosion of cloud computing, SaaS ecosystems, hybrid architectures, big data platforms, and machine learning, and a lot of marketing added layer upon layer to the narrative around data governance, conflated it with data management, and introduced variations (e.g., Big Data Governance, Cloud Data Governance, AI Governance).

Data governance now could mean:

• lifecycle management

• privacy and security

• data quality

• metadata and lineage

• stewardship and ownership

• data integration and interoperability

• compliance and risk management

• data strategy

• data fluency and literacy

This drives me crazy — yes, I’m ranting a bit, and no, they wouldn’t let me put this in the dissertation. I believe it is a symptom of data management’s industry-driven nature and reactive ethos, which, combined with a lack of understanding of what data governance actually is, leads to unnecessary change in response to macroenvironment shifts, undermining process resilience and sustainability. Does cloud modernization introduce new methods for the data management function? Sure. Does the impact on the management function, in turn, create new decisions that data governance must support? Absolutely. Does it wholly invalidate the principles, policies, authority, and decision-rights that were established for on-prem systems and require a “cloud” qualifier? Absolutely not.

I will spare you the rant on AI Governance for now. We’ll cover that in another article, but I’ll share my perspective — AI is just another use of data. I suspect the reason we might have a different concept of AI governance is that data governance has thus far not been resilient enough to handle the scale of this macroenvironmental shift (and to sell stuff, of course). And every underlying data management vulnerability — poor lineage, unclear ownership, weak controls, inconsistent definitions — became an AI risk.

AI didn’t change data governance.
It exposed it. Then rebranded.

Why We Still Don’t Have a Shared Definition

The definitional ambiguity isn’t a failure. It’s structural.

1. Different communities built governance for their own needs: security wanted control, regulators wanted compliance, architects wanted metadata, business users wanted quality, data scientists wanted access, and vendors wanted sales.

2. Current perspectives struggle with the interdisciplinary nature of data governance and the need for systematic collaboration: Effective data governance requires data literacy, legal expertise, risk management skills, organizational change management, business knowledge and acumen, and technical skills, among others. In other words, lots of people need to get along and work for the greater good, beyond their individual performance objectives — and not just for a project, in perpetuity. Most organizations do not have the systems in place to support these operations or incentivize work for the greater good. So, who you hire to lead your data governance program and who the most vocal leaders are probably have a lot to do with how it “looks” and “feels” in your organization.

3. Governance Still Lacks a Strong Empirical Foundation: Academic work tends to be theoretical, while practitioners rely on experience, improvisation, and vendor guidance that often conflates governance with tooling and generalized frameworks. The result — organizations often implement governance by trial and error. (I’ve been here, this is me!)

4. The Human aspects of Data Management are often overlooked. Data Governance failures rarely stem from missing tools; instead, the culprits are: unclear roles, lack of communication, insufficient knowledge, cultural resistance, and shifting priorities, to name a few.

Why It’s So Difficult

My close friend and mentor, Daragh O Brien, wrote an excellent piece describing data management as a “Wicked Problem” — it’s a perfect characterization. Read it.

Many data governance problems behave like classic wicked problems:
Recursive, cross-functional, stubborn, and resistant to permanent resolution.

Data is socially constructed.
People interpret it differently.
Systems encode imperfect representations of the world.
AI systems amplify these imperfections at scale.

Governance requires legal literacy, technical fluency, risk awareness, organizational design, and information architecture. No single team holds all of this, and no single leader owns all the incentives.

That’s why governance programs collapse during reorganizations, leadership turnover, or shifting priorities. They often depend on a small group of subject-matter experts whose responsibilities sit outside governance itself. When those individuals are stretched thin or reassigned, governance resilience disappears.

And with it, performance deteriorates, data debt grows, and the cycle of reinvention begins again.

Four Forms of Governance (Why They All Exist — and None Wins)

Across industries, data governance takes four recognizable forms. These forms aren’t theoretical categories — they reflect the very real motivations that lead organizations to build governance in the first place. And most organizations adopt more than one form at a time, often without realizing it. That’s part of why governance feels inconsistent: different people are practicing different versions of it under the same name.

Here’s how these forms play out.

Nearly every organization treats data as an asset (or so they say)— but how they manage that asset varies dramatically. This is why data governance shows up in four distinct forms. These forms coexist because different parts of the business are optimizing for different outcomes: quality, risk, value, or operational performance.

Form 1: Governance for Quality (Data as an Asset Whose Value Depends on Its Condition)

In this form, governance focuses on creating high-quality, consistent, interoperable data that the organization can trust, use, and build on.

Teams working in this mode think of data like a precision instrument: the better the calibration, the more valuable the output.

Their priorities include:

• delivering reliable and accurate information products

• ensuring interoperability across systems and business lines

• strengthening stewardship roles tied to quality outcomes

• enabling better customer experiences and analytics

• productizing or monetizing data responsibly

This is data as an asset whose value rises or falls with its quality.

Form 2: Governance for Risk and Compliance (Data as an Asset That Carries Exposure)

Here, the emphasis shifts from value to vulnerability.

Risk managers view data as an asset that must be protected because:

• inaccurate data can create regulatory violations,

• misuse can trigger legal exposure,

• poor controls can cause reputational damage.

Stewardship in this form is oriented around:

• meeting regulatory requirements

• preventing breaches, misuse, and reporting errors

• managing operational and regulatory risk

• ensuring defensibility

Quality still matters — but mainly because poor quality creates risk.

This is data as an asset whose value is threatened by risk events, requiring control.

Form 3: Governance for Strategic Value (Data as an Asset That Produces Return)

In this form, governance becomes an instrument of strategy and value creation.

Leadership teams see data not just as something to protect or improve, but as something that:

• drives revenue,

• powers new capabilities,

• strengthens competitive advantage,

• and justifies investment.

Priorities include:

• Executing the data strategy

• allocating resources toward high-value domains

• enabling digital transformation

• evaluating the ROI of data initiatives

• building scalable, future-ready capabilities

This is data as an asset with direct financial and strategic value — something that belongs on the balance sheet metaphorically, if not literally.

Form 4: Governance Embedded in Operations (Data as an Asset Managed Through Design and Performance)

This form treats governance as a built-in property of the data ecosystem rather than a separate function. However, it often incorrectly conflates the governance capability with the management function.

Examples include Domain Ownership in Data Mesh, where teams are accountable for:

• producing high-quality, well-documented data products

• maintaining operational KPIs (accuracy, latency, uptime)

• embedding controls and standards directly into pipelines

• assuring interoperability through platform services

In this form, the value of the data asset is protected and grown through operational excellence rather than oversight structures.

This is data as an asset, with performance measured through technical and operational KPIs.

The Real Issue: Competing Motivations Under One Label

Every form is grounded in the idea that data is an asset — but each focuses on a different dimension of what it means to manage that asset:

• Form 1: quality → maintain the asset

• Form 2: risk → protect the asset

• Form 3: strategy → invest in the asset

• Form 4: operations → operate the asset effectively

In reality, organizations rarely choose one form.
They practice all four at the same time, often without realizing it or the skills or resources to do so effectively.

The differences may seem nuanced, but when quality teams prioritize trust and consistency, risk teams prioritize control and defensibility, strategy teams prioritize enablement and ROI, and engineering teams prioritize automation and performance — can you really make everyone happy with a handful of analysts and part-time stewards?

And because the motivations are rarely made explicit, governance becomes confusing, fragile, or internally contradictory, with each group pulling the data office in a different direction.

This is how organizations end up with governance that feels chaotic, fragile, or perpetually “in redesign.”

What Organizations Actually Do (Patterns From the Field)

Across industries and roles, a few patterns consistently appear in my quantitative research:

Most organizations technically “have data governance” — programs, policies, stewards, and frameworks exist.
But structure does not guarantee behavior.

Where a formal policy exists, enforcement becomes more than three times as likely.

The most common challenges are not technical.
They are human:

• insufficient resources and expertise (64.1%)

• lack of awareness (63.8%)

• limited knowledge (51.1%)

• cultural resistance (47.1%)

And even if you believe technology can solve all of our problems, we identified a significant lag — by more than 30% on average — between awareness of industry innovations and their implementation.

We found that organizations that perceive governance as valuable tend to have:

• stronger data cultures,

• clearer decision-making,

• better metadata practices,

• and tighter alignment with strategy.

Organizations that struggle often rely on frameworks and tools without addressing the underlying systemtic and social factors that complicate data governance.

What Leaders Should Do Now

While a common definition would demonstrate to the world we know what they heck we’re doing — it’s really not all that important. In practice, we don’t need a definition (and certainly not another one). What we do need is a way out of the cycle of reinvention — something sturdier than a new framework, cleaner than a new slide, and more honest than pretending data governance is a tooling problem, or that data management is a data problem.

Three actions matter more than anything else:

First, decide what you actually want data governance to accomplish.
Not in a broad, inspirational sense. In a specific, operational sense. Pick the dominant motivation for your program: improving quality, reducing risk, creating value, or strengthening operational performance. You’ll still practice all four, but making the primary purpose explicit changes everything — funding, staffing, decision rights, and expectations. It also stops the quiet turf wars that derail progress.

Second, resource data governance like you mean it.
The research is blunt: programs collapse when they rely on part-time stewards, heroics, or borrowed staff. Leaders consistently underestimate the coordination burden, the communication load, and the ongoing change management required. If data is an asset, treat the people who manage it like asset managers, not volunteers. Build persistent roles. Train them. Give them authority. Make governance as routine as finance, audit, or risk — not an extracurricular activity.

Third, fix the social system, not just the technical one.
Every structural weakness uncovered in the research — unclear roles, weak accountability, cultural resistance, knowledge gaps — sits upstream of every technical failure. Metadata tools don’t eliminate political tension. Lineage graphs don’t fix conflicting incentives. Automated controls don’t replace shared understanding. Leaders who focus exclusively on technology will spend the next decade wondering why their expensive platforms didn’t close the trust gap. Governance works when people work together. That requires incentives, education, norms, and leadership support — not just software.

A final point: governance is not something you “implement.” It’s something you run. It evolves as strategy evolves, and it must withstand reorganizations, turnover, and the churn of new technologies. Treat governance as an operating capability, not a project with a finish line.

Data governance didn’t define itself because we never really paused long enough to think about it. Data Governance leaders have that opportunity now. Start by choosing the purpose, building real capacity, and treating the social architecture with the same seriousness as the technical one. That’s how governance becomes resilient — without needing a rebrand every time the world changes.

How Data Governance Evolved Without Ever Defining Itself was originally published in My Column Has NULLs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Data Governance Is Everywhere — And Still Misunderstood

Most large organizations now tick the visible boxes of data governance: a named program, a documented policy, designated data stewards and committees, and frameworks cited in slide decks. On paper, data governance has arrived. From the outside, many firms now resemble what the industry has been advocating for nearly twenty years.

But according to the people doing the work, beneath the formal structure lies a different reality.

What Practitioners Actually Experience

Survey responses from 348 data governance practitioners across 46 countries show that many practitioners operate in environments where data governance is still not well understood, accepted, or integrated into organizations’ systems. We refer to this as “the adoption paradox” — structure without shared understanding, presence without performance.

If we judged maturity solely by the presence of structures, it would look like success. However, the same practitioners who report strong structural coverage also say people within their organizations struggle to understand and work with those structures. A common theme emerges when interpreting practitioner endorsements of their most significant challenges: it’s a knowledge problem.

These are not edge cases. They describe the median experience: governance functions that exist but are not widely understood; expectations that have been drafted but not fully absorbed; and goals that are documented but not consistently shared. As data governance leaders, our job is first and foremost organizational change management, and our one job above all is to explain what’s coming next in a way people can actually understand. This, of course, would require a common understanding of data governance — that we don’t currently have.

But We Have Frameworks?!

Another key insight from the research concerns how organizations adopt data governance frameworks. I previously published an article based on the preliminary data. The survey asked: Which industry frameworks do you use (if any)?

Unsurprisingly, the DAMA Data Management Body of Knowledge (DMBoK) and the Enterprise Data Management Association’s (EDMA) Data Management Capability Assessment Model (DCAM) were the most prevalent.

Some organisations used both DAMA-DMBOK and DCAM (≈ 19.2 %). Remarkably, 18.4% of surveyed organizations operate without a formal data management framework, and others indicated that their organizations rely on ad hoc or consultant-led models.

What this tells us:

• Adoption of formal frameworks is far from universal.

• Many rely on “mix and match” or bespoke models.

• The diversity of approaches may reflect creativity — or it may reflect confusion.

When frameworks are loosely applied, partially adopted, or merely symbolic, they fail to provide the clarity and shared language needed for widespread understanding. That aligns directly with the high rates of “limited knowledge” and “lack of awareness.”

In essence, structure (policy + roles + framework) can exist while coherence (shared meaning + consistent application) does not.

Enforcement as a Stress Test

One way to determine if governance is more than just a box‑checking exercise is to examine enforcement. Do organizations actually respond when governance rules are violated?

The study found that organizations with a formal policy are much more likely to report consistent enforcement than those without one. When a policy exists and is visible, enforcement is the norm. When policy is absent or unclear, enforcement turns irregular and inconsistent.

That pattern is important. It tells us that structure influences behavior, but only when people know it exists and understand how it applies to them. Policy alone doesn't ensure enforcement, but without policy, enforcement lacks a foundation.

Why Structure Is Not Enough

The literature on data governance has been debating definitions and frameworks for almost two decades. I cover this topic in depth in another article. However, the reality is that data governance emerged through necessity, regulation, and vendor pressure—before it had a stable conceptual foundation. Decades of reactive practice, limited empirical research, and competing perspectives created ambiguity at the heart of our field.

One consistent thread in academic and practitioner literature is that data governance is ultimately about decision rights and accountability — who decides what, based on which rules, and with what oversight. In theory, that sounds straightforward. In practice, those decision-making rights sit within silod, political organizations that face pressures from their macroenvironment. If governance is introduced mainly as a set of documents and committee charters, without equal investment in communication, relationships, and incentives, it tends to stall. People hear “governance” and think “extra work,” “slow approvals,” or “someone else’s job.”

The research points to a simple conclusion: structure is necessary, but not sufficient. Governance becomes effective when structure and behavior move together. Policies, roles, and frameworks provide shape. Understanding, engagement, and reinforcement supply energy.

The Human Side of the Problem

The challenge, then, is not to invent yet another governance framework, to refactor organizational structures, to adopt the most elegant architecture, or to buy the latest tools. It is to make the existing structures legible and usable to the people who are supposed to work within them. That means:

• Explaining governance in business language, not only in technical or compliance terms.

• Making roles and decision rights clear, so people know when governance applies and what is expected.

• Aligning goals so that governance is seen as a way to achieve outcomes, not just avoid penalties.

• Investing in communication and reinforcement, rather than assuming a policy announcement is enough.

These are not “soft” problems. They are the primary reasons that structurally sound governance programs fail to deliver on their promises. When awareness is low, knowledge is thin, and goals are unclear, it does not matter how many frameworks an organization has adopted. The system will drift.

What Leaders Should Do Next

If you are leading a data governance program or a data management function, it is worth assuming that your organization already has more governance structure than it has governance understanding. The question is not “Do we have a program?” The better questions are:

• Do people across the business know what that program actually does?

• Can they explain, in simple terms, how data governance affects their decisions?

• Are enforcement actions predictable and fair, or ad hoc and painful?

• Do our stated goals for data governance match how people experience it day to day?

Answering those questions honestly will likely reveal that the next wave of work is less about new structures and more about communication, clarity, and alignment. The data suggests that organizations that invest in those areas are the ones that move governance from paperwork to practice.

In other words, data governance is mainstream. The next step is to make sure people actually understand it.

Data Governance Is Everywhere — And Still Misunderstood was originally published in My Column Has NULLs on Medium, where people are continuing the conversation by highlighting and responding to this story.

I am a veteran data leader in the financial services industry and a PhD candidate in the field of Information Quality, currently completing my dissertation entitled, “Towards Resilient Data Governance: An Industry Study on the Current State of Data Governance Practice.” The findings presented in this article are preliminary and subject to further refinement and validation prior to final publication. Given the significant interest from the data management community, I am sharing these early insights and plan to release additional findings as my research progresses.

Data Governance entered the lexicon of academic and industry literature more than a generation ago. Yet, practical implementation remains challenging and few organizations have achieved resilience — or the ability to incrementally adapt, recover, and continue mission when faced with disruption such as organizational change or macro-environmental influences. My research addresses a critical gap: the lack of comprehensive empirical understanding regarding the actual practice of data governance in organizations from those working at the coal face. I believe this gap (and the fact our profession is comfortable accepting the map as the terrain) combined with the capability’s ambiguously definition, amorphous practice, and reactive ethos, contribute significantly to the persistent perceptions of data management failure and skepticism surrounding data governance initiatives.

The core objective of my research is to provide a detailed and empirically grounded picture of data governance as it is practiced across industries, focusing particularly on perspectives from professionals who are aware of their organizations’ data management practices. By capturing information about them, their organizations, and their perspectives, my study aims to deliver insights necessary for both academia and industry to effectively tackle the broader and more complex challenges associated with data governance.

This preliminary analysis specifically explores organizational adoption patterns for widely recognized data governance frameworks, notably DAMA-DMBOK and DCAM. The survey gathered responses from 341 data governance professionals across various industries and organization sizes. Most worked in large firms, with a strong representation from Finance, Insurance, and Real Estate (45.5%). Over half held roles in Data Management, and most were in managerial or executive positions.

Cross-tabulation analysis reveals nuanced adoption trends: approximately 19.25% of respondents utilize both frameworks concurrently, suggesting they are not in conflict. Additionally, 27.30% exclusively use DAMA-DMBOK, while 22.41% solely implement DCAM, suggesting each framework uniquely addresses distinct organizational requirements. Meanwhile, a substantial portion of organizations (31.03%) still operate without formal frameworks, and those that do use a wide range of approaches — from DAMA and DCAM to custom-built models — reflecting the field’s diversity but also a lack of standardization.

Examining overall framework adoption reveals that DAMA-DMBOK is the most commonly cited (46.6%), closely followed by DCAM (41.7%). Usage of frameworks like the Cloud Data Management Capabilities (CDMC) and various ISO standards remains notably lower, at approximately 14.4% and under 7%, respectively. Remarkably, 18.4% of surveyed organizations operate without any formal data governance framework, underscoring significant variability in governance maturity across industries.

Statistical analysis further underscores significant industry-based differences in framework adoption.

Chi-square tests confirm disparities, particularly in organizations with no formal framework and those using DCAM, with notable differences driven by factors such as regulatory requirements, organizational scale, and data intensity. Sectors like finance and technology, characterized by stringent regulation and substantial data reliance, typically exhibit higher adoption rates and advanced governance practices. Conversely, smaller or less data-intensive industries often rely on customized or informal governance practices.

Additional examination of alternative governance frameworks reveals considerable diversity. Custom or in-house solutions were the most frequently cited alternatives (23.4%), suggesting a preference for highly tailored approaches addressing unique organizational challenges. Other noted alternatives include consulting-led, agile, or named frameworks, indicating continuous innovation and adaptation within the data governance community.

Understanding what industry frameworks practitioners and organizations apply to their data management practices is foundational to understanding predominant industry methods. These insights are crucial for evaluating the factors that contribute to the effectiveness of data governance in meeting organizational objectives, fostering necessary cultural and behavioral change, and refining strategies to manage data and information as a organizational assets.

Future analysis within my research will continue to explore these themes in greater depth, seeking to identify the attributes contributing to resilience in data governance practices. The aim is to help organizations and researchers gain a deeper, empirically informed understanding of effective data governance practices, thus enhancing the profession’s credibility and the efficacy of data governance initiatives.

Understanding Data Governance Framework Adoption Across Industries (Preliminary Findings) was originally published in My Column Has NULLs on Medium, where people are continuing the conversation by highlighting and responding to this story.