IT/OT Convergence Is Not One Thing

ReadIndustry InsightsStats & TrendsBest PracticesInfographic
Written By Jeff Winter

I've always gotten a kick out of asking an IT person and an OT person what “IT/OT convergence” actually means. You can start with a friendly technical discussion and, before anyone orders another drink, find yourself negotiating reporting lines for a department that doesn't exist yet.

Non-animated Infographic Version

If you know me at all, you know I thrive in this kind of ambiguity, especially when a buzzword comes from a real problem that everyone recognizes but describes differently!!! People want help connecting systems, using data, and working across organizational boundaries... they just arrive with different ideas about what needs fixing. My engineering background and commercial strategy work both pull me into understanding why a technically reasonable answer can be so difficult to make useful.

I think of IT/OT convergence as bringing information technology and operational technology into a workable relationship across systems, data, decisions, and responsibilities. Everyone would probably agree that IT manages information and enterprise processes while OT monitors and controls physical processes, but the details are far messier.

The concept has a longer history than the current conversation sometimes suggests. Manufacturers were working on connecting business systems with production systems well before “IT/OT convergence” became familiar conference language. ISA-95, first published in 2000, addressed enterprise-control system integration, giving people common models and terminology for exchanging information across that divide. Production orders, available capacity, material requirements, and actual production results already needed to move between different parts of the business. We had the coordination problem before we had today's preferred vocabulary for discussing it.

The technology was changing, too. NIST describes how historically isolated OT systems, built around proprietary protocols and specialized hardware and software, increasingly adopted standard computers, operating systems, and networking technologies. That made connectivity and remote access more practical, while creating new dependencies and security concerns. Sharing technologies gave IT and OT more reasons to work together, without automatically giving them the same priorities or an agreed way to make decisions.

As for the phrase itself, one early use I could verify appears in Gartner analyst Kristian Steenstrup's 2010 presentation, Integrate Operational Technology into IT Plans. It explicitly discusses IT/OT convergence, including governance, organizational responsibilities, and the CIO's role. By March 2011, Gartner was publicly announcing that the worlds of IT and operational technology were converging. Those are documented milestones, although they don't establish who first coined the expression. What I find interesting is that the people and governance questions were already there... we've had quite a while to work on this, and somehow “who owns it?” still gets a respectable amount of meeting time. That history is part of why I enjoy the topic so much. You can follow a seemingly simple request for production data into questions about reliability, funding, security, expertise, and decision-making. Everyone might support the intended outcome while having perfectly sensible reasons to object to the proposed approach. I find that much more interesting than assuming one department understands the future and the other needs a motivational presentation.

And the practical need keeps growing. Rockwell Automation's 2026 survey found that 90% of respondents considered digital transformation essential to competitiveness, while 59% reported actively using smart manufacturing technologies in operations. Those measure different things, but they underline why coordination matters when delivering improvements through systems and expertise spread across several functions.

