Advertise on podcast: 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

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? 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. Thanks for reading The IT/OT Insider! Subscribe for free to receive new posts and support our work. 🚀 See you in the next episode! Youtube: https://www.youtube.com/@TheITOTInsider Apple Podcasts: Spotify Podcasts: 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

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. Thanks for reading The IT/OT Insider! Subscribe for free to receive new posts and support our work. 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. 🚀 See you in the next episode! Youtube: https://www.youtube.com/@TheITOTInsiderApple Podcasts: Spotify Podcasts: 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 dataPARC *) 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. Thanks for reading The IT/OT Insider! Subscribe for free to receive new posts and support our work. 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. 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

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

Three years ago, over a glass of wine during summer break, we decided to start writing. No business plan, no editorial calendar — just a shared frustration that the conversation around IT and OT in manufacturing was either too technical or too abstract. We wanted something in between. Something practical, honest, and maybe a little opinionated. 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… Thanks for reading The IT/OT Insider! Subscribe for free to receive our weekly articles and podcasts and support our work. 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 Thanks for reading The IT/OT Insider! Subscribe today! 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

📣 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 📣 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 👉 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. 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

In this episode, Wybren van der Meer, a strategic data consultant, discusses the importance of data governance in industrial settings. He shares insights from his background in physics and experience in data management, emphasizing the need for a clear definition of data governance, the evolution of data practices in industry, and the role of trust and reliability in data management. The conversation also touches on practical applications of data governance, such as in coffee roasting, and the challenges of scaling governance practices across different plants. Wybren highlights the significance of starting small with governance initiatives while keeping the bigger picture in mind, and the necessity of engaging people in the process to ensure successful implementation. Find Wybren on LinkedIn: https://www.linkedin.com/in/wvandermeer/  More on the Unified Namespace: https://www.youtube.com/watch?v=d1QeZWb6rt0 More on the Industrial Data Platform: https://www.youtube.com/watch?v=mdtY2Ks8F6M  Learn everything about IT/OT Cooperation, Industrial DataOps and more: https://itot.academy  More about The IT/OT Insider: https://itotinsider.com/  Chapters 00:00 Introduction to Data Governance and Wybren's Background 02:51 Understanding Data Governance in Industrial Contexts 05:59 The Evolution of Data Governance in Industry 09:12 Defining Data Governance and Its Importance 11:56 Implementing Data Governance: Challenges and Strategies 15:01 Data Governance in Coffee Roasting: A Practical Example 18:06 Scaling Data Governance Across Operations 20:52 The Role of Data Governance in New Projects 24:06 Overcoming Resistance to Data Governance 27:01 The Future of Data Governance in Industry 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

