The unified namespace: one addressable picture of the plant instead of point-to-point wiring

The problem it addresses is the number of connections, not the data

In a plant with a dozen systems that each need something from several others, the count of interfaces grows far faster than the count of systems, and every one of them is a thing to build, monitor, document and repair when an upgrade changes a field. Publishing into a shared structure replaces that mesh with a hub, so a new consumer connects once. The saving is real but arrives later than expected, because the first few integrations cost more than a direct connection would. Organisations that judge the approach on its first project usually abandon it just before it starts paying.

Naming is the entire discipline

The hierarchy typically follows the physical and process structure of the business: enterprise, site, area, line, cell, equipment, then the values beneath. Getting that structure right matters because renaming later invalidates every subscription built on the old path. It also forces decisions the plant has avoided, such as what constitutes a line when two share equipment, or how a cell that moves between areas should be addressed. Establishing a naming authority, with a published convention and a route for requesting additions, is the governance element most implementations skip and most later wish they had started with.

Publish once, subscribe many, and nobody knows who is listening

Decoupling is the point, and it has a consequence: the publisher has no visibility of its consumers. Change the shape of a payload, rename a field, alter units from one representation to another, and something downstream breaks with no warning to whoever caused it. Treating published structures as contracts, with versioning, deprecation periods and a register of who subscribes to what, restores the discipline that a direct interface enforced naturally. Skipping it produces a system that is easy to extend and frightening to change, which is a familiar failure mode in a new setting.

Current state and history are different problems

A message broker holds what is happening now and, depending on configuration, a short buffer. It is not an archive, and treating it as one leads to unpleasant discoveries when someone wants to compare this month with last. A durable store subscribing alongside the applications is the normal answer, which means the architecture includes both a real-time distribution layer and a historical one with their own retention rules. The related question worth settling early is replay: whether a consumer joining later can catch up on what it missed, and what happens to a subscriber that was offline during a shift.

Where these programmes stall

A pilot on one line demonstrates the concept convincingly and then stops, because extending it requires other systems to publish and their owners have their own priorities. Legacy equipment that cannot publish anything needs gateways somebody must fund. Security teams reasonably want to know why a broker is reachable from both the control network and the business network. None of these is fatal, but all require an owner with authority across engineering, IT and operations. Where the initiative is carried by one enthusiastic engineer, it usually ends when that person changes role.

Frequently asked questions

Is this a product we buy or an approach we adopt?

It is an architectural approach that uses ordinary components: a publish and subscribe broker, connectors or gateways at the equipment side, a naming convention, and consumers that subscribe. Products exist that make each part easier, but none of them supplies the naming discipline or the governance, which is where the outcome is actually determined. A plant can adopt the pattern with modest tooling, and a plant can buy substantial tooling and still end up with the same tangle under a new name.

How does this differ from having a data platform?

They address different halves of the problem and are usually complementary. The namespace is about distribution: making current information available in one addressable structure to whoever needs it. The platform is about accumulation and context: storing history, joining it to orders and materials, and supporting analysis. Building only the distribution layer leaves you unable to answer questions about last quarter; building only the store leaves every application connecting directly to equipment again.

What is a realistic first step?

Choose one area with a genuine integration pain, agree the naming convention for that area with an eye to how it would extend across the site, and publish a small set of information several consumers actually want. Resist the temptation to model the whole plant on paper before anything runs. The information worth publishing first is usually equipment state, production counts and the current order, because most applications want those and they exercise both the control-side and business-side connections.