The recording is finally out, and honestly, it’s one of the best things we’ve put our names on. So this is mostly a “just go and watch it” post. But we’ll give you the highlights first.

Stand up if this sounds familiar

We opened the session the way we open most conversations about IT and OT: by asking a room full of people to admit how much it hurts.

Everyone stood up. Then we asked them to sit down the moment a statement stopped applying to them.

• You’ve waited more than three months for a network change request.

• You’ve had to drive to site at 11pm because remote access decided not to work.

• You’ve had to explain that no, ChatGPT is not going to run the plant next year.

• You’ve had to tell IT they can’t “just patch” that server.

By the end, almost nobody was still standing. Which was exactly the point: everyone in that room already works at the intersection of IT and OT, whether their job title says so or not.

The Oprah moment

Then came the part David has apparently been rehearsing for his whole career 😀

Three years ago, David told Willem: “Instead of just writing blog posts, let’s write a book. Shouldn’t take more than six months.” It took two years longer than planned. But on that stage, in front of everyone, we handed out early copies of the finished book before we’d even seen a printed one ourselves.

David’s reaction to handing out exclusive copies is the kind of thing you have to watch rather than have described to you. Turns out this is what an Oprah moment looks like when it’s two Belgian engineers on stage instead of a daytime talk show host giving away cars 😂

Why this is the video to watch on cooperation

Here’s the more serious reason to watch, though. If you want the clearest version yet of how we think about IT/OT cooperation, this talk is it.

We told the story of Patrick, an engineer at one of your plants who wanted to swap paper SOPs and inspection rounds for tablets. Cheap, sensible, no reason it shouldn’t happen by Friday. Except it needed a wifi password, and the moment IT and OT actually had to talk to each other about that password, everything slowed to a crawl. A ticket here, a “please open a request” there, a scope discussion that outlived the original problem. By the time anyone had agreed on anything, the tablets were still sitting in a box, wrapped in plastic.

Patrick’s story isn’t really about tablets. It’s about what happens when an organisation only knows how to handle two kinds of work: routine tickets, or capital-P Projects. If your request doesn’t fit either box, you’re stuck, no matter how sensible it is.

We also walked through why this is a management problem, not a Patrick problem. Operations optimises for cost and output at the plant level, IT optimises for security and scalability across the whole organisation, and both are right on their own terms; that’s the shared-goals gap. Then there’s no system of cooperation sitting between “file a ticket” and “start a project,” so anything in between falls through the cracks. And because nobody has invested in the technical foundations that would let small projects reuse what already exists, every one of them starts from zero, which makes each one slower and more expensive than it needs to be.

Your cooperation language

From there we introduced the three dimensions that actually determine how IT and OT need to work together on any given problem: work coupling, system coupling, and change velocity. How dependent are you on the other side to get anything done, how tightly are your systems wired into theirs, and how fast do you need to be able to change your mind?

Get a read on those three and you can start recognising which cooperation pattern you’re actually operating in, from silos, to shadow teams, all the way to long-lived, cross-functional product teams. In the talk we zoomed in on one in particular: Facilitation. If Patrick’s organisation had someone whose actual job was to build a bridge between IT and OT, without changing the org chart, this story plays out very differently, and probably ends a few weeks later with tablets that are actually switched on.

What to actually do about it

We closed with three things you can start doing tomorrow, no management mandate required.

1. Meet each other. Organise a site visit. Most IT and OT people have never actually seen where the other one works, and most managers won’t prioritise fixing that for you.

2. Ask the right questions on every project: what happens after go-live, and who do I call when it breaks? Questions like that expose the gaps before they become Patrick’s problem.

3. Facilitate without asking permission. You don’t need a mandate to start having better conversations with the people on the other side of the IT/OT boundary. It’s low-risk, low-cost, and it’s the fastest way to stop waiting for “the organisation” to fix this for you.

Patrick would thank you.

If Patrick’s story hit close to home, we go a lot deeper on cooperation models in the IT/OT Handbook. Pre-order now and register to claim your bonuses, including a free cooperation masterclass and cheat sheet (pre-orders really help us to beat the Amazon Algorithm Overlords 🙂).

📘 Pre-order the IT/OT Handbook now (+ claim the bonuses!) →

And really a last call: this is your final chance to join the next ITOT.Academy cohort, kicking off September 18 with an updated programme.

🙋 Join the ITOT.Academy (new cohort in September) →

Willem & David

• We’ve started recording “What is…” videos. Short pieces explaining foundational concepts in our own words. This article is the first one.

• You asked for more technical depth, and we’re delivering: late September we’re launching our IT/OT Builds, a series where vendors walk through how their software solves real architectural challenges (we use the typicals we also use in our ITOT.Academy).

• Also on popular request: yes, you can hire us to help pave the path towards your Data Platform/AI project or to just smoothen the relationship with the other side. We’re working on a dedicated page and offer, but feel free to reach out to David if you’d like to explore that further or take a look here.

This article is our first “What is…”, and what better place to start than the question that gave this whole publication its name: What is IT/OT convergence?

IT/OT convergence.

The term was coined around the same time Industry 4.0 was introduced, and it’s also one of the most misunderstood ones in our field. So what is IT/OT convergence, why does everyone keep talking about it, and (more usefully) why does the conversation keep changing shape?

The What: Two Kinds of Convergence

IT/OT convergence is not one thing. There’s a technical side and an organisational side, and conflating the two is where most confusion — and most stalled initiatives — begins.

Technical convergence is the easier one to picture, especially if you’re an engineer. Fifteen, twenty years ago, IT and OT ran on genuinely different technology stacks: different networking, different protocols, different everything. Industry 4.0 brought the idea of reusing IT’s off-the-shelf technology inside the OT world too — Windows-based servers, standard networking components, a slow migration away from proprietary fieldbuses towards TCP/IP. Today, that side of the story is close to being solved. There’s no shortage of vendors and integration options; getting two networks to talk to each other is no longer the bottleneck it used to be.

Organisational convergence is the harder one, and it’s the one that actually explains why “convergence” projects stall. It doesn’t mean collapsing IT and OT into a single org chart or a single team — that’s a common, and unhelpful, misreading. What it actually requires is cooperation between two genuinely technical departments, each with its own expertise, its own instincts, and its own comfort zone. Neither side sets out to start a turf war. But when two skilled, self-sufficient technical groups suddenly have to share ground, friction shows up whether anyone intends it or not. Getting this right is less about restructuring and more about designing how the two sides actually work together — which is exactly why “Cooperate” is one of the three pillars our Book and Academy curriculum are built around, and not just a nice word on a mission statement.

The Why: Three Waves

Understanding the what only gets you so far. The more interesting question is why we’re still having this conversation, years after Industry 4.0 first promised to make it a non-issue. The answer is that IT/OT convergence hasn’t been one conversation, it’s been three, arriving in waves, each one building on the last rather than replacing it.

Wave 1: Infrastructure Convergence

This was the first wave, and it’s largely the story told above: shared infrastructure, standard networking, machine-to-machine (M2M) communication, the shift from serial fieldbuses to TCP/IP. It’s the wave that made everything after it possible — and, as we said, it’s the one that today feels genuinely close to done. Pick a good vendor, and the plumbing works.

Wave 2: Cybersecurity Convergence (or: the need for it)

Connectivity is never free.

The moment industrial systems started talking to enterprise networks and unfortunately sometimes the open internet, the obscurity that used to pass for OT security disappeared with it. For years, OT systems were “safe” mostly because they were boring: proprietary protocols nobody outside the plant understood, specialised hardware, and simply nothing worth stealing. Attackers went after credit card numbers and corporate secrets, not steam crackers and water pumps.

That changed. Stuxnet, in 2009, is the incident most people know — a targeted attack that physically damaged centrifuges in an Iranian enrichment facility by compromising the automation layer. It wasn’t the last of its kind: the 2015 attack on the Ukrainian power grid cut electricity to hundreds of thousands of people, and in 2017 Trisis went after industrial safety systems specifically — the one layer everyone assumed was untouchable. More recent incidents like Pipedream/Industroyer2 and FrostyGoop have kept targeting OT protocols directly.

But the headline-grabbing, nation-state-grade attacks aren’t actually the bigger risk for most manufacturers. Petya and WannaCry, in 2016 and 2017, weren’t built to target factories at all — they were IT ransomware that spread indiscriminately, and OT became collateral damage. Production lines went dark, hospitals lost access to equipment, and none of it happened because anyone was specifically after a plant. It happened because the plant was connected, and modern malware doesn’t check intent before it spreads.

That’s the problem we face: most OT security planning is built to stop the next Stuxnet, when the more realistic threat is the next WannaCry — one outdated laptop, plugged into the wrong network segment. And notice this wave isn’t purely technical either. Firewalls and network segmentation only get you so far if IT security and OT security are still run as two separate organisations with two separate policies.

Attackers don’t care about your org chart, so increasingly, neither can your security strategy.

Wave 3: Data & AI Convergence

Which brings us to where we are today. Industrial data itself isn’t new: OT data has been actively used for the better part of a decade. What’s new is AI acting as an accelerator, putting fresh pressure on the data foundation underneath it: how it’s structured, contextualised, and made scalable enough for AI use cases to move past a single proof of concept.

Here’s the thing about that “AI-first” framing, though: most organisations are still figuring out what AI actually means for them, while the data side of the equation is largely ignored. We know what good data structuring, ontology and context could look like. The technical challenge is bringing that data together in a way that’s centralised and scalable across IT and OT, so applications — AI or otherwise — can actually be built on top of it.

And once again, this isn’t purely a technical exercise. Bringing the technology together also means bringing the teams together, which loops straight back to organisational convergence: who owns this data — IT, OT, or some newly formed data team — and how do the people responsible for it actually cooperate, day to day?

So, Is IT/OT Convergence Real?

Here’s the pattern across all three waves: every wave starts as a technical story and ends up being an organisational one.

• Infrastructure convergence made it possible for IT and OT to share a network — and then made it necessary for them to share responsibility for what runs on it.

• Cybersecurity convergence made it possible to attack both sides of the business at once — and then made it necessary to stop treating IT and OT security as separate disciplines.

• Data and AI convergence is making it possible to build one data foundation across both worlds — and it will make it necessary to figure out, organisationally, who’s accountable for it.

That’s really the answer to “what is IT/OT convergence”: it’s not a single project you finish, and it’s not primarily a technology purchase. It’s an ongoing pattern of two technical worlds discovering, wave after wave, that they need each other more than either side originally expected.

If you’re waiting for the moment when convergence is “done,” you’ll be waiting a while — we wrote about that illusion in a previous article, Ceci n’est pas IT/OT Convergence and in much more detail in our IT/OT Handbook.

Talk soon, Willem & David

Subscribe now

Shareable image:

Bob is the CEO and co-founder of Thred, and before that he spent twenty-five years in continuous improvement consulting: walking into manufacturing businesses, watching them fumble to measure themselves properly, and slowly realising that the real obstacle was never the sensor. It was context. Or rather, the almost total absence of it once you got past a folder structure.

That’s the conversation we wanted to have: not “what is a knowledge graph” as a product pitch, but what ontology actually means once you’re standing in a plant, and why the word has suddenly gone from academic curiosity to something everyone in industrial data seems to be talking about.

What do we even mean by “ontology” here?

It’s a word that gets thrown around with a lot of confidence and not much shared understanding. Strip away the philosophy department connotations and, in an industrial context, an ontology is simply this: a formal way of saying how things relate to each other, and what those relationships mean.

Most plants already have something that looks like an ontology. It’s usually a tag hierarchy — Enterprise, Site, Area, Line, Unit, tag — built in a historian or an asset framework. Every data point gets an address. It’s genuinely useful. It gives you navigation, rollups, and consistent templating, and it’s why an engineer can find “L15.B1.T01A.PV” without knowing offhand that it’s a temperature sensor in the baking oven.

But a hierarchy only knows one kind of relationship: parent and child.

As Bob put it, that’s a bit like trying to understand who someone is purely by knowing who their parents are. It tells you where something sits. It tells you nothing about how it behaves, what it depends on, or what breaks when it fails.

Most plants aren’t trees. A heat exchanger might serve three separate production lines that live in three different branches of your hierarchy. Your CIP (Cleaning In Place) circuit touches equipment across departments that, organisationally, have nothing to do with each other. A batch recipe routes material through a sequence of physical units that changes depending on which product is running that week. None of that fits neatly into a parent-child box, so it gets smuggled in through naming conventions, duplicate tags, or someone’s memory. Which is fine, until that someone retires.

A knowledge graph doesn’t replace the hierarchy. It sits alongside it and does the thing hierarchies were never built to do: it treats relationships as first-class citizens. A tank isn’t just part of Line 3. It also feeds a reactor, is cleaned by a specific CIP circuit, and shares a utility header with the tank next door. The hierarchy is still in there. It’s just one relationship type among many, instead of the only one the model can express.

That distinction is the whole ballgame, because it’s the difference between a model you can browse and a model you can actually interrogate.

Modelled or discovered?

Do you model your ontology up front, or let it emerge through use?
Bob’s answer: both, but start with the pain.

Some knowledge genuinely lives in documentation: PLC ladder logic, P&IDs, engineering drawings. That’s knowledge you can extract and formalise. But a large chunk of what actually explains a factory only surfaces when someone starts asking “why does this keep happening” and nobody has a clean answer. That’s discovered knowledge: hypotheses tested against evidence until they become known relationships in the graph.

What Bob pushed back hard on is the instinct to solve this with a grand, prescriptive modelling project (what he calls “boiling the ocean”). Build the perfect ontology, wait three years, then start finding value. He’s not dismissive of standards like ISA-95 (nobody sensible is), but he’s sceptical of treating them as a ceiling rather than a floor. His rule of thumb: clients buy painkillers, not multivitamins. You start where the pain is, and you let the ontology grow from there.

This is also, not coincidentally, exactly the pilot-purgatory trap we keep drawing on whiteboards in workshops. Teams take a shiny new tool for a spin without first doing the unglamorous work of defining why — and then can’t explain, two years later, what any of it was worth.

Democratising context, not just data

We spent the last five years in this industry talking about democratising data — self-service dashboards, citizen data science, all of it. Bob’s argument is that we solved the wrong problem. Access to raw tags was never really the bottleneck. Understanding what those tags mean in relation to each other is (to be honest: our take on this in our book is that there are two bottlenecks, the first one is getting to the data and the second one is contextualizing it).

His frustration, and it’s a fair one, is that ontology work usually gets handed to a small group of data scientists who then tell the rest of the organisation what their own plant means. That inverts who actually holds the knowledge. The fitter who’s been fighting the same recurring fault for three years, the operator who instinctively knows which alarm is real and which is noise. The tooling challenge, as Bob frames it, is building something that lets that knowledge get captured and validated where it’s created, rather than requiring it to be extracted, translated, and handed back down.