Welcome to the first IT/OT Insider Podcast of 2026! We’re kicking off the year with someone who’s done it all: refineries, equipment reliability, process safety, even the postal industry (and found data at the heart of every role). Kris Doering recently joined SaskEnergy, a government-owned natural gas transportation company in Saskatchewan, where he works on system modelling and asset planning. But before that, he spent years at the Co-op Refinery Complex as superintendent of refinery performance improvement, working on benchmarking, goal-setting, and deploying process safety software. His career also includes stints in equipment reliability, Lean Six Sigma at Canada Post, and early days implementing PI System for upstream gas producers. What ties it all together? Data. And not just collecting it. From Postal Sorting to Refinery Benchmarking Kris’s career path is anything but linear, and that’s precisely what makes his perspective valuable. As he put it: “Data has really been a common thread through the whole career. No matter where I worked, what field I worked in, it’s really been the thing that’s tied all of my roles together.” His time at Canada Post might surprise those who don’t think of postal services as manufacturing. But as Kris explained, the parallels are striking: “You’re getting things off of semi-trailers, you’re sorting mail based on barcodes, you’re dealing with advertising mail, newspapers, parcels from Amazon. There’s a lot of infrastructure and a lot of processes.” Those early Lean Six Sigma projects at Canada Post became foundational for everything that followed. “That work really kind of prepared me for all of the other stuff that I’ve done,” Kris noted. Leading vs Lagging: Why Process Safety Metrics Matter Our conversation centred on process safety. This is a topic that doesn’t always get enough attention outside refineries and chemical plants, but has lessons for anyone working with data and performance management. Kris worked extensively with process safety at the refinery, deploying HSE software and investigating incidents. He explained the critical distinction between leading and lagging indicators: “A lagging indicator is when something bad happens. A leading indicator is something that you can measure that you think will correlate to the outcome.” But here’s where it gets tricky. As Kris pointed out, truly leading indicators—ones that predict future incidents—are extraordinarily difficult to design: “The problem with trying to create a leading indicator for process safety is that, you know, there’s an infinite number of things that could go wrong and an infinite number of conditions that could exist out there.” Instead, what most organisations end up with are proxies—measures of how well they’re managing known risks. And that’s not necessarily a bad thing, as long as you’re honest about what you’re measuring. Front-Line Scoreboards: Making Data Visible Where It Matters Another practical insight from our conversation was Kris’s experience with front-line scoreboards—physical boards where teams track their own performance metrics. “If you’re tracking the right information and putting it on a scoreboard that is understandable to the people who are doing the work, then those people actually engage with it. They want to know how they’re doing.” This isn’t about surveillance or micromanagement. It’s about giving people the context they need to understand their impact: “They know that they’re there to do a job and they want to know if they’re doing a good job or a bad job... and how to be better at their job.” The key is connecting individual behaviour to outcomes in a way that’s visible and actionable. It’s deceptively simple, but as Kris noted, “Connecting individual behaviour to organisational performance is an inherently complex problem, and replicating it through an organisation is complicated, too.” Complex vs Complicated Work Towards the end of our conversation, we touched on an important distinction that anyone in industrial operations should understand: the difference between complicated and complex work. Complicated work has known solutions—it might be difficult to execute, but the path is clear. Complex work, on the other hand, involves uncertainty, ambiguity, and problems that aren’t well-defined. As Kris put it: “It’s so important not to complexify things. You must come to the simplest solution. And as you gain more knowledge, more skill, more experience, what ends up happening is you recognise how to make things simple and break things down.” The secret? “A desire to not choose to take on too much for myself.” Sometimes the most skilled move is knowing what not to do 🙂 Further Reading If you want to dive deeper into some of the topics Kris discussed, here are two excellent resources he recommended: * HSG 254: “Developing process safety indicators - A step-by-step guide for chemical and major hazard industries” Available free at: https://www.hse.gov.uk/pubns/priced/hsg254.pdf * API RP 754: “Process Safety Performance Indicators for the Refining and Petrochemical Industries” Available (subscription required) at: https://www.apiwebstore.org/standards/754 Annex I is particularly recommended for defining process safety data requirements. * The “useless machine”: https://www.cbc.ca/news/canada/saskatchewan/useless-machine-maker-from-regina-gaining-worldwide-fame-1.1326579 * And you can find the book “Sooner Safer Happier” by Jon Smart in our Mini Book Library. Stay Tuned for More! 🚀 Join the ITOT.Academy (May and September Early birds now available) → Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence. 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

