Every SCADA engagement we start has a conversation before the technical one. Someone from the data team wants historian data in the warehouse. Someone from operations does not want the data team anywhere near the historian. Both are right, and until that gets sorted out, no amount of Airflow or dbt matters.
That standoff is what people mean when they say “IT/OT convergence,” even when they don’t use the phrase. The OT systems that run the field (Operational Technology: the hardware and software that monitors and controls physical equipment, including SCADA, historians, PLCs, and RTUs) were built to be separate from the IT systems that run the business (Information Technology: the servers, networks, databases, and applications that store, process, and serve business data). The separation was deliberate. It was the correct engineering decision for its era. And it is now the single biggest reason your operational data is stranded.
This is the opening post in a four-part series we’re calling Beyond the Historian. The rest of it gets technical: unified namespaces, Airflow-run ingestion, digital twins. This one is the argument that has to happen first, because the gap between OT and IT is organizational and historical before it is ever a matter of connectors and protocols.
The separation was on purpose
It helps to remember why OT and IT grew up apart, because the reasons haven’t gone away.
A control system’s job is to keep a compressor from running away, keep a separator from overpressuring, and keep a well from flowing when a valve says it shouldn’t. Those systems are judged on availability and determinism. They run for years without a reboot. A patch that a corporate IT team would push on a Tuesday afternoon is, on the OT side, a change that gets scheduled around a turnaround and tested first, because the failure mode is not a help desk ticket. The failure mode is a release, a fire, or a fatality.
So the OT world optimized for the opposite of what IT optimized for. IT wants the latest patch, frequent change, broad connectivity, and everything reachable from everywhere. OT wants the thing that has run since 2011 to keep running exactly as it did in 2011, reachable by as few systems as possible. Connecting the two was not just unnecessary for most of that history. It was a liability the operations team had every reason to refuse.
That instinct got formalized. The reference architecture almost everyone in the industry still draws on a whiteboard is the Purdue model, adopted into ISA-95, which splits an industrial enterprise into levels 0 through 5, from the physical sensors and actuators at level 0 up to business planning at levels 4 and 5.[1] OT lives at the bottom, levels 0 through 3. IT lives at the top. Between them sits a demilitarized zone whose entire purpose is to keep the two from talking directly.
Why the gap persists
If it were only history, convergence would be a solved problem by now. It isn’t, and the reasons it persists are worth naming, because they’re the same reasons your last integration attempt stalled.
Safety and security are the honest ones. A control network that an attacker can reach from the corporate LAN is a control network that an attacker can use to open a valve. Regulators and insurers care about that, and so do the engineers whose names are on the process safety documents. The IEC 62443 standard that governs OT security is built on that same Purdue level hierarchy, grouping assets into zones with controlled conduits between them.[2] Nobody in operations is going to punch a hole through those zones so a BI dashboard can refresh faster.
Then there’s ownership. OT reports up through operations. IT reports up through corporate, often to a CIO who has never set foot on a lease. The historian is a production tool that operations paid for out of an operations budget to solve an operations problem. The data warehouse is an IT asset. The integration between them belongs to neither org chart, gets funded by neither budget, and shows up on neither team’s performance review. It is nobody’s job, which is a reliable way to guarantee it doesn’t happen.
Change cadence is the quiet one. IT ships continuously. OT changes on the calendar of the physical plant. When your ingestion pipeline assumes it can coordinate a schema change with the source system on a normal software timeline, and the source system is a historian that only gets touched during a scheduled outage, the two cadences grind against each other. We’ve watched pipelines break for six weeks because a tag got renamed during a workover and nobody on the IT side heard about it until close.
What convergence actually means
Here’s where the term gets abused. “Convergence” sounds like you’re merging the two worlds into one flat network where everything talks to everything. That is exactly what you should not do, and any vendor pitching it that way is selling you a security incident.
Convergence, done correctly, means data crosses the boundary while control does not. The operational systems keep their isolation. What changes is that a read-only copy of the data makes its way up to the analytical side through a path that is architecturally incapable of carrying anything back down.
The strongest version of that boundary is a data diode: a hardware device that physically allows data to travel in one direction only, because the return path doesn’t exist in the electronics. NIST’s OT security guidance (SP 800-82 Revision 3) lists unidirectional gateways as a primary defensive measure precisely for this case, sending sensor data from a high-security zone to a lower one with no route back for an attacker.[3] A software firewall enforces one-way flow with rules that can be misconfigured or bypassed. A diode enforces it with physics.
Most mid-size operators do not need a hardware diode, and saying so up front tends to earn more trust than pretending everyone needs the maximum. What you need is the principle the diode embodies: the data path out of OT is read-only, one-directional, and owned by someone. A read-only historian connector pulling on a schedule into a staging area that lives outside the operational network gets you most of the way there. We covered the mechanics of that pull in bringing SCADA data into your warehouse and, more pointedly, how not to take down your SCADA source while doing it.
The Purdue model, for its part, is fraying at the edges. It was drawn for a world where field data went up one level at a time. MQTT brokers, cloud historians, and edge devices that publish straight to a message bus don’t respect those clean horizontal layers, which is the whole reason the unified namespace conversation exists. That’s the subject of the next post in this series.
The problem is the org chart
Strip away the protocols and the standards, and what’s left is a reporting-line problem.
The person who owns the historian answers to a VP of Operations whose bonus depends on uptime and lease operating expense. The person who wants the data answers to a CIO or a VP of Finance who wants a single source of truth for production. Neither of them owns the wire between the two systems. When something breaks on that wire, operations says it’s an IT pipeline problem and IT says it’s an OT source problem, and the pumper goes back to reading tank levels off a screen because the analytical copy can’t be trusted.
We keep seeing this compound with acquisitions. Every deal brings another operator’s OT stack, another historian, another set of tag conventions, and another point-to-point integration somebody built once and documented never. After a few deals you have eight or ten of these brittle connections, each a little different, each owned by nobody. That’s the sprawl we wrote about in the hidden cost of SCADA vendor sprawl, viewed from the org-chart side rather than the licensing side.
The fix is not a technology. It’s naming an owner for the boundary. One person or one small team whose explicit job is the read-only data path from OT to analytics, with a foot in both worlds and enough standing in operations that they get told when a tag gets renamed. Everything downstream (the warehouse, the models, the dashboards) is a solved problem once that role exists. Nothing downstream works reliably until it does.
A realistic path for a mid-size operator
For an operator with a couple hundred wells and one or two historians, convergence is not a platform purchase and it is not a SCADA replacement. It’s a narrow, boring, read-only data path, built in the right order.
Start by getting operations to bless a read-only pull. That is a conversation, not a config change, and it goes better when you can show that the connector cannot write back and that the polling rate won’t degrade the live system. Land the data in a staging area outside the operational network. Map the tags to your well master, the same entity-resolution work every other source demands. Model it with the same discipline you’d apply to any other source, which is the case we made for dbt in your OT stack. Then, and only then, point the analytics at it.
Do it on the cleanest asset first, prove the pattern end to end, and expand from there. That sequencing is worth a post of its own, and it got one: crawl, walk, run for SCADA ingestion. The temptation is always to boil the ocean and ingest every tag from every well on the first pass. It fails every time.
None of this touches the control system. The compressors keep running, the safety zones stay intact, and operations keeps their isolation. What changes is that the data finally leaves the control room and shows up somewhere the rest of the business can use it.
That’s the whole series in one sentence. The next three posts get into how. Part two asks whether you actually need a unified namespace or whether a tag dictionary is enough. Part three covers running the ingestion on Airflow you probably already have. Part four takes on digital twins and what the term actually means once the data underneath it is real. But the historian-to-analytics path only gets built after someone decides they own it. That decision is the convergence. The rest is engineering.
International Society of Automation, “ISA-95 / IEC 62264” and the Purdue Enterprise Reference Architecture levels 0-5. Overview: Palo Alto Networks, “What Is the Purdue Model for ICS Security?” https://www.paloaltonetworks.com/cyberpedia/what-is-the-purdue-model-for-ics-security ↩︎
ISA/IEC 62443 series, zones and conduits model built on the Purdue level hierarchy. Dragos, “Understanding ISA/IEC 62443: A Guide for OT Security Teams.” https://www.dragos.com/blog/isa-iec-62443-concepts ↩︎
National Institute of Standards and Technology, “Guide to Operational Technology (OT) Security,” NIST SP 800-82 Revision 3 (2023). https://csrc.nist.gov/pubs/sp/800/82/r3/final ↩︎