The IT/OT Insider Podcast with David and Willem

Richard Beeson wrote one of the two forewords to our IT/OT Handbook. Our book launches on 6 October, so having him on the podcast now felt like the right way to close the loop.
What makes the pairing work is that our two foreword writers came at it from opposite ends. Richard brought the OT-first perspective, John Smart the IT-first one. Different starting points, different vocabulary, but… they end up in more or less the same place.
Richard describes himself as “a chemical engineer gone bad”. In 1990 he joined a company called Oil Systems Incorporated (yes, that is indeed OSIsoft). About ten people at the time. He’d spend the next three decades there, eventually as CTO, watching the PI System absorb every technology transition the industry threw at it.
The origin story of PI is a customer who wasn’t paying attention
Before PI was a product, OSIsoft sold optimisation consulting to refineries. A customer asked them to prove the before and the after. So the team captured all the data, went back, and presented how much better things were running.
Thanks for reading The IT/OT Insider! Subscribe for free to receive new posts and support our work.

The customer barely looked at the slides. They were staring at the data. The history. The comparison.
“That’s what they are valuing here,” Pat Kennedy realised. And the business pivoted. Richard’s summary is the kind of thing that sounds trite until you notice how rarely it happens: “It’s amazing. If you just listen to customers, it’s amazing.”
The bet on seven platforms nobody ended up wanting
By 1991, PI 2 ran on VMS and the business world had decided that open systems were the future. Which in practice meant Sun’s Unix, IBM’s Unix, HP’s Unix and Digital’s Unix — “which were not compatible in any way, shape or form.”
So they built PI 3 for seven platforms. Then Bill Gates came to San Francisco, Windows NT joined the stack, and within a couple of years nobody was asking for the Unix versions at all.
Wasted effort? Not quite.
“We couldn’t have even gone to the table and had that discussion and let that unfold if we weren’t able to bring those other things to the table. They wouldn’t have been allowed to sit down with us.”
Worth sitting with that one, because we’re watching the same film again. After two decades of Windows monoculture in OT, the first question on new installations now is: can it run on Linux? Can we containerise it? Can we move it across hardware?
Every model you build creates the next barrier
Let’s go to context!
Asset Framework, Richard explained, was never really about hierarchies. It was designed as an abstraction to enable model-driven analytics: how do you write a yield calculation, a material balance, an energy balance that works on a plant you’ve never seen? To do that, you need a model of the plant rich enough for the analysis to interrogate.
The graph-like and process-modelling capabilities were in there early on. Most of it didn’t survive contact with the market. “The parts that survived were the parts that were approachable,” he said, “and where you could maybe drive some quick wins, some quick value.”
Too early? Badly sold? Or simply too heavy a lift for the number of problems that justified it? Probably all three. Richard calls it the activation energy problem: as long as there’s a big climb before the first point of value, it’s a hard sell. Really, really hard.
And the problem doesn’t go away by modelling harder. It recurses. “Every single time that you define the thing, you’re creating the new barrier, the next barrier, the next impasse, because there’s always going to be some other way to conceive of it or shape it or label it or reference it.”
David has a story from exactly this. Trying to build the business case for a basic asset hierarchy at BASF, he pitched a plant manager, who was unmoved: name any location in my plant and my operator will reel off the five nearest flow meters from memory. Which was true — and which was the signal that a big top-down contextualisation project was the wrong shape entirely.
AI hell
Richard has these ongoing flashbacks to spreadsheet hell. Not as an insult: spreadsheets solved real problems for real engineers who had no appetite for building a governance system first. That’s precisely why they metastasised.
“I think you give AI to OT and you are defining, creating the next version of spreadsheet hell. It’s AI hell.”
Who governs it? Who manages it? What happens when that person leaves? We’ve all met the spreadsheet with the button nobody can explain, still pressed every morning, its author three jobs gone. (The modern twist: you can now ask an LLM to reverse-engineer what the button does. Progress, of a sort.)
The stakes shift when the output isn’t a report but PLC or DCS code. Confident, plausible, and wrong is survivable in a weekend app. Less so when it runs a plant.
Richard’s closing frame is one we use ourselves: the arrival of electricity in factories. For years, plants simply swapped the steam or diesel engine driving the central shaft for an electric motor (same shaft, same belts, same layout) and wondered where the productivity gains were. It took a generation to realise you could put a small motor on every machine and rethink the whole floor.
“I think the transformation we’re going to see in OT is going to be a fundamental shift in not just how you do things, but even what you do. I think it’s going to be that disruptive — if we can survive getting there.”
Which brings us to the line that nearly became the episode title, and that David talked himself out of using:
“You can do dumb things a whole lot faster.”
We’re holding Richard to a follow-up session on AI and OT. If that’s a conversation you want to be in the room for, it’s exactly the sort of thing our new IT/OT Deep Dives are built for.
Stay Tuned for More!
🙋 Join the ITOT.Academy (2027 cohorts now online) →📘 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.