Some guests make you pause halfway through the recording and think, “Okay… this one’s going to need a second listen.” That was the case with Dan Jeavons, president of Applied Computing, formerly VP of Computational Science and Digital Innovation at Shell — and one of the people who has quite literally been shaping how data, AI, and physics come together in industry. From ERP Reports to Foundation Models He began, like so many, somewhere between spreadsheets and SAP. “The biggest value of having an integrated system is the fact that you have an integrated data layer,” he recalls. “I didn’t like the systems much — but the data was really interesting.” That curiosity led him from analytics experiments in R and MATLAB to building Shell’s first Advanced Analytics Center of Excellence — which, as he jokes, “was neither advanced nor excellent… but we got better quickly.” Thirteen years later, he was leading teams across AI, data science, and advanced physics modeling — and wrestling with a problem that every industrial data leader knows too well: “You either rely on physics and trade off flexibility, or you rely on statistics and trade off explainability.” What AI Looks Like From the Plant Floor Dan has worked across the energy value chain — from offshore wells to refineries — and says something that surprises many: “From a data perspective, it all looks very similar.” Distributed control systems, process historians… “whether you’re on a platform in the North Sea or in a petrochemicals plant, the data architecture doesn’t really change,” he says. And that’s what makes the AI opportunity so big. If every facility generates data in roughly the same way, then algorithms can be adapted and scaled — not rebuilt from scratch each time. Why IT/OT Convergence Still Hasn’t Happened At one point, we asked the question: Has IT/OT convergence really happened? Dan didn’t hesitate: “No. We’re only scratching the surface.” He describes today’s operations as “a DCS at the heart of the operation, surrounded by siloed engineering processes — reliability, maintenance, safety — each with their own tool, using a fraction of the data.” Adding AI layers on top of that, he argues, is helpful but incomplete: “We’ve added a layer of intelligence on top of existing systems. But it hasn’t changed the work process yet.” True convergence, he says, will come when AI doesn’t just analyze the work — it redefines it. The Real Meaning of “Digital Twin” Few topics create more buzz (or confusion) than digital twins. Dan gives one of the clearest definitions we’ve heard: “A true digital twin must do three things: represent the physical world, be interrogable in real time, and run simulations that explain why and what next.” That’s a high bar… “The technology exists,” he says. “We just haven’t stitched it together yet.” Change Management: The Hardest Part Dan’s third “impossible problem” isn’t technical — it’s human. “These facilities are extremely risky. They’ve run safely for 40 years. So when you say, ‘Let’s change everything,’ it’s a hard sell.” He lays out the classic resistance: * It works, don’t touch it. * We can’t risk downtime. * We’re here to deliver return on capital, not to experiment. And yet, as he points out: “Even with the way we run things today, we still have reliability problems, we still have safety exposure, and we’re losing expertise fast.” His conclusion is blunt: “Someone is going to figure this out — and when they do, they’ll be 50 % more efficient. If you’re not on that train when it happens… good luck.” Rethinking the Cloud Debate When the topic of cloud reliability came up (AWS outages, anyone?), Dan didn’t dodge. “The idea that you’re safe because you’re air-gapped is a fallacy,” he said flatly. “Most OT environments are already virtualized — effectively private clouds. The question isn’t if you’re exposed, it’s how well you manage it.” The challenge, he says, isn’t cyberthreats — it’s change management in the cloud era. “Continuous deployment doesn’t work in operations. We need cloud architectures that respect industrial change control — and OT vendors who step up to modern security standards.” From Use Cases to Foundation Models Dan’s view of AI’s future is clear: we’re moving from narrow, use-case-specific algorithms to general-purpose foundation models that can reason across disciplines. “Before 2023, companies built algorithms for individual problems: corrosion, valves, compressors. Now, the next generation of models will handle all of them because they understand physics, language, and time series together.” He tells the story of Sam Tukra, his former colleague (now Applied Computing’s co-founder and Chief AI Officer alongside Callum Adamson) who figured out how to make those three domains “talk” to each other. “He built an agentic system that cross-validated physics, language, and time series. I was equal parts proud, frustrated, and amazed. Suddenly, you realize — this is it.” The result is Orbital, their platform that blends these layers — a system that can predict, explain, and reason across disciplines, from reliability to safety to economics. Looking Ahead Dan calls this convergence of physics and AI an “inflection point for industry.” He’s convinced that in the next decade, the companies who embrace it will operate differently — not because AI tells them what to do, but because it changes how they work. So that means that we need to plan for another podcast in a year or so from now ;) Thanks for listening! Stay Tuned for More! 🚀 Join the ITOT.Academy → 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

