Shared Data Accountability Between Engineering and Business Units

A sales manager pulls up the weekly revenue dashboard and sees a specific total. An engineer, looking at a different report built off the same warehouse, sees a noticeably different total. Both numbers come from the same company, the same quarter, the same underlying transactions. Neither person is wrong. They're just answering a question nobody agreed on the definition of.

That moment, two people staring at two numbers that should match and don't, is what happens when data governance has nowhere to live. For years, most companies treated data governance as something IT handled: engineering owned the pipelines, the permissions, the dashboards, and everyone else just asked for what they needed. The companies that handle data well at scale now treat governance as something engineering and business units build together.

The failure isn't technical. It's structural. When one team holds every piece of data governance, from who can see what to how "active user" gets calculated, two things can happen, and both are bad. Either that team locks everything down tight enough to stay in control, which pushes business units toward shadow spreadsheets and manual CSV exports because asking for official access takes three weeks. Or that team can't keep up with every request and definition, so access goes ungoverned and metrics go undefined, and nobody can agree on what "revenue" even means. One failure makes data inaccessible. The other makes it unreliable. Trust breaks down either way.

The clearest sign something's wrong is metric drift: the same KPI, calculated three different ways by three different teams, producing three reports that can't be reconciled no matter how long someone stares at the spreadsheet. This happens because every team building on top of the same warehouse ends up writing its own business logic, its own lookup tables, its own quality checks. Two tools reading from the exact same data warehouse end up with two different definitions of "active user," and nobody notices until a board meeting goes sideways. It's a gap in the infrastructure, not a naming disagreement people can sort out in a quick conversation, and only a shared definitional layer, something both sides help build and maintain, can close it.

What the split should actually look like: engineering sets guardrails, business units own their domain

The fix is splitting the job into two different kinds of ownership that work together, rather than picking a winner between "engineering controls everything" and "business units control everything. Engineering builds the infrastructure of trust: the permissions, the metric definitions, the access controls, the automated checks that catch bad data before it reaches a dashboard. Business units own the data inside their own domain: naming the right person to watch over it, confirming it matches reality on the ground, setting a cadence for reviewing it, and reporting it upstream when something looks off.

This lines up with where data governance is heading in 2026: away from one central team owning everything, toward a domain-based model where each business area manages its own data inside a governance framework that engineering sets and maintains. Engineering's job under this model is to build the platform, enforce the policy layer, certify which data assets are trustworthy, and define the shared vocabulary everyone draws from. That vocabulary is the rail system that keeps separate domains from drifting into total fragmentation. Business units' job is to put a named steward in every department, confirm that shared definitions actually match how the business runs day to day, own the accuracy of whatever data their team produces, and know exactly where to send a quality problem when one turns up.

DAMA-DMBOK, one of the standard frameworks for data management, formalizes this with specific roles: data stewards, and sub-roles like data custodians, which DAMA treats as functionally the same as stewards, paired with clear accountability structures and a maturity model teams can use to measure how far along they are. A data steward sitting inside a business unit catches things a central engineering team never will. They know that a "closed deal" in the CRM doesn't always match what finance means by "booked revenue," because the sales team closes a deal the moment a verbal yes comes in, while finance waits for a signed contract. A data custodian on the engineering side holds a different kind of responsibility: keeping pipelines running, schemas stable, access rules enforced, without needing to understand every nuance of how sales defines a closed deal.

The obvious pushback: doesn't handing domains their own autonomy just recreate the fragmentation problem at a smaller scale? If every department defines "active user" its own way, the drift returns, spread across more teams. The split only holds up if there's a shared definitional layer that engineering builds and maintains alongside that domain autonomy. Business units are free to own their data within definitions that are shared, governed, and enforced across the company.

How a shared business glossary prevents metric drift

A business glossary is a maintained, shared dictionary that spells out what each term means and how each metric gets calculated. It's the single mechanism that stops finance, marketing, and engineering from quietly using the same word to mean three different things. Auditors and regulators treat a well-maintained glossary as a basic requirement for sound governance, not a nice-to-have.

