You’re on a site, and you have roughly two million dollars of capital equipment sitting idle for five days because somebody in an office five hundred miles from the plant blocked a MAC address.
The sequence of events that got you to this point was unglamorous and entirely typical. A new vibration sensor had been installed on a critical line. The sensor was a known model, ordered through approved channels, commissioned by a competent integrator. It was also, as far as the central IT team was concerned, a new device on the network with no ticket, no security review, and no entry in the configuration management database.
The IT team did what their playbook told them to do. They blocked it. The plant did what its playbook told it to do. It tried to run anyway, which it couldn’t, because the line’s monitoring depended on the sensor that was now silently disconnected. By the time the politics resolved — through escalation, then meetings, then a hastily-drafted exception process — the plant had lost five shifts of production.
Sound familiar?
Here’s the thing — nobody in that story was incompetent. The IT team was applying a sensible policy. The OT team had ordered a sensible part. The integrator had done the work correctly. The thing that broke was the seam between IT and OT; the thing that broke was political.
Almost every modernisation deck I’ve ever seen treats the IT/OT gap as a technical problem — one that can be solved with a better gateway, a better protocol, a better diagram — and almost every modernisation project I’ve ever seen fails at the gap because it is not actually a technical problem. It is a political one. About 80% political, by my rough estimate. And until that 80% is dealt with, no amount of architecture is ever going to hold.
What the Gap Actually Is
The shorthand version of the IT/OT gap is that IT and OT have different priorities. IT cares about security, patching, compliance, and uptime in the abstract. OT cares about production, safety, and the specific machines on the floor. This framing is true and useful — but italso misses the part that actually causes the failures.
The deeper version is that IT and OT have different theories of accountability.
When IT makes a change that breaks something, the consequences are typically distributed — a service has degraded performance, a few users complain, the on-call rotation handles it, and life goes on.
When OT makes a change that breaks something, the consequences are concentrated and immediate — a line stops, a shift’s output is lost, somebody’s bonus is gone, and in the worst case, somebody gets hurt.
Simply put, these are not the same risk profiles — and accordingly, they cannot be managed by the same processes. And every modernisation deck that pretends they can is, intentionally or not, asking one of the two organisations to bear the other’s risk profile without compensation.
And that right there is the true battle you’re waging. It looks like a technical fight because the symptoms are technical — blocked MAC addresses, denied patches, disputed change windows, contested ownership of brokers and gateways. But the substance and the impact is ultimately political — it’s about who owns the data, who gets paged at 3 AM, and who gets blamed when production stops.
Until those are negotiated, the fight will keep happening, in the symptoms, forever.
Why Architecture Alone Doesn’t Fix It
Ok, so we see a problem — let’s address it with architecture. I’ve seen this play out before almost countless times — and I’ve also seen it fail more times than I can remember.
A vendor or consultant or internal architect proposes a modernisation architecture. The architecture has a clean line between IT and OT. There is a gateway. There is a DMZ. There is a Purdue model diagram with crisp boundaries. The pitch is that the architecture will solve the gap by making the boundary explicit.
But it will not. It can not.
The reason is that architectures are diagrams, and diagrams do not allocate risk. When the broker on the DMZ goes down at 2 AM on a Sunday, the diagram does not tell the on-call rotation who pages whom. When the gateway needs a security patch, the diagram does not tell the change-control board whether the patch can wait until the planned shutdown or has to go in next Tuesday. When the data fabric crosses the Purdue boundary, the diagram does not tell the auditors which team is responsible for the data loss. These are decisions that have to be made *by people*, in writing, in advance. The architecture is a precondition for the decisions, not a substitute for them.
And this is why “we have a great architecture but the IT/OT relationship is bad” is a sentence I hear all the time. It’s always a sentence about the same failure: the political work was deferred to be solved later, by the relationship, after the architecture was built. It does not get solved. It festers. The architecture survives, technically. But the project does not. And just as importantly, the relationships between the IT and OT teams fail catostrophically.
The Four-Part Political Playbook
To resolve this issue, you need to treat the IT/OT integration like the diplomatic problem it actually is. Diplomatic problems have known shapes. They’re solved by structured negotiations, not by technical specifications. And by attacking this problem through accepting what it actually is, you can significantly diminish the damage the IT/OT gap is doing to your business.
Below are the four agreements I’d insist on having in writing before any modernisation project crosses the IT/OT boundary in earnest.
Part 1: The Joint Incident Process
Every IT/OT seam needs a single incident process that both sides have signed. Not two processes — one. The process specifies who pages whom, in what order, on what timelines, for what classes of failure. It specifies who can call a production stop and who cannot. It specifies the escalation path when the two sides disagree about the severity of an event.
The reason this matters more than it seems is that incidents are when the seam between IT and OT is tested. During steady-state operation, IT and OT can avoid each other. During an incident, they can’t. If the incident process is not written down, it gets invented in the moment, by the people most stressed and least equipped to invent processes. This is how the MAC-address-blocking story happens. Nobody knew who could escalate to whom. So nobody did, until the production loss got large enough that somebody at the executive level intervened. Days, not minutes.
Write the joint process. Run drills against it. Update it after every real incident.
Part 2: The Data Ownership Matrix
The single largest source of unresolved IT/OT conflict, in my experience, is unclear data ownership. Who owns the historian? The MQTT broker? The dashboards that present plant data to the business? The AI models trained on that data? The training datasets themselves?
If you do not have a written matrix that lists each data asset, who owns it, who has access to it, and who is responsible for its quality, the answer in practice will be “whoever was loudest in the last meeting.” That is not a sustainable basis for an integration. The matrix is unglamorous to produce. It is a spreadsheet. It is also, in most plants, the most valuable single document the modernisation project can produce, because it forecloses dozens of latent fights that would otherwise happen one at a time over the next three years.
Build the matrix. Get signatures. Update it when assets change.
Part 3: The Shared Change-Control Window
IT change control runs on one rhythm — typically weekly or monthly patching cycles, driven by vulnerability disclosures and compliance schedules. OT change control runs on a completely different rhythm — typically driven by planned shutdowns, line changeovers, and seasonal maintenance windows.
When these two cadences collide, somebody loses. Either IT pushes a patch into a production window and risks breaking the line, or OT refuses to allow the patch and accumulates security debt. Both are bad outcomes. The fix is a shared change-control window, agreed in advance, that defines when each side can make changes to the shared infrastructure, and what the exception process is for changes that can’t wait.
The shared window is harder to establish than it sounds, because it forces both sides to admit their own constraints in front of the other. That admission is uncomfortable. It is also exactly what the integration needs.
Part 4: The Escalation Rules
The fourth agreement is the one that handles the cases the other three don’t. When IT and OT disagree on something — a patch, an architecture decision, a vendor choice, an incident response — there has to be a defined escalation path. Not a vague one. A specific one. Up to whom, on what timeline, with what required outputs.
In most plants I have worked with, the absence of a defined escalation path is the single biggest predictor of long-running IT/OT dysfunction. Disputes that should have been resolved at the working level escalate informally to the executive level, where they get resolved badly, by people who don’t have the context. Or they don’t escalate at all, and they fester. Either pattern poisons the relationship over years.
Define the escalation path. Use it sparingly. Document the outcomes.
Why This Is the Hardest Part
The four agreements above are not technically difficult. They are politically difficult, which is harder. Each one requires somebody to commit to a constraint — on response time, on access, on change cadence, on escalation — that they would prefer to keep flexible. The flexibility is, in a sense, what each side has been trading on for years. Giving it up feels like losing.
The reframe that helps, when I’m in these conversations, is that the flexibility is not actually flexibility. It is unmanaged risk. Each side has been quietly absorbing the other side’s risk in ways that nobody has accounted for, and the absorption is what makes the relationship feel adversarial. When the agreements are written, the risk gets allocated explicitly. The relationship gets less adversarial, because nobody is being asked to silently bear what they didn’t sign up for.
This is the part of the work the consultants don’t tend to write about, because it doesn’t sell frameworks. The frameworks are easy. The agreements are hard. Almost nobody who hasn’t worked the seam from the inside understands how hard.
What Good Looks Like
Of course I’m going to bring this back to FlowFuse, because it’s the team I work for and the case I think is honest. But hear me out, because the FlowFuse angle on the IT/OT problem is, perhaps surprisingly, mostly an organisational angle, not a technical one.
The platform-level value of FlowFuse in an IT/OT context is that it gives both sides a single tool they can both legitimately operate. OT engineers build flows in Node-RED, which they can read and reason about. IT operators manage the platform, which provides the audit trails, role-based access, and deployment controls IT needs to feel comfortable. The data flows are visible to both sides, which makes the data ownership matrix easier to fill in — because you can point at a flow and say “this is what we are doing with this data, this is who owns it, this is who can change it.” Visibility doesn’t solve the political problem, but it removes a class of arguments that would otherwise happen because nobody could see what was actually being done with the data.
To generalise the point back out: the tools that survive the IT/OT seam are the ones that *both sides can legitimately operate*. If your tool only OT can use, IT will block it on principle. If your tool only IT can use, OT will work around it. The shared-tooling property is a precondition for the political work, not a substitute, but it does meaningful work in dampening the symptoms while the political work is being done.
Treat It Like Diplomacy
The hardest sentence to write in a modernisation deck is “the IT/OT gap is mostly political, and the political work has not been done.” Nobody wants to hear it. Vendors don’t want to write it. Consultants prefer to sell frameworks. Executives prefer to believe the architecture will solve it.
But the engineers stuck in the middle — the people who get paged at 3 AM when the broker goes down, who eat the criticism when the patch breaks the line, who write the workarounds when the security policy collides with the production schedule — those people know. The gap is political. The fix is political. And the architecture is only the beginning of the conversation.
Ultimately, the modernisation projects that survive ten years are the ones whose teams treat IT/OT integration as the diplomatic problem it is, write the four agreements down, and update them as the relationship evolves. The projects that fail are the ones whose decks pretend the gap is technical and act surprised when the politics break the architecture. There are very few exceptions to this pattern.
And to be clear — I have yet to see one in my career.
Top comments (0)