--- title: "Why Convergence Is Dead" description: "Executives ask for IT/OT convergence thinking they want real-time data; they get a single attack surface and a decade of incident reports. The case that data acquisition is solved and infrastructure convergence is the mistake." canonical: "https://rivercaudle.com/writing/why-convergence-is-dead/" author: "River Caudle" date: "2025-07-12" --- # Why Convergence Is Dead *2025-07-12 ยท IT/OT convergence, architecture* *Data acquisition is straightforward. Infrastructure convergence is something else entirely.* --- ## The Setup: When Executives Discover Real-Time Data When executives say they want "IT/OT convergence," they think they're asking for something simple and necessary. They've suddenly realized that data previously available only as lagging indicators - shift reports, production logs, end-of-day summaries - can now be pulled from the plant floor in real-time. Maybe they've discovered that their ERP or MES system can integrate this live production data to generate revenue projections, optimize scheduling, or identify bottlenecks as they happen. This is genuinely valuable. Real-time production data driving business decisions represents a meaningful evolution in how companies operate. The C-suite is right to want this capability. But here's where the paradigm mismatch begins. The C-suite understands information technology as a proven driver of business transformation over the past decade. When executives need data capabilities, they naturally turn to the IT department - the recognized "keeper of data" and the established mechanism for implementing technological change. This makes perfect organizational sense. IT responds with genuine expertise and confidence: "Absolutely. This data flows over networks, and network infrastructure is our core competency. We'll get you that data." Projects are initiated with the best intentions. But then IT approaches operations with a solution shaped by enterprise networking paradigms: "The executive team needs data from the plant. We need to standardize your network infrastructure to enable secure, manageable data integration." ## The Paradigm Mismatch: CIA Triad Meets Safety and Reliability As someone who has managed both enterprise IT operations and industrial OT networks, I've experienced this paradigm clash firsthand. My background includes serving as IT director for a law firm, scaling data center operations from 70 to 700 employees, and unifying help desk operations across multiple acquisitions. I understand the IT perspective because I've lived it successfully. But I've also learned why applying IT paradigms to OT environments creates fundamental conflicts. IT operates under the CIA triad - Confidentiality, Integrity, and Availability. This framework makes perfect sense for enterprise systems where data protection, access control, and uptime are the primary concerns. IT professionals are skilled at implementing security policies, standardizing configurations, and maintaining centralized control over network resources. OT operates under different imperatives: Safety, Reliability, and Availability of physical processes. In industrial environments, network downtime can mean lost production, equipment damage, or human safety risks. OT professionals prioritize keeping processes running, optimizing performance, and maintaining direct control over systems that affect physical operations. These aren't competing approaches - they're different tools for different problems. The issue arises when we try to force one paradigm onto the other through "convergence." ## What Actually Happens: Well-Intentioned Misalignment The typical convergence initiative reflects this paradigm mismatch. IT begins by replacing plant switches with enterprise-grade hardware that supports centralized management, standardized VLANs, and comprehensive monitoring - all reasonable from a CIA triad perspective. But this immediately creates operational conflicts. OT staff lose direct access to network configuration, becoming dependent on IT change management processes designed for enterprise environments. Maintenance windows that make sense for office networks rarely align with production schedules. Network troubleshooting that worked fine for email and web traffic fails when applied to time-sensitive industrial protocols. The fundamental problem isn't that IT lacks competence - it's that IT applies enterprise expertise to industrial requirements. Most corporate IT departments excel at managing email systems, database servers, and user workstations. But they struggle with the timing requirements of EtherNet/IP, the multicast behavior of Profinet, or the deterministic needs of safety systems. This isn't a failure of IT - it's a mismatch of expertise to requirements. ## The Technical Reality: Data Acquisition vs. Infrastructure Convergence Here's what gets lost in convergence discussions: **data acquisition is a solved technical problem.** The technology to pull real-time data from OT networks without infrastructure convergence has existed for years. Data brokers can sit in DMZ configurations, connect to internal assets, request and store data, then make it available on demand to external systems. This can be accomplished with hardware or software solutions, deployed at the edge or as centralized collection points. MQTT and OPC-UA protocols were specifically designed for exactly this use case. Products like Rockwell's Optix Edge provide rack-mountable compute modules that act as data brokers with programmatic translation capability. Edge computing platforms can run containerized applications with open-source tools like Node-RED to create sophisticated data acquisition architectures. The most straightforward approach involves OT-controlled firewall rules that allow specific IT servers to access designated PLCs. Zero trust principles apply: one server accesses one device with documented rules, regular access reviews, and operations maintaining control of the security boundary. **This is proper engineering for data acquisition. It's not infrastructure convergence.** ## My Own Evolution: From IT Thinking to OT Understanding Early in my transition from enterprise IT to industrial networks, I fell into exactly this paradigm trap. When I arrived at a Canadian mining operation as an IT engineer, I discovered what I initially saw as chaos: unauthorized DHCP servers, wireless access points, switches - all installed by operations staff working around IT limitations. My first reaction was classic IT thinking: "This is uncontrolled. We need to centralize management and eliminate these unauthorized installations." I was applying CIA triad logic to an OT environment. But as I learned the operational realities, I realized these "shadow networks" existed because operations had legitimate needs that official IT couldn't or wouldn't address. The plant electricians weren't being difficult - they were solving real problems with the tools available to them. Eventually, I found myself building shadow networks too. I installed an OT firewall at the plant edge without IT approval because it was the right engineering solution for the specific requirements. When the VP of IT called angry about my "unauthorized" installation, his concerns weren't wrong: "What if it fails and you're not here to support it? How do we maintain something we don't control?" These are legitimate enterprise IT concerns about governance, supportability, and lifecycle management. My unauthorized installation, while technically sound, created an undocumented single point of failure dependent on my knowledge, exactly the kind of risk that keeps IT leaders awake at night. But his proposed solution - eliminate the shadow infrastructure - was wrong. The right answer was to legitimize it with proper documentation, support procedures, and organizational backing. ## The Solution: Infrastructure Independence, Not Infrastructure Convergence That conversation with the VP should have gone differently: "You've proven this approach works better - how do we make this the standard architecture for all our facilities?" Instead of fighting over territory, we could have tested the solution at another site, documented the approach, and proposed it as standard architecture across the organization. We could have legitimized OT infrastructure ownership with proper governance rather than forcing everything through enterprise IT paradigms. **This is infrastructure independence:** each domain operating within its area of expertise rather than forcing one paradigm onto the other. ## Addressing the Practical Challenges Infrastructure independence isn't just an architectural choice, it requires building organizational capabilities that may not currently exist. **The Skills Gap**: Decades of air-gapped isolation have left many OT departments without modern cybersecurity expertise. You can't simply hand OT teams firewall management responsibilities without proper training, staffing, and support. Organizations implementing infrastructure independence must invest in developing OT cybersecurity capabilities through training existing staff, hiring hybrid-skilled professionals, or partnering with specialized integrators. **The Accountability Question**: Executives often prefer the "one throat to choke" model where a single IT department owns all network infrastructure. Infrastructure independence creates two domains, which can lead to finger-pointing during incidents. The solution is clear documentation of responsibilities, defined interfaces between domains, and joint incident response procedures. When properly implemented, this actually improves accountability by ensuring each team has deep expertise in their area rather than surface-level knowledge across incompatible domains. But there's a deeper organizational issue at play: the "one throat to choke" preference is actually creating the convergence problem. When executives make the CIO responsible for both IT and OT, they're structurally forcing someone to serve two masters with fundamentally incompatible paradigms. The CIO gets pressured from above for unified solutions and pushes convergence initiatives down because that's the only way to meet impossible expectations. IT overreach isn't malicious, it's the predictable result of organizational structures that force the wrong person to solve incompatible problems. You can't serve two masters effectively. The solution isn't better CIO management, it's separate OT and IT leadership reporting high enough in the organization to have real authority. This means having two throats to choke, but positioned close enough to the C-suite that both have the organizational backing to succeed within their domains. **The Implementation Path**: This transition doesn't happen overnight. Smart organizations start with pilot projects at single facilities, build OT security capabilities gradually, and establish proven procedures before scaling across multiple sites. The evolution from isolation to independence looks like this: 1. **Isolation Era**: OT networks completely separated (safe but no data access) 2. **Convergence Era**: Connection through IT infrastructure (data access but paradigm mismatch) 3. **Independence Era**: OT-controlled security boundaries with proper data acquisition (right paradigms for right problems) ## The Real Problem: Conflating Data Needs with Infrastructure Control When executives ask for real-time data integration, they're not requesting infrastructure convergence. They're requesting data acquisition capabilities. The fact that these have become conflated represents a fundamental misunderstanding of the technical requirements. IT/OT convergence persists not because it's technically necessary, but because it applies familiar solutions to unfamiliar problems. IT sees OT equipment as additional network devices to integrate into existing management frameworks, without recognizing the fundamental differences in operational requirements. While most convergence initiatives stem from this paradigm mismatch, it's worth acknowledging that organizational politics and budget control can also be motivating factors, though addressing the technical and operational realities usually resolves both issues. The convergence approach works like this: **The Business Need**: "We need real-time production data for business decisions" (legitimate requirement) **The IT Response**: "Data flows over networks, therefore we need unified network management" (logical but incorrect conclusion) **The Technical Reality**: Data acquisition and infrastructure management are separate problems requiring different solutions ## Building the Bridge: Proper Data Acquisition with Maintained Independence The future belongs to organizations that recognize this distinction. They implement data acquisition architectures that serve business needs while respecting operational requirements. They legitimize OT infrastructure ownership with proper governance, documentation, and organizational support. Rather than forcing convergence, they build proper interfaces between domains. OT maintains control of industrial network infrastructure optimized for Safety, Reliability, and process Availability. IT maintains control of enterprise network infrastructure optimized for Confidentiality, Integrity, and data Availability. And both work together to implement data acquisition solutions that respect these different paradigms. Infrastructure independence isn't an end state of permanent separation, it's the essential foundation for effective collaboration. When each domain operates from a position of expertise and control, they can build trust and establish proper interfaces. Over time, this enables the development of hybrid roles: OT-aware IT professionals and IT-skilled OT engineers who can bridge the gap with shared tools and cross-functional capabilities. This approach serves everyone's actual needs: - **Executives get** real-time data integration for business decisions - **IT maintains** enterprise security and data management expertise - **OT maintains** industrial network control and operational flexibility - **Organizations build** the foundation for future collaboration based on mutual expertise rather than forced convergence - **Both teams develop** deeper understanding of each other's requirements over time ## The Path Forward The technology exists. The business case is proven. The organizational model works when properly implemented. The question isn't whether to pursue data integration - that's clearly valuable. The question is whether to pursue it through infrastructure convergence or through infrastructure independence. One approach forces incompatible paradigms together and creates ongoing conflicts. The other respects the expertise and requirements of both domains while delivering the business capabilities executives actually need. The choice seems obvious.