When Governance Clashes: Why Your Data Strategy Needs a Truce Between IT and Analytics

You’ve built something that works.

Your analytics team is delivering value across the organization—fielding thousands of reporting and analysis requests, integrating disparate data sources, and helping leadership teams make smarter, faster decisions. You’ve earned the trust of senior stakeholders because your team doesn’t just report the numbers—you shape decisions with confidence.

Your technical foundation is sound. Your operational workflows are mature. Your team is working in tight alignment with the people who rely on data every day.

And yet, tensions are starting to rise.

You notice a second reporting system popping up inside the IT organization. Definitions begin to drift. Data access requests reroute through unfamiliar channels. Colleagues in other departments aren’t sure whether to call your team or IT for their next project—and your stakeholders start questioning which version of the data to believe.

No one’s trying to sabotage the strategy. But the seams are showing—and they’re pulling wider.

What’s happening here isn’t rare. It’s the fallout of a common and costly misunderstanding: treating data governance and IT governance as the same thing.

They’re not.

And unless your organization makes that distinction clear—then aligns the two in partnership—your data strategy will eventually get stuck. Not because the strategy is flawed. But because governance, and the teams driving it, are misaligned at the foundation.

IT Governance Is Not Data Governance

When the word governance appears in two different domains, it’s easy to assume they belong together. But IT governance and data governance are not interchangeable—and mistaking one for the other is a primary source of friction that undermines even the best-intentioned data strategies.

IT governance focuses on technology. Its purpose is to align IT investments with business priorities, manage architectural standards, ensure security, mitigate risk, and keep the lights on. It's fundamentally about infrastructure and service delivery. IT asks: What platforms and processes do we need to run the business reliably and securely?

Data governance, by contrast, is about meaning and use. It’s the business function responsible for defining what data means, ensuring it’s fit for purpose, and making sure the right people have access to the right data at the right time—with confidence in its accuracy. It asks: What does this data represent, how should we use it, and who owns the responsibility for its quality?

Confusion arises because both disciplines contain shared language—governance, ownership, stewardship, compliance. But that shared language masks wildly different objectives. IT wants to manage change, secure systems, and deliver scalable solutions. Data governance wants to ensure that data is interpreted consistently and trusted by those who depend on it for decisions.

Without clarity and coordination between these two governance functions, organizations fall into a familiar trap: IT builds tools and pipelines based on loosely defined requirements. The analytics team responds by standing up parallel processes to protect quality and regain control over definitions. Each group believes they’re solving a business problem, but they’re working from different assumptions—and often, in isolation.

How the Tension Shows Up (and Why It Costs You)

The tension between IT and analytics is not just theoretical. It plays out in visible, painful ways—ones you’ve likely seen firsthand.

One of the most common patterns is the rise of competing systems. You see it when IT, under pressure to respond to stakeholder requests, spins up quick-win dashboards or reporting environments using data sources they barely understand. Their intention is good: deliver value fast. But in the absence of clear definitions, governance standards, or context, they inadvertently create artifacts that contradict core enterprise reporting.

At the same time, analytics teams often build their own infrastructure to protect quality and reliability. When they don’t trust IT’s pipelines—or when they've been burned by inconsistencies—they build shadow data pipelines, complete with their own ETL processes, data validation steps, and gold-standard sources. The result? Parallel infrastructure, version control chaos, and yet another data silo to manage.

Sometimes the consequences are more dramatic. For instance, a secondary system built outside the oversight of the analytics team might generate a report that claims an organization has millions of [insert critical enterprise data point here]—when the actual number is in the thousands. In this hypothetical (which we’ve seen this very real pain time and again), the developers aren’t negligent; they’re acting on the best information they have.

But that information lacks the domain context, rules, and quality checks maintained by the analytics team. Without that foundation, the system introduces serious reputational and regulatory risk.

Even when the outputs aren’t as egregious, broken reporting undermines trust. Stakeholders get different numbers depending on which system they use. Executives stop believing in the data. And teams that should be collaborating end up defending their own versions of the truth.