Doesn’t that just mean chaos with extra steps?

David raised the obvious objection: if you let people draw relationships freely, aren’t you just recreating the “everyone has their own Excel version of the truth” problem, except now it’s graphs instead of spreadsheets?

It’s a fair worry, and Bob didn’t wave it away. His answer is that freedom to explore relationships and rigour about which ones survive aren’t the same thing. Hypotheses get tested against evidence before they become part of the trusted model. The point isn’t “anything goes.” It’s that the alternative (the central team pre-defining every permissible relationship) guarantees you’ll miss the real, multi-causal reality of how failures actually happen on a shop floor.

Nail it, then scale it

Which brings us to the line that gave this episode its title: a really a cooperation point dressed up as a technology one. The debate over whether IT or OT should “own” the ontology is, in Bob’s view, the wrong debate entirely. Neither should. The organisations getting this right are the ones where a business problem sits in the room first, and IT and OT show up to solve it together. We couldn’t agree more and that’s why in our book, we have devoted the entire Part II to cooperation! Or as Bob says it:

“I love that part of your book in terms of framing how people try and organise OT and IT. It’s very, very useful. [..] Pattern 7 is probably the best that we have so far.”

The pattern he sees working, repeatedly: pick a real pain point, solve it small, quantify it, celebrate it loudly, then scale. The pattern he sees failing, just as repeatedly: a large central team spending years building a comprehensive model with no wins on the board (at which point the blame game starts, because nobody can point to what any of it delivered).

Success has many fathers. Failure is an orphan. Bob didn’t invent that line, but it’s hard to find a better one-sentence summary of why nailing something small, visibly, beats modelling something vast, invisibly.

Stay Tuned for More!

🙋 Join the ITOT.Academy (new cohort in September) →
📘 Pre-order the IT/OT Handbook (+ claim the bonuses!) →

Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence.

Subscribe now

🚀 See you in the next episode!

Youtube: https://www.youtube.com/@TheITOTInsider
Apple Podcasts:

Spotify Podcasts:

Disclaimer: The views and opinions expressed in this interview are those of the interviewee and do not necessarily reflect the official policy or position of The IT/OT Insider. This content is provided for informational purposes only and should not be seen as an endorsement by The IT/OT Insider of any products, services, or strategies discussed. We encourage our readers and listeners to consider the information presented and make their own informed decisions.

Two years ago, roughly every second booth at Hannover Messe had the word “AI” on it. This year the tone has shifted. Less about the layer you buy, more about the outcome you’re trying to deliver. That shift is what Vatsal Shah, co-founder and CEO of Litmus, came on the podcast to unpack. It’s also the first time he’d talked publicly about how Litmus rethought its own strategy around this idea. Coming from the CEO of one of the more established industrial data platforms, that’s worth paying attention to. (If Litmus is new to you, we covered them earlier with COO John Younes in our Industrial DataOps series, and wrote about their approach to consolidation in Fighting Entropy.)

The $1 trillion question nobody’s asking

Here’s the observation that reframed Litmus’ entire 2025 strategy.

“If you look at the manufacturing software market, it’s what, like $15 billion? How much is the manufacturing labour market? A trillion dollars plus. It’s a hundred times the software market.”
— Vatsal Shah

Vatsal’s numbers, not ours, but the ratio is what matters. Every industrial data vendor has been fighting for a share of that small software pie. Meanwhile the vastly bigger prize sits behind a wall we’ve barely tried to cross.

To be clear: this isn’t about replacing labour. “In no shape or form can AI replace human workers right now,” Vatsal said, and we agree. We’d add something we’ve argued for a while: in most manufacturing environments today, the constraint isn’t too many operators, it’s not finding enough skilled ones.

So the question isn’t “how do we cut headcount?” It’s “how do we make the people we have more effective?”

The Industrial Data Catalog: an old idea, new to the plant floor

You can’t get to outcomes without the plumbing. Ask a CIO how many databases they run and you’ll get an answer. Ask a plant leader how many PLCs, which historian versions, which SCADA systems — and past fifty sites, the honest answer is often I don’t know.

Data catalogs are a well-worn concept in IT. Vatsal’s claim is that Litmus is the first to bring one to the operational side: every data logger, historian, database, CNC machine — listed on a single interface, for humans on compliance duty and for AI agents as a source of context. Without the catalog, an LLM answering questions on top of plant data was landing at around 85% accuracy in Vatsal’s internal tests. With the catalog providing metadata and context, it jumped to roughly 97%. We haven’t independently benchmarked those figures, but the direction is what everyone building agents on industrial data will run into: garbage in, garbage out — and “garbage” here mostly means no context.

The most concrete example in the conversation came from pharma. A C-level exec, asked what burns his people out, named documentation — batch changes, recipe adjustments, quality fixes, all audit-critical, all soul-destroying. Offer them an agent that generates auditor-ready documentation from the underlying data continuously, and the response is “shut up and take my money.” Vatsal was honest about the follow-up: the agent doesn’t yet work to the 30–40% quality bar it needs, because the data, context and integration aren’t there yet. That’s the case for putting the foundation right. Rush the agent, and you’ve got another disappointed pilot.

You can check the catalog offering here: litmus.io/litmus-data-catalog.

Stop buying tools. Start buying outcomes.

Roughly halfway through, we asked the crystal-ball question: what should the industry actually do next? Vatsal’s answer was refreshingly non-vendor-y for someone running a leading platform:

“I’m CEO of one of the leading data technology companies out there, but even I’m thinking we need to get out of platform mindset and start thinking outcomes mindset.”

His three non-negotiable foundations:

1. Own your data. Edge or cloud, but you own it. Don’t hand it back to OEMs.

2. Document your processes in a way both the next generation of engineers and AI agents can consume.

3. Cybersecurity. A resilient perimeter isn’t optional.

Everything else — the agents, the LLMs, the specific tools — sits on top. This is where most manufacturers go sideways, buying point solutions the way they’ve been buying pumps and valves for fifty years. It’s the same argument for a platformed approach we’ve made elsewhere on scaling: without it, you don’t get repeatable value, and adding people or systems slows you down instead of speeding you up.

Vatsal turns the tables: how close is IT/OT convergence?

Halfway through, Vatsal flipped the script and asked David a question (a genuinely good one 😀): “How close are we to real IT/OT convergence?”

Short answer: technically closer than we’ve ever been, organisationally still a long way off.

Technical convergence is happening almost everywhere — cloud, containers, DataOps, AI on top. The operational data platform is the layer where IT and OT actually meet. The organisational side is where the speed gets lost. Without collaborative ways of working, no amount of technical convergence delivers the pace the business wants. The lessons from The Phoenix Project aren’t a one-to-one match with IT/OT, but they’re close enough that they transfer.

The pattern Vatsal described — pulling motivated talent from IT and OT into a single Industry 4.0 or Data Transformation team — is one we’ve seen work. It’s also one we’ve flagged with a warning in our upcoming book: if you’re not careful, that team becomes a third silo. Great internally, disconnected from the plants it’s meant to serve. There are ways around it, but it takes intent.

Vatsal’s closing line on this was, we think, exactly right: in a world where every technology is evolving rapidly, adaptability matters more than any specific choice — and that means building a culture where mistakes are treated as learning, not as career-ending events.

Final thoughts

First: the shift from platform to outcome is genuinely happening — and it’s now coming from platform vendors themselves, not just analysts. That’s a healthier signal than another wave of AI-branded booths.

Second: the foundation still matters. Vatsal isn’t saying “skip the platform.” He’s saying stop selling it as if it were the point. The platform is what makes the outcome affordable, repeatable, and scalable. Skip the foundation and the agents don’t work. Skip the outcome and the foundation looks like cost.

Own your data.
Document your processes.
Get the perimeter right.
Then figure out which 10% of somebody’s day you can genuinely give them back.

Stay Tuned for More!

🙋 Join the ITOT.Academy (new cohort in September) →
📘 Pre-order the IT/OT Handbook (+ claim the bonuses!) →

Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence.

🚀 See you in the next episode!

Youtube: https://www.youtube.com/@TheITOTInsider
Apple Podcasts:

Spotify Podcasts:

Disclaimer: The views and opinions expressed in this interview are those of the interviewee and do not necessarily reflect the official policy or position of The IT/OT Insider. This content is provided for informational purposes only and should not be seen as an endorsement by The IT/OT Insider of any products, services, or strategies discussed. We encourage our readers and listeners to consider the information presented and make their own informed decisions.

(*) At the IT/OT Insider we do value our independence and transparency. So as we look for ways to pay the bills we were looking for ways to work with sponsors without giving up on those principles. This is where the idea of sponsors comes from. Together with a few selected sponsors we’ll explore some topics that we both find interesting in the same way we write our normal articles. In the coming weeks you’ll find a couple of pieces that have been sponsored. Feel free to contact us if you are interested in a partnership as well.

This article is a small map pointing you to our best content. It is for readers who want the bigger picture, and for those of you who arrived recently and are wondering where on earth to start.

📣 A quick reminder before we start: our next ITOT.Academy cohort kicks off in September, and the early bird offer ends on 24 July. Want to join our fifth group and learn how to bridge IT and OT? There is no better time than now.
👉 Check the curriculum and enrol via ITOT.Academy.

Where the structure came from

When we started writing, we honestly did not know what we were doing. We knew we wanted to write about IT/OT things. Beyond that, we improvised.

The idea of writing a book is roughly as old as the blog itself, and it forced a question we had been happily avoiding: what is the actual shape of this? What comes first, what comes second, and why?

The answer turned out to be three steps: Understand, Cooperate, Scale. It is the framework this blog, the Handbook and the Academy are all built on. Not because it sounds neat, but because in that order our work actually holds together 😀.

Step 1: Understand

Every transformation runs on trust, and a bridge between IT and OT is no exception. Trust begins with IT genuinely understanding Operations and Operational Technology and Operations and OT genuinely understanding IT. Not just who these people are and the world they work in, but what each of them needs in order to be good at their job.

Do this properly and the requests start arriving on their own, from every direction. Can you help me get more throughput out of my lines? Can you help me meet these new cyber security guidelines? That is the moment you know understanding has landed: nobody has to sell the collaboration any more.

Start reading here:

• The IT and OT view on data (Part 1)

• ISA-95 and the Purdue Model explained

• Ceci n’est pas IT/OT convergence

• Let’s talk Manufacturing Execution Systems

Step 2: Cooperate

Understanding each other is necessary but not sufficient. To make progress, you have to work together and cooperation takes wildly different shapes depending on what you are trying to do. It might be three people in a corner building a pilot nobody asked for. It might be an enterprise platform team keeping the company’s core data infrastructure alive around the clock. Both are cooperation. They are not remotely the same thing.

This is where we make those formats tangible: the organisational maturity stages, how to get started, and how your organisation should evolve as the complexity of the work grows. Only once you have found a way of working together does it make sense to step into the technical and solution domain.

Start here:

• IT/OT Cooperation Models

• IT/OT Cooperation Models: A Field Guide

• Ceci n’est pas IT/OT convergence

⚠️ A note on these: they are still relevant, but the articles are partly out of date. Our thinking has moved on considerably and now lives in the IT/OT Handbook. Updated articles will follow over the coming months. In the meantime, if you have already ordered the book, do not forget to register for the bonuses: there is a new cooperation masterclass and a cooperation cheat sheet, both available immediately.

Step 3: Scale and Sustain

Groundwork done, it is time to execute! This is where technology finally enters the conversation. Start small. Solve a real, immediate problem with something practical. Then scale that success until it becomes the way the organisation works.

The tension here is permanent: short-term wins versus long-term vision. Lean too far towards the wins and you accumulate a graveyard of clever one-offs. Lean too far towards the vision and you spend two years building a platform nobody uses. What you need is a way to select, implement and scale data initiatives that survives contact with an industrial environment.

We have collected everything on scaling, data platforms and UNS on this dedicated landing page: itotinsider.com/operational-data-platform.

The essentials:

• Industrial Data Platform Capability Map (v2)

• What I don’t like about UNS

• The Digital Journey Model

• Where do I start? A three-step framework (free workshop guide)

The one chart you really need to understand about scaling:

This chart is explained in full here: https://itotinsider.com/operational-data-platform/

Why our framework is a loop, not a ladder

Each step builds on the one before it, a bit like levelling up in a video game: you do not get to fight the final boss before you have learned to move. Everyone knows this. Plenty of organisations still try to skip straight to buying a platform nobody asked for.

But getting through the three steps once is not the finish line. Digital transformation is not a project with a start date, an end date and a closing slide. It is a cycle. Done well, every solution you deliver sparks the next idea, and the whole thing starts again with deeper understanding, stronger cooperation, and broader scale each time round.

That is also why we do not think you ever really “arrive”. You just get better at going round.

And this is what it looks like as a book…

The IT/OT Handbook is that framework, worked out properly and at length, with the case studies, the diagnostics and the practical detail that a blog post can never quite carry. Its three parts map straight onto the three steps.

Part I: Understanding the Challenge is for everyone: practitioner, leader, vendor, integrator, consultant. It introduces the three groups whose collaboration decides everything (Operations, OT, IT), traces how we got here (the era of happy silos, the years when IT scaled globally while OT converged vertically, and today’s data convergence), and looks hard at why organisations get stuck: the CIO–COO disconnect, the reality that Operations always comes first, and the warning signs of divergence.

Part II: Cooperation Patterns is where the cooperation models you know from the blog have grown up. It starts with the DevOps precedent with a proof that warring technical tribes can learn to work together, because IT already did it once. Then come the seven patterns, from complete silos through shadow teams and facilitation to product teams, with a clear view of when each one works and when it fails. It closes with how to move between patterns, brought to life through the Halifax Water case study.

Part III: Building the Technical Foundation is the technical half: why operational data is genuinely different from IT data, why so many initiatives stall on that difference, what capabilities a real industrial data platform needs, and how to define your goal, start small and evolve without turning today’s solution into tomorrow’s legacy. We walk it through end to end at a (fictionalised, but very real) waffle manufacturer called Sweet Harmony Treats.

Want to learn more?

• 🙋 Join the ITOT.Academy — new cohort in September, early bird ends 24 July

• 📘 Pre-order The IT/OT Handbook and claim the bonuses

Subscribe now

In this article: new group starts on September 18, all you need to know about our changed (!) programme, and what our first 100 students had to say :)

A quick note while we have you:
Our IT/OT Handbook ships early October (more on that in the coming weeks), and if you pre-order today via itotbook.com or Amazon, it genuinely helps us get the book distributed across the globe. Pre-ordering also gets you into our virtual launch event in October, plus immediate access to our Cooperation Patterns Cheat Sheet and the 30-minute Cooperation Masterclass.
(You do need to register your pre-order via the form on our site)

