When Linking IT and OT with Real-Time Data, Where Should Your Brokers Live?

The center of gravity of industrial data is not the cloud, but the factory floor. While some events matter once they reach an enterprise analytics platform a thousand miles away, some need to be acted on in the room where they happen.

The architecture question that follows is really about placement: which of your brokers should run in the cloud, and which belong at the edge, close to the equipment they serve? Get that wrong and you either starve the plant floor of real-time responsiveness or drown your network shuttling data nobody is waiting for.

Plenty of smaller deployments run perfectly well with no on-site broker at all. But as a plant’s systems multiply and its appetite for real-time data grows, a local broker stops being an add-on and becomes a better way for the plant floor to become part of the larger picture — the nearest node of an event mesh that links every site, data center, enterprise applications, and cloud into one connected fabric.

The edge broker doesn’t wall the plant off from the enterprise; it ties the plant into it, giving local systems their own real-time hub while keeping every event reachable across the whole mesh. This guide lays out how to tell when you’ve crossed that line, and how the Solace Platform makes the edge a first-class part of that fabric.

The Role of an Edge Broker

An edge broker — an event broker deployed locally, sometimes called an on-site broker — runs in the plant, on the factory floor, or at a remote facility, and acts as the hub for everything happening at that location — the controlled meeting point between operational technology (OT) on the plant floor and the information technology (IT) systems beyond it, what ISA-95 and Purdue practitioners often call Layer 3.5. Devices, machines, controllers, and applications publish events to it and subscribe to the events they care about, without needing direct point-to-point connections to each other or a round trip to the cloud.

In an event-driven system, this publish-subscribe approach replaces brittle, hardwired integrations with a flexible data backbone. Producers and consumers are decoupled: a sensor publishes a reading once, and any number of systems — a SCADA dashboard, a quality-control routine, a cloud analytics pipeline — can consume it independently.

Solace Event Broker, now available in an edge-friendly package, can play this role at the site and, just as importantly, links it into a wider event mesh — a network of brokers spanning sites, datacenters, and clouds that dynamically route events across environments and geographies. A reading published on the plant floor is available locally in real time and, when it matters elsewhere, propagates across the mesh to any subscriber anywhere, with no point-to-point plumbing to maintain. Local autonomy and enterprise-wide reach stop being a trade-off and become two properties of the same fabric.

Five Signs a Broker Belongs at the Edge

Running a broker at the edge earns its keep under specific conditions — and if none of them describe your site, a cloud broker may serve you just as well. Read the five signals below against your own environment: the more that ring true, the stronger the case for running a broker locally rather than relying on the cloud alone.

• Events must survive an unreliable connection: Factory connectivity is rarely perfect, and where every event has to reach the cloud to count, each dropped link is a hole in the record — lost history, lost compliance evidence, lost inputs for analytics and AI. A broker at the edge holds events locally when the link is down and forwards them losslessly once it returns. The test to apply: if a few minutes of lost events means a compliance gap or a stalled line, local buffering pays for itself.
• Local systems need to exchange events directly: As more machines, controllers, and applications exchange events with each other, a broker at the edge gives them local infrastructure to publish and subscribe efficiently, without every message traversing to the cloud and back. Site-level applications such as MES and SCADA gain a high-speed, low-latency bus that respects the Purdue/ISA-95 layering they were built around. The test to apply: if your plant-floor systems already talk to each other constantly, a local broker spares them the round trip.
• You are linking diverse protocols and data sources: Plants rarely speak a single language. When you need to bring a mix of protocols and disparate sources into one coherent, governed stream before anything leaves the site, a broker at the edge becomes the natural aggregation and normalization point — the foundation for a unified namespace (UNS) that turns raw OT signals into structured, discoverable data. The test to apply: if normalizing data on-site is a precondition for anything useful downstream, that work belongs at the edge.
• Decisions can’t wait for a cloud round trip: Many processes need fast reactions — machine interlocks, safety shutdowns, closed-loop control — that cannot tolerate the latency of a trip to a data center. Brokered at the edge, the logic runs locally too: a line can trigger an actuator shutdown the instant a reading crosses a threshold. The test to apply: if any decision has a hard real-time deadline measured in milliseconds, those events belong at the edge.
• Most of your data was never meant to travel: At industrial scale, the cost of shipping every raw reading to the cloud can dwarf the value of the small fraction that drives decisions. A broker at the edge filters and aggregates locally, forwarding only what carries value upstream while keeping full-fidelity data where it is generated. The test to apply: if ingestion and bandwidth are a real line item across many sites, local filtering changes the economics.

