The scope is easy to agree on. Harvest the estate, model the concepts, version the definitions, compile them into the systems that consume them, verify that all of it still matches reality.
Then someone asks which team does it, and the answers stop.
In most organizations the honest answer today is four teams, partially. Governance owns the policy and the glossary. Analytics engineering owns the metric definitions inside the BI models. The platform team owns the harvest infrastructure. The AI team owns whatever context their application needs this quarter.
Four partial owners produce the same outcome as zero owners, and it takes longer to notice.
The four candidates, and how each one fails
Data governance has the mandate, the vocabulary, and the relationship with risk and audit. It's the obvious home on an org chart.
It fails when the team has no write access to transformation code. Definitions get documented, approvals get logged, and the estate goes on doing whatever the code says. The role degrades into a curation queue, which is the specific failure the discipline exists to prevent.
Analytics engineering is closest to the work. They already own the metric definitions, they live in the semantic models, and they write the transformations that create the numbers under dispute.
It fails at the boundary of their remit. The mainframe extract feeding the regulated report, the stored procedure from 2019, the source systems that predate the modern stack: none of that is theirs, and coverage stops where their scope stops. The estate ends up well described in the third of it they touch.
The data platform team has the reach. They run the infrastructure, they have CI/CD discipline, and they hold credentials on systems the other teams have never touched.
It fails on meaning. A platform team will run metadata as a system, keep it available, and have no view on which of four revenue columns is correct, because that isn't an infrastructure question. Coverage gets solved and governance state stays empty.
The AI platform team has the urgency and, right now, the budget.
It fails on scope and on time. Scope, because the work collapses to whatever the current application needs, and BI and audit get orphaned. Time, because a function justified entirely by AI initiatives has no second argument when the AI budget cycle cools.
The decision turns on capability
Placement debates usually get argued from the org chart. The better question is narrower.
Which of these teams has write access to the transformation code, credentials on the legacy systems, and a deploy pipeline they already run?
That's the constraint, because four of the five stages are engineering work. Harvest requires connectivity. Version requires environments and promotion. Compile requires writing into other systems' native formats. Verify requires automated checks. A team that has to file a ticket for any of those will run the practice at the speed of the ticket queue.
Model is the exception. It's the one stage that turns on business judgment, and engineering access does little for it.
That split determines the placement.
The default, and the two things that override it
Default: the data platform or data engineering team owns execution, with governance owning the Model stage.
The platform team has the reach and the operational discipline for four stages. Governance supplies what platform lacks: who owns a definition, what policy applies, what the audit requirement actually says. The MetadataOps engineer sits on the platform side and takes definitional requirements from governance the way any engineer takes requirements.
Override one: a BI consolidation is the forcing function. If the pressing problem is two BI tools producing different numbers, or a migration is underway, analytics engineering should lead and the platform team should supply harvest coverage. The work that matters in that scenario is concentrated where analytics engineering already lives, and reporting to a platform team would add a handoff to every decision.
Override two: regulated reporting is the driver. If the pressure is audit evidence and defensibility, governance leads and embeds an engineer with real write access. The evidence requirements are the hard part and governance understands them; the engineering is the tractable part.
Notice that both overrides follow the same rule as the default. Put the practice where the binding constraint already is.
The reporting line is a separate question
Where the work executes and who hears about it are different decisions, and conflating them is what stalls these conversations.
MetadataOps can execute inside a platform team and report its score to the CDO monthly. That arrangement gives the engineer the access they need and gives the executive the visibility they need, and it survives a reorg better than a function that reports where it executes.
For a data leader, the number to ask for is the metadata completeness score with its denominator, plus the list of systems still dark. That reporting relationship works regardless of which team the engineer sits in.
The anti-pattern
The most common resolution is a virtual team: representatives from all four groups, a monthly meeting, shared accountability.
This produces the four-partial-owners situation with a calendar invite attached. The five stages generate artifacts, and artifacts need a single owner who can be asked why one of them is missing. A committee can set the standard. It can't run the deploy.
If a virtual team is the only politically available option, give one named person the artifacts and let the committee advise them.
How to settle it
Put the same three questions to each candidate team.
What percentage of our estate do you currently have harvested metadata for, and what's the denominator? Can you promote a definition change through an environment and roll it back? Who would you call to find out what our finance close means by net revenue?
The first two sort on engineering capability. The third sorts on relationship. The team that answers two of the three is your owner, and the missing answer is the interface you need to build to whoever can supply it.