Right, back to the IT/OT Academy…

Next group starts September 18

This is the formal announcement: our next cohort kicks off on September 18, and we’ve rebuilt the programme based on four rounds of feedback.

The biggest change is what we cut.

We used to spend real time on theory in the live sessions. Now that’s handled upfront via recorded videos to review before each session. That means that the live time goes entirely to deep-dives, Q&A, real-world examples, and, importantly, networking and peer knowledge-sharing. We’ve also added a completely new session where we live-map architectural typicals together (more on that below), and because not every question fits into a group setting, every participant now gets a complimentary 1-hour private session with David.

What you get

• 11 hours of remote, live, instructor-led learning

• 1 hour private session with David to work through your own problems

• Full session recordings, delivered the next day in case you can’t attend

• A network of peers and industry experts to keep leaning on after the cohort ends

• + Slide decks, extra masterclasses, worksheets, and a stack of bonus resources

• + Complementary access to the recordings of all previous guest sessions

Curious what a seat looks like in practice?

→ Explore the full programme

Why our first 100 joined

We asked why people joined, and the same four reasons kept coming back.

• Understand the other side
  This is the most shared piece of feedback, by far. IT wants to understand OT’s constraints, OT wants to understand IT’s. Put both in the same (virtual) room, and the conversations get interesting fast.

• Learn from peers, not vendors
  People want to know how other companies are actually solving the same problems. Not what a vendor recommends in a sales deck. Peer learning across industries is a bigger draw than we expected.

• Make better decisions
  A lot of our attendees are moving into, or already sit in, architecture and leadership roles. They come away with usable frameworks for buy-vs-build, data architecture, platform choices, and organisational design.

• Understand why projects actually fail
  Ownership issues, governance gaps, IT/OT conflicts, local-vs-global tensions… these themes surface again and again. Our participants want the root causes, not just another list of symptoms.

The IT/OT Academy is trusted by learners from

The updated programme

• Session 1 — Understand + Cooperate (2h)
  Why IT and OT see the world so differently, and what to do about it. We start by getting to know each other and the industries in the room, then move into the divergence trap, the CIO–COO disconnect, and IT/OT cooperation: how do you actually engineer an organisation that can handle this complexity?

• Session 2 — Data Platform Architectures (2h)
  Data architectures, data modelling, and the Unified Namespace. Historian vs broker (or do you need both?). Time series vs events (or do you need both?). Plus the technical and organisational blockers that get in the way of scaling.

• Session 3 — Architectural Typicals (2h)
  A highly interactive session where we draw architectural typicals for different industries and needs, pull apart diagrams from well-known vendors, and use our capability map to find their strengths and weaknesses.

• Session 4 — Sweet Harmony Treats (3h)
  Meet your playground: Sweet Harmony Treats, a large industrial bakery known for dangerously delicious waffles. You’ll step into both IT and OT shoes to digitise their operations without breaking what already works: analysing challenges, mapping opportunities, and co-creating an architecture and digital roadmap with your cohort. The first two hours are group work, the last hour is feedback.

• Session 5 — Practitioner Panel + Q&A (2h)
  Experienced industry leaders join to share how they’ve actually applied these principles under real pressure: what organisational models look like when it counts, what DataOps really looks like on the factory floor. Space to network, challenge ideas, and connect directly with people shaping this space. And even better, you get access to all previous practitioner panels as well!

• Private session — Ask David Anything (1h)
  An on-demand, 1-hour slot with David to work through your specific questions and problems: technical, organizational or just personal career coaching.

What people are saying

“Stepping into a new role in the IT/OT space, the IT/OT Academy was a fantastic experience to quickly get into the subject and understand the complexities in this area. It covered the technological, organisational and human aspects of when two different worlds meet. The content was well-structured and practical, and the wealth of experience from the instructors, guest speakers, and participants was impressive.”
Linda Rothan-Cederberg, Manufacturing Digital & IT Product Portfolio Manager, Electrolux Group

“The IT/OT Academy is a great resource for people trying to solve problems and build solutions in the real-world overlap between IT and OT organisations and technologies. Refreshingly free from buzzwords and vendor hype, it’s by practitioners, for practitioners.”
Adam O’Gorman, Lead Architect – OT/IT Convergence, Stegra

“I recently completed the IT/OT Academy, and it was an incredible experience. Collaborating with engineers and automation experts on real-world challenges gave me fresh insights that directly shaped my recent talk on overcoming data silos and driving digital transformation. Big thanks to David and Willem for creating such a valuable space to learn and connect.”
Jessica Dillon, Channel Account Manager, Software Toolbox

More stories like these are to be found in our Hall of Fame.

Is the Academy for you?

• In IT?
  Why is it that working with operations is so hard, and how come they don’t simply put their data in the data lake and get it over with. You’ll learn what makes OT different from IT and how to talk the talk and earn their trust.

• In OT or Operations?
  You know your systems, but Cloud, UNS design, and data pipelines feel like moving targets. You want a data architecture that goes beyond buzzwords, a clear read on when a UNS actually makes sense, and ways to cultivate a real partnership with IT.

• A technology vendor?
  Your tech is good, but the CIO loves your cloud pitch while the plant manager rolls their eyes. You want to design for both domains, speak the right language in the boardroom, and find your champions earlier. And maybe that next prospect was one of your fellow students!

• An SI or consultant?
  Your clients expect you to guide them through the IT/OT maze, but the strategy often feels fuzzy and delivery fragile. You want to structure projects with confidence, avoid the cultural clashes that sink them, and back it with credibility.

If any of that sounds familiar, the next cohort starts 18 September. Spots are limited to 40 to keep the sessions properly interactive.

→ Grab your seat via ITOT.Academy

(Questions? Use the chat button on itot.academy, send David an email or a DM)

It’s episode 50 (🎉) of the podcast, and we’re only now getting to IIoT platforms. We sat down with Jürgen Krämer, Chief Product Officer and Managing Director at Cumulocity. Cumulocity is an IIoT platform with currently more than 25 million connected devices, three billion messages processed per day, and a roster of customers that includes wind energy operators, healthcare devices, and crane manufacturers.

Jürgen has been in the IoT and analytics space for over 20 years, which means he’s lived through every wave of the hype cycle and that made our conversation another super interesting one! He also knows that the term “IoT” is notoriously elastic: it gets applied to everything from smart lawnmowers to offshore wind farms, and that ambiguity is a genuine problem when you’re trying to make a technology decision.

So time to demystify some concepts around (I)IoT Platforms!

IIoT Platform vs Historian

We’ve written before about the power of the process historian, and in a typical manufacturing or process plant, the historian is genuinely well-suited. It is designed for high-density time-series capture in a controlled, physical environment where you own the network, the devices are close together, and the architecture is well understood.

The moment you move to distributed assets out in the world: in customers’ facilities, on wind farms, on construction sites, in buildings, data centers, and so many others… the picture changes entirely.

Because in those cases, you don’t own the network. You have no physical access. You’re managing connectivity across 30,000 turbines in a dozen countries. Firmware updates need to happen over the air. Security is paramount because the device is sitting inside someone else’s infrastructure.

That is where the IIoT platform becomes the right tool.
As Jürgen puts it:

“You need to connect and manage devices you don’t control, in environments you’ve never seen, at a scale that makes manual management impossible.”

The M2M → IIoT → AIoT evolution

Time for a history lesson!

The first wave, around 2010, was M2M (machine-to-machine). It was essentially about connectivity: get the device online, manage the firmware, enable remote access. Useful, but narrow.

The IIoT era, roughly 2015 to 2024, added the layer above: dashboards, analytics, edge computing, application enablement. Operations became more optimised, but the work was still largely human-centric. An alert would fire, and a technician would spend hours diagnosing the situation (reviewing log files, cross-referencing documentation, forming a hypothesis).

AIoT (what Cumulocity now positions itself as) is the next step. The vision is that the agent does the diagnosis. The technician receives a package: probable bearing failure on Pump 4, replacement part ordered, repair guide attached, shutdown recommended at 14:00, awaiting your approval. The human is still in the loop, but the cognitive labour of diagnosis shifts from the person to the system.

We’ve used the term “virtual operator” in previous articles. This is what it could look like in practice (obviously given the availability of enough data, context and the right understanding of the physical reality!)

The part most people still skip: Context

Context is the most important thing to get right today. It’s the answer to scaling, it’s the answer to UNS, it’s a necessity for AI. And thus we’d encourage you to slow down here.

Every AI initiative in industry eventually runs into the same wall: raw telemetry is not enough. A value arriving every second from a sensor labelled “Reg_004” means nothing to an LLM, and very little to a human who didn’t configure that tag. Feed that data stream to an AI agent without context, and you will get hallucinations. Jürgen’s team has run this experiment directly: same query, without and with a semantic layer. Without it: plausible-looking KPIs that are simply fabricated. With it: accurate, actionable results (take a look at the result in this video).

What does context actually mean here?
Jürgen describes three layers:

• The first is the system of record — the secure, scalable, mission-critical foundation. This is not exciting, but it is load-bearing. You do not rebuild it from scratch.

• The second is the semantic layer. This is what makes industrial data AI-ready. It includes the metadata (is this temperature reading in Celsius or Fahrenheit? what are the normal ranges? when was the sensor last replaced?), the alarm history, the maintenance documentation, and critically: the asset hierarchy. This sensor belongs to this component, which is part of this pump, which sits in this production line, in this plant. Without that hierarchy, you cannot roll up to a meaningful OEE calculation. Without that context, the AI agent is just pattern-matching on noise.

• The third layer is the agentic layer — where the AI agents operate, with access to the semantic layer as their knowledge base.

There is a parallel here worth naming. We’ve argued for years that industrial DataOps — getting data clean, contextualised, and accessible — is foundational work that pays off for humans first and AI second. Jürgen made the same point: companies that invested in a proper semantic layer years ago, for human operators, got a head start. They built the infrastructure that now, with AI on top, is worth considerably more than they probably expected.

Should you vibe-code your own IIoT platform?

The short answer is no.
The longer answer is: it depends what you mean.

David raised the question that’s circulating everywhere right now: with AI-assisted development, can’t we just build our own platform? It’s a reasonable thing to ask, given that a motivated developer with a good LLM can now scaffold something that looks functional in a weekend.

The problem is in the word “looks.”

The system of record layer — the part that manages tens of thousands of devices, handles over-the-air firmware updates, maintains security compliance in a post-NIS2 world, and operates at 24/7 SLAs — is mission-critical infrastructure. Generating a million lines of code with an AI framework and then being responsible for operating it against contractual uptime commitments is not a viable strategy. As David put it:

“Who takes responsibility when things go sideways — not just on availability, but on cybersecurity and supply chain risk?”

Jürgen’s distinction is worth keeping: AI-assisted development is genuinely useful at the application layer — building custom dashboards, tuning models on your own data, accelerating vertical use case development. It is not a substitute for a proven platform at the foundation.

We’ve watched this cycle before. The Excel macro era, the Access database era, the no-code/low-code era — each one produced a generation of fragile, undocumented tools that someone had to maintain long after the person who built them had moved on. AI-assisted development is the new version of this pattern. Some of what gets built will be excellent. Much of it will become technical debt.

The strategic question remains the same as it always has: where does your competitive advantage actually live?
(Probably not in having built your own secure, scalable data foundation from scratch)

Finding the right use case is harder than it looks

Cumulocity has seen hundreds of deployments — predictive maintenance, asset performance management, remote service operations, cybersecurity compliance — and the consistent failure mode is enterprises that start by playing with the technology rather than by defining the business outcome.

The right starting point is not “what can we do with AI?” It is “where do we get the most leverage from our investment?” Those are different questions, and the second one is harder to answer without experience.

Cumulocity is offering a free one-day consulting workshop for organisations that want to identify their best starting point for an AIoT journey. If you prefer to get your hands on the platform directly, there is also a free trial at cumulocity.com. On our side, the workshop assessment framework we use in our own engagements is available at itotinsider.com.

About Cumulocity

Cumulocity is the leading independent AIoT platform, built to bridge the gap between IT and OT. We empower equipment manufacturers and distributed asset operators to securely connect, manage, and extract value from millions of devices on a global scale. From remote device management to industrial DataOps and AI-ready semantic models, Cumulocity provides the mission-critical foundation needed to turn raw telemetry into actionable intelligence; and securely close the loop by executing remote commands, updates, and automated actions right back at the edge.

Learn more about Cumulocity

Stay Tuned for More!

🙋 Join the ITOT.Academy (new cohort in September) →
📘 Pre-order the IT/OT Handbook (+ claim the bonuses!) →

Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence.

Subscribe now

🚀 See you in the next episode!

Youtube: https://www.youtube.com/@TheITOTInsider
Apple Podcasts:

Spotify Podcasts:

(*) At the IT/OT Insider we do value our independence and transparency. So as we look for ways to pay the bills we were looking for ways to work with sponsors without giving up on those principles. This is where the idea of sponsors comes from. Together with a few selected sponsors we’ll explore some topics that we both find interesting in the same way we write our normal articles. In the coming weeks you’ll find a couple of pieces that have been sponsored. Feel free to contact us if you are interested in a partnership as well.

Before we start…

We started our 4th IT/OT Academy two weeks ago. Last week and this week we’ll talk about architectural typicals for different use cases, dissect vendor diagrams and step into organizational dynamics with our Cooperation Models. All while our students can network and learn from each other.

The next Academy kicks off September 18 and our early bird offer is open. Are you interested in joining? Claim your seat early enough, because the first registrations are already in 🙂

🙋 Join the ITOT.Academy (new cohort in September) →

And… have you already pre-ordered our IT/OT Handbook?
If so, don’t forget to register to receive your exclusive bonuses.
📘 Pre-order the IT/OT Handbook now (+ claim the bonuses!) →

Andreas Vogler crossed paths with us at Hannover Messe this year. We all know that moment of “I know your face, I know your name”... and a few weeks later, here we are. Andreas is the Chief Innovation Officer at ETM, the Siemens subsidiary behind WinCC Open Architecture, one of the major SCADA systems in industrial automation.

Some years ago, Andreas already built a project called Automation Gateway. A colleague once described it as a collection of open source pieces stitched together and called it Frankenstein of Automation. When he wanted to learn more about MQTT, he built his own broker (which we think is pretty awesome 👍) and the name almost wrote itself: Frankenstein’s monster. MonsterMQ.

(If you’re new to MQTT and want a solid grounding before diving in, we covered the protocol in depth in our episode with Kudzai Manditereza.)

From broker to MQTT+