The real value of a glossary is what it replaces. Without one, metric definitions live as tribal knowledge, held in the head of whoever happened to build the first dashboard. With one, those definitions become a governed artifact that any team can look up and any tool can pull from directly. A sales leader and a finance leader looking at "revenue" see the exact same number, calculated the exact same way, because the definition is enforced at the layer both their tools read from. For marketing and revenue teams especially, governance gaps produce inconsistent metric definitions across different ad platforms and broken attribution chains between a click and a closed sale. A glossary that covers those specific definitions removes the single most common source of cross-team arguments.

Engineering's job in this setup is to build the glossary and enforce it technically. Business units' job is to write the actual definitions and confirm they hold up in practice. A marketing steward owns what "qualified lead" means. Engineering makes sure every dashboard pulling that term reads from the same certified column, so there's no second, slightly different version floating around in someone's personal spreadsheet. Skipping the validation step from the business side turns the glossary into a document engineering keeps updated that nobody else actually trusts or checks.

The most common way glossaries fail: they get built in a wiki or a Confluence page, and within a few months the definitions go stale, nobody enforces them, and every team quietly goes back to writing its own logic. The fix is embedding the glossary directly into the tools people already query, so a term gets pulled automatically at query time instead of requiring someone to go look it up manually. The major governance platforms built for 2026, Collibra, Microsoft Purview, Atlan, Informatica, Alation, and Snowflake Horizon, all treat the business glossary as a core feature rather than a bolt-on extra, and all link glossary terms directly to the actual data products and assets people query. Collibra's platform integrates its glossary directly with the technical assets it describes. Informatica's catalog automatically links glossary terms to the technical data assets that carry them. That's what a governed definition looks like at the scale of a real company: not a document, but a live link between a word and the exact column it points to.

Role-based access controls as the permission architecture that makes domain ownership safe

None of this works if giving a business unit access to its own data means giving that unit access to everything. That's the real reason engineering teams push back on broad self-serve access, and they're right to. The permission system that enforces self-serve access decides whether domain ownership is something teams can actually act on or just a policy written on a slide.

Role-based access control, RBAC, solves this by grouping permissions into roles and assigning those roles by team membership. Someone joining the marketing team inherits whatever role marketing has. Someone leaving the company loses every permission tied to that role the moment it's revoked, in one step, without an engineer hunting down individual grants across a dozen tools. Access tracks who's actually on the team, automatically.

Reusing the application's own database user for analytics access is the mistake that undoes all of this. Do that, and the BI tool inherits every write privilege the application has, with no way to audit, rate-limit, or revoke analytics access on its own. One runaway query from a well-meaning analyst can lock a production table. The access split should mirror the accountability split directly: analysts and other business-unit users get read access scoped to their own domain, engineers get operational access to build and maintain the systems, and administrators alone hold the keys to cost and scaling decisions.

Row-level permissions push this further, down to the data itself. A support rep can see every ticket assigned to their own region without seeing tickets from any other region, and engineering never has to build a separate custom view for each team to make that happen. This is the actual mechanism that turns "safe, permissioned self-serve access" from a policy statement into something real. A BI layer or database interface that enforces row-level permissions automatically at query time, rather than counting on analysts to behave and self-restrict, is the right tool for any team that wants to open up broad access without opening up broad risk.

Data stewardship by department: how to assign ownership without creating new bottlenecks

Putting data stewards inside business departments, not inside a central data team, is what actually makes domain accountability real. If this step is skipped, governance responsibility quietly drifts back to engineering by default, because someone has to own it and engineering is the only team left holding the keys.

A steward's job is different from an engineer's. Stewards confirm that shared definitions match how the business actually runs, review data quality alerts as they come in, approve access requests for their own department's data, and own the accuracy of whatever their team reports upward. Inside a sales department, the steward is the one who knows "closed-won" means a contract has been countersigned, not that someone said yes on a call. That's a distinction a data engineering team has no reliable way to encode on its own, because it depends on how sales actually operates, not on how the database is structured.