That's why I enjoyed getting a copy of The IT/OT Handbook from my friend David Ariens, who wrote it with Willem van Lammeren. David and I first met at Hannover Messe 2026, and I'm excited about what they're doing and about collaborating more with him. I love seeing people this dedicated to the subject. What I enjoyed most was the authors' respect for both sides and their willingness to explain when different arrangements make sense. Their example of a plant ordering tablets for inspection rounds, then abandoning the initiative after connectivity and security issues stall progress, captures the problem painfully well. Everyone can have a reasonable concern while the tablets accomplish approximately nothing. Of course, I started adding my own questions and eventually another graphic (apparently reading quietly wasn't an option 🤣). The IT/OT Handbook gave me a useful structure to work with, then made me want to adapt it around the choices I think leaders need to discuss.

The Patterns We See

The seven cooperation patterns in The IT/OT Handbook gave me the starting point. I liked having recognizable arrangements to discuss, especially because “we need better collaboration” leaves an impressive amount of room for everyone to agree without changing anything. My take grew out of asking what I wanted someone looking at a single graphic to understand about how work gets done, who makes decisions, and who remains responsible afterward.

Some changes were about wording. I renamed Outsourced Innovation as External Integration because an external partner can perform that coordinating role even when the solution is well established. I changed the Handbook's IT/OT Convergence label to IT-Lead to make the organizational arrangement explicit. And with Product Teams, I brought persistent shared ownership into the foreground. The Handbook explains how product capabilities can find homes within IT or OT; my graphic emphasizes the continuing responsibility across disciplines, wherever the team happens to report.

The big addition I made was adding Federated IT/OT. I wanted a separate place for organizations that retain distributed responsibilities while sharing governance, platforms, and standards. A permanent team owning one capability and an enterprise coordinating responsibilities across many plants raise different questions. For the discussion I wanted the graphic to support, seven left that second arrangement insufficiently visible. Federation deserved its own box, especially because several of the other patterns can operate within it. That brought me to eight. A ninth would need to describe another meaningful difference in how responsibility and coordination work. A different technology, industry, or job title wouldn't be enough on its own; otherwise, we'd soon have a separate pattern for every company that assures me its situation is unique (which, admittedly, would make a very large graphic).

I also kept the word patterns deliberately. These are recurring arrangements you can recognize in how requests move, decisions get made, people get funded, and problems get resolved. Some are designed intentionally; others develop because people need to get something working before the next organizational review. The Handbook already makes the useful point that several can coexist. Corporate IT might use formal service requests with one plant, support a joint project at another, and discover that a third has built its own application while everyone was discussing the first two.

My other addition was grouping them by the working relationship they create. The red/pink group, Transactional Coordination, contains Silos, External Integration, and Shadow Teams: work moves through handoffs, external partners, or capabilities built around organizational gaps. The orange group, Shared Delivery, contains IT-Lead, Facilitation, and Cross-Functional Project Teams: delivery gets an explicit coordinating mechanism through a lead function, designated people, or a joint team. The blue group, Shared Ownership, contains Product Teams and Federated IT/OT, where responsibility continues through ownership of a capability or the governance and platforms supporting many capabilities. Blue comes with ongoing obligations and costs... something the colors, rather conveniently, don't invoice you for. I also added the applicability dimensions beneath the patterns to make people consider where each arrangement fits.

Together, those changes give me a way to discuss combinations and tradeoffs. Conway's Law links system design to organizational communication, which is a useful reminder that the way we arrange the people tends to show up in what they build. The graphic is my way of making those arrangements easier to recognize and question.

1. IT and OT in Silos

IT and OT operate as separate functions with their own responsibilities, priorities, and processes, interacting mainly through requests and handoffs. I'm quite happy to defend silos when the work is predictable and the boundaries are clear. IT handles its responsibilities, OT handles its responsibilities, and nobody needs a steering committee to approve a standard laptop.

The IT/OT Handbook acknowledges the efficiency of that arrangement, which I appreciate. Trouble starts when the request needs discovery, like linking production events to customer commitments before anyone has agreed on definitions, timing, or consequences. A ticket can travel between departments collecting perfectly reasonable comments while the actual decision makes very little progress. By the third reassignment, it may contain enough history to qualify as an archive, although the original requester still needs an answer. I would preserve the efficient route for routine work and create a joint route for requests requiring interpretation. Repeated handoffs, reopened tickets, and regular executive rescues suggest that the coordination pattern no longer fits the task, even if every department is following its process correctly.

2. External Integration

External Integration puts an outside partner in a central role coordinating and delivering a capability across IT and OT, potentially including ongoing support. The manufacturer relies on that partner to connect systems and expertise it cannot easily bring together internally. Deloitte's 2025 Smart Manufacturing Survey found that, depending on the technology role, 65% to 70% of respondents reported outsourcing across areas including IT, OT, cybersecurity, analytics, and automation. That measures roles rather than this particular operating pattern, but it shows how much manufacturers rely on external expertise.

Imagine condition monitoring across equipment from several manufacturers, with the partner coordinating the applications, connections, and operational requirements. That is why I broadened The IT/OT Handbook's Outsourced Innovation label: the integrating role matters even when the capability itself is familiar. Simply buying software leaves quite a lot of integration work available for whoever discovers it first. My commercial strategy instincts send me toward the contract: who controls the roadmap, who can reuse the data, and who investigates a failure between the application and the network? I'd keep an informed internal owner who can challenge the answers and understand the dependency being accepted. A good partner should help that person become more capable over time, including at renewal, when everyone's enthusiasm for the relationship acquires a price.

3. Shadow Teams

Shadow Teams emerge when one function develops capabilities normally associated with the other, often because the established way of getting help cannot meet its needs. The name makes this sound more mysterious than it usually is. Quite often, somebody needed a useful capability and eventually stopped waiting for the official route to provide it.

OT builds its own IT capabilities, or IT brings in industrial expertise because coordinating with plant organizations has become equally frustrating. The IT/OT Handbook covers both directions, which avoids making this another argument about which department needs to behave better. Consider an engineer who builds a downtime application that operators actually use: more people adopt it, features accumulate, and an experiment quietly becomes something production depends on. Then the engineer changes roles, something breaks, and everyone discovers that much of the documentation was available only during that person's working hours. The application may have been delivering real value, even if the support arrangement had developed more by accident than anyone would comfortably admit.

I tend to admire the resourcefulness while also wondering who gets the call when it fails. The practical response is to understand why the workaround was needed, preserve what is useful, and address security, documentation, support, and ownership together.

A successful experiment might become a Product Team's responsibility, while recurring requests might become a standard service. Whatever comes next should fix the original blockage, because absorbing the team into the process it escaped can reproduce the same problem with more mandatory fields. If asking for help means losing a useful tool without a workable replacement... people will draw their own conclusions about asking next time.

4. IT-Lead

In the IT-Lead pattern, IT takes ongoing ownership of manufacturing digitalization, with industrial expertise inside IT and no separate internal OT department to coordinate with. Vendor-supplied equipment handles much of the control complexity, while internal work centers on connectivity, data, and enterprise integration. The IT/OT Handbook describes particular conditions that make this viable, including limited internal automation complexity. I made IT leadership explicit because calling this arrangement IT/OT Convergence can imply that everyone else has an unfinished organization chart. Connecting standardized machines and engineering complex automation involve different responsibilities, and changing reporting lines doesn't make the required expertise appear (a disappointing limitation of PowerPoint).

I would begin by asking who understands the process consequences, where machine responsibility sits, and what expertise must remain available. If those answers support IT leadership, use it deliberately and revisit the choice as the environment changes. The arrangement should fit the work people actually need to do, including the awkward cases that tend to arrive after the reorganization announcement.

5. Facilitation

Facilitation assigns people to coordinate between IT and OT while the functions retain their own responsibilities. A designated liaison can make a surprising difference by helping IT understand production constraints and OT understand infrastructure requirements. Vendor access or a new data connection may need somebody who can bring the right people together before everyone's assumptions harden into policy. The role needs a mandate and a useful escalation path, or the facilitator becomes a well-informed messenger carrying the same disagreement in both directions. Team Topologies offers a related distinction between facilitation, close collaboration, and consuming a service, which I find helpful when deciding how much ongoing interaction the work really requires.

I would judge the role by what becomes easier without the facilitator: reusable agreements, clear responsibilities, and decisions people can repeat without another meeting. Otherwise, the organization has quietly concentrated its ability to cooperate in one person's calendar. They should be able to take a vacation without returning to evidence that nobody spoke constructively for ten working days.

6. Cross-Functional Project Teams

Cross-Functional Project Teams bring IT, OT, and often Operations together for a defined initiative, with a shared delivery objective and a planned endpoint. A manufacturing execution system rollout is a good example: production workflows, enterprise applications, infrastructure, and data definitions affect one another, so decisions need to be made together while delivering the initiative. Deloitte found that 52% of respondents had created a central team or working group to research, develop, and deploy smart manufacturing initiatives. That doesn't measure this exact pattern, but it shows organizations deliberately creating coordination structures. What interests me is whether those structures can actually decide and deliver, because putting names on a project slide doesn't automatically remove anything from their existing workload. People can belong to the same team on Monday's presentation and spend the rest of the week discovering that their managers have different priorities.

The IT/OT Handbook's emphasis on executive support and authority matters here. I'd want a shared outcome, protected capacity, and agreed decision rights, with leadership resolving conflicts the team cannot reasonably settle itself. I'd also ask who will support and improve the capability after delivery, while everyone still has an incentive to answer. That includes funding, ownership, and the transition into ongoing operations, which is where this pattern connects to Product Teams or established service teams. Leaving it until handover creates an impressive opportunity for people to remember different versions of what was agreed (usually with remarkable confidence).

7. Product Teams

Product Teams provide ongoing, shared responsibility for running and improving a digital capability, with a stable team that stays involved after deployment. This is the pattern I find most compelling when a capability becomes part of running the business and keeps requiring decisions across disciplines.

Consider quality analytics after the initial deployment: a supplier changes a material, a process drifts, operators start questioning an alert, and another plant wants to use the solution. Someone needs to investigate whether the issue comes from the model, the data, or the process, then validate an adjustment before people rely on it. That takes context, authority, and continuing capacity. If the original team has dispersed, those needs remain, although now each question also requires finding someone who remembers why a particular decision was made. Having a folder called “Final Documentation” can be reassuring right up until you need it.

I think this is one of the hardest patterns to sustain because the organization has to keep funding work after the original deployment stops attracting attention. Reliability, maintenance, and small improvements compete with newer initiatives that have more interesting presentations, and the people keeping the capability useful are often exactly the people another project would like to borrow.

I recognize a much smaller version of this when preparing presentations. Even with a familiar topic, I still need to update evidence, adapt examples, and think about the audience; owning the slide file doesn't save me from doing the preparation. The IT/OT Handbook's comparison with the permanent crew supporting a production line makes the point more directly. It discusses product capabilities finding homes within IT or OT, then explores teams organized around business outcomes. My graphic brings persistent shared ownership into the foreground because I want the ongoing responsibility to remain visible across reporting lines. That doesn't require every specialist to stay permanently assigned. A stable team can use standard infrastructure services, external partners, and specialist help while retaining the capacity to make continuing decisions. I'd measure adoption, reliability, and operational results alongside delivery, and be cautious about creating a full product arrangement for something that a standard service can handle perfectly well. The additional coordination should earn its place through the work the capability actually needs.

8. Federated IT/OT

Federated IT/OT combines shared governance, platforms, and standards with responsibilities that remain distributed across functions, plants, or business units. I added it because I wanted a way to discuss enterprise consistency while preserving legitimate local responsibilities and differences.

This is the arrangement I kept wanting to show when adapting the Handbook's seven. A Product Team can own a specific capability, while federation establishes how many teams and locations work within a common set of rules. A plant can choose how to improve its process while the enterprise sets requirements for identity, connectivity, and data exchange. That combination deserved its own pattern because local autonomy and enterprise coordination have to be designed together. The interesting question becomes how much freedom each site needs, and where variation creates costs or risks that everyone else ends up inheriting (usually without volunteering).

My Lego habit probably explains why shared interfaces appeal to me. Different builds can do different things with compatible pieces; imagine instead that every plant specifies slightly different studs because its requirements are special. You can still assemble something across them, but somebody will eventually propose glue, and I will have concerns about both the architecture and the Lego. In organizational terms, plants might own local automation while using common identity services, approved connectivity patterns, and shared data definitions. The common elements should make local work easier, with a sensible exception process for differences that matter. Fortinet's 2026 global OT survey found that 60% of respondents placed ultimate OT cybersecurity responsibility with the CISO. That concerns security accountability rather than ownership of every OT function, but it illustrates why oversight and local engineering expertise need a workable relationship.

I put federation alongside Product Teams as the hardest to sustain because the decisions keep returning: what is mandatory, what stays local, who funds shared services, and who resolves exceptions? Too much reinvention makes reuse expensive, while overly rigid standards can obstruct a perfectly sensible local improvement. Everyone usually supports “common standards” until the proposed standard differs from the one they already use. What may be interesting is The IT/OT Handbook's discussion of reusable data infrastructure helped inspire this addition. Product Teams can own capabilities and project teams can deliver changes within a federated arrangement, while suppliers contribute where needed. Somebody still has to maintain the shared platforms and agreements, or local teams will find their own ways around them... which brings Shadow Teams back into the conversation.

Dimensions of Applicability

But simply listing eight patterns wasn't quite enough for me. I wanted patterns within patterns 🙂... because once I started looking at how these arrangements actually show up in companies, the combinations became just as interesting as the individual patterns. A manufacturer can have several of them working reasonably well at the same time, depending on which part of the business you're looking at.

That's why I added scope, capability, and lifecycle. Someone can say, “We're using Product Teams,” and I immediately want to know which teams, responsible for what, across how much of the organization, and for how long. Otherwise, we risk having the same wonderfully ambiguous conversation we started with, just with eight more terms available. The IT/OT Handbook already explains that several patterns can coexist; these dimensions are my way of making that coexistence easier to discuss and apply.

  • Scope: the organizational level where the pattern applies. A team, plant, business unit, and global enterprise each have different coordination needs. One plant might use a Cross-Functional Project Team for a deployment while the enterprise uses Federated IT/OT to maintain shared platforms and standards. Both descriptions can be accurate simultaneously. Scope helps identify where decisions belong and which dependencies extend beyond the people currently in the meeting.

  • Capability: the work the arrangement needs to support. Standard network access, production scheduling, quality analytics, and safety-critical machine control require different combinations of expertise, responsiveness, and accountability. Routine infrastructure requests may work efficiently through service handoffs, while an evolving analytics capability needs continuing involvement from production, engineering, and data specialists. I added this dimension because “manufacturing digitalization” covers an enormous amount of work for something people regularly assign to one box on an organization chart.

  • Lifecycle: how responsibilities change as the capability develops. Designing, deploying, operating, improving, and eventually retiring a solution create different demands. A project team might establish a capability, a Product Team might maintain and improve it, and an external partner might provide specialist support throughout. This dimension makes the transitions visible, including the awkward moment when the project budget ends but the application continues expecting electricity, maintenance, and somebody to answer questions.

Together, these dimensions make the discussion more specific:

This arrangement, for this capability, at this organizational level, during this stage of its life.

They also give us reasons to revisit a decision. A successful pilot at one plant can create a very different ownership problem when twelve more plants want it. I'd rather have that conversation while expansion is being planned than discover that our global support model is still one helpful engineer named Jim.

What do we do?

I'd start with one capability that's causing friction and get the people responsible for delivering, operating, and supporting it into the same conversation. Map how decisions actually happen, including who gets called when the documented process runs out of answers. The combination I run into most is silos, shadow teams, and facilitation, often together, so I'd look closely at where a few helpful people are compensating for responsibilities nobody has settled. Then agree on the arrangement the work needs: who owns the outcome, who can decide, what capacity is funded, and what changes after deployment. Try it on that capability and revisit it as the scope grows. That's the practical conversation I want the graphic to start, and what the Handbook inspired in me.

I'm looking forward to more of those conversations with David and Willem... although I appreciate that giving someone a book doesn't normally commit them to reviewing another framework. 😇

References:

Jeff Winter
Next

Why AI Transformation Gets Stuck in Old Ways of Working