The first version of MonsterMQ had no UI. Configuration files only because that was the fastest way to get it working.

Then AI coding arrived. First GitHub Copilot (hat strange experience of typing a line of code and having it suggest the next one) and eventually more capable agentic tools. Suddenly he could build dashboards. He pulled connectivity features from the Automation Gateway: PLC4X integration for direct PLC communication, database backends (PostgreSQL, MongoDB, SQLite), workflow engines and later also AI agents.

What MonsterMQ has become today is probably best described as ‘MQTT+’. A broker, but also a connectivity layer, a persistence layer, and increasingly an intelligent edge runtime.

Andreas runs it at home. He has photovoltaic panels, a jacuzzi, a collection of sensors, and an agent inside the broker that checks every 30 minutes whether it makes sense to run the jacuzzi heater. “It tells me: now is a good time.” Practical. A little nerdy. Completely in character.

Open source in industrial settings

MonsterMQ is fully open source and is not a Siemens or ETM product.
It’s Andreas’s project.

And that’s where it gets interesting for anyone thinking about adopting it in a production environment. Companies come to him, they like what they see, and then they ask: can I get a support contract?

Subscribe now

The answer right now is no.

That’s not a criticism; it’s just the reality of where the project is. Andreas is aware of it. He’s had those conversations. The EU’s Cyber Resilience Act adds another layer: if you’re supplying software to European companies, there are obligations around development process, supply chain and security disclosure, just to name a few. This purely open source side project isn’t yet set up to meet those requirements.

None of that makes MonsterMQ unsuitable for exploration or for production grade use, as long as you have the needed skills in-house. But if you’re planning to put it at the heart of a production line, go in with your eyes open. Know what you’re taking on.

Vibe coding and the architect problem

Andreas has been through the full arc of AI coding (or Vibe coding).

Early on, he reviewed every line the AI produced: checking that new code landed in the right class, in the right file, that nothing unnecessary was created. These days, for personal tools like a custom MQTT explorer he built, he doesn’t look at the source code at all. “I don’t care. It works.”

But for MonsterMQ itself the standard is different. The human has to remain the architect. Someone needs to know what they want, where it belongs, and whether what was generated is actually doing the right thing.

AI coding doesn’t remove the need for expertise. It changes where that expertise matters. You need less of it in the execution and more of it in the direction.

The ProveIT demo of WinCC Open Architecture with AI-driven engineering (where an engineer can give the system a Modbus device specification and have it configure the driver automatically) shows where this is heading for industrial software.

Faster, yes. But the engineer still has to understand what they’re asking for.

Contribute or follow along

MonsterMQ is on GitHub. Andreas would welcome contributors. He actually met one of them in person at Hannover for the first time, which he described as “a cool experience.” The project has a demo server, a dashboard, and an active development roadmap.

What happens next with MonsterMQ, whether it stays purely open source or evolves into something with commercial backing, is genuinely open. Andreas isn’t ruling anything out.

Find Andreas on LinkedIn and the project at monstermq.com.

Stay Tuned for More!

🙋 Join the ITOT.Academy (new cohort in September) →
📘 Pre-order the IT/OT Handbook (+ claim the bonuses!) →

Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence.

🚀 See you in the next episode!

Youtube: https://www.youtube.com/@TheITOTInsider
Apple Podcasts:

Spotify Podcasts:

Before we start…
We just started our 4th IT/OT Academy last week.
The next one kicks off September 18 and our early bird offer is open. Are you interested in joining? Claim your seat early enough, because the first registrations are already in 🙂

🙋 Join the ITOT.Academy (new cohort in September) →

And… have you already pre-ordered our IT/OT Handbook? If so, don’t forget to register to receive your exclusive bonuses.
📘 Pre-order the IT/OT Handbook now (+ claim the bonuses!) →

Welcome to another episode of the IT/OT Insider Podcast!

We sat down to talk about i3X with John Dyck, CEO, and Jonathan Wise, Chief Technology Architect at CESMII. CESMII is a US not-for-profit consortium, federally funded by the Department of Energy, with a clear mission: make smart manufacturing accessible for all manufacturers, not just the ones with deep pockets and dedicated engineering teams.

Fifty projects. One persistent frustration.

Before CESMII built anything, they watched. Jonathan’s team ran or supported roughly fifty smart manufacturing projects with US manufacturers — small facilities getting their first sensors connected, large enterprises with decades of automation behind them. Across all of them, the same pattern appeared: interoperability was never designed in.

Not because anyone was careless. The mindset across much of the industry — especially in the US, as Jonathan puts it — is to find the problem in front of you, fix it, and move on. The result is what he describes as a patchwork quilt: software layers brought in at different times to solve different problems, never built to work together, often arriving through acquisition. You end up with deeply heterogeneous architectures where nobody — and no system — has a shared understanding of the data.

Out of those fifty projects, CESMII extracted valuable lessons. Jonathan’s team identified three things that had to be true for manufacturing data to be genuinely usable across systems. They called them the Smart Manufacturing Imperatives. The first two set the foundation. The third is where i3X comes in.

The 3 Smart Manufacturing Imperatives

The first imperative is about information modelling.
Before data can travel, it needs to mean something. CESMII calls this Information Model Standardisation — an open, standards-based approach to describing manufacturing devices, assets and processes consistently. They’ve built this out through their Smart Manufacturing Profiles: a library of reusable, community-maintained models that give manufacturers a head start rather than asking everyone to start from scratch.

The second imperative is about the platform layer that sits on top of those models.
A Contextual Manufacturing Information Platform — a clear set of requirements for what any serious industrial data platform needs to support in order to enable application interoperability. If that sounds familiar, it should: it maps closely to what we’ve described in our own Industrial Data Platform Capability Map. The capabilities required are broadly the same. The language is different, but the thinking converges.

The third imperative is having an open and common API to get to all data in context.
Even with shared models and capable platforms, applications still can’t talk to each other if every vendor exposes their data through a different API. i3X — the Industrial Information Interoperability eXchange — is CESMII’s answer to that: an open, common API for manufacturing systems that enables rapid application development, AI deployments, Edge AI, and supply chain integration. We’d go further and say it might also be the answer to something we’ve been asking since we published our Capability Map: what does Capability 7, Data Sharing, actually look like in practice?

What i3X is

i3X is a vendor-agnostic, open API specification that any manufacturing information platform can implement, regardless of what’s running underneath. It is not a platform. It doesn’t tell you how to build your system. It defines the surface your system needs to expose: typed data, live and historical access through a consistent structure, hierarchical organisation that can expand into a full graph of relationships.

Explore CESMII’s interactive visualization here: https://i3x.dev/viz/

Explore the API endpoints and try them out yourself via https://api.i3x.dev/v1/docs

To make all of this even more accessible, CESMII released i3X Explorer: a free test client that lets you load your implementation and see exactly which functions are covered and which aren’t. Whether you’re a developer building a platform or an engineer specifying a project, it gives you a concrete view of where you stand.

At the ProveIT event in Dallas, six vendors demonstrated live interoperability against i3X on the same stage, (Aron Semle from HighByte who joined us on the podcast a few weeks ago is one of them). Take a look at the full recording here:

Why it matters beyond the API.

The bigger picture, as John frames it, is democratisation. If the API is common, a developer or an AI model built against i3X works across any compliant platform. That changes the economics entirely — especially for small and medium manufacturers who can’t afford to rebuild integrations for every environment they deploy into. It also opens up genuine innovation: build once, run anywhere, learn fast, iterate.

For manufacturers, the practical message is simple. Start asking your vendors whether they support i3X. If they don’t, ask why. The vendor community has shown it’s willing to move when customers ask for it.

The big question for the coming years now becomes:
Will this one stick?
So…. to be continued 🙂

Extra Resources

• i3X specification: https://www.i3x.dev

• i3X on GitHub: https://github.com/cesmii/i3X

• Our HighByte episode with Aron Semle: https://itotinsider.substack.com/p/aron-semle-on-mcp-agents-and-the

Stay Tuned for More!

🙋 Join the ITOT.Academy (new cohort in September) →
📘 Pre-order the IT/OT Handbook (+ claim the bonuses!) →

Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence.

Subscribe now

🚀 See you in the next episode!

Youtube: https://www.youtube.com/@TheITOTInsider
Apple Podcasts:

Spotify Podcasts:

There’s a lot of discussion about using AI in industrial environments.

On one side: proponents claiming this technology changes everything. You need to embrace it fast or you risk being out-innovated.
On the other side: the dangers seem so large that even thinking about using it in production means certain doom.
So why not leave it to IT to play with their new tools??

This probably sounds familiar to many. We’ve had exactly the same debates with cloud computing, wireless IIoT sensors, machine learning and before that even Advanced Process Control (APC).

Every new technology comes with unknowns.

And if there’s one thing engineers don’t like, it’s handing control to something they don’t fully understand. (We’re convinced the decision to give SkyNet the launch codes was made by a politician, not a control engineer ;))

Can We Learn From History?

Why is it that these tech savvy engineers aren’t jumping on every new technology?
Is it because they’re just conservative old-timers resistant to change?

We’re not denying that there is a little bit of that with some of them, but at the core the issue comes from the difference between IT and OT, the virtual and the physical.

In IT when your prediction goes sideways, the impact is a wrong product suggestion or some other form of revenue loss. In a plant you’re talking about equipment damage, regulatory issues, injury and even death.

That means that whatever we do in an operational context needs to be explainable. To operators, for them to trust the system, but equally important to regulators (especially after an incident has happened)

For APC, this journey took almost 30 years to move from “interesting idea” to “trusted, closed-loop optimiser.”

Let’s trace that evolution and see what it teaches us.

The Trust Ladder (with APC as an example)

A story about trust…

• Phase 1: Read-Only (1970s) Model-based control started when engineers in petrochemical plants ran simulations on mainframes to determine setpoints. These simulations took hours, the idea of real time control was outlandish at the time. Instead, they served as additional information for engineers and operators. The algorithm watched the process. Operators watched the algorithm. There was no interaction with the real world that didn’t involve a human operator. This gave everyone freedom to experiment and validate. What works? What doesn’t?

• Phase 2: Recommendation (mid-1980s–early 1990s) Faster computers enabled near-real-time APC running alongside the DCS. The logical next step: APC giving live proposals. “Increase temperature by 5°C. Lower reflux ratio by 2%.” Initially, these “black boxes” weren’t trusted. How could they replace hundreds of years of combined control room experience? Most operators simply overrode the recommendations. But over time, trust grew. The models were actually performing.

• Phase 3: Limited Autonomy (1990s) A huge step. Instead of humans making every decision, APC was allowed to directly modify system parameters, but only within narrow bounds and on a limited scope! Soon we discovered that over time models tend to drift off and model maintenance came to the forefront. Engineers learned from this failure that closed-loop requires continuous model care.

• Phase 4: Supervised Autonomy (2000s–today) APC now runs 24/7 on thousands of units worldwide. Operators trust it but still have override authority. Some plants run “lights-out” optimisation overnight, with operators reviewing in the morning.

Let’s use this analogy and apply it to where Industrial AI stands today:

Most industrial AI is still in Phase 1—observing, predicting, learning patterns. We’re seeing the first steps into Phase 2, where AI actively recommends actions based on your systems.

Moving to Phase 3 and 4 requires earning trust at each step. Just like APC, AI will need to prove itself before it’s given more autonomy.

This is where Industrial AI platforms have to prove themselves.

In a market prone to overpromising, the platforms that actually fulfill that promise do so by embedding where real work happens on the frontline. The vendors who succeed there and help teams move through the progression of autonomy, offloading unnecessary work and finding new opportunities for improvement, ultimately earn their trust.

TwinThread was founded with that reality in mind. The platform was created by people with decades of experience in the same roles as the teams it serves. They understand that operators and engineers only trust tools that fit into existing systems, follow a responsible acceptance progression, solve real problems, respect operational guardrails, and make daily work easier without adding new risk.

That shows up across the TwinThread platform. Predictive analytics allow teams to observe, anticipate, and understand performance issues earlier. Prescriptive recommendations guide better decisions. And where trust has been earned through adoption, evidence, and guardrails, closed-loop adjustment helps teams standardize execution and continuously improve performance.

These capabilities give teams a legitimate path to scaling this new technology: start with a focused use case, prove value quickly, and expand into deeper integrations as trust grows.

The Example (Hill’s Pet Food)

Hill’s Pet Food is a good example of this in action.

Within Hill’s, TwinThread deployed quality optimization models through edge agents connected to their existing AVEVA (Wonderware) Historian and AVEVA MES. The models predicted end-of-line product quality and recommended startup changes. Rapidly, Hills targeted and hit ideal conditions for each quality parameter in each run.

As adoption grew, TwinThread also captured and digitized onsite operator expertise. They embedded best practices back into both startup and in-run quality work processes. That reinforced trust in the system and eventually helped Hill’s reach closed-loop operations.

The project’s impact was substantial. Hill’s scaled the quality optimization framework across their entire enterprise, improving CpK across several critical quality measures—while significantly reducing material loss.

This happened even as average operator tenure was cut in half. Despite that, with a digitally mature, closed-loop solution, less experienced operators still delivered consistent, on-target performance. It’s a testament to how Industrial AI, when done right, can preserve tribal knowledge, orchestrate optimal production, and drive measurable value at scale.

The question isn’t whether AI will close the loop in industrial operations. It’s how fast it can earn the right.

The Trust Ladder isn’t new. It’s how every control technology has proven itself—from the first PID controller to modern APC. AI is on the same journey.

The only question is: where does your application sit on that ladder?

About TwinThread

TwinThread is the world’s first complete Industrial AI Platform built to amplify human expertise and optimize legacy systems. Through Predictive, Prescriptive, Generative, and Agentic AI, we enable operations teams to anticipate issues, accelerate problem-solving, and innovate on a single line or across global operations. With over 1 million digital twins, nearly 50 million sensors, and 2 million AI models deployed, TwinThread is proven to deliver scalable AI, maximize ROI, minimize downtime and provide continuous value.

More about TwinThread

Stay Tuned for More!

🙋 Join the ITOT.Academy (new cohort in September) →
📘 Pre-order the IT/OT Handbook (+ claim the bonuses!) →

Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence.

Subscribe now

(*) At the IT/OT Insider we do value our independence and transparency. So as we look for ways to pay the bills we were looking for ways to work with sponsors without giving up on those principles. This is where the idea of sponsors comes from. Together with a few selected sponsors we’ll explore some topics that we both find interesting in the same way we write our normal articles. Feel free to contact us if you are interested in a partnership as well.

Image to share:

