Moving from strategy to execution requires coordinated changes across systems and teams. In part two of our IT/OT convergence series, learn practical steps to make IT/OT convergence work in real operations.
Most operators are recognizing that IT and infrastructure operations need to be more closely aligned. The real difficulty, though, is in translating that understanding into day-to-day operations that hold up under real conditions, because the challenge shows up in how work is actually performed (especially in AI/HPC environments where systems are more tightly coupled and performance expectations are higher.)
Systems were implemented at different times for different purposes, and teams built processes around them. Over time, those processes became embedded in how the organization operates, even when they no longer reflect how the infrastructure behaves. Operationalizing convergence requires changing how work flows across those systems and teams. Here’s how.
Step 1: Define a Shared Operating Model Across IT and OT
In most environments, IT workflows, infrastructure workflows, and telemetry systems run independently, each with its own triggers, owners, and definition of done.. Each has its own triggers, ownership, and definition of completion. When an issue spans multiple systems, those differences introduce delays and make it harder to determine whether a problem has actually been resolved.
Establishing a shared operating model clarifies how issues are identified, who owns them, and how resolution is validated.
In practice, this often breaks down during incident response. A cooling anomaly might trigger an alert in a building management system while, at the same time, IT teams are seeing degraded GPU performance. If those signals are handled in separate workflows, teams can end up working the same issue from different angles without a clear owner or shared understanding of the root cause. A shared operating model ensures that these signals are treated as a single event, with coordinated ownership and a defined path to resolution.
Step 2: Build a Technology Stack That Connects Data and Workflows
Once the operating model is defined, the technology stack determines whether convergence is achievable. Many organizations are working with a mix of IT service management tools, infrastructure systems, and building management platforms that were not designed to operate together. Each system captures part of the operational picture, but none provides a complete view on their own. A connected technology stack allows operators to link telemetry data with work orders and maintenance activity in real time.
A practical example of this is during maintenance validation. A technician may respond to an alarm on a cooling unit, perform the necessary work, and close the ticket. Without a connected system, there’s no immediate confirmation that supply temperatures, flow rates, or rack-level conditions have returned to expected ranges.
When systems are connected, that same workflow can incorporate real-time feedback. If temperatures or performance metrics have not normalized, the system can flag that the issue is still unresolved, preventing the work order from being closed prematurely. This is where the technology stack moves from just storing information to actively guiding operations, which becomes especially important in AI/HPC environments where small performance gaps can compound more quickly.
Step 3: Simplify Workflows to Eliminate Redundant Work
Siloed systems often create redundant workflows that add unnecessary operational burden. In some facilities, technicians complete rounds using printed sheets or spreadsheets, then re-enter that same data into another system. That data is later reworked again into reports. Each step increases the likelihood of error and takes time away from maintenance and problem-solving.
This becomes more pronounced as portfolios scale. What works at a single site becomes difficult to sustain across multiple locations. One operator described a process where rounds were captured on paper, transcribed into a shared spreadsheet, and then manually compiled into monthly reports. At a single site, this added friction but remained manageable. Across multiple sites, it created a significant amount of time spent handling data instead of maintaining equipment.
Simplifying workflows so that data is captured once and used across systems removes that friction. It allows teams to spend more time on the work that directly impacts performance.
Step 4: Connect Actions to Outcomes With Real-Time Validation
Completing a task is often treated as the endpoint, but in converged environments, it’s more important to confirm that the task achieved the intended result. This becomes especially critical in environments where systems are tightly coupled. A technician may complete a repair on a cooling loop or power component, but the true measure of success is whether the system has returned to expected operating conditions.
For example, after addressing a cooling issue at the rack level, validation should include confirming that temperatures, flow rates, and compute performance metrics have stabilized. If GPU utilization or thermal conditions remain outside expected ranges, the issue isn’t fully resolved, even if the initial task was completed.
Incorporating this level of validation into workflows reduces repeat incidents and ensures that actions are tied directly to outcomes.
Step 5: Empower Teams With Structure and Trust
Even with the right processes and systems in place, operations still depend on people. Human error is a common factor in many incidents, often tied to using the wrong procedure or not following steps correctly. At the same time, these environments are becoming more complex, and experienced talent is limited. This creates a balance operators need to manage.
Procedures, systems, and real-time feedback should reduce the likelihood of error by guiding technicians through the correct steps and validating outcomes. At the same time, teams need to be trusted to interpret information and act when conditions fall outside expected patterns.
For example, when a technician completes work on a system and observes that performance hasn’t returned to normal, they need both the visibility to recognize the issue and the authority to escalate or continue investigating rather than closing the task. Organizations that combine structure with trust are better positioned to operate effectively as complexity increases.
Operationalizing Convergence Is an Ongoing Process
Unfortunately, there’s really no single point where convergence is complete. As infrastructure evolves, operating models, systems, and workflows need to evolve with it. Organizations that treat convergence as an ongoing process are better able to adapt to changes in technology, scale, and customer expectations.
The goal is to ensure that systems, teams, and data operate as a cohesive whole, supporting reliable and efficient operations.
What Comes Next
Once convergence is operationalized, its impact becomes most visible in the workflows that drive daily operations. The final blog in our IT/OT convergence series examines the workflows where convergence has the greatest influence on performance and reliability, and how operators can refine those workflows to support increasingly complex environments.
