Building Software Between OT and IT

Building software between OT and IT

The popular version of building technology goes like this. A building runs on operational technology, the BMS and its controllers, and the job is to lift that data up into information technology, the cloud and the software, where it becomes useful. OT to IT, one direction, done. Our version is stranger and harder. We didn't set out to move data from one world to the other. We came out of the OT world, the BMS world, and we are building IT-world software, a SaaS, for an audience that mostly still lives in OT, plus a fast-growing crowd that doesn't. We are not migrating between two worlds. We are trying to build something that belongs to both at once, and that, far more than any protocol, has been the hard part.

Two worlds that don't speak the same language

Operational technology (OT) is physical control: the BMS, the PLCs, the SCADA, the sensors and controllers wired into the plant. An OT person, a controls engineer or a plant operator, thinks in physical things. A point. A sequence. AHU-3, chiller 2, the supply-air sensor on the east riser. Their instinct is to trust what they can point at, and their first loyalty is to keeping the building running. Change is risk. The panel has worked for fifteen years, so don't touch it. It's a culture built, correctly, around reliability and the physical, where an outage isn't a bug ticket but a building full of people who are suddenly too hot.

Information technology (IT) is data and software: networks, the cloud, SaaS, abstractions, models and scale. It thinks in things you can't point at, a normalized data model, a user role, a release. It ships updates, versions everything, integrates systems, and assumes a number is a number whether it came from one building or a hundred. Where OT prizes "don't change what works," IT prizes "improve it continuously."

The industry has a tidy phrase for joining them, IT/OT convergence, usually meaning OT data flowing into IT systems. What we're doing is a little different and a little harder. We're not piping data across a border. We're building software that has to be fluent on both sides of it. Getting OT data into an IT system is easy. Building an IT product that an OT engineer trusts and an energy manager actually enjoys, at the same time, is the real project.

Why the concepts don't translate cleanly

A few frictions came up again and again while building.

The same reading means different things to different people. A supply-air temperature to the operator is an energy figure to the energy manager, a carbon number to the sustainability officer, and a line on a budget to the executive. The operator's "point" is the manager's "metric" is the director's "outcome." Translating a protocol is trivial next to translating a point into a KPI into a story that three different people each recognise as their own.

OT trusts the concrete; software runs on abstraction. A platform has to normalise a messy, multi-vendor building into a clean model of locations, equipment and sensors. But the first question a good BMS engineer asks any dashboard is, "is that the real number, from the actual sensor, right now?" If the abstraction is ever caught lying, even once, you lose that user for good, and rightly so. Earning trust across a layer of abstraction is a different and harder thing than building the layer.

Reliability culture meets iteration culture. OT lives by "if it works, leave it alone." SaaS lives by shipping improvements constantly. Both are right in their own world, and a product spanning them has to honour each without letting one poison the other. You cannot tell a facilities manager you'll be pushing weekly changes to the thing tied to their chillers and expect them to sleep at night.

The part that surprised us: a BMS had one user, a platform has a crowd

This is the one we underestimated, and it's the heart of why building the software was hard rather than just laborious. A BMS was essentially built for a single kind of person, the operator or the integrator, who shared its vocabulary and its assumptions. You could design every screen for that one reader and be right.

A SaaS has a crowd. The same platform gets opened by a facilities operator who lives in the OT world, an energy manager chasing kWh and ringgit, a sustainability officer thinking in carbon and Scope 3, an executive who wants one number and a direction, and sometimes a tenant who only wants their bill explained. The same data underneath, completely different jobs sitting on top. It's a big reason CobiNeural resists being filed as a plain BMS or EMS, which we get into in what it actually is.

That was the design problem we kept circling. Build it for the engineer and the energy manager drowns in points she doesn't care about. Build it for the manager and the engineer finds it shallow, stops trusting it, and goes back to the panel. There's no single screen that serves all of them at once, and pretending there is gets you a tool that's almost right for everyone and genuinely right for no one. Our hardest calls were not technical. They were about whose mental model a given view should be built around, and how to let the other audiences in without breaking it for the first.

How we tried to build for both

We haven't fully solved this, and I'm not sure it's the kind of thing you finish. But the shape of the answer stayed consistent.

Keep what the OT world already trusts. The structure mirrors how a building person thinks: locations, then equipment, then sensors, with the ability to drill all the way down to the real reading from the real device. The engineer can always reach the actual number, and the abstraction sits on top of the physical rather than replacing it. That's the foundation under turning data into decisions without losing the people who know the building best.

Let the same data wear different faces. Instead of one screen for everyone, the same underlying figures are framed differently by role and job scope: energy insights for the energy manager, sustainability and reporting for the ESG officer, a headline and a direction for the executive, equipment and alerts for the operator. The numbers don't change with the audience. The framing does.

Make it answerable in plain language. Not everyone speaks "point," and not everyone should have to. Letting people simply ask the building a question, which is what CobiBot is for, lowers the barrier for the users who arrived from the management and IT side rather than the plant floor.

Leave control where it belongs. The deterministic, reliability-critical control stays at the edge, in the systems OT already trusts, while the software iterates above it without putting the building at risk. That edge and cloud split is half an engineering decision and half a peace treaty between two cultures.

The real lesson

Joining OT and IT is usually sold as a data-integration problem. Build the product from the inside and you learn it's a translation problem between people. The hardest thing we're building isn't the pipeline that carries a reading from a sensor to a screen. It's software that is genuinely native to two cultures that don't share a language, built from the OT side, which means earning the IT-era things, multi-user, role-aware, always improving, without giving up the OT things, trust, the physical, reliability.

We're not finished, and I doubt that work ever fully ends, because every new kind of user shows up speaking a slightly different dialect. But it reframed how we think about what we're making. A Smart Operation Platform isn't really a tool for managing buildings. It's a tool for letting very different people manage the same building together, without each having to learn the others' language first.

If you live on one side of this divide and have always found the other hard to read, that gap is exactly what we're building CobiNeural to close. Come and have a look, and tell us whether it speaks your language.