From Platforms to Outcomes: Vatsal Shah on What Industrial AI Actually Needs

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.

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 propos

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!) →

(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 re

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!) →