Bridging IT and OT

The Unified Namespace (UNS) Explained: Design Pattern, Not Product

The Unified Namespace is the most discussed—and most misunderstood—concept in industrial digital transformation. If you’ve heard claims like “UNS will solve all your data problems” or “just buy this MQTT broker and you’re done,” you’ve encountered the hype. Here’s the truth: UNS is not a product you can buy. It’s a design pattern for organizing and contextualizing real-time data across your entire operation—from shop floor to ERP.

But here’s what no one tells you: the technology is the easy part. The hard part? Governance, ownership, and getting IT, OT, and operations to actually work together. This guide cuts through the marketing noise to show you what UNS really is, when it makes sense, and—most importantly—what stands between you and a successful implementation.

What Is a Unified Namespace?

David’s new 2026 video:

Watch David’s original video from 2024:

The Updated Definition (2026)

A Unified Namespace is a design pattern towards:

An organized and centralized data platform
Depicting data in context from your entire business

Notice what’s missing? “As it is right now.” That’s intentional. The broker holds current state, but you still need storage, governance, and historical data management—capabilities the UNS concept alone doesn’t address.

Why the Definition Changed: The original definition treated UNS as if it were a complete solution. It’s not. A central broker works beautifully for greenfield IoT deployments or modern SCADA systems. But most factories are brownfield environments with decades of existing infrastructure. In those contexts, treating UNS as a single central broker ignores reality.

What UNS Really Solves:

Point-to-point integration chaos: Instead of 50 custom connections, applications connect to one structured source
Asset Hierarchy Context loss: Turns “Tag_1254 = 83.2” into “Reactor #3 temperature is 83.2°C”
Data accessibility: Makes the current value of operational data available to other IT and OT systems without building custom integrations for every use case

What UNS Doesn’t Solve:

Historical data storage (you still need historians or time-series databases)
Data quality issues (garbage in, garbage out still applies)
Organizational silos (technology can’t fix people problems)
Data governance (modeling, ownership, and standards require discipline)

Why Does UNS Matter?

Scale data projects with an operational data platform by reducing time to integrate find and clean data

In today’s world, businesses are swimming in data—tons of it. However, most of this data is often isolated in separate systems, which makes it hard to transform it into useful, actionable information. The issue isn’t that we lack data or advanced algorithms—it’s that the data is disorganized, inaccessible, or both.

For instance, projects like predictive maintenance often fail because technicians waste too much time manually sifting through spreadsheets. AI initiatives stall, not because of weak algorithms, but due to messy, uncontextualized data. By implementing a UNS, companies can access clean, organized data across applications in real time, allowing for streamlined decision-making and improved data-driven outcomes.

Unified Namespace Architecture: The Core Components

To explain the role of a UNS, we’ll need to introduce the Industrial Data Platform first.

1. Data Sources (The Edge) Your data originates from:

OT Systems: PLCs, SCADA, DCS, Historians, HMI
MES/MOM: Manufacturing Execution Systems, LIMS, BMS
IT Systems: ERP (orders, materials), Engineering tools, Digital twins
Cloud & IoT: IIoT devices, cloud services, external APIs

Protocols Used:

MQTT (lightweight, publish-subscribe, ideal for IoT)
OPC UA (industrial standard, semantic models, security)
REST APIs (modern web services)
Direct database connections (legacy systems)

Critical Clarification: MQTT ≠ UNS. MQTT is one protocol option. You can build a UNS with OPC UA, Kafka, or even a hybrid approach. The protocol is not the pattern.

2. Central Data Platform This is where data models from all sources are unified into a structured hierarchy, typically following ISA-95 or ISA-88 standards:

Enterprise → Site → Area → Line → Equipment → Tag

Organizational Challenge: Who owns this model? IT? OT? Plant engineers? Without clear data governance, this becomes a political nightmare.

3. Data Consumers (Applications) Once data is in the platform, applications consume it:

Real-time dashboards
Predictive maintenance models
Digital twins
Business intelligence tools
Data lakes / historians (for long-term storage)
MES systems
Third-party analytics

Unified Namespace vs Data Lake: What’s the Difference?

Aspect	Unified Namespace (UNS)	Data Lake
Purpose	Real-time data access and distribution	Historical data storage and batch analytics
Time Horizon	Current state (“right now”)	Historical data (minutes to years)
Structure	Organized hierarchy (ISA-95) with context	Can be structured, semi-structured, or unstructured
Storage	Minimal (broker holds latest values only)	Massive (stores all historical data)
Protocols	MQTT, OPC UA, event-driven	Batch ingestion, files, databases
Use Cases	Real-time monitoring, control, immediate alerts	Trend analysis, ML training, compliance reporting

