IT Versus OT: Do CIOs Have To Do Both?
For CIOs, the real question is not whether to โownโ OT or IT, but where decision rights sit when business units buy technology that will later affect enterprise data, security and support. That calls for a clearer operating model: what must be disclosed early, what requires architecture review, and which investments can proceed locally with defined guardrails.
The management trade-off is autonomy versus coherence. Local teams often move faster and may have specialist vendor support, but unmanaged purchasing can create hidden integration cost, duplicate contracts, and gaps in identity, logging, patching or incident response. The practical issue is not technical purity; it is whether the organisation can still assure service continuity, auditability and recoverability when a โstandaloneโ system becomes business-critical.
CIOs should treat OT-style purchases as portfolio items, not exceptions. The next question for governance is which criteria trigger central review: customer or patient impact, data sensitivity, safety exposure, third-party access, or dependency on enterprise networks. That helps establish proportionate control, rather than forcing every operational purchase through the same process. It also gives business leaders a transparent way to justify speed when risk is genuinely low.
The leadership challenge is organisational, not just architectural. Successful models usually clarify who funds integration, who owns lifecycle decisions, and who accepts residual risk when a department selects a vendor. Before approval, leaders should ask: if this system must connect later, who pays for the bridge; who will support it after go-live; and what is the exit plan if the supplier underperforms?
As more systems move to the enterprise edge and citizen IT grows, independent user departments are developing mini-IT budgets of their own and purchasing their own systems.ย ย
In many cases, IT isnโt aware of these purchases, and there are users who feel that IT has no need to know, saying these systems and technologies are operational in nature, designed for the functions of a specific user area, and already supported by outside vendors that can give users the support they would otherwise need from IT.ย
These user systems are known as OT, or operational technology, because they are intended to meet a specific operational need in the business. They may even do it in โstandalone,โ non-integrated fashion. They are not intended to be broad-based information repositories for systems that everyone needs, and that require IT involvement.ย
Examples of OT systems in business are medical diagnostics systems that physicians use, MRI machines that radiologists use, robotic surgery arms used by surgeons, industrial automation in manufacturing, automated forklifts that warehouses use, and turnkey engineering 3D product design systems for engineers.ย
The divide between OT and IT systems can be difficult for CIOs to navigate because of fights over who is the decision maker and owner of which technologies.ย
Related:Tech Leaders Devise Strategies for Controlling Legacy Tech Costs
From experience, I can remember the painstaking effort involved in integrating a standalone engineering CAD OT system with other downstream systems in manufacturing. The company found itself having to maintain multiple parts and product configuration databases, with manufacturing and engineering often working from different product revision levels. In some cases, this resulted in obsolete or incorrect product components that either failed manufacturingโs quality assurance (QA) checkouts or caused issues for customers.ย ย
Everyone knew about these product โdisconnects,โ and they understood that some kind of integration between engineering and manufacturing systems was needed. There was also consensus that any systems integration required ITโs involvement. Despite this, there was pushback from engineering. โWe run and maintain our own system,โ they said, โWhy would we need IT when we have skilled software engineers of our own who can surpass the skill levels that you have in IT?โย
Engineering, indeed, had specialized software engineering skills that IT didnโt have. Yet, as the product โdisconnectsโ made their way to the bottom lines of our corporate profit and loss statements, the issue of engineering and manufacturing systems not working well together gained the attention of the board and the CEO. These executives wanted system integration that would fix the problem, and they expected IT to provide it, which we ultimately did.ย
Related:AI, Edge, and IoT Demand a Software-Centric Approach
OT/IT dialogues and debates like this continue today, and CIOs need to be aware of them.ย
Many already are aware, and from their experiences, here are some the OT/IT lessons that are beginning to emerge:ย
-
Stay in touch with your users! Donโt bury your head in the sand when a user talks about a new standalone analytics system, an automated assembly line or a new CT Scan machine. No matter how autonomous vendors and users claim the new technology to be, OT will ultimately turn into IT. Why? Because sooner or later, IT will be called to integrate these systems, and thatโs when both OT and IT become the IT teamโs issues.ย
-
Early on, itโs sound practice to know which new OT systems that users are contemplating. This is so IT can check the application programming interfaces APIs) and other types of connectivity options that come with the OT technology. The same goes for security and governance. Will the new OT technology (and its vendor) meet enterprise requirements? Most users will welcome an advance IT review of such issues, because the users themselves wonโt know much about them. More importantly, upper management and the board will want such a review, because OT technology is expensive and they donโt want to find that they have invested in tech that canโt โtalkโ to other tech, or that has lax or non-existent security.ย ย
Related:3 Tips for CIOs: Pitching Edge to Your Organization
-
Donโt lose your cool when a user tells you they purchased some new OT and they now want to integrate it with other corporate systems, and you had no โheads upโ on this. A few CIOs have told me that the initial response they are tempted to say is, โWell, you never told me about this new OT so I canโt guarantee that it will work well with other systems. Itโs your problem!โ From the gut, this is a natural reaction, but itโs not advisable when your job is to make technology work for the overall benefit of the company. Still, itโs fair to advise users and upper management of any system integration challenges you foresee.ย
Where We Go From Here With OT/ITย
As more automation and edge technology is deployed at remote locations, the lines between OT and IT will continue to blur. Companies are already seeing this, and many have seized upon new ways for IT and end users to do more upfront collaborating and planning.ย
On the operations side, users can see the possibilities for bringing data from more systems into their operations so they can do their jobs better, and they can appreciate what IT can deliver. On the IT side, IT can gain a better understanding of how the end business and its OT works, which puts IT in a better position to deliver โspot onโ technology that solves tough business issues.ย
The OT/IT divide has the potential to be a โcoming togetherโ for everyone, and itโs likely that CIOs will have a central role in shaping it.ย ย
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.