Meanwhile, the tool sprawl gets worse. IT is asked to support infrastructure they didn’t build. Analytics teams are stretched thin maintaining legacy scripts and data assets no one remembers building. And instead of aligning around scalable enterprise capabilities, everyone is stuck managing exceptions.

These aren't just operational inefficiencies. They're signs of a deeper cultural disconnect.

At its root, the problem is one of mutual misunderstanding. IT doesn’t always understand what the business needs—or why those needs matter. So, they act like order takers, implementing requirements without questioning whether they align with business goals. But that lack of questioning robs them of their ability to serve as gatekeepers. Developers lose the chance to catch bad requirements before they result in broken solutions.

On the flip side, the business doesn’t always understand the limits of legacy systems—especially brittle, aging infrastructure that can’t accommodate a new requirement without major rework. That gap in understanding leads to frustration on both sides. Business users think IT isn’t responsive. IT thinks the business is asking for the impossible.

And through it all, developers get caught in the middle. They're the ones asked to interpret unclear requirements, find “golden sources” of data with no guidance, and build applications that straddle conflicting definitions. Without formal inclusion in the data governance process, they become accidental arbiters of data meaning—forced to make calls that should’ve been decided upstream.

This dynamic leads to costly outcomes:

• Regulatory exposure, when incorrect data flows into compliance reports.
• Duplicated costs, as teams build redundant systems in parallel.
• Delayed projects, when tension stalls development or derails delivery.
• Siloed expertise, as developers, DBAs, and analysts work without a shared understanding.
• And most critically, lost trust, which corrodes every part of the data value chain.

The fix isn’t to collapse one governance structure into the other. It’s to clarify the distinction—and build the collaboration.

In the next section, we’ll explore how to do just that.

Five Moves to Rebuild Collaboration and Clarity

1. Clarify Ownership vs. Stewardship

One of the first—and most foundational—steps toward rebuilding clarity between IT and analytics is making a sharp distinction between ownership and stewardship.

In many organizations, ambiguity around who "owns" the data creates ongoing confusion and resentment. IT believes they are responsible for the data because they manage the systems that house it. Analytics teams, by contrast, see themselves as the curators of data meaning, responsible for ensuring definitions, quality, and usability. When this line is blurry, tensions around authority and accountability escalate quickly.

The truth is, both perspectives have merit—but they are different roles.

• IT owns the systems. They are responsible for the technical infrastructure: the databases, platforms, servers, security, and compliance mechanisms that ensure the safe storage and movement of information.
• Analytics stewards the data. They are responsible for what the data means, how it’s defined, how it’s trusted, and how it’s used by decision-makers across the business.

Ownership is about technical custody. Stewardship is about business responsibility.

Without recognizing this distinction, organizations risk one of two failures: either IT overreaches into defining data meaning (without business context), or analytics teams attempt to bypass IT entirely in pursuit of speed—resulting in fragmented, insecure solutions.

A healthy governance model formalizes both roles without diminishing either. IT remains critically important. They ensure the systems are secure, resilient, and performant. But it’s the business—through analytics and domain stewardship—that defines what the data represents and how it should be used.

This clear division of labor doesn't weaken collaboration; it enables it. IT can focus on delivering high-quality, trusted systems. Analytics can focus on maximizing data’s business value.

Organizations that get this right foster an environment where infrastructure supports innovation, not stifles it—and where trust grows because roles and responsibilities are understood, respected, and codified.

2. Co-Define Governance Priorities

Once roles are clarified, the next step is to co-define governance priorities—deliberately and collaboratively.

In too many organizations, governance frameworks are written in silos. IT drafts standards to control system changes, manage access, and enforce security. Analytics—or the business—drafts guidelines for metadata management, data quality, or data accessibility, often in response to project needs. The result is a patchwork of policies, many of which inadvertently work against each other.

This fragmentation isn’t just inefficient; it actively breeds distrust. IT feels blindsided by analytics-led initiatives that create architectural risk. Analytics feels stifled by IT processes that delay or limit critical data access.

The antidote is a shared governance agenda.

Instead of separate, competing documents, IT and D&A leaders must come together—early and often—to define a mutual governance charter. That charter should answer foundational questions, such as:

