When do we use an Enterprise broker architecture?

enterprise broker vs single broker when to use which audience this document is intended for non technical stakeholders and plant managers it explains the two main architectural patterns for connecting plant level systems to the wider organisation, and helps you decide which one fits your situation the core concept what is a broker? a broker is a central hub that collects data from machines, sensors, and systems on the shop floor, and makes that data available to other applications think of it like a postal sorting office equipment sends messages to the broker, and the broker routes those messages to whoever needs them mantsu uses brokers at both the plant level (mqtt) and the it level (redpanda) in a manufacturing environment there are two levels at which brokers operate plant level on the factory floor or within the local network of a single site enterprise level across the wider organisation, spanning multiple plants or divisions pattern 1 single broker architecture in a single broker setup, one broker serves both the plant and the enterprise all data flows through this single hub, and any application (whether it runs on the shop floor or at headquarters) connects to the same broker graph td subgraph plant\["🏭 plant"] m1\[machine a] m2\[machine b] s1\[sensor array] end subgraph broker\["📡 single broker"] b\[broker] end subgraph consumers\["📊 applications"] l1\[local mes] e1\[reporting dashboard] e2\[erp system] end m1 > b m2 > b s1 > b b > l1 b > e1 b > e2 when a single broker is sufficient a single broker is a good fit when you have one plant or one site , and there is no need to compare data across multiple locations all applications that consume data are within the same network or it domain the team managing the broker also manages all the applications that connect to it you have straightforward security requirements where a single access policy covers all users and systems what to watch out for a single broker becomes a bottleneck when the organisation grows all traffic, from every machine to every application, flows through one place access control is also harder to manage since everything connects to one broker, it becomes difficult to give plant operators and corporate analysts separate, appropriate levels of access pattern 2 enterprise broker architecture in an enterprise broker setup, each plant keeps its own local broker , and a second, separate broker at enterprise level pulls in a selected subset of data from the plant brokers this enterprise broker is the only point of connection between plant systems and the wider organisation graph td subgraph planta\["🏭 plant a"] ma1\[machine line 1] ma2\[machine line 2] ba\[plant broker a\nlocal / dmz] end subgraph plantb\["🏭 plant b"] mb1\[machine line 1] mb2\[machine line 2] bb\[plant broker b\nlocal / dmz] end subgraph enterprise\["🏢 enterprise domain"] eb\[enterprise broker] r\[reporting & analytics] erp\[erp / planning] kpi\[division kpi dashboard] end ma1 > ba ma2 > ba mb1 > bb mb2 > bb ba >|"selected data only"| eb bb >|"selected data only"| eb eb > r eb > erp eb > kpi when an enterprise broker is the right choice an enterprise broker becomes necessary when you operate multiple plants or sites and need to compare performance, output, or quality across them different plants belong to different divisions , each with their own reporting or management structure you need to enforce a clear boundary between what happens on the shop floor and what is visible at corporate level plant systems should remain operationally independent , as a network issue at enterprise level must never affect local production the key benefit bringing selected data upward the enterprise broker is not a copy of every message generated on the shop floor its purpose is to promote a curated set of data from plant level to enterprise level aggregated oee figures, production counts, quality metrics, energy consumption, and similar kpis this selective promotion makes it possible to compare results across plants, because all sites feed the same enterprise broker using consistent data definitions benchmark performance across a division leadership gets a unified view without needing access to raw machine data avoid information overload enterprise systems only receive what is meaningful at their level, not every low level sensor reading analogy think of a plant manager who prepares a weekly summary for the regional director the director does not need every individual machine log; they need the summary the enterprise broker plays the role of that summary layer, automatically and in real time security separation of roles and responsibilities one of the strongest arguments for an enterprise broker is the security boundary it creates graph lr subgraph ot zone\["🔒 plant zone\n(local server or dmz)"] pb\[plant broker] ot\[ot systems\n& machines] end subgraph it zone\["🏢 enterprise domain\n(corporate network)"] eb\[enterprise broker] apps\[enterprise\napplications] end ot > pb pb >|"one way\ndata promotion"| eb eb > apps; how responsibilities are split responsibility plant broker enterprise broker who manages it plant it / ot team corporate it where it lives local server or plant dmz enterprise network or cloud who can connect machines, sensors, local mes reporting tools, erp, dashboards data scope all plant data selected, promoted data only security policy defined per plant defined at organisation level why this matters plant teams stay in control of their own environment they decide what data to expose upward, and manage their own broker independently a configuration change at enterprise level does not affect local operations corporate teams cannot reach into plant systems directly enterprise applications connect only to the enterprise broker there is no direct path from a corporate application to a machine on the shop floor incidents are contained if the enterprise broker goes offline, plants continue to produce and their local brokers continue to function only the flow of data toward enterprise applications is interrupted, not production itself audit and compliance are cleaner since the two brokers have separate access logs and separate administrative domains, it is straightforward to demonstrate who accessed what and from which level key takeaways a single broker is simple, fast to set up, and sufficient for a single site deployment where all applications share the same network and administrative domain an enterprise broker adds a second layer that sits between plant systems and the wider organisation its primary purpose is to bring selected, meaningful data from the plant floor up to enterprise level, enabling division wide comparisons and benchmarking as a side effect, it creates a clean security boundary plant brokers stay within the plant's own network or dmz, corporate applications connect only to the enterprise broker, and the two teams manage their respective systems independently when your organisation spans multiple plants, multiple divisions, or has strict ot/it separation requirements, the enterprise broker pattern is the appropriate choice decision guide situation recommended pattern single site, all applications in one network single broker multiple sites, need cross site comparison enterprise broker plant and corporate teams are separate organisations enterprise broker strict ot/it separation required enterprise broker simple proof of concept or pilot single broker scaling from pilot to multi site rollout migrate to enterprise broker frequently asked questions when is a single broker enough for a mantsu deployment? when one site needs local data exchange and there is no requirement for cross plant visibility when does mantsu use an enterprise broker? for multi site or multi division setups that need cross plant comparison, or where strict ot/it separation is required what does mantsu promote to the enterprise broker? only selected, curated data such as aggregated kpis (oee, production counts, quality metrics); the plant broker keeps serving local consumers unchanged summary a single broker serves one plant; an enterprise broker adds a second tier that aggregates selected data across sites start with a single broker and move upward when multi site visibility, governance, or scale demands it