How an Edge Broker Enhances Your Architecture

The signs above are about making a determination on a site-by-site basis. If you step back and look at your system as a whole, a set of benefits emerges around the fact that edge brokers are nodes of one event mesh, which changes what your system can do across every site at once.

• One pattern, every site: Because each edge broker joins the same mesh the same way, a new facility comes online with the data model, integration points, and topic structure it inherits from the rest of the estate — not a bespoke build. You replicate a known-good pattern instead of reinventing one plant at a time.
• A governed boundary at every site: Each edge broker is the one controlled doorway between a plant’s OT systems and the wider IT mesh — a clean IT/OT boundary at Layer 3.5 — so you authenticate, authorize, and encrypt at a single defensible point per site rather than policing a tangle of direct connections. Governance applied at one node holds consistently across the whole fabric.
• Growth without redesign: Adding the hundredth site is the same operation as adding the second — stand up an edge broker, and it extends the existing mesh rather than bolting on a new silo. The estate absorbs more assets, more events, and more locations without anyone re-architecting how the pieces connect.

Two Views of the Same Decision

Whether an edge broker is worth it depends on who is asking and what they are optimizing for. Plant managers and enterprise architects judge the same decision against different priorities.

• Plant and Ops Managers: The question here is how much your operations depend on reacting in real-time and riding out network interruptions. Where they do, an edge broker translates into smoother day-to-day operations — more responsive local control, faster reactions on the line, and autonomy from the wider network — with critical processes running through connectivity hiccups and safety logic executing in real time at the edge. Where the line tolerates latency and the link to the cloud is dependable, that local control buys you less, and a broker may be more than the site needs.
• Enterprise Architects: The question here is scale and repeatability. When you are standing up the same pattern across many facilities, an edge broker gives you a blueprint that replicates cleanly, supports a growing and more diverse set of connected assets, and keeps operational technology and information technology aligned around a single, governed stream of events. For a one-off site with modest volumes and no replication on the roadmap, that architectural leverage is harder to justify — the design discipline a broker enforces is worth most when you are repeating it.

Making the Right Decision for Your Situation

So, where should your brokers run — at the edge, or in the cloud? The honest answer is that it depends on where your events need to live, and by now you have the tests to decide. A small site with a few devices, forgiving latency, and a dependable link can let a cloud broker handle everything. But when events have to be acted on in milliseconds, survive a dropped connection, reconcile a dozen plant-floor systems, or scale cleanly across many facilities, their center of gravity has moved to the edge — and a broker should run there to meet them. For a growing share of industrial operations, that is exactly the direction of travel: more data, more local intelligence, more interconnection at the source.

The Role of Solace Platform

This is where Solace Platform comes in. Solace Event Broker runs at the site to manage local, real-time event traffic, and connects into an event mesh that links every broker — at the edge, in the data center, and across clouds — into one fabric where events flow to wherever they are needed. You get guaranteed delivery across intermittent links and full local autonomy, without the edge ever becoming an island: each broker you add at a site simply extends the same mesh.

Combined with the filtering, governance, and integration capabilities the platform provides, it delivers an architecture that meets your needs today and adapts as they grow. When your events belong at the edge, Solace is built to be the partner that puts them there — and keeps them connected to everything else.