If you work in manufacturing, you’ve probably felt the tension between IT and OT (Operational Technology) teams. I’ve seen it at every level—from shop floor engineers rolling their eyes during architecture reviews, to IT folks wondering why “those OT guys” resist every new platform. If you’re leading digital transformation or IIoT projects, you can’t ignore this. The OT team’s frustration with IT architecture is real, and if you don’t address it, your best-laid plans will stall or fail.
So, why does this conflict happen? What can you do—practically, not just theoretically—to fix it? Here’s what I’ve learned over two decades, in plain English.
Where the Friction Starts
1. Legacy and Siloed Systems
Most plants still run on a patchwork of legacy systems—local historians, SCADA, DCS, and MES—each built for a specific task, often by different vendors, and rarely designed to talk to each other. These systems were set up for stability and safety, not for cloud integration or big data analytics.
When IT comes in with ambitious plans—cloud data lakes, real-time analytics, or even just standardizing data—OT sees risk. They remember the last time a “simple” update crashed production for hours. For example, I’ve seen sites where adding a new sensor meant weeks of negotiating with automation engineers, IT security, and even finance, just to get the right protocol working and the data flowing to the right place. Multiply that by hundreds of machines, and you get a sense of the daily grind.
2. The Purdue Model Is Outdated
A lot of OT architecture is still based on the Purdue Model—think of it as a tall, wobbly wedding cake with strict layers. Data moves up and down, but only through tightly controlled, point-to-point connections. This was great for security and stability in the ‘90s, but now it’s a nightmare. Every integration means more custom code, more vendor APIs, and more things that can break. It’s slow, expensive, and inflexible.
Meanwhile, IT wants to break down those silos and move towards event-driven, cloud-connected platforms. But OT teams see this as poking holes in their carefully guarded perimeter. They worry (rightly) about opening new attack surfaces for cyber threats. I’ve lost count of the times I’ve heard, “We can’t let that data leave the plant—it’s a safety risk!”.
3. Data Ownership and Context
OT teams live and breathe context. A temperature reading is just a number unless you know which reactor, which batch, which shift. But IT architectures often treat data like generic “streams,” stripped of the context that makes it useful on the shop floor.
I’ve seen projects where data was pushed to the cloud, but when a problem hit, no one could trace the signal back to the actual equipment or process. OT teams end up doing double work—maintaining their own “shadow” systems just to keep context intact.
4. Integration Pain and Vendor Lock-In
Integrating new equipment is still way too hard. Most plants have a zoo of protocols—OPC UA, Modbus, proprietary stuff from 20-year-old machines. IT wants everything to speak the same language, but that’s rarely possible without custom connectors and endless troubleshooting. And don’t get me started on vendor lock-in. If your architecture is built around one vendor’s stack, OT teams know they’re stuck with whatever limitations or costs come next.
5. Security and Compliance Headaches
Cybersecurity is a shared nightmare, but the priorities are different. OT’s worst fear is a safety incident or production stop; IT worries about data breaches and ransomware. Both are right, but their approaches clash. For example, patching a vulnerability in a PLC isn’t as simple as running Windows Update. OT needs downtime windows, validation, and sometimes even regulatory signoff (think GxP environments in food or pharma).
Why This Drives OT Crazy
Let’s put ourselves in their shoes. OT teams are measured on uptime, safety, and compliance. Every new IT initiative looks like more risk, more work, and more chances for something to go wrong. They’ve seen too many “transformations” that ended with more dashboards but less reliability.
I remember one project where we tried to standardize historian data across multiple sites. The IT team thought it was a matter of mapping tags. The OT team spent months cleaning up naming conventions, fixing gaps, and negotiating what “standard” really meant. In the end, the biggest blocker wasn’t technology—it was trust.
What Actually Works (From Real Experience)
Here’s what I’ve seen help, after a lot of trial and error:
- Shift to event-centric, modular systems: Use event-driven patterns like MQTT and Sparkplug B to avoid point-to-point messes. This makes scaling easier and keeps data more visible to OT. Old equipment will need gateways, so begin small with a pilot line and grow from there.
- Create a unified namespace with OT input: A UNS is a shared, organized data space based on models like ISA-95. It gives clear naming and structure. OT must be involved early because they understand the real-world process details, and trust depends on their input.
- Make device onboarding simpler: Aim for plug-and-play onboarding, even if reality is still rough. Use guided setup tools, automatic discovery, and protocols that match your plant. If custom connectors are needed, document them and keep OT in the loop.
- Add context and ensure data quality at the edge: Don’t send raw data without meaning. Tag it with useful context like batch, equipment, or shift before it leaves the plant. Good governance that both IT and OT accept saves headaches later.
- Security and compliance are non-negotiable: Plan updates and changes with OT. Validate, document, and use security tools suited for industrial environments. In regulated spaces, compliance must be built in from the start.
- IT and OT must move together: Treat OT as a key partner. Build shared architecture teams, celebrate wins, and solve problems jointly. Industrial Centers of Excellence help align leadership and give the effort authority.
One Honest Opinion
Here’s something you won’t hear in most IT strategy decks: Most digital transformation projects fail not because of technology, but because of people. If you don’t build trust, respect OT’s expertise, and deliver quick wins that matter to them, your architecture will never get adopted—no matter how “modern” it is.
So, How Do You Fix It?
- Start small, prove value, and scale up.
- Involve OT early and often—let them lead where it matters.
- Use modern, event-driven architectures and a unified namespace, but don’t force a “one-size-fits-all” approach.
- Respect context, compliance, and security needs.
- Build trust, not just technology.
That’s how you turn “Why does OT hate our IT architecture?” into “How did we ever work any other way?”
Leave a Comment