The Quiet Collision that’s becoming the New Operating Model
What’s happening across industrial, utilities, transportation, energy and facilities-heavy operations isn’t a mandate to merge IT into OT or vice versa.
It’s subtler and honestly more interesting.
The early-stage reality of IT/OT convergence are already occurring; operational teams adopting service-management patterns because the work demands it, and IT teams are beginning to wrestle with supporting systems that don’t behave anything like laptops or SaaS applications.
The result: a fusion of working models driven by real world complexity, not academic theory.
First: OT is Absolutely Not “just another IT domain”
The OT / IT convergence is not about forcing OT into IT’s space. It’s about connecting information, governance and workflows so both sides can operate without stepping on landmines.
OT systems exist to keep real physical processes safe, predictable and continuously available.
That’s why the change windows are narrow, assets are live for decades, and “reboot it” is often the most dangerous suggestion in the room.
The security playbooks that work fine for business apps can break things when physical processes are involved.
What’s Actually Happening (early-stage convergence patterns)
Most organizations aren’t starting with a grand “IT/OT operating model” blueprint. They’re starting with operational pain and realizing informal processes can’t keep pace with scale, complexity, or risk.
Here’s what’s consistently showing up first:
1) OT starts adopting structured intake because chaos doesn’t scale
When maintenance requests, vendor coordination, access needs and break/fix work all flow through radio calls, texts, hallway conversations and tribal norms, things work, right up until they don’t.
What OT teams are discovering is that a lightweight service intake model gives them:
- A single front door for work instead of ten informal channels
- Prioritization that isn’t determined by who yelled loudest
- Visibility for supervisors and plant leadership without constant check ins
- Traceability across shifts and handoffs
- Fewer dropped balls when multiple teams or vendors are involved
This isn’t “ITSM for OT.” This is operational discipline that allows OT work to scale without changing how OT does the work itself. No standards name drop needed here, it’s just operational sanity.
2) OT security pressure forces shared governance
OT used to be isolated enough that security could be “contained.” That’s no longer the reality. IIoT, historian integrations, remote engineering access, cloud analytics, vendor connectivity and modern SCADA ecosystems have expanded the attack surface faster than traditional OT governance can absorb.
The result:
IT and OT are being pushed together because risk is now shared by default, not by choice.
Standards bodies reinforce this: ISA/IEC 62443 explicitly aims to bridge operations and IT, while NIST SP 80082 treats OT’s reliability/safety constraints as first class design inputs.
So convergence here looks like:
- shared risk reviews
- shared access patterns
- shared segmentation decisions
- shared accountability for connectivity changes
Not shared org charts, shared responsibility for not accidentally taking production down or opening a security hole big enough to drive a forklift through.
3) The CMDB/Asset context becomes non‑negotiable
In OT, asset context isn’t a “nice to have,” it’s the only way to understand what could fail, what it could take down with it and what that means for safety, production and compliance.
As soon as incidents, alarms, or changes tie to the thing they actually touch, spreadsheets and tribal memory collapse under their own weight. This usually begins with questions like:
- “Which line goes down if this PLC faults?”
- “How many systems rely on this firmware version?”
- “What safety interlocks are impacted if this controller is replaced?”
- “What’s the failure history of this inverter?”
Once those questions show up, ad hoc spreadsheets and tribal memory collapse under their own weight.
This is why asset relationships become the backbone of early convergence:
IT needs them for governance and security; OT needs them for failure mode visibility, maintenance and operational continuity.
Not because someone wants a CMDB, because without shared context, you’re effectively running blind.
The Hidden Force Behind All of This: Convergence Debt
Most organizations don’t realize they’ve been accumulating “convergence debt” for years:
- disconnected workflows
- inconsistent change practices
- parallel asset inventories
- two worlds making decisions that impact one another without shared context
Convergence isn’t about centralization, it’s about paying down that debt before it becomes operationally expensive.
Why IT/OT Convergence is Accelerating (the real drivers)
Value drivers
- Visibility and data utilization: you can’t optimize what you can’t see.
- Cybersecurity reality: connectivity + remote access + IIoT forces shared security posture and governance. Shared attack surface means shared posture and governance; OT’s safety/availability constraints change the playbook.
- Operational resilience: when systems are interconnected, service disruption becomes enterprise disruption.
- Workforce and skills: OT teams want less admin overhead; fewer heroics, more repeatable workflows.
- AI pressure: predictive maintenance and cross-domain event correlation need shared data and consistent workflows.
- Workforce transition: younger engineers expect modern tooling. Retiring OT experts take tribal knowledge with them. Hybrid IT/OT roles are growing by necessity.
Watchouts (because this is where people get hurt operationally and politically)
- “IT rules” applied blindly to OT: patch cycles, reboot assumptions and generic SLAs can create safety and uptime risks if misapplied. NIST stresses OT’s unique reliability/safety constraints for a reason.
- Tool sprawl / duplicate systems: OT already has EAM/CMMS, historians, SCADA tooling, vendor portals… if you add “yet another platform” without an integration strategy, you’ll pay for it.
- Ownership ambiguity: who approves a change when it impacts both a plant network zone and a business application? Convergence breaks org charts before it fixes workflows.
Where the Purdue Model Still Helps (and why it isn’t the whole story anymore)
Most organizations don’t pull out the Purdue Model because they’re feeling nostalgic about 1990s reference architectures. They use it because it still gives a shared mental model for where things live and who touches what across the enterprise–to–plant boundary. It’s not perfect, but it’s the closest thing to common language that IT, OT, vendors and auditors all recognize without needing a glossary.
Purdue gives you a way to talk about:
- What’s actually down at Level 0/1 (sensors, actuators, PLCs)
- What’s orchestrating at Level 2 (SCADA/HMI)
- What’s coordinating at Level 3 (MES/plant operations)
- What’s analyzing/reporting at Level 4 (enterprise IT)
That hierarchy still matters because most of the “who approves this?”, “what’s allowed to talk to what?” and “what breaks if we change this thing?” arguments map back to those layers whether people realize it or not.
But here’s the important part: modern convergence doesn’t flatten Purdue and it doesn’t replace it. It bends it.
Connectivity, cloud analytics, remote access, IIoT gateways and security requirements have all poked holes in the clean layer boundaries. Instead of throwing the whole model out, organizations have been quietly layering operational governance, identity, automation and risk controls across those levels. Not in a dramatic “tear down the pyramid” way, more like “let’s stop pretending the layers are impermeable and build guardrails that match reality.”
That’s why you now see overlays like:
- Identity based access instead of “trust the level you’re physically in”
- Vendor access workflows that expire automatically
- Segmentation based on zones and conduits, not just layers
- Monitoring and change governance that spans both IT and OT
- Remote engineering access that’s controlled like an IT privilege, but approved like an OT change
In other words, the Purdue Model is still the skeleton. But the musculature, the practical controls needed for modern operations, now lives on top of it, not instead of it.
So when organizations move toward IT/OT convergence, they’re not replacing their architectural heritage. They’re acknowledging that the physics of their plants haven’t changed… but the connectivity, risk surface and governance demands absolutely have.
The result is a hybrid reality:
- Use Purdue to understand the system.
- Use modern workflows, segmentation and access controls to safely operate it.
- Use convergence to eliminate the friction between the teams who live at each layer.
It’s not a new model. It’s a more honest one.
What Good Looks Like
If you do this well, you get an operating model where:
1) Incidents become faster to coordinate (not just faster to detect)
OT incidents often require multi-team response: controls, network, vendor, reliability, safety, operations leadership.
A service management backbone gives you:
- consistent intake + triage
- documented actions and comms
- repeatable post-incident learning, even if OT calls it something else
2) Change becomes safer and less political
You move from “permission by proximity” to:
- standardized change intake
- risk and impact captured with asset context
- auditable approvals and backout plans
And yes, it’s possible to do this without smothering OT agility if you design the workflow around plant realities.
3) Security becomes operational, not theoretical
ISA/IEC 62443 is lifecycle-oriented and explicitly holistic across people/process/tech. Convergence lets you operationalize that: requests, exceptions, access reviews, segmentation changes, vendor access, managed like real work, not spreadsheets.
4) A Minimum Viable Convergence Model
The organizations that avoid cultural blowback start here:
- shared intake
- shared prioritization logic
- shared asset context
- shared change governance
- domain-specific execution
No reorgs. No “one tool to rule them all.” Just shared operational truth.
Practical Steps That Actually Work
If you want this to stick, borrow the same adoption logic outlined in our AI posts: tools deliver zero value if they aren’t adopted.
Practical steps that tend to work:
- Start with one high-friction OT workflow (e.g., vendor access + approvals, maintenance request intake, incident comms).
- Define a minimal shared taxonomy (service, asset, location/site, priority model).
- Design for OT constraints (outage windows, safety gates, on-call reality).
- Measure outcomes (mean time to engage the right team, downtime minutes avoided, audit time reduced).
Final thoughts: Don’t Converge Org Charts, Converge Outcomes
IT/OT convergence doesn’t begin with a reorg, a steering committee, or a slide deck declaring a new operating model. It starts the moment the business recognizes a simple truth: downtime is no longer a “plant problem,” cyber risk is no longer an “IT problem,” and operational work can’t keep relying on tribal processes just because they’ve worked for 20 years.
The point isn’t to merge teams, blur roles, or force OT to adopt IT’s worldview. The point is to align the outcomes both groups care about:
- safer changes
- faster multi‑team incident coordination
- shared context for decisions that impact uptime
- clearer ownership across boundaries
- less operational debt accumulating in the shadows
Convergence sticks when it upgrades the operating model without breaking what already works in OT. That means starting with the workflows that produce the most friction like vendor access, maintenance intake, cross domain incidents; improving value and then scaling carefully. Not by importing IT bureaucracy into the plant, but by giving OT the structure it needs without losing the flexibility it relies on.
If you avoid the false choice between “centralize everything under IT” and “keep everything siloed for safety,” you get the version of convergence that actually sticks; shared truth, shared context, shared governance where it matters and domain autonomy everywhere else.
And if you want a platform that supports that “start small, scale intentionally” approach, especially one built for mixed workflows, asset context and cross team response, Jira Service Management is one of the few tools that can handle convergence without forcing you to redesign your entire world.
To learn how JSM is a great fit for OT, check out our 10 Reasons Why OT Teams Would Leverage Jira Service Management (JSM) post.