Back to our regular schedule, finally. Hannover Messe is in the rear-view mirror, the noise is fading, and we’re easing into one podcast a week again. To get us going, we sat down with Kevin Jones, Director of Partner and Product Strategy at dataPARC, for a conversation that took us all the way back to 1981 — and somehow ended up in a control room in the southeastern US, in the middle of the night, with a piece of black paper taped to a screen.

Meet Kevin (and dataPARC)

Kevin has spent 26 years at the same company. That’s not a typo. He’s worked on industrial data from every angle imaginable — applications, advanced process control, and for the last two decades, the data architecture and management layer underneath it all.

dataPARC itself is a 150-person, globally-distributed team that has stayed laser-focused on one thing: the industrial data stack. Connecting it. Storing it. Moving it between systems. Making it usable for analytics. As Kevin puts it, they’ve thought about expanding into other parts of the business over the years — and consciously decided not to.

“That’s been our focus from day one. We just work with industrial plants on their data stack.”

In a market where every vendor seems to be drifting into AI, into platforms, into “the data fabric for everything,” that kind of discipline is increasingly rare. And it’s exactly why this conversation went deep on the part of the architecture that gets the least attention but does the most heavy lifting: the historian.

What actually makes a historian

It’s tempting, especially if you come from the IT side, to assume any modern database can do the job. Why not just dump time-series data in a data lake and let the hyperscaler figure it out?

Kevin’s answer is one we’ll be borrowing for years.

“We were once in a meeting where one of the hyperscalers was advertising a use case. They said, ‘we stored 500 values and did all these great things.’ In the industrial world, a big fish tank can have 500 data points.”

Industrial historians aren’t dealing with thousands of data points. They’re dealing with thousands to millions of signals, sampled at up to millisecond frequency, retained for years. And — crucially — they’re built so that when an engineer says, give me a thousand tags for the last twelve months because I want to run a machine learning experiment, the answer comes back in seconds, not hours. That’s an architectural decision, not a configuration setting.

The other point worth flagging: the cloud-first mindset often forgets the egress side of the equation. Getting data into a cloud system is cheap. Pulling it back out, repeatedly, to compute weighted averages or run rolling analytics, can become eye-wateringly expensive very quickly.

From sensor data to semantic layer

Time-series data alone isn’t enough, and dataPARC realised this early. Their first commercial historian already had the basics of an asset model — process areas, an organising structure, a way to actually find data without knowing the cryptic tag name.

That principle has only grown more important.

With AI and large language models entering the picture, the semantic layer is no longer a “nice to have” for analytics teams. It’s the thing that determines whether your AI is repeatable or not.

“If we can have a good semantic layer, we can be more repeatable. The use cases are really prevalent and it’s becoming just as important as ever.”

Which, of course, brings us to the term that’s been impossible to avoid for the past two years: Unified Namespace.

Kevin’s view here is one we share. There’s a broad definition of UNS — having a universal, semantic naming for everything in your enterprise — and a narrower, more branded one that essentially says “MQTT broker on top of your data.” The broad version is foundational. The narrow version, on its own, gives you the most recent value. Useful, but limited.

“What happens if there’s a problem with this main flow pump? When did it start? Was it now, or did it start on the night shift? You want to look at your history. So having that universal semantic layer is key — but it should give you the current value and the historical values and be useful when you point a machine learning model at it.”

Closing thoughts

Forty-something years on from that first homegrown historian at Georgia Pacific, the historian has been declared dead more times than we can count. And every time, it has come back not as a relic but as something more central than before.

That’s because, as Kevin put it, all the AI in the world is only as good as the data feeding it. And the data feeding it has to be time-series, has to be contextualised, has to be reliable, and has to be retrievable on demand. Whatever you call that layer of your architecture — historian, time-series database, operational data store — the function isn’t going anywhere.

The harder, less glamorous truth is the human one. The piece of black paper taped over a monitor in the middle of the night is a more honest snapshot of where most plants are than any maturity model. Operators have already done the analysis in their heads. They’ve already decided what matters. The job of every IT/OT team is to listen to that, codify it, and build systems that respect it.

If your historian is doing its job, the next 2am phone call should be a sign of trust, not failure.

About DataParc

Founded in 1997, dataPARC is a comprehensive industrial analytics software suite that helps process manufacturers optimize operations, boost productivity, and drive sustainability. Featuring an enterprise data historian, embedded analytics, and tools for real-time data monitoring, trending, and reporting, dataPARC empowers manufacturers to make smarter, faster decisions that positively impact the bottom line. dataPARC serves customers across the process industries with deployments at thousands of sites globally.

More about dataPARC

Stay Tuned for More!

🙋 Join the ITOT.Academy (new cohort in September) →
📘 Pre-order the IT/OT Handbook (+ claim the bonuses!) →

Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence.

Subscribe now

🚀 See you in the next episode!

Youtube: https://www.youtube.com/@TheITOTInsider
Apple Podcasts:

Spotify Podcasts:

(*) At the IT/OT Insider we do value our independence and transparency. So as we look for ways to pay the bills we were looking for ways to work with sponsors without giving up on those principles. This is where the idea of sponsors comes from. Together with a few selected sponsors we’ll explore some topics that we both find interesting in the same way we write our normal articles. In the coming weeks you’ll find a couple of pieces that have been sponsored. Feel free to contact us if you are interested in a partnership as well.

But, for today, let’s start with what NIS2 is.

It isn’t a new standard or recommendation from a professional body. NIS2 or “Network and Information Security Directive” was adopted in the EU parliament in 2023 and describes what laws the member-countries need to implement to elevate the level of cybersecurity across the EU. At the moment of writing the law has been implemented in 21 of the EU27.

Unlike its older brother, NIS, NIS2 goes wider and deeper.

• Wider because it now targets all manufacturing organizations, not just strategic ones like utilities.

• Deeper because unlike NIS, the measures and requirements of NIS2 cover more scope, have higher fines (up to 2% of global annual turnover) and make C-level management personally liable in case of gross negligence.

That still doesn’t answer the question why this becomes your problem as a non cybersecurity and (probably) non C-level person. Just let the cybersecurity folks do what they need to do right?

Well, the addition of a single phrase expands the scope of NIS2 from your typical IT scope to every production site: NIS2 aims not only to protect your data and IT systems but the physical environment as well. This (non-accidental) addition means that systems that control your shopfloor are in scope: your SCADA, MES and even your HMI and PLC are now part of NIS2 scope.

If you want even more proof that the walls between IT and OT are becoming thinner, look no further. Thinking that you’re safe with a DMZ between level 3 and 4 and having the Purdue model implemented in your networks is simply not going to cut it anymore.

True, you won’t be audited, but your EU customers might. The directive explicitly requires companies to take a look at their entire supply chain and how it impacts their cybersecurity risks. Your customers must assess who they buy from, what security practices those suppliers have, and whether vulnerabilities in their supply chain could affect their own operations. That means a components manufacturer in the US supplying EU automotive or energy companies will find their security practices scrutinised by their own customers. Expect questionnaires, contractual security requirements, and requests for proof. NIS2 doesn’t need to apply to you directly to change what’s expected of you.

So we have personal liability of the CEO, huge fines, impact on the shopfloor and requirements that will propagate down the supply chain across the globe. But what exactly must be done? We saved you the time of going through the directive and picked out 4 elements that matter to you (don’t be afraid to check the official texts, it isn’t as scary as you’d expect)

The company’s management carries the responsibility for the cybersecurity governance : They must approve and oversee the measures that are set in place. That means that the moment they ask whether the organization is compliant and what the gaps are they’ll need a response and actions from IT and OT. (Chapter IV, Article 20)

Cybersecurity risk management measures are the ‘what you must do’ items on the list, and they’re not separated neatly in IT and OT categories. Some of them are broad and don’t make distinction between shopfloor and corporate IT systems like multifactor authentication requirements. And others require a concerted effort to set up business continuity plans and incident response plans where both IT and OT must work together. We’ll cover those in more depth in a follow-up article (Chapter IV, Article 21)

Reporting Obligations: Your organization has the obligation to report serious incidents in strict timelines: 24 hours for an early warning, 72 hours for full notification, one month for a final report. Those deadlines don’t care about IT or OT silos. (Chapter IV, Article 23)

Supervision & enforcement: Auditors can come in and start requesting evidence whether you’ve properly implemented and enforced the 10 measures. And while most IT organizations are already used to that, most plants would find it hard to come up with a complete asset inventory on the spot, have documented disaster recovery exercises or prove how MFA is implemented in their entire landscape. (Chapter VII)

Of those four, the risk management measures are the most interesting to us. In the next Cyber Security article we’ll go deeper into them and find where the IT/OT boundary makes each one harder to implement than it looks on paper.

Subscribe now

In this Mini Insider: our Hannover takeaway, the IT/OT Handbook, an article on AI we wrote for IT Revolution, and what’s coming next.

What we heard at Hannover Messe

Last year, we both walked away with the same feeling: most vendors were just slapping “AI” stickers on their existing products. Data was still in the conversation, but AI was the headline.

This year, AI is still everywhere, but the conversation has moved more towards real applications.

Literally every vendor now has some way to expose data as an MCP server. Well… we’ve yet have to meet an operator who’s planning to ask questions to a chatbot. But we get it: this is part of the maturity curve. (Btw: we did a podcast on MCP with Aron Semle a few weeks ago, and we’ve got one on i3X coming soon.)

What stood out most: a lot more talk about a scalable data foundation — and crucially, the discussion is starting to shift towards “we need the right context, the right ontology”. Which makes us happy, because that’s exactly the critique David put out in his article a while back: “What I (don’t) like about UNS”.

On the other hand, the technology is there. What we’re still missing is discipline, and an organization capable of delivering. Jon Smart describes it like this in the foreword he wrote for our book:

“The most important improvements are rarely purely technical. They are social, behavioral, and human. Our behaviors determine our outcomes. If we want outcomes to improve, behaviors must change. Making the most of each successive technology-led revolution is, therefore, both a social and technical endeavor. My own rule of thumb is that improving outcomes is roughly 80% behavior and 20% technology or processes.”

—Jonathan Smart, author of Sooner Safer Happier

(as you might have guessed, our Book and Academy are mostly focussed on the organizational stuff 🎉)

Beyond that, we had dozens of great meet-ups.
Thank you to everyone who came to say hi 🙂

The IT/OT Handbook is almost here

As you most likely saw, we announced the IT/OT Handbook at Hannover Messe. We gave away a seat in the Academy to the first person to show us their pre-order on the spot. HighByte also gave away another Academy seat through their competition, so if you entered, stay tuned ;)

If you’ve already pre-ordered our book — like Raf and Kudzai in the pictures below — make sure to register at itotbook.com to claim the bonus content and get access to our exclusive launch event in October.

We also recorded a new announcement video:

And we received these kind words from Evan Kaplan, CEO at InfluxData (and a previous podcast guest):

“David and Willem have written a practical guide to one of the hardest problems in industry today: getting IT and OT to actually work together…. This book stands out because it connects this organizational shift to the technical foundation required to make it real. It’s a clear, actionable path to building systems that scale and turning data into action.”

— Evan Kaplan, CEO at InfluxData

We wrote for IT Revolution

Speaking of the publisher: we published a piece on the IT Revolution blog called Two Problems Standing Between You and Industrial AI at Scale. If you’re trying to figure out why your AI pilots keep stalling before they reach production, this one’s for you.

Read it here

What’s coming in the next few weeks

We’re starting a new ITOT.Academy group on May 22 (you can still register). Here are some posts by the participants in our January group:

We’re stepping into industrial cybersecurity. Willem already has two articles on NIS2 in the pipeline. Since not everyone reading this works in cyber, chances are NIS2 is one of those acronyms you’ve heard but never really had to engage with. The next two articles will give you a high-level view of what it means for you as an IT/OT professional — without the legal jargon. Later on, we’ll also be telling some of the stories that shaped the OT cybersecurity narrative in the podcast. Some of them are genuinely fascinating.

On top of that; coming out soon:

• “Earning The Right To Close The Loop in Industrial AI” — written together with TwinThread.

• A deep dive on Historians — coming up with dataParc.

• An episode on IoT platforms — with Cumulocity.

Plenty in the oven.

Until next week!

— David & Willem

We wrote a book.
Not just a book.
The IT/OT Handbook.

You can pre-order it today. It ships in October.
(And if you order now and send us proof, we’ve lined up a few extras you’ll actually want)

📣 Quick reminder before we dive in: our next ITOT.Academy cohort kicks off in May, and there are only two early-bird seats left at the time of writing. If you’ve been on the fence, this is the moment.
👉 Check the curriculum & enrol via ITOT.Academy

Why we wrote it

After more than a decade of Industry 4.0, digital twins, and now industrial AI, it’s easy to feel like everyone else has figured it out and you’re the one lagging behind.

You’re not.

Most companies still can’t scale past their first two flashy pilots — let alone bridge the gap between IT and OT in a way that actually sticks.

Two years ago, we went looking for a book that showed the full picture: how technology, organisational dynamics, cooperation patterns and culture all link together on the shopfloor. We didn’t find it. So we wrote one ourselves.

The IT/OT Handbook is the result. Two years of research. Hundreds of conversations with practitioners. Everything we’ve learned across decades digitalising chemicals, food & beverage, and critical infrastructure — distilled into the three-step framework we wish someone had handed us on day one.

“David and Willem have put together a ‘must read’ for anyone who works at or near the intersection of IT and OT. The book provides helpful, practical and actionable insights that you’ll be able to apply to your own efforts right away.”

—Rick Bullotta, Investor, Former Co-founder and CTO at ThingWorx, Former CTO at Wonderware

The framework: Understand, Cooperate, Scale

Three steps. No shortcuts (and technology only comes third ;))

Understand. Before you can bridge the gap between IT and OT, you need to understand what actually makes them different. Not the surface-level stuff — the real differences in constraints, assumptions, cycles and mental models. Most of the friction on your projects has its roots here. Name it, and a lot of your everyday problems suddenly make sense.

Cooperate. Understanding alone won’t move the needle. But neither will a poster telling people to “collaborate more”. We walk you through seven cooperation patterns — from ad-hoc pilot teams to enterprise-wide product organisations — with their strengths, their weaknesses, and the pitfalls we’ve seen kill them. These patterns give you vocabulary you’ll use for years. They turn fluffy conversations about “working better together” into something tangible.

Scale & Sustain. This is where most companies get stuck — the infamous pilot purgatory. You’ll learn why operational data is fundamentally different from IT data, how to build a platform that compounds value instead of collapsing under its own weight, where UNS fits (and where it doesn’t), why context matters more than any specific tool, and how to recognise — and push through — the plateau that always comes.

“The IT/OT Handbook promises to be everything and more than the author’s blog and podcast is. Based on hands-on experience, thorough analysis and critical evaluation, it points to a world where after many years of stagnation we can finally move forward, making industrial production better, safer, more efficient.”