This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit itotinsider.substack.com

This is an episode we were hoping for since we started this podcast 🙂
Gene Kim has spent twenty-eight years studying high-performing technology organisations and wrote best-selling books such as The Phoenix Project, The DevOps Handbook, Wiring the Winning Organization, and most recently Vibe Coding. He also runs the conference where the two of us first stood on a stage and tried to explain the IT/OT problem to a room full of technology leaders.
Gene set the tone in the first minute:
“I’ve been an admirer of your work and I’m so happy for you that you’re done with the book and get to share what you’ve learned with the rest of the world. This is like the perfect timing, as every critical infrastructure provider finds themselves having to do things that they’ve never been asked to do before in this age of AI and AI infrastructure.”
Why a book about IT is set in a factory
Willem asked the question we’d been sitting on for years. The Phoenix Project is a novel about IT… so why set it in a car parts plant?
The answer goes back to 1999, when Gene read The Goal by Dr Eliyahu Goldratt.
“It changed my life. It’s a novel about a manufacturing plant manager who has to fix his cost and due date issues in ninety days, otherwise they shut the plant down. I’ve never worked in manufacturing. I’ve read a lot of books about it, but it was such a riveting story just because you could see the problems.”
His ‘goal’ (pun intended) was to write The Goal, but for IT.
“To say that we copied the book is literally true. Same constellation of characters, same sort of plots, same number of breakthroughs. We deeply studied that book for over a decade getting ready to write it.”
The ideas underneath DevOps did not originate in IT. They came out of Toyota, out of lean, out of the theory of constraints — Dr Steven Spear’s Decoding the DNA of the Toyota Production System, the work of Liker and Shook, Goldratt’s constraint thinking. Different traditions, same questions. How do you shrink batch sizes? How do you improve flow?
So when manufacturing borrows from DevOps, it isn’t importing something foreign. It’s getting its own ideas back, with a decade of software-industry mileage on them.
Gene’s own summary:
“In the high performers, everyone is able to do what they need to do because they have independence of action, and that’s enabled because everyone has what they need, when they need it, in the right format, with the right decision rights and the right authority. And the opposite side — what showed up in The Goal — is that no one can do what they need to do because no one has what they need when they need it. It doesn’t matter whether it’s physical transportation of materials or the transformation of information.”
The escalation tax
Fun fact: our problem statement apparently landed harder on Gene than we realised.
“One of the things that you helped me understand and concretise is that when you don’t have what you need, the only way to get it is by escalating. When you talked about how IT and OT only meet at the CEO level, this is terrible, because it means you are routinely having to escalate things all the time to get what you need in your daily work.“
And because nobody wants to be the person knocking on the CEO’s door every week, most of the escalations never happen. Problems just sit there. The dysfunction is invisible precisely because people are too reasonable to surface it.
Gene remembers the first time he heard the framing, back when we submitted to the call for papers at what was then DevOps Enterprise Summit:
“Imagine the DevOps problem, but it doesn’t go to the head of IT, the CIO. It has to go to their boss, and their boss’s boss, and maybe even their boss’s boss’s boss. I found that problem statement so vivid and beautiful — in a terrible way. You’re sort of doomed to dismal performance.”
We can now admit the backstory: getting published by IT Revolution was goal number one from the moment we started thinking about a book. When the call for proposals came in, we brainstormed for the better part of a day about what on earth we could tell a room of technology leaders who had never expressed any interest in manufacturing.
The Art Smalley question
The best story of the episode, and the one we keep coming back to.
At the Enterprise AI Summit in Charlotte on 7–8 October, one of the speakers is Art Smalley — the second American hired by Toyota in Japan, brought in by the famous John Shook of NUMMI fame. Gene describes him as possibly the most switched-on vibe coder he has ever met. He’s in his sixties.
Why? Because in 1986 Smalley was doing engine design at Denso. Extremely high-precision work. And central IT was never going to help him.
“He was a person on his Toshiba laptop, using dBase IV to solve all the frontline problems. He’s a technologist, not classically trained in computer science like many of us. But he was without doubt helping solve problems on the front line.”
Then Gene asked the question that reframes the entire industrial AI conversation:
“How many Art Smalleys are there in the world, in manufacturing flows right now, who have problems that need to be solved? And IT is never going to — they’re just not important enough to make it onto the priority list. What I find very exciting about AI is that Art Smalley is evidence that you don’t have to be an Art Smalley. Any frontline worker can solve their own problems.”
He also pushed back gently on treating this as a small thing. Toyota moving manufacturing to the United States and bringing its entire supply chain with it could not have happened without people like Smalley building the tools to manage flow and replicate a supply chain that did not yet exist.
Writing a Book was more work than we thought
Gene turned the interview around on us near the end and asked what surprised us most.
David’s answer: the naive assumption that you start writing and the words follow, and half a year later you have a book. The reality is that the moment you write things down, you discover you’re missing information, that you’re not sure about things, that some things need validating and others need more time to digest. Going from the first page to the last page, in order, exposes the gaps in your own thinking. That turned out to be worth more than the book itself.
Willem’s answer was more practical and more painful: he writes best at six in the morning and does not enjoy waking up early. And beyond that, knowing when to stop. Writing is a bit like painting — you start with a general idea and discover things along the way — but it’s genuinely hard to say when a thing is finished. You need an editor to tell you. (Thanks, Anna and Leah.)
The substantive learning was about the cooperation models. We started out assuming some forms of IT/OT interaction were simply inferior to others. We finished convinced that every pattern is a good pattern within the right context — and that the real work is describing the context properly.
Gene’s line on this is one we’ll be stealing:
“In order to be able to write clearly, you have to be able to think clearly first.”
And then, on what a book is for:
“Methodologies and books have in common the ability to connect all the dots together — and that often means you have to name all the dots first. My heartiest congratulations for writing a book that makes people see a problem they have that they might not have recognised before, and more importantly, gives them hope that there’s actually something you can do about it.”
Final thoughts
Somewhere in the middle of this conversation, Willem said the thing that ties it all together: manufacturing and IT are both just people trying to solve problems. One with software, one with machines.
Gene’s reply was immediate:
“It’s always about people trying to solve problems. And to what extent are we creating the conditions that enable people to solve problems well? We can make it very, very difficult, or we can do it very well. That’s what we all have in common — trying to make it easier and explainable, so that people can solve problems well.”
Twenty-eight years of research, three decades of industrial digitalisation, two very different books, and it comes down to the same sentence.
Thanks for listening.
Stay Tuned for More!
🙋 Join the ITOT.Academy (2027 cohorts now online) →📘 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.


This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit itotinsider.substack.com

We went a bit further than usual to talk to Bob van de Kuilen, because New Zealand is roughly the outer edge of what our time zones will allow 😀
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.
Before we start…Our next IT/OT Academy kicks off September 18 with an updated program. 🙋 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!) →

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.
Thanks for reading The IT/OT Insider! Subscribe for free to receive new posts, podcasts and support our work.

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.
🚀 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.


This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit itotinsider.substack.com

(Our topic, Our tone, Sponsored by Litmus.io *)
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?”
Thanks for reading The IT/OT Insider! Subscribe for free to receive new posts and support our work.

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:
* Own your data. Edge or cloud, but you own it. Don’t hand it back to OEMs.
* Document your processes in a way both the next generation of engineers and AI agents can consume.
* 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 is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit itotinsider.substack.com

(Our topic. Our tone. Sponsored by Cumulocity *)
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.
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:
(*) 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 is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit itotinsider.substack.com