• What does good data governance look like in this organization?
• Where do we jointly need to enforce standards (e.g., security classifications, access protocols)?
• Where do we enable flexibility and business-specific adaptation?
• How will we handle disputes over ownership, priority, or interpretation?
• What are the first principles guiding decisions when trade-offs are required?

When these conversations happen before projects launch, governance becomes an accelerator, not an obstacle. It creates a shared understanding of guardrails and freedoms—where precision is critical, and where agility is acceptable.

Critically, this shared charter should not be academic. It must be built around real business priorities. It must consider regulatory obligations, organizational risk tolerance, and the true cost of governance complexity.

The goal is not to create a perfect governance model on paper. The goal is to create working governance that evolves with the business—minimizing friction, maximizing trust, and aligning the strengths of both IT and analytics toward shared outcomes.

Organizations that co-define governance priorities don’t just move faster. They also endure change better—because when pressure mounts, their teams aren’t guessing about what matters most. They already know.

3. Anchor Governance in Use Cases

If governance lives only in policies and frameworks, it quickly loses its relevance to the people it’s meant to serve. To truly succeed, governance must be anchored in real, tangible business use cases.

It’s easy for governance initiatives to get bogged down in abstract principles. Teams debate hypothetical risks, perfect taxonomies, and theoretical controls. Meanwhile, project teams struggle to find the right data, stakeholders default to workarounds, and the business quietly builds new systems to sidestep slow processes.

Grounding governance in use cases flips this dynamic.

When you anchor governance in the real-world decisions that people are trying to make—whether it’s regulatory reporting, enrollment forecasting, customer segmentation, or resource allocation—you make governance practical. You move it from theory to practice.

Instead of debating whether a policy is comprehensive, you ask:

• What decision is at risk if the data is wrong?
• What controls will meaningfully protect the decision quality?
• Where do we need speed, and where do we need caution?
• Who owns the outcome, and who stewards the data that enables it?

This shift changes how teams think about governance. It’s no longer about compliance. It’s about protecting business outcomes.

Let’s go back to our earlier example of a secondary data system built outside the oversight of the analytics team, designed to quickly deliver ad hoc reports. It seems efficient—until one day it produces a report claiming the organization has millions of XYZ, when in reality the true count is in the thousands. The developers who built the system aren’t at fault. They’re fulfilling requests with the information available to them. What’s missing is the context: business rules, source knowledge, and validation protocols defined and maintained by the analytics team.

This is what happens when governance is abstracted from use. Had the governance program been built around actual business priorities—regulatory reporting, performance management, operational forecasting—data definitions would have been standardized. Stewardship responsibilities would have been clear. And the discrepancy would have been caught upstream, long before anyone hit “send” on that flawed report.

The lesson here: successful governance starts with specific, high-value use cases. Define what decisions must be supported, what data those decisions rely on, and what it takes to make that data reliable. Only then can you build governance structures that stick—because they’re solving problems the business already cares about.

By focusing on use cases, you also prioritize efforts where they matter most. Instead of trying to govern every piece of data equally, you concentrate resources on critical data domains where the cost of error is highest—compliance reports, executive dashboards, customer impact metrics, and so forth.

Anchoring governance in use cases creates urgency. It builds credibility. And it provides the clearest possible answer to the inevitable question: “Why are we doing this?”

4. Empower Developers as Gatekeepers

Developers are often treated as order-takers—handed specs, tasked with implementation, and rarely looped into the "why" behind what they’re building. That’s a missed opportunity. In truth, developers are one of your most powerful allies in enforcing data governance—if you give them the right tools, rights, and responsibilities.

When developers understand the business rationale behind a data request—not just what to build, but why it matters—they become a second line of defense against flawed assumptions and bad data. If a request contradicts earlier logic or seems to bypass established rules, a well-informed developer can raise a flag, question the requirement, and help prevent downstream issues.

But this only works if the ground rules are clear. Developers need to know where to find authoritative sources, what quality standards apply, and when to escalate a requirement that seems off. They also need air cover—support from data governance leadership to say “no” or “not yet” when something violates the integrity of the system.

