The Unified Namespace Explained (2026 edition - 30 min crash course)

Hi, I'm David and in this IT/OT Insider video I'll do a new deep dive in the unified namespace. So I often get messages from people who are slightly or totally confused on what to do and not to do. So this is my next attempt in providing you with some answers. By the way, this video is the logical follow-up on my recent industrial data platform video. If you haven't seen that one, I suggest to do that first. I'll put a link in the show notes. In this video, I'll talk about the concept of a UNS, some of the misconceptions, and most importantly, why true IT-OT cooperation and data management is what all of this actually boils down to. So let's get started. First, I wanna take a couple of steps back. What is the problem again? Most people say it's to solve the system spaghetti, which has grown over time. Absolutely true. Others say we need this to become future proof to enable our AI use cases, to connect our MCP server to. Yeah, sure. But actually, it's about solving business problems. The business problem has to come first. And unfortunately, or whatever you wanna call it, those problems then often turn into data management issues. And I'll talk a little bit on that in this video. But let's start with the system spaghetti. So. I'm going to take my pen here and draw a bit your typical setup. So we'll probably have a SCADA system for line one. And we might have a different SCADA system for another line or another plant. We might have another brand of SCADA. We might have some direct PLCs. We might have some IoT devices or just some other databases. And obviously, as you know, and this is the typical data spaghetti, let's see, what shall we do? This one and this data system, they log data in one specific historian. This one has another site, so they use another historian. The PLC doesn't have data logging at all. The IoT device... probably and shouldn't do that right here maybe but probably logs into some cloud solution and the database well the database just expose a sequel. So what did we do? We have our data consumers, have an ERP system, we have an MES system, we have some some trends tools and then here is the access access database an operator made to solve a specific certain problem. There are custom interfaces going like this. There is a custom interface like this. The IoT data, somebody wrote a script to publish some data into the historian and then the historian can be read into the trend tool. Then, you know, we have some custom scripts here running on an edge device near the PLC to extract some data. and send that to the access database, you get a picture, this is your data spaghetti. We all have data spaghetti, we all have several systems, we have legacy, we have new ones. And it's very clear that scaling your data initiatives is not an option in this case. I talked about scaling also in the previous video. So again, go back to that one to understand these concepts more. So this is clearly the data spaghetti. And that means that's, yeah, then in came the UNS narrative in an attempt to solve this one. And two years ago, I defined the unified namespace in the following way. I said a unified namespace UNS is an organized and centralized data broker depicting data in context from the business as it is right now. That's the definition I gave two years ago and I'll slightly change that one. later in this video. So suppose that we would have, I would say we would apply this principle immediately. Let's go to the same example. So we again have SCADA system one, SCADA system two, SCADA system three at the other location, some PLCs, some IoT devices and some other database, databases. So the idea would be to have, as I said in the definition, to have a form of a central data broker in the middle. And either the SCADA system publishes directly and the PLC publishes directly into the broker or via a couple of steps in the middle. It can be that we keep our historian as a middle system here as we already had. And then we have the historian publishing in the data broker, et cetera. Same holds for the IT devices. they might be doing that directly. You might do that through a second step or whatever. It doesn't really matter for the discussion. And then you could say indeed that your ERP system, your MES, et cetera, would also publish certain data points in the broker, but more importantly, they would read the data points from the broker. The access database I was talking about. Well, you could also then have the access database getting data from the broker or maybe just replace the access database at all, but that's a completely different topic. So that's the, let's say general idea. To give you a quick example in how we would then structure the data, because I said that in the definition, I said there is a data broker which is centralized, but which is also structured. Typically you would structure that using an ISA95 type of approaches. So you would have some kind of a namespace where you go through the ISA95 hierarchical model. And this is an example from our beloved Sweet Harmony Treats bakery. So in this case, the topic structure could be something like we have the company Sweet Harmony Treats, the Antwerp site, the baked goods production hall, waffle line 01, and then we step into the baking tunnel oven. And then the baking tunnel oven consists of a heating zone one with a couple of tags. heating zone two, a belt drive module, an air circulation module, your humidity control, but also some, for example, some utility metering. So this could be the structure which we use, for example, when we would choose for an MQTT broker or when we would be using OPC UA, we could be using, or we could be using this topic structure to structure our data. in that broker and then the PLC would sit somewhere and your SCADA system one would sit somewhere, your SCADA system two would sit somewhere. And then the interesting thing is that obviously, suppose that again, we have our SCADA system one, we have some cryptic tag names here. So what we would do is by publishing it using such a structure, we would change that cryptic tag name. to something like, for example, it's the top temperature from heating zone one in the baking tunnel oven, which is part of the waffle line zero one, for example. So this is, guess, very clear. This is also how most people understand the concept of the UNS. But there is a lot of stuff I like in this approach, really. Don't get me wrong, I'm not trying to debate the concept here, but there is also a lot of stuff I don't like. Actually, I wrote an article about that a couple of months ago. I literally titled it, What I Like and Don't Like About the Unified Namespace, and I'll also make sure to put a link in the show notes of this video. So again, there are a couple of problems. Problem number one for me is, and please this is really, really, really important. Again, understanding what is the business problem we are trying to solve. It is not about technology first. It's not about choosing a certain protocol first. It should be about understanding what this we are trying to solve for our business. Are we trying to... make communication easier and are we using a broker for example on our IoT site or on our SCADA site because we just want to get rid of some legacy protocols might perfectly be but in most cases when we're discussing data problems we're seeing the broker more on the enterprise side so that means that we need to understand which enterprise problems we are trying to solve. I don't get a good answer to this question too often, unfortunately. Even more importantly, understanding your business needs will also drive the architectural decisions, which might be a bit strange. It's not the other way around. not, let's start with architecture and then out of that comes business problems or business solutions. No, it's the other way around. So this is really, really important. To do that, to understand those business needs, we've created something which we call a data maturity workshop. In that workshop, what we basically do is really, really short, is in a diverse group of people from operations, process engineers, IT people, data people, we try to assess the current data maturity states. We try to understand what is working today, really important to share that knowledge between each other. Then we try to identify the blockers, technically and organizationally. And then we try to identify the future state. What is it what we would like to achieve in the years to come? We teach this methodology in our ITOT Academy and I will make sure to also talk, write or record a video on this concept somewhere in future. So number one, understanding the business problem, really, really important. And that's not just a technology problem, it's... Everybody together. Secondly, I mentioned that multiple times in the past, there is a misconception that a unified namespace equals MQTT. Now don't get me wrong. I love MQTT as a protocol. It's simple. It's lightweight. Everybody understands it. It's easy to scale. It's easy to make redundant. You name it. Easy to make secure. By the way, we actually have a great article with HiveMQ coming up. really really soon where we'll also build a MQTT demo on Sweet Harmony Treats, the example I showed you just before. But UNS does not equal MQTT. For me UNS is more a concept. How are we going to step away from the data spaghetti? This again is for me really important. A third big problem is data persistence in general, so storing data. So because let's face it, most applications, almost all applications need more than the current state of data. So that means that even if you would choose for a broker architecture, which can be really, really, really relevant in a lot of cases, you still, still, need to think about how your applications will be getting their historical records. And then the problem becomes if we have a broker and all the data, so we have an historian or a database or whatever who subscribes to the broker gets all that data. And then our applications are again getting the data from that historian or from the database or whatever it is. Now, what problem did we actually solve? Secondly, are we also able to transfer? the namespace structure, the structure context, are we able to transfer that as well into that historian database whenever we choose to persist the data? This again boils down to the business problems. What are we trying to solve? But if most business problems require historical data, then you need to think about that. And then finally, and these things are really, really closely linked. Finally, the biggest misconception of all is, well, let's say the lack of data management. Just starting. Putting in other words, Data management is needed to create the digital representation. And if you would like to call it the digital twin, by all means do so. But to create your digital twin or the digital representation of the physical reality. And you could say, yes, but we have that ISA 95 type of structure. I can do that. In some cases, it's really easy. So suppose you have a vast amount of connected machines or smart meters. Maybe you are a machine builder, maybe you are a water company, you have smart meters at people's houses, homes. Maybe you have a container company and you have some measurement points on each cooling container. Then it's rather easy to define a small data management standards for that machine. So that, for example, that cooling container. It's probably you always have a temperature, you have humidity, and you have maybe some GPS coordinates. Maybe you have a battery level or something like that, which you're sending into a bigger, into a bigger namespace, maybe over a broker. This is a perfect, perfect example of using a broker where you could easily publish thousands, tens of thousands, millions of that type of data points. But in manufacturing, well, context isn't that easy. It already starts with who is going to take ownership, who is going to decide that structure. How are we going to align across sites? Who is going to drive that project of alignments? Data management quickly becomes a much broader data governance, a company-wide data governance problem. We actually have a podcast coming up next week where we talk about data governance as well. It's not that easy. But also, some people do understand that, but most don't, ISA95 is much more than that simple hierarchy I depicted a couple of minutes ago. ISA95 is an object model. It defines relationships, not just depicting the physical assets, but also how materials flow, how work is organized. Not to mention if we go into the ISA 88, so batch control and how recipes are handled. And you cannot depict those relationships in a linear structure, in a linear namespace. You actually need some kind of a graph approach. So you have this graph with multiple connections. And again, that is the reality, especially in a manufacturing context. Depicting this reality again, isn't that easy. It's certainly not just, let's make a decision to start a UNS and let's just start writing down, you know, the tree structure and we'll get somewhere fast. Those insights led me to improve my definition of a UNS. And I changed that into a unified namespace is a design pattern. A design pattern towards an organized centralized data platform. The platform can consist of a broker, but it's more than the broker. It's the entire solution. Depicting data in context from the entire business? Still possible? and the as it is right now, I remove that one. Because there aren't too many solutions who only require current state data. I'm not going to repeat the industrial data platform. Again, that's a previous video. But the industrial data platform is designed to give you that I would say the concepts of the industrial data platform is designed to give you that freedom of connecting several data sources, various data sources, legacy and new, having data consumers on the right side, having the platform in the middle. where you also persist data and where in the blue circles you add contextual layers that can be asset context. That's really, really powerful, but much, much, much more powerful is also having your quality context and your production context, et cetera. And this is where, yeah, you don't have your typical linear representations anymore. to make data platforming to something tangible, we then added our seven core capabilities and also our four supporting ones. And you'll get all that information in the data platform video. So with that, a bit of Q &A, not between me and me, but those are questions I got in the last days. I wrote them down. I'm gonna try to give you a short answer. First question is, Should the UNS always live inside an MQTT broker? Again, my answer, my take on that is no, it is more than only the broker. It is about the entire platform that might consist of a broker, that might be provided by one vendor or multiple vendors, but it's not just a broker. You need the persistence as well. Where should my data broker be positioned? Well, that's a really, really good question. And it boils down to again, I would say the business problem we are trying to solve. Here are a couple of examples. Suppose again, you have these connected devices, let's say the containers or the smart meters or whatever. Well, probably you have a broker running in a cloud somewhere because those devices are, well, probably cloud connected. So you have your broker running in the cloud somewhere, which... then becomes a data source. Let's go back to the previous slide. So suppose we have our IoT platform here. Suppose we would have a data broker sitting somewhere here, probably in the cloud. And then that data broker then becomes the source. And that data can then be persistent in the platform, for example. That's one example. Suppose we are... more local with your SCADA systems. Well, in that case, suppose we have, do I have some PLCs here? Well, yeah, a SCADA system, a PLC, maybe another PLC, et cetera. Well, in that case, I could perfectly have, or I could perfectly depict an example or think about an example where again, you have a broker sitting somewhere here. And this one again, is persisting its data in the industrial data platform. If we are thinking about the other side, ideally, the industrial data platform doesn't only give you APIs or SDKs, or maybe even an MCP server to get the historical records in context out of the platform. We might also have an MQTT broker here. where there might be certain applications who can then just subscribe to that MQTT endpoint, which is provided as part of the industrial platform. I got a question, what is the core of the platform? And that's actually, that's a really, really good one. The... the core of the platform. And here there are several solutions available. First of all, it's a question of where do you run this thing? Does it run on-prem? Does it run in the cloud? Or do you need some kind of a hybrid approach? More and more, do see more, let's say, most manufacturing companies, most process companies, et cetera, also infrastructure companies, they still really go for an on-prem solution. and then offload some data into the cloud. But again, if you are more into the connected device world, for example, you'll probably go for a cloud first approach. What is really important for me, or in my opinion, is that the industrial data platform consists of a time series store, because you want to be able to persist your time series data in a raw manner. It should also consist of an event store. more relational and the relational data base type of thing. Events can be all kinds of things, but you know, that's our typically the relational ones. So for example, your batch start, batch stop type of things, maybe some alarms, some et cetera. And then obviously you also have all metadata, which is more static. The core of the platform should be able to store these different. sets of data. And then, and then we actually come back to the graph type of approach. At the moment where you need the data. suppose I have, let's take two examples. Let's say I have a trend client and I wanna draw certain trends. Maybe I also wanna add some of the event data on my trends. And I have a BI client here as well. The trend client needs raw data, the BI client needs aggregated data. Okay, so if the trend clients need that data, it should able to get that directly. from the platform. if you need, for example, aggregated data in a BI client, the platform should be able to give you that aggregated data. Yeah, then the question who defines the use cases, who owns data, the data and the models. Yeah, this is really, really, really interesting. This actually also boils down to the last question about ITOT cooperation It is clear, again, it is clear that there needs to be some form of data governance, some form of ownership. Somebody needs to define what architecture is going to be implemented. what data, how the data is going to be structured. There needs to be data owners in operations themselves. There needs to be owners on the platform side. This boils down to ITOT cooperation. I'm not going into our cooperation models too detailed in this video. Again, we do some deep dives in the academy and we will also publish more information on that in the year to come. But here is where you go from siloed approach, maybe over some joint architectural decisions you are making, we're calling that facilitation, towards a joint project you're executing, but projects are always limited in time. And then you step into a product management approach where you're persisting, in this case not the data, but where you're persisting the capabilities you have built over the longer time. Alright, again, what are the next steps here? Because this is yet another video where I'm sharing some of my thoughts. Willem and I are working on some architectural typicals. So we will be giving, are drawing some more detailed architectures for certain cases. We're actually going to use them for the first time in our upcoming academy. And then in the months to come, we will also publish a bit of that. via our channels. We are also working on RFP templates when you are building a data platform where you in a unified namespace also has a part in that as well. Those RFP templates when one's available will also be distributed through our channels. And then maybe a small note to end. I use this blog and the videos not just as a way to communicate the truth. No, I just wanna share my current opinion. gonna do some more research, I'm gonna talk to many of you. And that's again gonna change my point of view, that it's also work in progress, which means reach out to me. Comments, say where you think I'm right, say where you think I'm wrong, and then also preferably why. In the meanwhile, if you wanna learn more, go to itot.academy. to figure out everything about our six week live online learning program. Next cohort starts in May. Go to our DataOps vendor list on our website, itotinsider.com. That will give you some a head start in your selection process. Also includes articles and interviews and all fun stuff. Or just subscribe to our blog or YouTube channel to get our weekly updates. So that's it for now. Thanks for watching. See you next time. Take care. Bye bye.