—Margret Bauer, Professor of Process Automation, Hamburg University of Applied Sciences

Who we wrote it for

This book sits at the intersection of IT and OT. If you live anywhere near that line, there’s something in here for you.

IT & OT practitioners. Automation engineers, data scientists, plant IT managers, control-system specialists — the people actually implementing digital change on the shopfloor. You’ll get frameworks to navigate the organisational mess that usually kills your technical work, and the language to explain your problems upwards.

Operational & technology leaders. Plant managers, CIOs, CTOs, heads of manufacturing excellence — the people who fund, sponsor and scale these initiatives. You’ll understand why pilots stall, how to stop funding the same failure twice, and what it takes to make transformation stick.

Consultants & advisors. If you’re advising industrial clients on digital transformation, this is your playbook. Cooperation patterns, data platform architecture, organisational maturity models — all grounded in manufacturing reality, not a deck from last year’s conference.

Vendors & system integrators. If you deliver technology into industrial environments, you only ever see a slice of the picture. This book helps you understand the context your customers are actually operating in — and how to unblock the hidden factors that make or break your projects.

Pre-order now

Pick whichever is closest to you. Amazon ships globally. Barnes & Noble ships to most countries outside Europe.

North & South America

• Barnes & Noble (North + South America)

• Amazon.com US

• Bookshop.org US

• Amazon Canada

• Indigo Canada

Europe

• Amazon Belgium

• Netherlands: order via Amazon Germany

• Amazon Germany

• Amazon France

• Amazon Spain

• Saxo Denmark

Other Countries

• Barnes & Noble

• Amazon.com

• UK: currently only possible via Amazon.com

Claim your pre-order bonuses

If you pre-order through any online bookstore, we’d love to thank you properly. Upload your proof of purchase via itotbook.com and you’ll unlock:

→ An invitation to the exclusive virtual launch event in October, with speakers from both IT and OT. Limited to the first 100 pre-orders.

→ Our Cooperation Patterns Cheat Sheet — the one-pager version of Part II you can hang above your desk.

→ Access to our Cooperation Virtual Masterclass.

Two years of work. One book. Ready for you in October.

We genuinely can’t wait for you to read it :)

— Willem & David

In this episode of our podcast, David sits down (again 😀) with Aron Semle, CTO at HighByte, for a follow-up conversation roughly a year after our first podcast together.

A lot has changed in a year. When we last spoke, Industrial DataOps was still a concept many people needed convincing about. AI was already making waves, but the link between data foundations and AI readiness wasn’t as obvious to most manufacturing organisations as it is today. So where are we now? And where is the hype outpacing reality?

You can listen to the episode, or get the main ideas in this article!
Let’s get into it.

We Don’t Sell the Problem Anymore

The market conversation has shifted in the last year. “We don’t sell the problem anymore,” Aron says. “People understand the problem. We have customers and prospects coming to us saying: we know we need to clean up this data to get AI-ready.”

That’s a big shift. And it mirrors what we see at the IT/OT Insider as well. During the peak of the LLM hype, everyone wanted AI but nobody wanted to talk about foundations. Now? People come to us and say: we want AI, and therefore we need to build a foundation.

That loop is finally closing. And AI is the catalyst.

Sebastian from Frost & Sullivan, who presented at HighByte’s DataOps Days late last year, made the argument that AI and DataOps are coupled — hand in hand — and showed the market growing accordingly. He’s right.

Starting from Where You Are

So what does that foundation look like in practice?

Aron breaks it down using a digital maturity lens:

If you’ve got equipment with nothing connected and everything is manual, you’re not ready for AI on the factory floor. You need connectivity first — HMIs, SCADA, historians. If you’re at that level, you’re probably ready for the next step: Industrial DataOps.

The way HighByte positions it is straightforward. Industrial DataOps is not going to overlap with your existing systems that run the plant. It’s a layer you put on top — one that connects to all those systems, contextualises the data, and provides access to it from other consumers. AI being one of them.

The real work, though, is in harmonisation. “How do you consistently represent equipment that could be the same or completely different across facilities?” Aron asks. That’s the scalability piece. At one factory, the production order comes from an ERP or MES. At another, it’s a CSV file on someone’s desktop. If you’re consuming that data from AI — or from anything else — you shouldn’t need to know the difference.

UNS: Valuable, But It Was Always Just the Start

We couldn’t have this conversation without touching on Unified Namespace. And Aron’s perspective has matured in the same way the market has.

Five years ago, UNS was the start of DataOps at the edge: connect to everything, contextualise it, publish it to an MQTT broker. And for someone coming from nothing — like that bakery with independent machines and local HMIs everywhere — being able to subscribe to a broker and see the real-time state of the factory was genuinely transformative.

But now? Aron is candid: “Publishing to MQTT is just the transport of real-time data out. That strategy sticks around.”

With AI entering the picture, you also need historical data access, governance across multiple sites and contextual dimensions.

“It’s not that anything we did is nulled,” Aron clarifies. “It was the first step of the journey towards something bigger.”

LLMs and Agents: Let’s Demystify This

David pushes for definitions, and Aron delivers them with refreshing clarity.

• LLMs are the large neural networks most of us experience through chatbots. You put in a request, a response comes out. The context of the chat goes in each time (or a compressed version), and a new response is generated.

• Tool calling is when the LLM detects it can’t answer on its own and reaches out to external tools — this is where MCP comes into play.

• Agents are really just the code around the LLM. An agent is an LLM in a loop: instead of a human driving the conversation, the agent code handles tool calls, feeds results back into the context window, and decides when the task is done. How autonomous it is depends entirely on the code you write around that loop.

“But make no mistake about it,” Aron says. “We’re just building text documents and feeding them into a large language model. And then stuff comes out that’s sometimes in JSON format that we can code against. It’s not beyond that.”

LLMs are probabilistic. They’re hallucinating all the time and they just happen to be right a percentage of the time. In manufacturing, where determinism is fundamental, that’s a real constraint.

Now imagine that kind of confident hallucination in a pharmaceutical clean room. Or on a production line with multi-million-euro equipment.

“If we’re talking about fully autonomous agents that are going to get control of our machines — very bad idea,” Aron says flatly.

MCP: Getting Beat Up, But Here to Stay

MCP (Model Context Protocol) has had a steep rise — and Aron acknowledges it’s getting some backlash. That’s normal for anything with a sharp hype curve.

His take: “MCP is remote procedure calling for LLMs.“ It provides discovery, remote calling, and a bit of instruction in between. Where it gets criticised is by technologists who look at it and say: this should just be a REST API.

The funny thing? “If you go look at the latest version of MCP, it essentially is a REST API,” Aron says. “They got rid of server-sent events and it’s essentially an API now.”

The only scenario where MCP loses relevance, in Aron’s view, is if LLMs get good enough to call conventional APIs directly — and those APIs evolve to be more interaction-oriented rather than CRUD-style developer tools. But for HighByte, it doesn’t matter much either way: you’re still building the Industrial DataOps layer, the contextualisation, the custom pipelines. Whether the AI calls that via MCP or REST is an implementation detail.

What matters is that the tools are deterministic. “You define the MCP tool, its inputs, its outputs. If you get a call that’s trying to do SQL injection, you detect that and stop it with deterministic logic,” Aron explains. That’s why HighByte’s implementation was never a static, one-size-fits-all tool set. It’s designed so you build your own tools — like APIs — and control exactly what they do.

A Quick Teaser: i3X

We briefly touched on i3X, a new standard that Aron is heavily involved in alongside Jonathan Weiss and Matthew Paris. We won’t go into detail here — we’ll be recording a dedicated podcast with John Dyck and Jonathan Wise in the coming weeks — but the short version is this:

Aron sees i3X as a standardised API layer for the factory.

Every vendor already has APIs, but everyone does it their own way. If the industry can standardise how contextual data is accessed across vendors, it removes a massive amount of inefficiency.

“If cloud vendors step up and build clients for i3X, that is going to be the ingestion highway in and out of the factory,” Aron says. Version one of the spec is expected before the end of Q2 2026.

More in i3X in this podcast:

AI for DataOps: The Slider from Manual to Autonomous

Beyond using DataOps to feed AI (which is the foundation story), there’s the flip side: using AI to do DataOps faster.

HighByte’s latest release includes what they call a Pipeline AI Agent. Pipelines are their ETL tool for moving and transforming industrial data. The agent lets you prompt an LLM to analyse and edit pipeline configurations. What’s clever is the middle ground it occupies. Aron describes it as an AI slider:

On one end, fully manual — you know what you’re doing and you want full control. On the other end, full autonomy — let the AI handle it. The Pipeline AI Agent sits in between: human in the loop. You prompt it, the UI shows you inline what it edited, you review, accept or reject, and iterate.

This is where AI genuinely accelerates experts. Not by replacing them, but by handling the tedious parts so they can focus on what requires judgement. Give it a P&ID diagram, an Excel sheet, and access to an OPC server, and let it help you get started with contextualisation. Human in the loop to create deterministic output — absolutely needed — but accelerated by AI.

Wrapping Up

A year ago, we talked about Industrial DataOps as a discipline. Now it’s a recognised market segment. The conversation has shifted from “why do I need a data foundation?” to “how do I build one so AI can actually deliver?”

The takeaway from this conversation? The foundation hasn’t changed. The urgency has. And the hype-to-reality gap on agents and autonomous AI is still very wide. The vendors and practitioners who will win are the ones who are honest about where that gap lies — and focus on the use cases that deliver real value today.

HighByte will be at Hannover Messe 2026 (April 20-24) — look for Aron and his colleagues at the AWS, Siemens, and Microsoft booths.

Thanks for listening — and thanks to HighByte for sponsoring this one!

… and if you haven’t listened to the previous conversation we had with Aron, why not do it now?

About HighByte

HighByte is an industrial software company founded in 2018 in Portland, Maine USA. The company builds solutions that address the data architecture and integration challenges faced by manufacturers and industrial companies as they digitally transform. HighByte Intelligence Hub, the company’s proven Industrial DataOps software, provides modeled, ready-to-use data to the Cloud using a codeless interface to speed integration time and accelerate analytics. The Intelligence Hub has been deployed in more than a dozen countries by the world’s most innovative companies spanning a wide range of vertical markets, including automotive, energy, food and beverage, life sciences, and mining and metals.

Stay Tuned for More!

🚀 Join the ITOT.Academy (new cohort starts in May!) →

Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence.

Subscribe now

🚀 See you in the next episode!

Youtube: https://www.youtube.com/@TheITOTInsider
Apple Podcasts:

Spotify Podcasts:

(*) At the IT/OT Insider we do value our independence and transparency. So as we look for ways to pay the bills we were looking for ways to work with sponsors without giving up on those principles. This is where the idea of sponsors comes from. Together with a few selected sponsors we’ll explore some topics that we both find interesting in the same way we write our normal articles. In the coming weeks you’ll find a couple of pieces that have been sponsored. Feel free to contact us if you are interested in a partnership as well.

This week, we are publishing our hundredth piece of content.

Some are articles, some are podcasts (like this one). Every single one started with the same question: does this actually help someone working at the intersection of IT and OT?

To celebrate we sat down in the same room (David’s living room, to be precise) and hit record. No guest this time. Just the two of us, looking back at what we’ve built — and looking forward to what’s coming next.

Here’s what we talked about…

Our Favourite Podcasts

We’ve recorded roughly 40 conversations over the past two years, starting with Shiv Trisal from Databricks back in April 2024. Picking favourites is hard, but here we go:

Dan Jeavons on AI and Physics: If you’re drowning in “AI will change the world” marketing material, this one is the antidote. Dan takes a fundamentally different look at how AI can reshape manufacturing — not by adding chatbots to help files, but by understanding the physical world in ways that don’t require manually modelling every asset in the plant. It connects directly to the two problems standing between you and industrial AI we wrote about recently: the lack of an integrated digital twin and the lack of understanding of the physical twin.

Nikki Gonzales from Automation Ladies: Completely the other end of the spectrum. Nikki lives and breathes the SCADA/OT world, and she speaks for the smaller manufacturers — the ones who are twenty people, not the ones who can hire twenty people. If you’re North American and into that HMI/SCADA layer, also check out her OT SCADA Con conference.

Our Best Trips

We don’t just write and podcast — we also speak at conferences, attend events, and occasionally manage to be in the same country at the same time.

Vegas and ETLS: Last year, we were invited to speak at the Enterprise Technology Leadership Summit in Las Vegas, organised by our friends at IT Revolution. Here’s the thing: ETLS is an IT audience. The focus was squarely on generative AI, vibe coding, and the pace of change in the non-manufacturing world. For us, that contrast was gold. Seeing how fast things move outside manufacturing gives you perspective on what’s coming — and what’s different when your systems run 24/7 and a wrong deployment doesn’t just crash an app but shuts down a production line. Also, the Hoover Dam was genuinely impressive. Built to impress, and still functional.

Hannover Messe: The size of Hannover Messe is hard to describe — it’s a village. What’s valuable is sensing where the industry is heading, shaking hands with the people building things, and seeing the common themes across big tech vendors and small start-ups alike. We’ll be back this April.

Our Favourite Articles

Writing an article sounds simple. It is not. The writing itself is the easy part — getting it down to around 800 words and one core idea that you actually remember after reading? That takes iteration. A lot of it.

But the process forces you to think through your own ideas, and they often change while writing. That’s the real value.

Ceci n’est pas IT/OT Convergence: A nod to Magritte, because we’re Belgian and we can. This one was written in under an hour, almost out of pure frustration. The term “IT/OT convergence” dates back to Industry 4.0, and it has been misused so thoroughly that it’s lost meaning. It covers everything from adding an ethernet port to a sensor to deploying advanced AI models. People either love it or hate it, but most don’t realise it has both an organisational and a technical dimension — and conflating the two is where the trouble starts. It remains one of our most-read articles.

IT/OT Cooperation Models: Willem wrote this one early on — October or November of our first year — and it’s still our most shared article. The core idea: when IT and OT need to work together, the problems are rarely technical. It’s about how you cooperate. Inspired by DevOps and Team Topologies, we looked at cooperation from an IT/OT perspective and defined models that go beyond “let’s have more alignment meetings” (spoiler: those don’t work). Since then, our thinking has evolved. We’ve come to appreciate that simpler cooperation models aren’t necessarily low-maturity — they’re great when used for the right problem. You don’t need a full-fledged cooperative project team just to get a laptop sorted. But when you’re building something complex together, simple won’t cut it. Much of this updated thinking has already made it into the Academy, and we’ll be publishing more on the blog this year. Also, check out our mini IT/OT book library — it’s consistently one of our top-five reads.