Too often, teams try to route around governance. They hand a vague requirement to a developer—"go find this data and make it work"—without regard for source system limitations, conflicting definitions, or necessary validations. And when that developer dutifully delivers what was asked for, the result can be a report built on sand.

The fix isn’t more process. It’s smarter empowerment. Train your developers on the governance principles that matter. Give them reference architecture and lineage documentation. Clarify escalation paths. Then, treat them as what they are: the stewards of how governance becomes real in production systems.

When developers are equipped to ask better questions—and trusted to challenge incomplete requirements—you create a system where governance isn't just a policy. It’s a practice embedded in the build.

5. Build Governance Partnerships at the Top

If you want data governance to stick, it can’t just be a middle-management project or a technical initiative buried in IT. You need senior leaders—specifically your CIO, CISO, and CAO—aligning around shared goals and visibly modeling the collaboration you expect across the organization.

In environments where IT, security, and analytics have historically operated in silos, this alignment won’t happen by accident. It takes deliberate effort to build relationships, clarify roles, and acknowledge cultural differences between teams.

Your CIO may be steeped in system architecture and risk mitigation. Your CISO lives and breathes compliance and security. And your analytics leader is focused on enabling decision-making with trusted data. These leaders bring different instincts and priorities to the table—but that diversity is a strength, not a barrier.

And the breakthrough won’t come from redrawing org charts. It comes when the CIO, CISO, and CAO recognize that they could form a coalition of peers—each owning their distinct area of governance but coordinating on points of intersection.

Rather than arguing about who “owns” data governance, they should focus on where their mandates overlap:

• The CISO defines risk thresholds for sensitive data and advised on monitoring.
• The CAO champions stewardship, business-defined quality standards, and reporting accuracy.
• The CIO ensures architectural support, system integration, and operational execution.

Together, they map a joint governance model with clear handoffs and shared accountability. And more importantly, they agree to present a united front—to executive leadership and to the teams below them—signaling that collaboration wasn’t optional.

The result? Better trust, faster resolution of conflicts, and a governance structure capable of supporting both control and innovation.

If you’re rebuilding governance today, don’t underestimate the symbolic and practical power of top-level alignment. It’s what turns governance from a theoretical framework into an operational reality—one that everyone, from developer to board member, can understand and respect.

Five Moves to Rebuild Clarity and Collaboration: Recap

1. Clarify the Difference Between Data Governance and IT Governance
   Don’t let shared language create false equivalence. IT governance manages systems and infrastructure; data governance manages meaning, quality, and usage. Conflating the two will derail both.
2. Define Shared Principles and Handshakes
   Collaboration starts with clear boundaries and intentional connection points. Agree on principles, define handoffs, and empower each domain to lead where they are strongest.
3. Anchor Governance in Real Use Cases
   Abstract policies don’t drive adoption. Align governance to high-impact business needs—like regulatory reporting or operational decision-making—to keep it practical and outcome-oriented.
4. Treat Developers Like the Gatekeepers They Are
   Developers shape how data is sourced, transformed, and delivered. Equip them with standards, golden sources, and the authority to flag broken requirements before they turn into bad builds.
5. Build Governance Partnerships at the Top
   Senior leaders must model cross-functional alignment. When your CAO, CIO, and CISO act as peers—not competitors—governance becomes actionable, respected, and sustainable.

Conclusion: The Cost of Misaligned Governance Is Real

Governance tension between IT and analytics isn’t just a philosophical debate—it shows up in missed deadlines, conflicting reports, regulatory risk, and the slow erosion of trust in your data assets.

The good news is that the friction isn’t inevitable.

It’s often the result of misaligned roles, unclear priorities, and governance efforts that lose sight of the decisions and outcomes they’re meant to enable.

By drawing clearer lines between IT and data governance, anchoring efforts in real business needs, empowering developers as stewards of quality, and securing strong leadership alignment at the top, organizations can rebuild trust—and set their data strategies up for durable, scalable success.

Governance done well isn’t a barrier to innovation. It’s the foundation that allows innovation to happen responsibly and at scale.