HolOps: Bridging the IT/OT divergence like McClane and Farrell

A practical mindset for running connected systems across departments, domains and disciplines.

Jul 06, 2025

Picture this: A power plant flickers, traffic lights go haywire and someone in a dark basement types faster than the eye can follow. Live Free or Die Hard wasn’t just explosive entertainment, it nailed a deeper truth: the chaos that unfolds when the digital world and the physical world don’t speak the same language.
John McClane doesn’t do protocols. He acts. He’s boots on the ground, knows every inch of the system he protects. That’s OT. Matt Farrell? A genius behind the screen, drowning in code but blind to the blinking warning light in the control room. That’s IT. Alone, they fail. Together, they just barely pull it off.
And that’s exactly where most companies stand today.
Operations and IT often live in different realities. Different goals, different vocabularies, different clock speeds. The result? Misunderstandings, delays, security gaps and too many incidents where no one really knows who’s in charge.
What’s missing isn’t just a shared toolset, it’s a shared operating culture.
That’s where HolOps comes in. Not a framework. Not a product. A mindset. A way to run connected systems together, even when worlds collide.

HolOps stands for Holistic Operations, but that doesn’t mean chasing perfection. It’s about making daily operations work in the real world: where IT wants to patch a server and OT needs to keep a packaging line running. Where one side thinks in sprint cycles and the other in production windows. Where both sides care deeply about stability, but define it in completely different terms.

It is a cultural approach that addresses this tension. Not as an idealized vision, but as a pragmatic attitude in the operation of digitally connected systems.

Let’s break down why IT/OT convergence so often fails, what HolOps actually means in practice and how organizations can move from siloed firefighting to shared operational clarity.

Because like McClane and Farrell, IT and OT don’t need to become the same.
They just need to stop working against each other.

Why convergence often fails

A look through Conway's lens

Conway's Law states: "Organizations that design systems are constrained to produce designs which are copies of the communication structures of these organizations." This is evident in IT/OT environments: When IT and OT report separately, plan separately and operate separately, they also create separate systems with interface conflicts, duplicated efforts and misunderstandings. When teams don’t talk to each other, their systems won’t either. HolOps aims to break this structural separation by embedding collaboration within the organization, so that systems, processes and tools align.

Different goals, different operational logic
IT thinks in software lifecycles: version maintenance, security updates, performance. OT thinks in production cycles: cycle times, equipment availability, fault history. This leads to goal conflicts, such as when an IT update is planned, but the production manager is in the middle of a peak week.
Example: An IT team installs a security patch1 on Sunday. On Monday, the shift can't start because OPC2 communication is disrupted. No one had involved OT beforehand.
Different time perceptions and pacing
IT works agilely, in sprints3. OT in coordinated maintenance windows, often quarterly. What seems "flexible" to one side appears chaotic to the other. OT isn’t slow, it’s careful. And for good reason: lives, processes, and millions in equipment depend on stability.
Example: IT wants to deploy a monitoring script4 at short notice. OT refers to validation requirements and safety proofs. Four weeks' lead time is mandatory.
Different language and meaning
"Availability" for IT means 99.9% uptime per month. For OT: "The line must not stop." Same terms, different worlds.
Example: Both sides report green KPIs, but machines on the shop floor stop every other day for minutes. With no shared responsibility model, no one has the mandate to fix it.
Separate control and power lines
IT and OT often report to different executives (CIO/CTO and COO). This makes joint control difficult and fosters territorial thinking (especially in bigger companies).
Example: An IT security project stalls because OT has neither budget nor approval authority and vice versa.
Different security logic
IT focuses on data confidentiality. OT on equipment availability. Both consider security, but from opposing perspectives.
Example: IT wants to route all connections through a central VPN5. OT declines because remote maintenance in emergencies would become too unstable.
No shared operational space
Many organizations lack a platform, both organizationally and technically, for joint operational action.
Example: In an incident call, no one knows who can decide whether to shut down the system. Responsibility remains unclear.

What joint operational models achieve

An integrative operational model doesn't replace established processes. It connects them. HolOps isn't a substitute for governance or technical excellence but their cultural foundation. It brings structure and attitude together.

Critics often ask: "Culture doesn't replace operations management." Correct. But without cultural understanding, processes remain formal and responsibility becomes diffuse. What companies really need is a shared mindset in which structured processes like change management, security controls, or incident response can become effective.

You won’t fix this with checklists. That’s why HolOps starts with mindset and turns it into structure, not the other way around.

