Key Takeaways
- IT and OT collaboration is essential as modern operational technology networks operate on IP infrastructure, emphasizing that the debate on convergence is resolved.
- Collaboration helps bridge the historical divide between IT and OT teams, which have different operational priorities and security approaches.
- Effective collaboration requires IT’s early involvement in building automation projects to ensure secure and manageable network design from the start.
- Cross-functional fluency is crucial; both IT and OT professionals need to understand each other’s terminology and requirements to communicate effectively.
- Leadership plays a vital role in fostering collaboration, as successful convergence relies more on organizational structure than on technology alone.
For years, IT/OT convergence was debated. After years at the intersection of networking and building automation, here’s where I land: the debate is over. Modern OT networks—for HVAC, lighting, access control, and elevators—operate on IP infrastructure and share a backbone with your IT network. The issue isn’t if IT and OT will converge, but when—and whether your organization leads or faces the consequences of not doing so.
That difference comes down to leadership and structure, not technology.
Why IT and OT Teams Retreat to Their Corners
The tension between IT and facilities teams is real, and to be fair, historically earned. OT professionals have spent careers managing systems designed to be closed, deterministic, and physically embedded in the building. Elevators and fire systems don’t have maintenance windows the way servers do. BACnet — the dominant protocol in North American building automation, and one I’ve worked with throughout my career — was purpose-built for machine-to-machine communication in an isolated environment. It isn’t encrypted by design. It discovers devices through broadcast messages rather than the address resolution methods IT teams are used to. These aren’t flaws—they reflect what the protocol was built to do.
IT professionals, on the other hand, manage dynamic, data-intensive networks where security policy, patch cycles, and centralized control are standard practice. When those same professionals are suddenly asked to support a network potentially filled with decades-old BACnet controllers that can’t be patched and were never meant to face external traffic, the friction makes sense.
The real risk is when friction results in organizational paralysis, with teams defending territory instead of solving shared problems. I’ve seen projects delayed and security gaps persist, not due to technical barriers, but because collaboration wasn’t structured.
Where IT and OT Collaboration Becomes Architecture
Before getting into the organizational piece, it’s worth being clear about what the right technical posture actually looks like — because “convergence” gets misread as “put everything on one flat network.” That’s not it, and that approach creates real risk.
Because OT devices are difficult to patch and because BACnet traffic is unencrypted, the IT team’s job is to extend their cybersecurity umbrella over the OT environment — not absorb it wholesale. In practice, that means OT systems live in logically segmented islands on the shared IP backbone, with tightly controlled checkpoints between those segments and the rest of the network. Firewalling, monitoring, and access control sit at those boundaries. The OT network keeps the operational independence it needs; the IT team maintains the security posture the organization requires.
This isn’t a compromise. It’s the right architecture for the environment. What it requires is that IT and OT teams agree on where those boundaries sit, how access is governed, and who is accountable when something goes wrong on either side.
IT and OT Collaboration Has to Start Before Construction Does
One of the most consistent patterns we see in failed convergence projects is that IT gets brought in too late. On new construction and major renovation projects, building automation systems are commissioned months — sometimes over a year — before staff arrive. Infrastructure decisions about port locations, subnet allocations, and VLAN structure are made by facilities contractors who may have little familiarity with IT’s requirements. Then, IT inherits a network they had no hand in designing.
The fix here is procedural, not technical: IT needs a seat at the table from the first planning meeting on any project involving networked building systems. Not to take over — just to make sure the infrastructure being built can be secured and maintained to the standard the organization will eventually demand.
How many issues will you solve today?
Cross-Functional Fluency Is Not Optional
The other pattern I see consistently is teams that speak entirely different languages with no structured process for bridging the gap. OT professionals may be unfamiliar with VLANs, subnets, or DHCP. IT professionals may have never encountered a BBMD (BACnet Broadcast Management Device) or had to reason through why a building controller needs a static IP address that can’t simply be moved without risking the system it belongs to.
Neither side needs to become an expert in the other’s domain. But both need enough fluency to have a productive conversation. “Cross-disciplinary onboarding” — where each team documents and shares its requirements, constraints, and terminology with the other — is one of the most underused tools in convergence planning. It’s a subject I explored in a recent Q&A session with Optigo, more on that below.
What IT and OT Collaboration Looks Like in Practice
Dartmouth College’s Technology Services team offers a concrete example of what getting this right looks like. Their team is deliberately composed of both OT network and facilities expertise, operating as a unified group rather than two departments negotiating with each other. When a major renovation of Anonymous Hall revealed BACnet integration failures between vendor systems that no individual contractor could explain, the team had the cross-functional capability to diagnose the problem at the protocol level, trace it back to the underlying OT network design, and resolve it. Douglas Plumley, the team’s Software Architect, put the gap plainly: strong IP capability was already there, but BACnet visibility had to be built. The hybrid team structure meant that building that capability became a shared organizational priority rather than a jurisdictional dispute.
That structural decision — treating OT network operations as a shared domain — is what enabled everything else.
The Leadership Mandate
None of this is self-executing. Segmentation policies don’t write themselves. Cross-disciplinary onboarding doesn’t happen without someone commissioning it. Early IT involvement in OT projects requires someone with the authority to make it a standing requirement.
The organizations navigating IT/OT convergence well aren’t the ones with the most advanced technology. They’re the ones with leaders who recognized early that this is an organizational problem with a technical dimension — not the other way around.
The convergence is already underway. The only real choice left is who leads it.
We recently held a Q&A session with Ping on the subject of IT and OT integration. Check it out below (and subscribe to the new podcast, How To Handshake!).
FAQ
IT/OT convergence describes the technical reality: operational technology systems like HVAC, lighting, and access control now run on IP infrastructure that shares a backbone with the enterprise IT network. IT and OT collaboration is the organizational response to that reality — how the two teams structure decision-making, security ownership, and project workflow so the converged environment can actually be operated and secured. Convergence is the condition. Collaboration is the work.
Neither team should own it alone. The most workable model is one where OT systems live in logically segmented zones on the shared backbone, with IT responsible for the security controls at the boundaries — firewalling, monitoring, and access control — and OT retaining operational authority inside those zones. Ownership is shared at the boundary, not absorbed by one side.
At the first planning meeting. New construction and major renovations often commission building automation systems months — sometimes more than a year — before IT staff arrive. Decisions about subnet allocation, VLAN structure, and port locations get made early by facilities contractors, and IT inheriting that infrastructure after the fact is one of the most common failure modes in convergence projects.
BACnet was built for closed, deterministic, machine-to-machine environments. It isn’t encrypted by design, and it discovers devices through broadcast messages rather than the address resolution methods IT teams are accustomed to. Those aren’t flaws — they reflect the protocol’s original purpose — but they’re why BACnet traffic can’t simply be dropped onto a corporate network without segmentation and additional security controls.
Dartmouth College’s Technology Services team is a useful reference point: a single team combining IP networking and facilities expertise, rather than two departments negotiating across a boundary. When integration issues surfaced during a major renovation, the hybrid structure meant the team could diagnose the problem at the protocol level and trace it back through the underlying network design — without a jurisdictional dispute slowing the resolution.