The Reality: You need both. UNS provides the “nervous system” for real-time operations. The data lake provides the “memory” for historical analysis. They complement each other.

Common Mistake: Calling a data lake a UNS. If your “UNS” is storing months of historical data and running batch jobs, it’s not a UNS—it’s a data platform with a UNS pattern applied to real-time ingestion.

Why Most UNS Projects Fail (And How to Avoid It)

We’ve seen it dozens of times: companies invest in “UNS platforms,” hire consultants, run pilots… and three years later, they’re still stuck. Here’s why:

Reason 1: Treating UNS as a Technology Project The Mistake: “We’ll buy MQTT broker X and we’re done.”
The Reality: UNS is 20% technology, 80% organizational change. You need data governance, ownership models, and cross-functional collaboration.

Reason 2: Building the Perfect Model Before Proving Value The Mistake: Spending six months defining the ideal ISA-95 ontology.
The Reality: Start with one use case. Build a namespace that solves a real problem. Then expand.

Reason 3: Ignoring Existing Infrastructure The Mistake: “We need to replace our SCADA/historian with a UNS.”
The Reality: Your existing systems are assets, not liabilities. Integrate them, don’t replace them.

Reason 4: Organizational Gaps From our ITOT.Academy students, the top blockers weren’t technical:

“Who defines the use cases?”
“Operations isn’t interested—what’s in it for them?”
“We can’t get IT and OT to collaborate.”
“We have no plan to scale beyond the pilot.”

The Fix: Start with organizational readiness:

Define ownership: Who owns the data model? Who maintains it?
Establish governance: Standards, naming conventions, change processes
Create a bridge team: IT-OT collaboration doesn’t happen by accident
Start small, prove value quickly: One line, one use case, measurable impact
Then scale with discipline: Governance, templates, training

How to Start with Unified Namespace: A Practical Roadmap

Step 1: Define Your Problem Don’t start with “we need a UNS.” Start with “we waste 60% of our time finding and preparing data for predictive maintenance.”

Step 2: Build Organizational Readiness

Form an IT-OT bridge team
Get C-level sponsorship (this isn’t an IT project or an OT project—it’s a business project)
Define roles and ownership
Create a shared vocabulary (IT and OT speak different languages)

Step 3: Start Small

Pick one production line or one use case
Build a minimal namespace structure
Connect one PLC, stream one dataset
Demonstrate value quickly

Step 4: Prove Value

Solve the problem you defined in Step 1
Measure the impact (time saved, downtime reduced, quality improved)
Get buy-in from operators and engineers (not just management)

Step 5: Scale with Governance

Codify your data model as a template
Document standards and naming conventions
Train teams on the model
Replicate across lines, sites, and regions

Step 6: Integrate, Don’t Replace

Work with your existing SCADA, historians, MES
Don’t rip and replace—extend and integrate
Use open standards (MQTT, OPC UA) to avoid vendor lock-in

ISA-95 and UNS

SA-95 is the international standard for integrating enterprise (IT) and control (OT) systems. It defines a five-level hierarchy:

Level 4: Business Planning & Logistics (ERP)
Level 3: Manufacturing Operations Management (MES)
Level 2: Supervisory Control (SCADA, HMI)
Level 1: Basic Control (PLCs, DCS)
Level 0: Physical Process (sensors, actuators)

How UNS Uses ISA-95: The namespace typically mirrors this hierarchy in its topic structure:

Enterprise/Site/Area/Line/Equipment/Tag
Example: ACME/PlantA/Packaging/Line3/Filler2/Temperature

This structure provides:

Consistency across sites and systems
Context about where data originates
Scalability as you add new plants, lines, or equipment
Interoperability with systems that already speak ISA-95

The Challenge: Real ISA-95 models are complex. They include relationships between physical assets, process segments, equipment classes, and materials. Most “UNS implementations” build a simple tree structure and call it ISA-95. That’s a starting point, not the full model.

Practical Advice: Start simple. Build a basic hierarchy that works for your first use case. Don’t spend six months modeling the perfect ISA-95 implementation before delivering value. Iterate based on real needs.

Next Steps: Deepen Your UNS Knowledge

Read: Our Full UNS Article Series

Join: ITOT.Academy Learn the language, architecture, and governance to push past “just a POC” in our live online academy. 6 sessions, built by practitioners, for practitioners.
Save Your Seat

Subscribe: Get Weekly Insights
Join other fellow industry professionals getting our weekly newsletter on IT/OT cooperation, data platforms, AI, and more.
Subscribe Free

Full transcript of David’s video

I’m going to explain the Unified Namespace, or UNS for short. It’s a concept that’s been around for a while but is gaining quite a bit of traction right now. I’ll talk about the concept, but more importantly, I’m going to share some of my personal experiences with you.

