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

What Is a Unified Namespace?

The Updated Definition (2026)

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 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?

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

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?

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:

1. Define ownership: Who owns the data model? Who maintains it?
2. Establish governance: Standards, naming conventions, change processes
3. Create a bridge team: IT-OT collaboration doesn’t happen by accident
4. Start small, prove value quickly: One line, one use case, measurable impact
5. 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

• The Unified Namespace Demystified (Part 1)
• What I Don’t Like About UNS (Updated Thinking)
• Industrial Data Platform Capability Map V2
• What I (don’t) like about the UNS (new!)

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

Here is the 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.