The risk with this model is obvious: if every single access request has to route through one central steward or one central governance team, the original bottleneck just reappears one level down, with a different name. The fix is federated governance, where each domain's own steward approves requests for that domain's data, paired with self-service paths that let analysts grab non-sensitive data instantly through a catalog with no approval step. Tiering requests by sensitivity, instant self-serve for low-stakes data, steward approval for anything domain-sensitive, engineering review only for genuinely restricted data, keeps the common case fast while keeping real controls where they're actually needed.

Dashboard ownership is the stewardship task most teams skip entirely, and it's usually the first thing to fall apart. Every dashboard and every metric needs one named owner and a set cadence for review, or it degrades quietly while the underlying data keeps changing underneath it. If that step is skipped, dashboard sprawl sets in: hundreds of overlapping reports, no owner, no process for retiring the old ones, and people spend more time guessing which report is current than actually using the data. Naming conventions, clear ownership, and regular cleanup are organizational habits, not engineering tasks. They belong to the steward.

Kiwi.com put this into practice by deploying Atlan as a data catalog and governance platform, assigning stewardship out to the business side. Engineering workload dropped significantly, because requests that used to land on an engineer's desk now got handled by the steward who actually owned that data. That's the practical payoff of distributing stewardship correctly: engineering no longer bottlenecks every access request and quality question, and instead spends its time on the guardrails only engineering can build.

Cost accountability for shared data infrastructure follows the same ownership logic

Shared data infrastructure runs up costs that are hard to pin on any one team by default, and when ownership of that cost is unclear, finance can't reconcile its allocations and engineering has no way to know who should actually fix the inefficiency. That's the same structural problem as metric drift, just measured in dollars instead of definitions.

A chargeback model fixes this by assigning platform costs to the teams and business units that actually generate them, using rules that finance, platform leaders, and business owners agree on together. It connects technical usage to business ownership the same way RBAC connects technical access to organizational roles: someone's team, someone's resource, someone's responsibility. The design principle behind it produces the same governance split: engineering sets the guardrails, business units own their domain. Separate the costs that can be traced to a specific team or workload from the costs that are genuinely shared platform overhead, and explain both clearly instead of either allocating every dollar to someone or allocating nothing to anyone.

Showback, reporting each team's estimated usage without actually charging them for it, is the right place to start when teams need time to understand their own consumption before it starts hitting their budget. It builds awareness first, consequences second.

None of this works without named owners on every side of the table. A named owner in finance and a named owner in each consuming team gives both sides a clear path for resolving a dispute over cost allocation, without needing to pull engineering in to referee every disagreement. This is a failure of accountability, not just a technical gap: business units running expensive queries often have no visibility into the cost they're generating, and engineering has no built-in way to attribute that cost or cap it. Statement timeouts, budget alerts set at the warehouse level, and usage reports tagged by workload are the engineering controls that make business-unit consumption visible and bounded, the exact same kind of guardrail engineering builds for access and definitions, just applied to the budget line instead.

Connecting a BI tool to a production database safely under a shared accountability model

All of this comes down to one concrete decision engineering has to make: how to let business units query real data without putting the production system at risk. Four controls belong entirely to engineering's side of this split, and skipping any one of them is how a well-meaning analyst accidentally takes down a live application.

A dedicated read-only database role, separate from the application's own database user, is the first one. Reusing the application's credentials for analytics means losing the ability to audit, rate-limit, or revoke that access independently, and the BI tool ends up holding write privileges it has no business touching.

A statement timeout is the second. Without one, a single analytics query can run indefinitely, chew through production resources, and slow down the actual application everyone else depends on.

These aren't complicated controls to put in place, and that's exactly the point. The engineering side of this split means setting a small number of guardrails correctly, once, so that business units can own their data confidently without ever putting the systems underneath it at risk.