Importantly: HolOps doesn't dilute OT's specific requirements. It doesn't demand DevOps6 with machines or agile experiments in safety-critical environments. Instead, it acknowledges that OT has strict regulatory, safety-related and operational requirements and that precisely for this reason, a shared model is necessary to confidently handle the growing complexity of digital systems. HolOps doesn’t replace technical security concepts like zoning7, firewalls, or Zero Trust8, but it makes them actionable by creating shared context and ownership.

And yes: HolOps is a coined term. But one with purpose. It names what many organizations need but can't yet grasp: a shared operational culture for a connected age. Not a framework, not a buzzword, but a conversation starter with direction.
You won’t find HolOps in textbooks (yet). But the need for it is real and growing.

It's not a product, not a project. It's an attitude: How do we operate connected systems together, even though we come from different worlds, use different tools, languages and have different goals?

It accepts the differences between IT and OT and transforms them into collaboration. It doesn't replace technical specifics but creates the context for operations in the digital space: with shared responsibility, clear control and lived collaboration.

Five principles for integrative operations

Holism instead of silos
We operate systems together, even if they are technically separate.
Example: A network segment for production is not planned solely by OT but coordinated jointly with IT and security.
Clarity enables ownership
Responsibility is not implicit but clarified, documented and visible.
Example: An operations board defines who can make changes, who tests, who decides in case of incidents. No more chaos during incidents.
Security as an operational principle
Security doesn't start at the firewall but at the architecture.
Example: New machines are only integrated if their communication paths are documented and risk-assessed.
Culture before toolset
Technology can help, but without trust, ownership and clarity, it achieves little.
Example: A SOC9 (Security Operations Center) is useless if OT doesn't know how to respond in case of an alarm and no one takes responsibility.
Learning in operations
Errors are not failures but insights.
Example: After a network outage, IT and OT jointly document what happened and adjust the alerting plan.

From principle to practice: building the bridge

Establish joint operational documentation

A consistent, cross-disciplinary documentation is the basis for any stable operation. It should include:

Topology and communication plans for all IT and OT-relevant systems
Availability and maintenance windows per system
Responsibilities (technical, organizational, operational)
Security classification of systems (e.g., according to IEC 6244310)
Dependencies and escalation paths

Recommendation: Use central platforms (e.g., an operations wiki or a configuration management system) accessible to all stakeholders.

Establish integrated change, incident and problem processes

Standard ITSM11 (IT Service Management) processes must be adapted for OT but thought of integratively. This means:

Change Management: Every system change, whether IT or OT, goes through the same governance process-with specific review paths for security, availability and production relevance.
Incident Management: Central recording and assessment of all operational disruptions, with clear response paths for both sides.
Problem Management: Root cause analysis and structural resolution across disciplines including lessons learned.

Important: Don't separate processes, but define roles and exceptions. HolOps means: one operational model, different rhythms, shared control framework.

Introduce operational rounds

Conduct weekly operational meetings with fixed participants from OT, IT and Security. These meetings should:

Have a fixed schedule (e.g., every Tuesday at 10 a.m.)
Follow a structured agenda: status reports, planned changes, current risks, open escalations
Be moderated (e.g., by an operations coordinator)
Not be reporting events but understood as control
Have decision-making authority: minor changes should be approved immediately

Prerequisite: Clear role distribution, documented responsibilities, maintained operational documentation.

Create cross-functional operational roles

Roles like "Digital Plant Manager" or "Operations Coordinator" take responsibility for the interface between IT, OT, Platforms and Security. They should:

Have a technical background in at least one area (OT, IT, or Networks)
Be able to communicate with all three worlds
Weigh operational goals against security and architectural requirements
Evaluate and prioritize escalations
Be able to approve changes initially (within a defined framework)

Success Criterion: These roles must be visible, recognized and organizationally integrated. Without leadership support, HolOps doesn't work.

Plan operational architecture together

Avoid the separation between "IT architecture" and "production planning." Think of operational architecture integratively:

Which communication paths are operationally relevant?
Which systems need shared visibility (e.g., network monitoring, log data)?
Where are the biggest operational risks in case of changes?
Who needs to be involved when something changes?

Tools: Joint architecture workshops, visual operational maps, central approval processes for system changes.

Define joint operational goals

Move away from purely technical KPIs. Formulate goals that unite operations, security and collaboration. Examples:

"No unplanned downtime due to IT changes in the production network"
"All security-relevant incidents are detected and assessed within <15 minutes"
"All systems with operational relevance have clearly documented responsibilities"

Important: These goals should be part of target agreements in IT and OT. Only then does HolOps become an attitude, not a side issue.

Institutionalize learning

Every outage tells a story, if we’re willing to listen. Use them:

