The UNS debate is over. Most plants past pilot stage have accepted that a broker-based, ISA-95-modeled namespace beats a spaghetti of point-to-point historian tags, and that “data products” — OEE, genealogy, downtime, quality events, published as governed, discoverable, contract-bound datasets — are the right unit of delivery for an MES project. That argument is won. What’s left is messier and less glamorous: now that a plant has thirty, sixty, a hundred of these things published from MES, SCADA, and edge historians onto MQTT Sparkplug B or OPC UA-based namespaces, who actually owns any single one of them once it’s live?
Ask that question at most sites and you’ll get a shrug, or three different answers from three different teams. The controls engineer who built the downtime data product two summers ago has moved to a different line. The MES admin knows the schema changed last quarter because a dashboard broke, but nobody told her why. The data science team building a predictive-maintenance model is quietly consuming a genealogy data product whose field names just changed, and they found out from a failed pipeline run, not a notification. This is the governance gap, and it’s the predictable next problem after any successful first wave of data product publishing.
Why this gap opens up right on schedule
It happens because the first wave of data products gets built by project teams under project incentives. The MES integrator or controls team stands up an OEE data product, ships it, moves to the next work order. Ownership was implicit in “whoever built it,” which works fine until that person is reassigned, the integrator’s contract ends, or the plant simply has too many data products for tribal knowledge to cover. Nobody assigned a deprecation policy, a versioning scheme, or a consumer notification list, because at the time there was one consumer and one producer and everybody sat near each other.
Scale changes the math. A quality-event data product that started as a feed for a SPC dashboard now also feeds a corporate quality data lake, an MES-to-ERP integration, and a machine-learning model looking for correlations between process parameters and scrap. Three consumers, one producer, zero contract. When someone on the automation team decides a field should be renamed for clarity, or a downtime reason-code taxonomy gets restructured to match a new corporate standard, that change ships to production with the same casualness as fixing a tag name in a PLC — because from the producer’s seat, it *is* just a tag name. From the consumer’s seat, it’s a breaking change with no warning.
The registry is not optional anymore
The fix doesn’t require a heavyweight enterprise data catalog platform, though those exist and some plants will eventually want one. What it requires, immediately, is a lightweight data product registry — even a well-maintained spreadsheet or a Confluence-style wiki page per data product beats what most plants have today, which is nothing. The registry needs to answer, for every published data product, a short list of questions:
- What is this data product, in plain language, and what business or engineering decision does it support?
- Who is the named owner — a role or team, not a person who will leave — accountable for its schema and lifecycle?
- What is its current schema version, and where is the schema definition itself (JSON schema, AVRO, whatever the shop standardizes on)?
- Who are the known consumers, and how were they discovered — self-registered, or found by asking around?
- What is the deprecation and change policy: how much notice, what channel, what counts as breaking versus additive?
That last point matters most. Treat every data product like a published API, because that’s functionally what it is. Additive changes — a new optional field, a new namespace branch — can ship without much ceremony. Breaking changes — renamed fields, changed units, restructured payloads, altered cardinality — need a version bump, a deprecation window on the old version, and a notification to every registered consumer before the old version goes dark. This is not a novel idea; it’s just API governance, borrowed from software engineering and applied to shop-floor telemetry. The manufacturing world has been slow to adopt it because MES and SCADA data was historically produced and consumed by the same tightly coupled team. That coupling is exactly what the UNS breaks apart, which is the point of a UNS — and exactly why it now needs contract discipline it never needed before.
Who should actually own this
Ownership of individual data products should sit with whoever owns the source-of-truth system — the MES admin for genealogy and quality events, the controls or reliability team for downtime and OEE feeds pulled from PLC and historian data. But ownership of the governance process itself — the registry, the schema versioning standard, the change-notification mechanism — belongs to whoever owns the UNS architecture as a platform, typically a plant IT or OT data architecture role, sometimes a corporate manufacturing data team if the namespace spans multiple sites. Splitting these two roles matters: the data product owner knows the domain, the platform owner enforces the discipline so thirty different teams don’t invent thirty different versioning conventions.
What to actually do this quarter
Don’t try to boil the ocean with a formal data governance program before you’ve done the cheap thing. Inventory every data product currently live on the namespace — most plants are surprised how many they find once they actually look, since data products accumulate quietly during MES rollouts, SCADA upgrades, and one-off integration projects. Assign an owner to each one, even provisionally. Add a schema version number to each, even if it starts at 1.0 for something that’s been running for two years. Publish the registry somewhere every engineer and analyst on-site can find it without asking around. Then set one rule that will do more good than any tooling purchase: no breaking schema change ships without a version bump and a notice to the registered consumer list, full stop.
None of this is exciting work, and it won’t show up in a project ROI slide. But the UNS was supposed to be the fix for a historian architecture that had become brittle, undocumented, and impossible to change without breaking something downstream. Skip the governance layer and you’ll rebuild that exact same brittleness inside the thing that replaced it — just with better transport protocols underneath.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