I’m David. I worked in the chemical industry for 12 years as an end user. Today, I manage analytics for industry, which is an IT/OT solution provider—that’s my day job. In addition to that, I also write for the IT/OT Insider. In my day job at Analytics for Industry, I mostly work with food and beverage customers and critical infrastructure, among other verticals. Through IT/OT Insider, I’m exposed to all kinds of sectors worldwide, from both an end-user perspective and a technology provider perspective. That exposure gives me some great insights.

So, first things first—the Unified Namespace is not a product you can buy off the shelf. It’s a concept, and you should think of it as an aspirational state—something you want to achieve when building your operational data platform. But what is it? And do you need one? Consider this: you have machines, sensors, databases, and ERP systems, all generating tons of data, often in silos. It’s hard to make sense of it and turn it into something useful.

For example, predictive maintenance is difficult because technicians waste time digging through Excel sheets. AI projects fail, not because of a lack of algorithms, but because the data isn’t well organized. If you want to build a data-driven organization, you need fast, secure, and contextual access to your data across all applications.

Instead of reinventing the wheel for every data use case, you want to invest in a data platform. You don’t just want to throw your data into a data lake, which can quickly become a data swamp if you’re not careful. You need a structured operational data platform built to work with manufacturing sensor IoT data. What does it mean to work with sensor data? First of all, we’re obviously talking about time-series data. Time-series data flows in at varying rates—sometimes fast, sometimes slow. You might be dealing with tens of thousands of sensors, or even more. The scale isn’t the most important factor; what matters is how your time-series data looks, because it flows in as it comes. This means that, to work with that time-series data in applications further along the line—whether it’s downloading into Excel, integrating with Power BI, or running Python scripts—you’ll need to interpolate the data at scale, which adds complexity.

Storing time-series data is something many platforms can handle. What’s more important is adding a contextualization layer—understanding the context of the manufacturing process, the infrastructure, and the assets involved. This means understanding the physical assets, production lines, and everything that goes along with them. You need to know what role each asset plays, what data points are associated with them, and the broader production context, such as what batch is running, which operator is working, and what product is being made.

And, of course, you have to manage data quality because garbage in is garbage out. Data quality in the sensor world is different from the IT world, and establishing when data is correct is harder.

As I said at the start, the Unified Namespace, or UNS, is a design pattern—it’s not a product. The concept helps you organize your data into an operational data platform. So, let’s start with a definition: what is a UNS? A Unified Namespace, in my understanding, is an organized and centralized data broker that depicts data in context from across your entire business—not just from one line or silo, but from the entire business as it is right now. It provides real-time insights.

The key points are context and organization. Your data should be organized, typically following models like ISO 95, which reflects the hierarchy of your business. This could be a plant, a production line, or even down to a specific machine.

Beyond organization, you also need context to go alongside your sensor data. You want to easily find out what product was produced, what maintenance actions were taken, and even the results of quality tests in the lab. You should be able to overlay these contexts on top of your sensor data and allow applications to extract this context along with the sensor data.

For example, “Give me the temperature profile of that batch” or “Give me the average steam production over the last 100 CIP cleaning-in-place cycles.” You want that context to be readily available to everyone who needs it. In my experience, a major barrier to data-driven projects is the lack of readily available context. I’ve seen up to 70-80% of the time spent on data-driven projects go towards finding, contextualizing, and cleaning the data.

The third point is real-time. A Unified Namespace shows you what’s happening right now, potentially across the entire organization, without outdated reports or delays—just instant access to your latest data.

But there are challenges. First, organizing data doesn’t just happen. You still need to model it. Yes, templates can help, but someone has to build those templates. And who decides what the perfect model is? This is all part of data governance. Personally, I prefer a use-case-based approach rather than trying to build the perfect data model from the start. Start with a problem, like predictive maintenance, and build a namespace for that use case. You might end up with multiple models or namespaces coexisting—and that’s perfectly fine.

Another challenge is storing your data. It’s not just about accessing real-time data; you also need to store historical data. The UNS gives you access to real-time data, but you still need a way to store the data, whether in a traditional historian or a more modern approach. You might end up with a hybrid architecture where you have both local and cloud components working together.

When storing data, you also need to decide whether you’ll store raw data, clean data, validated data, or all three. This is where architectures like the medallion or Delta Lake architecture come in, with tiers for raw, clean, and prepared data.

From an IT perspective, it’s important not to build everything from scratch. Use the foundations you already have—if you have OPC, you don’t need to replace it with MQTT, for example.

So, is the Unified Namespace the solution for all your data-sharing problems? No. It’s a very good concept to build your vision around, but it’s not a solution on its own. It’s a way to think about making data available in a centralized way for all users and applications.