Conduct systematic post-mortems for all incidents with production relevance
Document causes, reactions, insights - not to assign blame but to improve the system
Share these insights across teams
Use them to improve operational architecture, monitoring, or response plans

Tools: Joint incident wiki, quarterly review meetings, change backlog with lessons learned.

Additional: Securing Governance

Anchor HolOps as an operational principle at the leadership level:

With an operations board that serves as a decision-making and escalation instance
With a documented operational model (including roles, processes, target systems)
With clear anchoring in the security strategy

Only when operational responsibility is not delegated but shared and jointly managed does sustainable collaboration between IT and OT emerge.

Roles and organization

Digital Plant Manager: The link between IT, OT and production. Plans, moderates and makes decisions at the interface.
Operations Board: Regular decision-making body for evaluating changes and operational risks. Makes fact-based decisions.
Security Owner for OT: Assesses and prioritizes protection needs jointly with OT stakeholders.
Operations Architect: Designs operational architecture systematically: technology, responsibilities, responses.

Maturity levels of integrative operational models

Side-by-side: Separate teams, no interaction
Defined Interfaces: Occasional coordination, initial shared processes
Joint Operations: Regular meetings, clearly defined responsibilities
HolOps Culture: Shared responsibility, continuous learning, trust across IT and OT

Common misconceptions and the reality

"OT can't be agile"
Maybe not in the software sense, but it can still adapt quickly within clearly defined boundaries, cycles, feedback loops and release processes.
"Security slows down operations"
Only when it's brought in too late. As an operating principle, it helps prevent downtime and mitigate risks.
"We need tools first"
Tools are useless if responsibilities and culture aren’t clear. Mindset first, then tech.

Related concepts: what else helps bridge the gap?

HolOps doesn’t stand alone.
There’s a growing set of ideas, both from the OT world and classic IT, that aim to close the same gaps: culture, visibility, control. They come with different labels, but often share the same goal: making connected operations work across disciplines.

From the OT side: tools to build common ground

Digital Twins - Think of them as shared, real-time dashboards for machines or processes. They create a common language for IT and OT by simulating assets and workflows before anyone touches the real system.

IIT (Industrial IT) – A mediator between the fast-moving world of IT and the real-time demands of OT. It decouples data flows, simplifies access and helps both sides work with what they need: safely.

Industrial DevOps – Agility, adapted for the shop floor. Not about rapid releases, but about structured, feedback-driven improvements in production environments.

IBPT (Industrial Business Process Twin) – Instead of mirroring machines, this mirrors processes. It shows how workflows run in real time and lets teams simulate changes safely.

Governance frameworks – Standards like IEC 62443 clarify roles, responsibilities and protection goals. Critical when IT and OT operate together.

Middleware & Protocol Converters12 – These are the technical translators: letting systems talk to each other even if they “speak” different languages.

From the IT side: lessons worth borrowing

DevOps – Originally for developers and sysadmins, it’s about collaboration over handoffs. A mindset HolOps shares, but applied to different tools and timelines.

SRE (Site Reliability Engineering) – Think race car pit crews: balancing change speed with rock-solid uptime. A good metaphor for OT/IT collaboration.

ITIL – A standard for managing IT processes. Often too rigid for hybrid environments, but still useful for understanding structured service delivery.

Bottom line: HolOps doesn’t reinvent the wheel, but it gives these ideas a place to work together, grounded in the daily operational reality of connected systems.

Conclusion

HolOps is not a method. It’s a mindset.

One that recognizes: Operating connected systems is a team sport. No discipline can manage it alone. No organization can afford to keep thinking in silos. HolOps is a mindset to shape this reality: technically, organizationally, culturally.

Additional perspectives and challenges

Consider global differences

Challenges in IT/OT integration vary by region. In Europe, OT is often heavily regulated. In the U.S., there's more functional separation and outsourcing. In Asia, centralized operating models dominate. HolOps is not a rigid model, it must be adapted to cultural and regulatory contexts.

Integrate Regulatory Requirements

Whether it’s CRA, NIS2, ISO 27001, or IEC 62443, legal requirements can’t be solved by culture alone. But HolOps creates the conditions for consistent technical and organizational controls, because the right people are involved at the right time.

Choose tools carefully

HolOps is not a tooling concept, but some technologies can support collaboration:

ITSM platforms with OT modules
Asset discovery solutions for unified IT/OT inventory
OT-capable SIEM13 (Security Information and Event Management) / SOC (Security Operations Center) systems for comprehensive event detection

What to do in case of conflicts?

Even with the best intentions, tensions will arise. That’s why we need:

Clear escalation channels like an operations board
Transparent decision rules for goal conflicts
Role clarity on who has the final say (e.g., safety responsibility overrides operational preference)