IT/OT Convergence Explained: Culture, Architecture and a Shared Data Layer

IT OT convergence is the process of bringing information technology (business systems, cloud, analytics) and operational technology (PLCs, SCADA, machines) onto a shared foundation so that both work from the same data. In this explainer you will learn why the two worlds developed so differently, what actually has to change on the technical and cultural side, and how a shared MQTT namespace gives IT and OT teams one live view of the plant without compromising either side's priorities.

Two Worlds That Grew Apart

Operational technology grew up on the plant floor. Its job is to keep a physical process running safely, every second, for decades. A PLC controlling a furnace may run the same program for fifteen years, and that is considered a success. Change is risk, and an outage can damage equipment or hurt people.

Information technology grew up in the office. Its job is to process business information securely and efficiently. Systems are patched monthly, replaced every few years, and an outage is expensive but rarely dangerous. Change is normal, and staying current is part of being secure.

Neither view is wrong. They are optimised for different consequences of failure. Most friction in convergence projects comes from people applying one world's rules to the other.

What IT/OT Convergence Really Means

Convergence is often misread as "put the PLCs on the corporate network." That is the version that makes OT engineers nervous, and they are right to be. Done properly, IT OT convergence means three narrower things:

1. Shared data. Production data flows reliably to business systems, and business context such as orders and recipes is available to operations.
2. Shared practices. Security, identity, monitoring and change management are applied consistently, adapted to each side's constraints.
3. Shared people. Teams understand each other's priorities and own the integration layer together.

What convergence does not require is a flat network. The Purdue model and IEC 62443 zones still apply. The integration happens at a defined boundary, usually an industrial DMZ, and the plant network stays segmented. Our comparison of the Purdue model and ISA-95 explains how those layers relate.

The Technical Building Blocks

Event-driven data instead of point-to-point integrations

The traditional way to give IT access to OT data is a point-to-point integration: the MES polls SCADA, the ERP queries the historian, a reporting tool reads a database the historian writes to. Each link is custom, fragile and owned by whoever built it. Adding a new consumer means another integration.

Publish/subscribe messaging changes that. Each OT source publishes its data once to a broker. Each IT consumer subscribes to what it needs. The OT side never has to know who is listening, and the IT side never needs a connection into the plant. If the role of the broker is new to you, see what an MQTT broker does.

A Unified Namespace as the shared language

A broker alone does not make data understandable. A Unified Namespace (UNS) adds structure: every value lives at a predictable topic based on the ISA-95 hierarchy, such as connectmq/acme/plant1/assembly/line2/press04/state. An OT engineer recognises the physical location. An IT developer sees a stable, documented API. Both read the same topic. Our guide on how to build a Unified Namespace walks through the design.

Outbound-only connectivity

OT gateways connect out to the broker over TLS, and IT consumers connect out as well. No inbound ports open into the plant. This is the single most important property for winning the OT security team's support. The pattern is covered in detail in our article on MQTT in an industrial DMZ.

Clear ownership of the data layer

Someone has to own topic naming rules, payload conventions, access credentials and data quality. In mature organisations this becomes an industrial DataOps function that sits between IT and OT. Read more in our industrial DataOps overview.

Example: Both Teams Reading the Same Live Data

Here is what convergence looks like in practice. An OT gateway publishes machine state as retained messages into the UNS. An IT developer writes a few lines of Python to feed that state into a business application, without ever touching the PLC or the gateway.

Try it on the public broker first. Publish a retained state as the "OT side":

mosquitto_pub -h broker.connectmq.com -p 1883 -i ot-sim-$RANDOM -r \
  -t connectmq/demo/itot42/plant1/assembly/line2/press04/state \
  -m '{"state":"RUNNING","order":"WO-1182","ts":"2026-10-16T09:12:00Z"}'

Then run the "IT side" subscriber:

import json
import uuid
import paho.mqtt.client as mqtt

TOPIC = "connectmq/demo/itot42/plant1/+/+/+/state"

def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(TOPIC, qos=1)

def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    area, line, machine = parts[4], parts[5], parts[6]
    data = json.loads(msg.payload)
    # Hand off to a business system, here we just print a row
    print(f"{area:10} {line:6} {machine:8} {data['state']:8} order={data.get('order')}")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"it-app-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

The subscriber receives the retained state immediately on connect, then every change as it happens. The OT engineer can open a desktop MQTT explorer on the same topic and see exactly the same message. That shared view is what convergence looks like day to day. For production, both sides use their own credentials from the broker on port 8883, and real plant data never goes to a public area, which anyone can read.

Cultural Steps That Make Convergence Stick

Technology is the easier half. These practices help the people side:

1. Start with an OT problem. Pick a use case the plant cares about, such as unplanned stops on a bottleneck machine. IT-driven projects that only serve reporting rarely get OT support.
2. Let OT own the edge. Controls engineers decide what is read from which PLC, at what rate, and in which mode. IT owns the consumers.
3. Agree on the boundary. Write down where OT responsibility ends, usually at the gateway's outbound connection, and where IT's begins.
4. Use one vocabulary. The ISA-95 hierarchy in topic names gives both teams shared words for sites, areas, lines and machines.
5. Pair people. Put an IT developer and a controls engineer on the same pilot. Two weeks of working together does more than any workshop.
6. Respect change windows. Gateway updates follow OT maintenance schedules, not IT patch Tuesdays.

Where a Managed Broker Helps

The shared data layer has to be secure, always available and maintained, which is classic IT work. Running it on plant hardware hands that work to OT, which usually does not want it. A managed MQTT broker is a neutral place for both teams to meet. ConnectMQ detects ISA-95 and Unified Namespace topics automatically, shows devices grouped by ISA-95 level, decodes Sparkplug B for teams that use it, and offers a live topic explorer that both a controls engineer and a developer can use. Organisations with strict data residency rules can run ConnectMQ BYOC in their own cloud account. To compare hosting models more broadly, see our cloud MQTT broker guide, and for the full industrial picture, the Industrial IoT with MQTT guide.

Give IT and OT One Namespace on ConnectMQ

Create a free Serverless broker at app.connectmq.com, no credit card required. Publish one machine's state into an ISA-95 topic tree, give both teams a credential, and let the conversation start from shared data instead of competing spreadsheets.

Frequently Asked Questions

What is IT OT convergence in simple terms?

It is getting business systems and plant systems to work from the same data, with shared practices for security and change. It does not mean merging the networks or giving IT control of PLCs.

Does IT/OT convergence increase cyber risk?

It can if done by flattening networks. Done with segmentation, outbound-only connections through a DMZ and per-client credentials, it usually improves visibility and security compared with ad hoc integrations.

Why is MQTT popular for IT/OT convergence?

Clients connect outward to a broker, so no inbound ports into the plant are needed. Publish/subscribe also lets many IT consumers use the same OT data without additional integrations.

Who should own the Unified Namespace?

Ideally a joint team or an industrial DataOps function. OT owns what is published from the edge, IT owns the consumers, and the joint team owns naming rules and payload standards.