The ITOT.Academy

Speaking of the Academy: we launched it last year, and it’s become one of the things we’re most proud of. The idea was born on a tram in Hannover and started from a simple question: what training would we actually want to follow ourselves?

Not a week-long course. Not someone reading slides at you. Not a massive one-directional webinar. Something live, interactive, vendor-neutral, and focused on the people and organisational side of IT/OT — not on protocols and programming.

We’ve now had close to 80 people go through the programme across our first groups. The interaction is bi-directional: we teach, but we learn just as much from the participants. People from different backgrounds, different industries, all working on fundamentally the same type of problem. And the feedback from one group genuinely shapes the next.

The next group starts May 22nd.
Head over to itot.academy if you’re interested in joining.
(or take a look to our Hall of Fame if you are not sure yet)

What’s Coming Next

Cybersecurity: This is a big one. We chose to focus here because cybersecurity in manufacturing is non-negotiable, and with NIS2 and the CRA, it’s coming to your company whether you want it or not.

What we’ve noticed: not everyone has the same understanding of what OT cybersecurity means. Is it an IT problem? Is manufacturing somehow exempt because it’s “different”? (Spoiler: no.) We’ll approach it the way we approach everything — people and organisation first, technology second. Translating the legal texts into what it actually means for your plant, your teams, and your processes. Expect articles, podcasts, and a few good stories.

Hannover Messe 2026: End of April. We’ll be there. We already have meetings planned, and we’ll record a podcast somewhere on the fairgrounds (hopefully not on an ironing board this time). If you want to meet up, reach out to us.

And we’ll be making a major announcement.
We’re not saying what it is yet. You’ll have to stay tuned.

Thank You!

One hundred articles.
Roughly forty podcasts.
Three academies.
Zero regrets.

None of this would exist without the people who read, listen, share, challenge, and reach out. You’ve made the IT/OT Insider what it is. We started with a glass of wine and a blank page. Three years later, we have a community — and we’re just getting started.

Until we meet again — take care.

David & Willem

In this video, David walks you through the framework we presented last year at the ETLS conference in Las Vegas, and on multiple other events since.

Quick recap: where AI sits today

Today, AI in industrial settings is a bolt-on. A very clever bolt-on in some cases, but a bolt-on nonetheless.

On the digital twin side, AI tools help you search through sensor data faster, spot patterns in quality data, optimise production planning, just to name a few applications. On the automation layer, it can act as a coding assistant, helps configure systems, or aid operators in analysing events.

Useful? Absolutely.
A step change? Not yet.

Because the fundamental relationship between the digital and the physical world hasn’t changed. Operators and engineers still bridge that gap. Automation still handles the deterministic stuff. And for everything outside those described boundaries — the unforeseen, the non-deterministic — humans step in.

So what needs to change to move beyond bolt-ons?

Three steps towards the Virtual Operator

To frame that, it helps to think in three stages of autonomy.

Step 1 — Assistance (where we are today). AI acts as a digital assistant. It gets access to a part of your data set and helps you get work done more effectively. Think of it as a smarter search engine for your plant.

Step 2 — Collaboration. AI becomes a virtual coworker. It has enough context to recommend actions, flag anomalies, and support decision-making. But it has no direct control of the plant. It suggests; it doesn’t act. This is the equivalent of lane assist or adaptive cruise control in your car.

Step 3 — Autonomy. The AI system can independently handle operational decisions. In most cases, this requires a full rethink of your plant’s control and safety concepts. And we’re not there yet — not by a long shot.

The self-driving car analogy is useful here. The hard part of autonomous driving isn’t controlling the steering wheel. It’s the fact that every intersection is different, road conditions change constantly, and there will always be unforeseen circumstances. Industrial operations face the exact same challenge.

Challenge #1: The integrated digital twin

To move from Assistance to Collaboration, AI needs context. Not just access to one historian or one maintenance system, but a coherent view across all your digital twins.

Today, those systems are often standalone. Even when they are connected, they use different naming conventions, different data models, and different levels of detail. Linking them in a unified, structured, contextualised way is non-trivial.

We’ve talked about this before — when we covered the industrial data platform and unified namespace concepts. But it bears repeating: an integrated data layer is a prerequisite for everything we want to do with AI at scale. Without it, you’re optimising locally. You’re making a smarter silo, not a smarter plant.

The technology to build this layer exists. The complexity isn’t purely technological any longer — it’s the sheer amount of work it takes to integrate systems, align data models, and get your data governance right. And let’s be honest: you often need to build that model from scratch. It won’t magically drop out of the air.

Challenge #2: Understanding the physical twin

Here’s the harder problem — and the one that doesn’t get talked about enough.

Even if you solve the data integration challenge, your Virtual Operator still only sees the digital world. And the digital world is a representation of physical reality, not reality itself.

For a Virtual Operator to truly collaborate — let alone act autonomously — it needs to understand what’s actually happening in the physical plant. The context, the constraints, the unwritten rules, the things your experienced operators just know but have never documented.

Some startups are beginning to tackle this by parsing engineering diagrams, ingesting technical literature, and building physics-informed models. That’s promising work. But this is an extraordinarily tough challenge, and we’ll be working on it for years — probably decades.

Here’s the uncomfortable truth: it is simply impossible to use historical data alone to understand the physical twin. We’ve seen companies try it, and they fail. You can’t infer the physical reality purely from its digital shadow. Full stop.

And as long as we can’t bridge that gap, there is no replacement for the human operator.

Is that pessimistic?

We don’t think so. We think it’s realistic.

The progress in industrial AI is real. The assistance phase is delivering genuine value, and the tools are getting better every month. But when you see vendors claiming they’ll deliver autonomous operations with a bit of historical data and a large language model… it’s worth pausing and thinking through the fundamentals.

Taking things step by step isn’t pessimism. It’s how you build something that actually works — safely and sustainably.

The data foundation is everything. Start there. Get your integrated digital twin in order. And keep an eye on the physical twin challenge — because that’s where the real breakthroughs will come from.

“OK, great. But where do I start?”

It’s a fair question. The vendor landscape is overwhelming. The technology options are endless. And let’s be honest: most of the advice out there jumps straight to solutions without helping you figure out what problem you’re actually solving.

So here’s our answer. It’s not complicated, but it does require honesty, discipline, and the willingness to involve the right people.

The way we approach this question is by organizing a combined maturity assessment and workshop. In that workshop, we both identify the current state as well as the future goals.

It’s extremely important to involve people from IT, OT and Operations in these types of activities, otherwise, you are again back to making technology choices nobody is waiting for.

And the good news is that we have written down our entire approach! 🙂
(and we are also teaching about it in our ITOT.Academy)

Step 1: Define Your Goal

Before you evaluate a single vendor, before you spin up a single broker, before you write a single line of code — you need to answer one question: what are you trying to achieve?

This sounds obvious. It’s not. We’ve seen plenty of organisations jump straight to technology (”We need a UNS!” or “Let’s build a data lake!”) without ever aligning on why. The result? Expensive pilots that impress in boardrooms but die on the shopfloor.

The vendors in our DataOps Vendor Database are more than happy to help you with the technical side. They have the tools, the expertise, and the reference architectures. But here’s what they will NOT do for you: they won’t define your goals.

That’s your job.

And the best way we’ve found to define those goals? Run a Data Maturity Assessment Workshop.

What Happens in the Workshop?

We use our five-stage Data Journey Model — from the “Dark Ages of Data” (Stage 0, where data is trapped in SCADA systems) all the way to guided optimisation (Stage 4, where models actively recommend decisions). If you’ve followed our Data Platform series, you’ll recognise these stages.

The workshop itself follows four phases:

• Current State — Every participant places a sticky note where they think the organisation sits today. No discussion yet, just collect perceptions. What usually happens: IT and Operations end up on opposite sides of the board. That visual gap? It’s worth more than any consultant’s slide deck.

• What’s Working — Identify the systems and tools already delivering value. This is where IT learns things from Operations they’ve never heard of, and vice versa. You’ll be surprised how much good work is happening in pockets nobody knows about.

• Blockers — What’s holding you back from the next stage? Missing technology? Lack of skills? Organisational silos? Budget? Data quality? Get them visible. Group them. You’ll notice the same themes emerging across departments.

• Future State — Where do you want to be in 2–3 years, and what would that enable? Not “Stage 3 because it sounds impressive” — but what you’d actually be doing at that stage. What decisions would be faster? What problems would disappear? Good future state statements describe outcomes, not shopping lists.

From there, you prioritise. We use four criteria: High Enablement (will this unlock more use cases?), High Value (does it solve a real pain point?), High Impact (will people notice?), and High Visibility (never underestimate the power of a visible win for securing your next budget).

The sweet spot sits at the intersection.

Get the Moderation Guide

We’ve packaged everything you need to run this workshop into a free Moderation Guide. It includes step-by-step facilitation instructions, the Data Journey Model explained, and ready-to-use whiteboard templates — available as PDF and as a Miro board so you can run the session physically or remotely.

Whether you’re doing this with five people in a meeting room or twenty across multiple sites, the guide gives you a structured way to build consensus on what actually matters.

Download our Free Workshop Guide

One honest note: the exact method you use to run this workshop is less important than ensuring the right people are in the room and willing to engage honestly. You can’t workshop your way out of IT and OT stuck in silos. But if the group genuinely wants to collaborate and improve, a grassroots initiative can gain traction quickly.

Step 2: Start Small, Build to Scale

With your goals defined and your first use case(s) identified, it’s time to move. But “start small” is only half the mantra. The full version is: start small, think big — and thinking big is not optional.

Starting small without a vision means you’ll solve one problem and create three new ones. Thinking big without starting small means you’ll be stuck in analysis paralysis for another year. You need both.

What “starting small” actually looks like depends on several factors:

Your current capability. This is exactly what you assessed in Step 1 using the Data Journey Model. If you’re at Stage 0, your first step is getting data out of those SCADA systems. If you’re at Stage 1, it’s adding context. Don’t try to do predictive maintenance when you can’t even reliably access your historian data.

Your OT complexity. Not every manufacturing environment is the same, some have heavily invested in DCS systems, optimizers and the like since decades, others are perfectly fine with a couple of standalone HMI’s. The distinction matters. An MQTT broker is perfect for OT-light and IIoT use cases, but it’s not necessarily the right starting point if you already have a mature SCADA/MES landscape.

Your willingness to build versus buy. Some organisations want full control and are ready to invest in internal platform teams. Others prefer managed solutions. Neither is wrong — but be honest about what your team can actually sustain.

Bonus: your production process type. Asset-heavy environments (pumps, compressors, turbines) benefit from asset-first modelling. Process-driven environments (batch, continuous) often need process-first modelling. This shapes your data architecture more than most people realise.

Whatever you choose, one principle applies: design like you’ll be solving five problems tomorrow, even if you’re only solving one today. Use structured data models. Document your integration points. Choose tools that allow for modular upgrades. It’s not about slowing down — it’s about not painting yourself into a corner.

Step 3: Evolve

Here’s what nobody talks about at the beginning: the plateau always comes.

You’ve started. You’re building momentum. Use cases are multiplying. Early wins have bought you credibility and budget. And then, gradually, things start to slow down.

It’s not dramatic. It’s subtle. But the warning signs are predictable:

• It’s becoming more and more difficult to add new data sources.

• Users are starting to complain about speed. Dashboards load slowly. Queries time out.

• Your team spends more time maintaining than innovating. Bug fixes dominate the backlog.

• Key person dependencies are increasing, not decreasing. When someone goes on holiday, projects stall.

• Workarounds are multiplying. Instead of using the platform as designed, teams are building custom solutions around it.

These signs don’t appear overnight. They accumulate gradually. That’s what makes them dangerous — you can rationalise each one individually while missing the pattern collectively.

The plateau isn’t failure. It’s a signal. Technology evolves, requirements change, and what worked brilliantly at 10 sites might not work at 50. Recognising it early and evolving before you stall is what separates sustained transformation from one-hit wonders.

Starting again doesn’t mean throwing everything away. Reuse what works. Keep the organisational structures that enabled your success. Preserve the trust you’ve built on the shopfloor. But be honest about what needs to change.

We covered this in depth in our article on Fighting Entropy: How to Scale Without Spaghetti. If you’re already past the starting phase, that one’s essential reading.

So, Where Do You Start?

Right here:

1. Define your goal — Run a Data Maturity Assessment Workshop with IT, OT, and Operations in the room. Surface the perception gaps. Build consensus on what matters.

2. Start small, build to scale — Pick your first use case based on value, impact, and visibility. Choose technology that fits your OT complexity and current maturity. Design for tomorrow.

3. Evolve — Watch for the plateau. Recognise the warning signs early. Adapt before friction becomes crisis.

The Moderation Guide gives you everything you need for Step 1. It’s the foundation everything else builds on.

Download the free Data Maturity Assessment Workshop Guide →

Includes: step-by-step facilitation instructions, the Data Journey Model, and whiteboard templates (PDF + Miro board).

Want to go deeper? Check out our ITOT.Academy where we focus on concepts, not tools — and on frameworks, not features.

An often heard request from our readers (you 😀) is to translate some of our ideas into a tangible architecture, something you can follow and potentially implement. That’s exactly what we have planned for today together with HiveMQ, and hopefully more often in the future!

In the last year, we have published our second Industrial Data Platform Capability Map, a podcast with Kudzai Manditereza on the differences between OPC UA and MQTT, our recent article on the pitfalls around UNS and even our interview with HiveMQ Co-founder Dominik Obermaier.

Time to put all four together! And to do that: we’ll go back to Sweet Harmony Treats, our beloved industrial bakery which you might still know from previous data articles.

Meet Sweet Harmony Treats

Sweet Harmony Treats (SHT) started a century ago as a local bakery. Today, it’s a gigantic family-owned business producing cookies, confectionery, and (their specialty) waffles across multiple countries. Think golden, gooey, crispy waffles—the kind that makes you buy two packs even when you promised yourself just one.

Their production footprint reflects that growth: some facilities are over a hundred years old, smelling of nostalgia and buttered dough. Others were acquired from competitors, each bringing its own quirks, machines, and ways of working. It’s a patchwork that’s common in food manufacturing—and it creates real operational challenges.

Food and beverage companies don’t just make products; they operate under strict regulatory requirements. Traceability is everything. If a bad batch of ingredients gets through, or a quality concern emerges, you need to know exactly which products were affected, where they are, and how to recall them. Not being able to do that isn’t just bad for business—it can be catastrophic.

Which is why operational data matters so much in this industry.

Subscribe now

Islands of Data

This brings us to Mark, a process engineer at SHT, and Emma, the lead maintenance engineer. Both are experienced. Both are brilliant at their jobs. Both are drowning in spreadsheets.