Today’s guest has lived what most companies are still figuring out: how to turn fragmented systems, manual Excel work, and well-intended “shadow IT” into a coherent Industrial DataOps strategy that actually delivers value. In this episode of the IT/OT Insider Podcast, we sat down with Rija Rakotoarisoa, Group IT Operations & Industry 4.0 Lead at Poclain Hydraulics, a French (international) independent group specializing in the design, manufacture and sale of hydrostatic / electrohydraulic transmissions: motors, pumps, valves, system for off-road or mobile machines and one of the global leaders in hydrostatic transmissions. If you’ve ever found yourself trying to bridge IT and OT while juggling standardization, culture change, and budget cuts… you’ll feel very at home in Rija’s story. From Developer to Industry 4.0 Leader Rija started his career firmly on the IT side: a master’s in computer science, developer turned IT manager, working in a plant where his job was to keep systems running and people connected. Then came the shift. “After five or six years, I felt like I had seen everything. I wanted to do something more than pure IT, something that had a direct impact on the business.” So he went back to school, this time for a master’s in finance. Not because he loved accounting, but because it was his way to “remove the geek tag.” “If you wanted to have more impact, you had to speak the business language.” That change paid off. Rija became both IT and finance manager at one of the company’s plants and learned firsthand what happens when you put technology in service of the business. He used automation to help teams understand their own costs, improve efficiency, and cut the manual data entry that was eating up hours every day. Lessons from Good and Bad Projects In his later roles, including a global Industry 4.0 function, Rija saw dozens of digital projects across multiple plants. Some brilliant, others not so much. “A bad example is when a company rolls out something top-down. They say, ‘This is the strategy, you must implement it,’ without asking the real problems at the plant. It takes time, money, and in the end, nobody uses it.” Sound familiar? The good examples, he says, start from the other direction. From real operational pain points. “When you address the real problem in manufacturing - something that changes the day-to-day of the operational team - then they support you, they use it, and they apply it every day.” It sounds simple, but as he adds, “it’s not.” It takes change management, communication, and people inside each plant who carry the message and help build local momentum. Starting from a Digital Greenfield When Rija joined Poclain Hydraulics, about 6 years ago, it was, as he puts it, “a digital greenfield.” The company had strong IT foundations (infrastructure, networks, ERP), but no consistent support for manufacturing systems yet. “There were many IT/OT projects managed only by operational people. They cared about the end result, but not the implications in term of IT constraints. In the end, you have a big nightmare.” In other words: well-intentioned local initiatives, zero standardization. The kind of environment where every plant has its own version of the truth. So where do you start when the elephant is that big? “We started with the most painful issue: the end-of-line quality control system. Each plant had its own version. We moved from local executable applications to a web-based, centralized one.” Then came work instructions, and so on and so on. It was a classic “bite-by-bite” transformation. How COVID Changed the Game Like many others, Poclain had big plans for a global MES rollout. And then COVID hit. Budgets froze, priorities shifted, and suddenly the grand plan was off the table. “We had to rethink everything. How can we do more with less? How can we use what we already have?” What followed was a shift from “big system thinking” to a more agile, best-of-breed approach. “I always say it’s not a happy event for everyone, but I thank COVID-19,” he laughs. “It forced us to be creative.” That creativity led to the Data Hub project: a pragmatic approach to connecting existing systems, automating data collection, and building live dashboards that operators could actually use. Building a DataOps Mindset The guiding principle was simple: make data useful, make it live, and make it easy for non-IT users. “I didn’t want my team to be the bottleneck. The system should be usable by non-IT people.” That requirement drove their vendor evaluation which eventually led to selecting Litmus.io as their main Data Hub platform. “Since 2021, we’ve been implementing Litmus as our main data hub. Step by step, we break the silos and build on it.” But technology was only one part of the story. The harder part was governance and culture. “It took a lot of time to explain to top management that the Data Hub is just an enabler. It’s not magic. You need something meaningful for the people at the plants on top of it.” Standardization Without Killing Flexibility Today, Poclain’s model combines global consistency with local agility. “We master the data model centrally and duplicate it for each site. Plants can adapt the templates locally by defining their equipments and their mappings, but the core remains the same.” The result? Faster rollouts, cleaner data, and dashboards that update automatically without anyone touching Excel. Rija’s model proves that digital transformation doesn’t have to mean disruption, just the right balance between structure and freedom, one data point at a time. Interested in knowing more about Litmus? A few months ago we published our 5 Step Playbook for a Painless DataOps Rollout: And have you already listened to our Industrial DataOps podcast with John Younes? Stay Tuned for More! 🚀 Join the ITOT.Academy → 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