OT/IT Convergence: Where Industry 4.0 Gets It Wrong

OT (Operational Technology) refers to the systems that run physical plant operations: PLCs controlling manufacturing lines, SCADA systems monitoring utilities and processes, DCS systems in continuous process industries, and the industrial networks - Profibus, Modbus, EtherNet/IP - that connect them.

IT (Information Technology) refers to the enterprise systems: ERP for business processes, cloud analytics platforms, databases, and the corporate network and internet-connected infrastructure that business functions run on.

Convergence means connecting these two worlds so that operational data — machine states, process parameters, production counts, energy consumption — flows into business intelligence without manual extraction. In theory, this enables real-time production visibility, AI-driven optimisation, and predictive capabilities that were previously impossible. In practice, most IIoT initiatives stall before reaching production scale — Cisco's IoT Value/Trust Paradox research puts the proportion of "fully successful" projects at just 26%.

The stall rate is not because the technology does not work. OPC-UA, MQTT, and modern cloud IoT platforms are mature, reliable, and capable. The stall happens because organisations underestimate the non-technical dimensions of OT/IT convergence: network architecture, security model, organisational ownership, and the fundamentally different operational priorities of OT and IT teams.

OT teams prioritise uptime above all else. A PLC that controls a production line cannot be patched, restarted, or modified during a production run - and often cannot be touched at all without a planned maintenance window. The IT team's instinct to push updates, enable remote access, and connect systems to the internet is incompatible with this constraint until specific security measures are in place.

The result is a predictable standoff: IT wants to connect OT systems to the cloud. OT refuses because it represents a security and uptime risk. Neither side is wrong - but without a defined architecture that addresses both concerns, the project stalls in the design phase.

The first mistake is connecting OT directly to the cloud. Sending PLC data straight to an Azure IoT Hub or AWS IoT Core without an edge layer is architecturally fragile and operationally risky. Edge computing - a local gateway that buffers data, applies protocol translation, and manages the OT-to-cloud handoff - is not optional. It is the architectural keystone that makes everything else reliable.

The second mistake is ignoring network segmentation. OT networks must remain operationally isolated from IT networks. Data flows one way - from OT to IT - through a defined and monitored DMZ. Any architecture that places OT and IT systems on the same network segment, or that allows bidirectional traffic without explicit security controls, will be rejected (correctly) by the OT team and the plant engineering function.

The third mistake is treating the data flow as the end goal. Getting sensor data into a cloud platform is a means, not an end. Projects that focus on the data pipeline without a defined analytical use case - a specific decision that will be made differently because of the data - consistently fail to demonstrate value and lose executive sponsorship before they reach scale.

Industrial communication protocols are not standardised. A manufacturing plant built over 20 years will typically have PLCs communicating over Modbus (1979 standard, still in use), Profibus, DeviceNet, EtherNet/IP, and possibly PROFINET - each requiring a different driver and a different approach to data extraction.

OPC-UA (OPC Unified Architecture) was designed to solve this: a modern, secure, platform-independent protocol that abstracts the underlying industrial protocol and presents a consistent interface to any consuming application. For new equipment, OPC-UA is the right standard. For existing equipment, OPC-UA connectivity often requires a middleware gateway - a Kepware or similar industrial connectivity platform - that translates legacy protocols into OPC-UA.

MQTT is the complementary protocol for the other side of the edge: the connection from edge gateway to cloud. Lightweight, publish-subscribe, and optimised for high-frequency data with intermittent connectivity, MQTT is the de facto standard for IIoT data transport. Together, OPC-UA on the OT side and MQTT on the cloud side, with an edge gateway translating between them, form the protocol backbone of a practical OT/IT architecture.

A convergence programme that reaches production scale has four non-negotiable components: a joint OT/IT steering team (not separate workstreams), a defined edge architecture agreed before any connectivity work begins, a pilot scope limited to one asset or one production line with a specific analytical use case, and a security model reviewed by both OT engineering and IT security before any data leaves the OT network.

The pilot scope discipline is critical. Every successful large-scale IIoT deployment started as a small, well-defined pilot that proved the full stack - from sensor to insight - on a single asset or line. Trying to connect an entire plant at once is how 68% failure rates happen. One line. One use case. Full stack. Prove it. Then scale.

The organisational model matters as much as the technical architecture. Assign a dedicated convergence engineer whose role sits between OT and IT - someone with enough OT knowledge to earn the plant engineering team's trust, and enough IT knowledge to build the cloud integration. Without this bridge role, the organisational standoff will outlast the technology project.

The reference architecture is consistent regardless of plant. On the OT side, PLCs and the SCADA historian present data over OPC-UA — natively on new equipment, through a Kepware or Ignition gateway that translates Modbus, Profibus, and EtherNet/IP on older lines. An edge gateway buffers that data, applies protocol translation, and publishes north over MQTT through a monitored DMZ. Crucially, the flow is one-way out of the OT network, which is what makes the architecture acceptable to plant engineering in the first place.

On the IT side, MQTT lands in Azure IoT Hub, and Microsoft Fabric Real-Time Intelligence streams it into OneLake — one governed Delta Lake foundation holding machine state alongside the production context pulled from ERP and MES via Azure Data Factory. A Power BI Direct Lake semantic model then turns that converged stream into the thing the business actually wanted: live OEE, energy-per-unit, and the feed that makes predictive maintenance possible. The edge handles the OT realities; Fabric handles the analytics; the DMZ keeps them properly separated.

The point of standing it up on one governed platform is reuse. The same OneLake foundation that proves a single line's OEE scales into plant-wide manufacturing analytics and predictive maintenance without a second integration programme. You design the edge-and-segmentation architecture once, then add use cases on top — rather than running a fresh OT/IT negotiation for every new dashboard.

The deepest limit is organisational, and no architecture diagram fixes it. OT optimises for uptime and will not accept a patch cycle that risks a production run; IT optimises for connectivity and integration. Without a single owner of the converged data architecture — and a joint OT/IT steering team rather than two workstreams — the project stalls in design while both sides defend legitimate positions. This is why the bridge role, often a Fractional CDO with the mandate to arbitrate, matters more than the tooling choice.

The second is the legacy-protocol long tail. A plant built over 20 years carries Modbus, Profibus, DeviceNet, and PROFINET, each needing its own driver, and a 20-year-old asset with no digital output needs a sensor retrofit before it joins the stream at all. Promising whole-plant connectivity in one phase ignores that reality — and is exactly how the three-in-four stall rate happens.

And the most common quiet failure: a data pipeline with no decision attached to it. Getting sensor data to the cloud is a means, not an end. A pilot that streams beautifully but does not change a specific operational decision loses executive sponsorship before it scales — every time.

The discipline that separates the successful 26% from the rest is scope, not budget. One line, one named analytical use case, full stack from sensor to decision — proven — then scaled. The leaders who try to connect the whole plant at once are the ones generating the failure statistic; the ones who prove the loop on a single asset are the ones who reach production scale. Insist on the narrow pilot even when the vendor pitches the platform.

It also starts faster and smaller than the Industry 4.0 framing suggests. A six-week Discover phase agrees the edge architecture and security model with both OT and IT, instruments one line, and lands its data in Microsoft Fabric against a specific decision — first value is a working, secure, one-line stack, not a multi-year transformation programme. You earn the right to scale by proving the architecture once.

Unify the OT data through a properly segmented edge, then predict, then act — in that order, with OT in the room from the first design session, not the first deployment. The technology has been ready for years. What stalls convergence is starting it as an IT project instead of a joint one.