Why? Because most of SHT’s production equipment operates in isolation. Mixers, ovens, packaging lines—each has its own local HMI. Some speak OPC-DA. Other fancier ones OPC-UA or MQTT. And then there’s the legacy stuff that barely speaks at all.

The result? Mark can’t quickly compare energy consumption across product types. Emma can’t correlate maintenance events with process parameters. And neither can do it without manually exporting data from multiple systems, hoping the timestamps match up.

SHT’s leadership knew they needed a central data platform. Not someday. Now. Energy costs were climbing, sustainability targets were getting stricter, and their existing approach simply didn’t scale.

So they decided to do it right. SHT formed a small cross-functional team: a couple of people from plant operations (including Mark and Emma as subject matter experts), one from IT infrastructure, and one from OT systems.

Define the Standards Upfront

Before touching any hardware, they sat down with cybersecurity. Where would edge devices live in the Purdue model? What about the central broker? How would authentication work? What protocols were allowed?

They decided:

• Edge gateways at Level 2 (close to machines)

• Central broker in the DMZ (Level 3)

• MQTT as the primary transport protocol (but with bridges to OPC-UA and DA where needed)

• A central Data Broker structured on ISA-95 hierarchical asset model

That last point is critical. As we’ve written before, proper data management is key. And if you don’t define governance upfront (Who owns the namespace? Who approves new topics? How do we handle schema evolution?), you’ll end up with another data swamp.

Building the Namespace

Here is a quick overview of a part of the Namespace as it aligns with SHT’s production plant. We didn’t expand it completely, but this gives you a first idea.

Waffle Line 01
│
├─ Ingredient-Handling
│
├─ Batter-Mixing
│
├─ Proofing (yeasted waffles)
│
├─ Oven
│   ├─ Heating Zone 01
│   │   ├─ Temperature: Top (°C/F), Bottom (°C/F)
│   │   ├─ Gas burner: Valve position (%) 
│   │   ├─ Gas burner: Mass flow (Nm³/h), 
│   │   └─ Circulation Fan Speed (%)
│   ├─ Heating Zone 02
│   │   └─ …
│   ├─ Belt-Drive-Module
│   │   └─ …
│   ├─ Air-Circulation
│   │   └─ …
│   ├─ Humidity-Control
│   │   └─ …
│   └─ Oven Utility Metering
│       ├─ Electricity: Total oven (kW)
│       ├─ Electricity: Incoming mains current (A)
│       └─ Gas: Total oven (Nm³/h)
│
├─ Cooling
│
└─ Packaging

We use the equipment hierarchy from ISA-95 which helps us to build the above namespace. Now we do need to note a few “buts” here:

• This gives us a simple, easy to understand starting point

• But… ISA-95 is much more elaborate and complex than just an equipment hierarchy (it is actually object model which much more complex relationships)

• But… We also don’t depict anything related to the actual batch process here, as this is more the ISA-88 turf

However, for Emma and Mark, this is the perfect starting point for their data infrastructure!

The Architecture - From Edge to Enterprise

Here’s how we would implement a broker based architecture at Sweet Harmony Treats using HiveMQ:

1. HiveMQ Edge - connecting to legacy PLCs and collecting tags, enforcing consistent naming conventions, arranging the data in a UNS structure and bridging to a Site/Central broker.

2. HiveMQ Enterprise - Site/Central broker holding real time UNS structured data from across Sweet Harmony Treats equipment at massive scale.

3. HiveMQ Data Hub - Engine running on broker adds a UNS data validation layer to ensure data transmitted from all edges conforms to define schema.

4. HiveMQ Extension Ecosystem - persisting the sensor data on to a database

Stage 1: HiveMQ Edge – Collecting and Normalizing Data

The waffle line’s baking tunnel oven is a perfect microcosm of SHT’s challenge. It’s got:

• Temperature sensors in each heating zone (OPC UA)

• Gas flow meters on the burners (Modbus)

• A belt drive motor with vibration sensors (MQTT from an IIoT vendor)

• A state machine in the PLC tracking oven modes (OPC DA, because it’s an older controller)

Rather than writing custom integration code for each protocol, SHT deployed HiveMQ Edge—an open-source gateway designed exactly for this scenario.

For the OPC UA sensors, they used HiveMQ Edge’s protocol adapters to poll specific tags. But here’s the key: they didn’t just forward raw tag names like L15.B1.Zone01.TempTop.PV. Instead, they mapped them to a consistent, human-readable structure:

sweetharmony/site/plant1/waffle-line-01/oven/zone-01/temperature/top

By enforcing naming conventions at the edge, they ensured every data point had context before it even left the production floor.

For the legacy Modbus and OPC DA systems, HiveMQ Edge bridged those protocols into MQTT. The result? A single, unified data stream published to MQTT topics—regardless of the original source.

Stage 2: HiveMQ Enterprise Broker – The Central Nervous System

All that edge data now flows to a central HiveMQ Enterprise broker sitting in SHT’s DMZ. This isn’t just a message router—it’s the backbone of their real-time data architecture.

The broker handles:

• Real-time pub/sub for thousands of data points (current values only—remember, this is an event stream, not a historian)

• TLS-encrypted connections from all edge nodes

• Quality of Service (QoS) guarantees to ensure critical messages aren’t lost during network hiccups

What does this enable? Other systems can now subscribe to exactly the data they need:

• The historian subscribes to /sweetharmony/+/+/+/oven/# to store all oven telemetry

• Mark’s dashboard subscribes to energy-related topics

• Emma’s maintenance system subscribes to vibration and temperature anomalies

Because it’s pub/sub, adding a new consumer doesn’t require changing anything upstream. No point-to-point integrations. No fragile ETL pipelines. Just clean, decoupled data flow.

Stage 3: HiveMQ Data Hub – Governance at Scale

Here’s where things get interesting.

As SHT scaled from one line to twelve, they needed to ensure data quality didn’t degrade. What if an edge node starts publishing malformed JSON? What if someone creates a new topic that doesn’t follow the namespace standard?

This is where HiveMQ Data Hub comes in. It’s an engine running on the broker that validates all incoming data against predefined schemas.

For example, SHT defined a schema for temperature sensors:

{
  “location”: “string”,
  “sensor_id”: “string”,
  “value”: “number”,
  “unit”: “celsius”,
  “timestamp”: “ISO8601”
}

Any message that doesn’t conform? Rejected. Logged. Routed to a dead-letter queue for investigation.

This is governance in action. It’s not a policy document gathering dust—it’s an automated quality gate that prevents bad data from polluting the platform.

And because schemas are versioned and managed centrally, SHT can evolve their data model over time without breaking existing consumers.

Stage 4: HiveMQ Extensions – Persisting the Data

Real-time data is great. But Mark and Emma also need history. Trend analysis. Batch comparisons. That requires storage.

SHT uses the HiveMQ TimescaleDB extension to automatically persist sensor data into a time-series database. TimescaleDB is optimized for this: it compresses old data, handles massive write throughput, and supports SQL queries (which their analysts already know).

The extension subscribes to relevant MQTT topics and writes them to TimescaleDB—no custom code required. Retention policies ensure they’re not storing decades of sub-second data unnecessarily.

And finally: Governing the entire landscape

HiveMQ Pulse is a distributed data intelligence platform that turns fragmented, inconsistent operational data into structured, governed data for real-time decisions, analytics, and AI.

It uses a centralized Semantic Graph and distributed agents to catalog data, validate structure, compute KPIs, and apply governance at the source.

Pulse helps teams structure and govern their MQTT data - forming the foundation for a Unified Namespace, even across diverse edge and broker environments.

Pulse Capabilities:

1. Semantic Graph & UNS Governance
   Define and enforce the structure of MQTT topics, payloads, and metadata through a centralized Semantic Graph — applied consistently across edge and broker agents. Pulse provides the enforcement backbone for Unified Namespace strategies by ensuring site-to-site consistency, eliminating schema drift, and reducing fragile scripting.

2. MQTT Discovery & Runtime Validation
   Agents observe active topics and payloads, identify data not yet modeled, and validate live messages against expected formats, surfacing deviations for resolution.

3. Asset Mapping & KPI Computation (Edge‑only)
   Map non‑MQTT sources (e.g., OPC UA) into governed MQTT payloads and compute derived values such as KPIs, rollups, and expressions using local history.

A big thank you to HiveMQ for contributing to this article!

Extra resources you might find useful:

(*) At the IT/OT Insider we do value our independence and transparency. So as we look for ways to pay the bills we were looking for ways to work with sponsors without giving up on those principles. This is where the idea of sponsors comes from. Together with a few selected sponsors we’ll explore some topics that we both find interesting in the same way we write our normal articles. In the coming weeks you’ll find a couple of pieces that have been sponsored. Feel free to contact us if you are interested in a partnership as well.

📣 A quick reminder before we start: Our next ITOT.Academy kicks off in May, and our early bird offer is available once more. Want to join our fourth group and learn how to bridge IT and OT? There is no better time than now!
👉 Check the curriculum & enrol via ITOT.Academy 👉

If you’ve been following our blog and podcast, you know we spend most of our time in what we call the IT/OT zone: data platforms, connectivity, governance, AI use cases, and everything in between. We’ve also covered the Purdue model, MES, UNS, and even Model Predictive Control. However, we rarely talk about what happens at Level 1 and Level 2 — the actual process control layer that keeps plants running. Not the data it produces. Not the dashboards built on top of it. The control itself.

So when we had the chance to sit down with Margret Bauer, Professor of Process Automation at the Hamburg University of Applied Sciences, we jumped at it. Margret is an electrical engineer by training, did her PhD in data analytics on process data back in the early 2000s (before “data analytics” was cool), worked for ABB Corporate Research, and even did early IT/OT integration work — connecting SAP with ABB’s 800xA system back in 2007. (Yes, 2007)

PID: The Most Important Algorithm Most Don’t Know About

Let’s talk about PID control.

Not P&ID (the diagram) — PID, short for proportional, integral, derivative. If you studied engineering, you probably had one half-lecture on it, sandwiched between Kalman filters and Lyapunov functions. Easy to overlook.

Except it runs the world.

Margret was blunt about this: 99.9% of all rockets that have flown into space run on PID control. All the robots you see online? PID underneath. Every valve opening and closing in a chemical plant, a refinery, a bakery? PID.

The concept is elegant: the proportional part looks at the present, the integral part looks at the past, and the derivative part looks at the future. Three aspects of time, one controller. As Margret put it: it has the worst name and the best track record of any control strategy out there.

But don’t let the simplicity fool you. In practice, PID is hard to implement well. Valves have physical limits — they can’t open beyond 100% (no matter how politely you ask). They take time to respond. And when you need to coordinate two valves for the same flow — say, one big valve for coarse control and a small valve for fine-tuning — the strategies on top of PID get complex fast. These layered strategies exist across every process plant, and they are the strategies that nobody outside the automation world ever talks about.

A Dying Breed

Margret posted on LinkedIn that process control engineers are a dying breed. When we asked why, her answer was painfully logical: the automation worked. Companies invested in control systems in the 1970s, 80s, and 90s. Plants got more stable. And then management looked at the 20-person controls department and said: “Why do we still need these people? The process runs fine.”

So they cut the teams. One by one, across the industry.

And that is a major problem.

In industry, many control departments are gone — and with them, the expertise to improve or even maintain automation performance. And in academia, process control is barely taught anymore. There are barely any new process control engineers coming through the pipeline. The academics who still focus on it? A handful worldwide, passionate but outnumbered (and Margret surely is passionate 🙂)

The AI Reality Check

Willem couldn’t resist: “Margret, of course, I’m going to come in with the solution for all your problems. You need to use AI. It’s going to solve everything.”

(We all laughed.)

Margret’s response was obviously more measured.

One of her master’s students developed a reinforcement learning algorithm for a batch penicillin process that improved throughput by 25%. Genuinely impressive. But it worked because the student had a well-understood simulation model. In the real world? The algorithm wasn’t scalable, wasn’t repeatable, and wouldn’t transfer to another process.

This ties straight into something we’ve been discussing a lot recently on this blog: the physical twin problem. AI models need to understand the underlying physics, the process behaviour, the control strategies. Without that, you’re optimising in a vacuum. David’s own experience with nonlinear MPC during his master’s thesis confirmed the same thing — beautiful results on simulated data, useless on real plant data.

The takeaway isn’t that AI can’t help. It’s that AI without process knowledge is just maths looking for a purpose.

The Operator Paradox

There’s another angle Margret brought up that resonated with us: the better your automation, the more bored your operators become. One of her students — a former operator — said she used to bring a book to her shift. Press the button, sit down, read for eight hours, hand over to the next shift.

That’s great from a stability standpoint. But it creates a dangerous gap. When something does go wrong — and it always does eventually — operators haven’t seen enough upsets to know how to respond.

The more you automate, the less exposed your operators are to disturbances, and the harder it becomes to train them for the exceptions.

And you can’t just “turn off the MPC layer to make things interesting again,” as David pointed out. So the industry adds another layer — operator training simulators, essentially flight simulators for plant operations. Layer upon layer upon layer.

Margret’s view? We’ll never fully automate everything. Every process is different, every plant is an individual. We’ll always need people. The question is how we keep them engaged, trained, and ready for the moments that matter.

Why This Matters for the IT/OT World

If you’re reading this blog, chances are you’re working on data platforms, digital twins, AI use cases, or integration architectures. All of that is important. But it all sits on top of a foundation that most of us take for granted.

Process automation isn’t a solved problem. It’s an under-invested, under-documented, under-appreciated layer that directly determines the quality of the data we work with, the stability of the processes we try to optimise, and the feasibility of the AI models we try to deploy.

If the foundation crumbles, nothing above it works.

So next time you’re debugging a data quality issue, or wondering why your AI model produces nonsense, or trying to understand why a sensor reading oscillates when it shouldn’t — maybe the answer isn’t in your data platform. Maybe it’s one layer below.

Find Margret on LinkedIn: https://www.linkedin.com/in/margret-bauer-a885618/

Book ‘Process Control in Practice’ mentioned during the podcast: https://www.amazon.de/Process-Control-Practice-Gruyter-Textbook/dp/3111103722

Stay Tuned for More!

Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence.

🚀 See you in the next episode!

Youtube: https://www.youtube.com/@TheITOTInsider
Apple Podcasts:

Spotify Podcasts:

Disclaimer: The views and opinions expressed in this interview are those of the interviewee and do not necessarily reflect the official policy or position of The IT/OT Insider. This content is provided for informational purposes only and should not be seen as an endorsement by The IT/OT Insider of any products, services, or strategies discussed. We encourage our readers and listeners to consider the information presented and make their own informed decisions.