By shift accounts (or team accounts, functional accounts, generic accounts, pick your favourite) we mean one login shared by a whole group: the night shift, the lab, the control room. It’s one of the evergreen discussions in industrial cybersecurity. (We both lost count how many times we talked about this…)

The principle: every interaction needs to be identifiable

Security has a simple key principle: every interaction with a system needs to be uniquely identifiable. That includes the interactions of humans.

And that is exactly why IT is allergic to functional accounts.

Before anyone reaches for the pitchforks: this is not an IT-bashing article. Moving to named accounts really (really) closes a large number of gaps:

1. Authentication and authorisation. With a named account you know who is logged in, and you can make sure people only do what they’re allowed to do.

2. Logging and accountability. When actions are tied to a person, you can answer the “who did this?” question.

1. Deterrence. People behave differently when they know their actions are traced back to them. And it’s not only about your own staff. Generic credentials get exposed more often and are easier to find out, simply because they rarely change. That makes them just as attractive to outsiders.

The reality: not everyone is sitting at a desk

The above 3 points might all be true, but that doesn’t make it easy to implement.

An office worker logs in once in the morning, and then hopefully after each coffee and that’s it. Operators, lab technicians and maintenance crews walk around the plant, share systems with colleagues, and need to act now, not after a login screen. A lab where people have to log in and out every time they move from one instrument to the next doesn’t work.

So instead of arguing yes or no, we need to add some detail. And the first question is: which systems are we actually talking about?

Scope: the middle of the Purdue model

For this discussion we split systems into three groups:

• Control systems (Purdue levels 1–2). These are normally always logged on, with exceptions for distributed or remote systems spread across a large site or even a country. They mostly don’t live in the corporate domain either. Out of scope here.

• Office IT (level 4 and cloud). Corporate laptops and applications managed by IT. Also out of scope.

• Everything in between. The applications you find in a control room, a lab or a workshop, typically sitting around levels 3 and 4: MES, LIMS, ERP, CMMS, even the HR system where you request a holiday or swap a shift. These usually connect to the corporate world and often require a corporate account. This is where the discussion gets heated, so this is where we focus.

(If the Purdue model is new to you, our video explains it. Yes, we drew a pyramid in the video. Yes, we’ve complained about pyramids before. It’s still a handy way to point at levels.)

Five options

The good news: this isn’t black and white. There’s a small menu of ways to manage the risk while still respecting how people actually work.

Option 1: We don’t care. Usability above everything.

“We trust our people.” One login for everything, often on a sticky note on the screen, or written into the work instructions (which conveniently means nobody dares to reset it).

It’s easy. It’s also about as insecure as it gets. The password never changes, so anyone who ever knew it can get in, modify the system, install malware or worse. It’s a hacker’s dream, and David has been involved in more than one incident where an open system like this was abused. We like to think we’re past the admin/admin days. Recent attacks show we’re not...

Option 2: Segregate by user group.

Instead of one account, you create a few generic ones with clearly limited rights. A daily-use account that is read-only or allows limited interaction, and a better protected account for anyone who needs to change the system. You might split them per shift, or keep a dedicated emergency account that is locked down to the bare minimum.

This however does not close the gaps we listed above. You still don’t know who did something. But it limits what a shared login can do, and in some situations it’s simply required.

Option 3: Make individual authentication easy.

This is where it gets interesting. Instead of typing a username and password, people identify themselves with a badge or a fingerprint. Fast enough for a lab environment, and we see more and more companies exploring it.

You can layer it, too: a badge for everyday work, a PIN on top for more sensitive actions, and a second factor for the really sensitive stuff, like changing configurations or installing software.

Badges and fingerprints are still on the less secure side of the spectrum. But it’s a lot better than doing nothing, and there’s a bonus that has nothing to do with security: you get traceability of who did what.

Option 4: Individual accounts and passwords everywhere.

From a security perspective, this has been the default for years. From a change management perspective, it’s a lot harder. People find it annoying, especially on an HMI. On a PC it’s easier to defend.

There’s also a distinction to make: are these accounts managed centrally in the corporate domain, or created locally on each system? And the closer you get to IT, the more you’ll see this option. A technician who needs to interact with the ERP system will, in most cases, already have to authenticate on the domain anyway.

Option 5: Individual accounts with MFA.

This is today’s gold standard, and for good reason: a lot of past hacks started with nothing more than a breached password. Think authenticator apps on a smartphone (hardware tokens less and less), and passkeys for the more advanced setups.

In an industrial setting, though, MFA needs real thinking. You can’t hand every operator or lab technician a smartphone, and in many areas they’re not even allowed to carry one because of explosion protection or other safety rules. And even if we do this, these industrial devices are typically shared devices as well, defeating the purpose of MFA!!

It also adds a dependency: what happens when there’s no network connection at the moment someone needs to log in? You wouldn’t do this on safety-critical equipment without a very serious fallback. And if people need to go through it several times per shift, it quickly becomes unworkable.

So this is the option for the most demanding environments, where impact and regulation leave you little choice.

You’ll probably need more than one

In practice, the answer is rarely one option for the whole plant. It’s a choice per system, and often per action. Option 3 already shows how that works: a badge tap for routine work, more friction as the action gets more sensitive. Viewing results on a lab screen and changing a recipe don’t need the same level of protection.

We hope this shows there’s more nuance in the shift account discussion than “just use MFA” versus “we trust our people”. It’s also a textbook IT/OT cooperation problem: IT brings the principle, OT brings the shop floor reality, and you need both at the table to land on something that’s secure and actually gets used.

If you want to dig deeper into how IT and OT can work together, have a look at our explainer on IT/OT convergence or read our IT/OT Handbook 🙂

Shareable image:

We launched our IT/OT Sales Enablement Academy for vendor sales teams (more on that in a future post, but if you lead a sales team, take a look at our program!)

And yes, the IT/OT Handbook is finally out in the world with already close to 2000 (🎉) copies sold. There are still some delivery hiccups in Europe, but our publisher is on it and that should be sorted in the coming weeks.

That brings us to…
our 2027 IT/OT Academy Core Cohorts:

• Cohort 6: starts 15 January 2027

• Cohort 7: starts 14 May 2027

• Cohort 8: starts 17 September 2027

We still run our 3+1 deal, perfect if you want to join with a couple of your colleagues.

Agenda, pricing and registration →

Our New Community Format: The IT/OT Academy Deep Dives

Until now, the Academy had a clear beginning and a clear end. But our students asked us: is there a way to keep this going? At the same time, we also lacked a place to share what’s happening in the IT/OT market right now. The landscape moves fast, especially with AI.

So we built the IT/OT Academy Deep Dives: a monthly live session where past, current and future Academy students keep learning and networking. Each session goes deep on one topic: whatever is hot at that moment, or whatever we’re working on behind the scenes. Think AI, UNS, knowledge graphs and live builds.

For our very first Deep Dive in November, 60 people have already signed up.
How cool is that? 🙂

And by the way, if you register now for one of the 2027 cohorts, you get access to the next Deep Dive right away!

What’s coming up:

• November: The State of GenAI in Manufacturing. We’re in the middle of some solid research on this and can’t wait to share what we’re finding.

• December: Live-building a UNS on one of our demo environments (more on those below).

See all Deep Dives Sessions →

Data Architectures more than ever front and center

DataOps architectures are a big part of what we teach, and for good reason. Knowing where to start, which components you need, and where certain vendors fit (and where they don’t) is simply too important to leave abstract.

We listened to the feedback of our students and transformed the way we tackle this topic.

In our updated program, the second Academy session is now entirely dedicated to data architectures. We start from our reference architectures for different industries (a refinery is not an industrial bakery). But we also go deeper in the specific problems our students have: we ask for your questions upfront and draw them out live on the whiteboard. And finally, we also take vendor diagrams, talk you through them, and map them onto our capability map, so you can see exactly where their product fits in the bigger picture.

The rest of the programme looks as follows:

• Session 1: Understand, Cooperate, Scale. This is our foundation: how IT and OT really differ, how to set up structures that help them cooperate, and what it takes to scale use cases beyond the first site. It’s the most conceptual session, yet everyone walks away having learned something different, depending on where they come from.

• Session 2: DataOps/UNS Architectures (see above)

• Session 3: You do the work. Sweet Harmony Treats is a bakery in distress, and it’s up to you to either save it or sell it the solution that will. End users design the architecture, plan the project and build a business case for the board. Vendors and integrators sit on the other side of the table: who are the buyers, what blocks the deal, and how do you sell in a way that scales? (That vendor perspective was added on popular demand.) In the debrief, you hear how other groups tackled the same dilemmas. There’s no single right answer and no prize to win. The value is in seeing how differently people make the same trade-offs.

• Session 4: Practitioner panel and Q&A. We invite people who’ve actually done it. Past guests came from a water company, a candy factory, a dairy plant, a bakery and a harbour, covering topics such as merging IT and OT organisationally, UNS in practice, MES at scale, and adding AI on top of it all.

Prefer to hear it from us?
Watch the video where we walk through every session!

See you in 2027

Whether you work in a factory, build software for one, or help others get it done, the Academy gives you the frameworks, the vocabulary and the network to bridge the gap between IT and OT. Thanks to the Deep Dives, it no longer ends after four Fridays.

Book your seat for 2027 →

We hope to see you there!

David & Willem

(And if you want to see what other people have to say, take a look to our ever growing Hall of Fame)

In this article we want to be completely transparent about how. Writing a good article takes a lot of time and effort: each line you read has been rewritten and reread multiple times. A single article takes us about 6-8 hours of writing, on top of days or weeks of research and discussions with specialists. So anything that supports that process is welcome.

Here is where we use AI, and where we don’t.

Where we use AI

1. Coding
   Does this need explaining? We hope by now everybody uses, or at least experiments with, AI-assisted coding. We use it for our websites and, more importantly, for all the demos we build for our IT/OT Builds and our Academies.
   By the way, here is a fun way to lose your next weekend: we have published our full Sweet Harmony Treats UNS Demo and Haltenberg Chemische Werke environments on GitHub 😀
   

2. Research
   A huge time saver. What used to take days or even weeks now takes less than an hour.
   Before tackling a new domain or subject, we have AI create a ±30-page discussion paper with a long list of references to kickstart our own process. We prioritise independent and academic research where possible, and we use these papers as a starting point, not as the end result.
   

3. The website
   Is the time of hiring webmasters over? At least for small, engineer-led companies like ours, probably. We rely heavily on AI to maintain and expand our website and to improve layout, readability and searchability. However, all original content is still ours.
   

4. Podcast and video transcripts and summaries
   Each podcast and most videos come with an article on our blog that summarises the discussion. These summaries are made with AI, based on automated transcripts. Of course, we read them ourselves and the people we interviewed vet them before we post anything.
   Every video also ends up in our video archive. That archive is super helpful because we, and search engines, can easily find something discussed in a video. The entire archive is built with AI workflows, from transcript to summary. Luckily, it’s still us and our guests in the videos, with no plans to switch to avatars any time soon.
   

5. Text and article editing
   This is one we picked up while writing the book. When writing, it helps to have an extra pair of eyes to check for issues and inconsistencies. We use AI in two ways:

   1. Structural editor: checks for gaps in the logic (e.g. we’ve cut so much text that it becomes confusing for the reader), balance, repetition, consistency in voice (am I writing as “we” or “I” to you, the reader?) and more.

   2. Copy editor: we’re not native speakers, so we use AI to check grammar, spelling, clarity and consistency.

We don’t simply accept what the AI proposes. We treat it as suggestions on what could be rewritten, but always in our own voice.

Where we do it ourselves

1. Our Book
   The IT/OT Handbook is written by us and edited by our publisher. Not by AI. However, as stated above, it’s extremely useful to use AI to help us in the editing phase. Our publisher IT Revolution has a very good article on their AI usage as well. Every IT Revolution author – that includes us – works under their formal AI policy, which rests on a simple premise: Original human insight, expertise, judgment, and authorship are essential to every IT Revolution publication.
   

2. Articles
   The words you read are ours, in our voice, even the em dashes. We try to keep each article focused on a single idea, at ±800 words. You might know the quote from Blaise Pascal: “I have made this one longer only because I did not have the leisure to make it shorter”. It’s absolutely true. Getting to 800 words means a lot of cutting and discussing what exactly we are trying to convey.
   Our goal is to make the topic so clear that you don’t just understand and remember it after one pass, but understand it well enough to explain it to somebody else. That’s the only way these ideas spread.
   

3. LinkedIn
   We admit, we tried it. But in the end, the best way to be noticed in a sea of AI slop is not to write AI slop. So yes, we add those stupid emojis intentionally and take a hot shower afterwards to feel clean again.
   

4. Research and reading
   Wait, didn’t we just say we use AI for research? We use it to get started, but we still check the references and read them, often printed out on paper with lots of notes and discussions between ourselves and others (fun fact: that still works so much better).
   

5. Images
   We don’t use many images in our articles, and when we do, they are normal stock photos. Our Academy certificates are made by real artists, without AI. Maybe the odd infographic, but only to save some time (we’re not graphic designers, after all…).

Why we believe it’s important to share this

In a world where we are drowning in content, knowing which sources are worth your time is more important than ever. Credibility is key, and being transparent about where we use AI is part of that. That’s why, going forward, we’ll clearly label every article as AI-generated or not.

That’s a wrap!

This article was not generated by AI.
To learn more about how we use AI, start from the top.

Addendum:
Here’s an example of the type of feedback we use:

Structural edit:
 The opening is still slow. The promise to be transparent doesn’t arrive until paragraph 3. A one-line statement of the policy up front would fix that.

Copy edit (largest issues only):
 “even more content than ever before ever since” repeats itself, so cut it to “more content than ever since LLMs came on the scene”
 “if I would be interested” → “if I were interested”
 “luddites in the IT/OT Insider” → “Luddites at IT/OT Insider”
 “so that you know” → “so you know”

Well it’s not all bad. Some companies really do get the most out of their data. They don’t just build dashboards; they’ve changed the way they work on the shop floor, and some have even come up with new business models. (Not coincidentally, those are also the companies experimenting quickly with AI today)

And then there’s everybody else. Plenty of manufacturers where an Excel file with a few macros (or some Python scripts, if you’re feeling modern) is still the pinnacle of digitalisation.

Industry 4.0 came with a vision. It didn’t come with a manual.

So let’s look at the three most common traps first, and then at how to avoid them in this video, and as text below the video!

The Three Traps

Trap 1: We confused connectivity with transformation

The early focus of most Industry 4.0 programmes was on connecting things: a new wireless IoT sensor here, a connectivity project there. Visible, tangible, and easy to put in a business case.

But connecting machines is not the same as changing the way people work. A dashboard on its own doesn’t translate into lower costs or better products. Data availability doesn’t create accountability, ownership or process redesign.

Connectivity is simply a lot easier to sell than change. It’s also more exciting to talk about the new stuff. Change doesn’t sound very sexy. It sounds like hard work, and that’s because it is.

We see this in our own work too. Whether it’s in the Academy or in workshops, people almost always walk in with a technology question first. The change question comes later, if it comes at all.

Trap 2: We ignored that IT and OT live on different clocks

Nothing new here, but it keeps biting us. OT lifecycles span decades: 20 to 30 years for many assets isn’t unusual. Qualification, safety, uptime and vendor support all mean you don’t swap out a control system just because a newer version came out. Meanwhile, IT lifecycles keep getting shorter. We used to talk in years; now it’s sometimes months.

And the lower you go in the Purdue model (or whatever you prefer to draw instead of a pyramid), the slower the lifecycle. That’s very hard to change, so you need to accept it.

Now picture your shiny new AI tool that needs to talk to a 30-year-old legacy system. Exactly.

Industry 4.0 never really tackled this tension between fast and slow lifecycles, or the very different priorities that come with them. The good news: there are ways to work around it. We’ll get there.

Trap 3: We got a vision, not a roadmap

There is no standard five- or ten-step plan to go from a disconnected to a fully digitalised, integrated shop floor. So where do you start? There are so many solutions and technologies. Some vendors promise a complete ecosystem; others offer a very well-designed point solution for one specific problem.

It all boils down to knowing which problems you want to solve on the shop floor. And no, “connecting systems” is not the answer. It’s a step towards it at best.

The other half of the answer is architecture. Willem has a habit of asking every architect he meets how they define architecture. Each one gives a different answer. Our favourite comes from Martin Fowler: architecture is about the important stuff, whatever that is. You need to define what that important stuff is for your company, because it won’t be the same as for anyone else.

In practice, architecture is the set of choices that are hard to reverse. You’ll often live with them for ten or even twenty years, because migrations are expensive. And here’s the cruel part: you have to make those choices at the very start, exactly when you know the least. Get them wrong, and you find out the hard way:

• Your data is stuck and can’t be integrated into your enterprise data strategy.

• Your vendor’s portfolio turns out not to follow your use cases as your needs evolve.

• You’re expected to keep pace with technology (AI being the obvious example) but you don’t have the flexibility to do that quickly and efficiently.

That last one is becoming more and more important. Change moves so fast now that you can’t start a two-year project and hope for the best; by the time it’s finished, it’s outdated. The end goal is a moving target. So it’s not about implementing the right architecture in one go. It’s about building in the flexibility to keep changing, for needs you don’t even know about yet.

We noticed how confusing this is for many people. When we started the ITOT.Academy, architecture was only a small piece. The feedback from our first hundred students was crystal clear: give us more. More architecture, more insight into how vendors fit into the landscape, more guidance on running an architecture workshop yourself. That’s why we now have two full sessions on data architecture.

How to avoid the traps

1. More connectivity, but between people

Our first trap was too much focus on connectivity.
The solution? More connectivity. Just of a very different kind.

What’s missing in most organisations is the connective tissue between IT and OT. It’s the soft side, and it’s exactly what makes the difference when it comes to digitalising production.

It starts at the top. Your COO and CIO (or whatever those roles are called in your company) need to share a vision and truly commit to it. If they don’t, don’t waste your time. Changing an entire company from the bottom up is incredibly hard.

Then comes the next mistake. “Great, we have a mandate. Now you shall work together. Or else.” We know how that goes. Cooperation isn’t an on/off switch. It takes deliberate organisational design: cross-functional teams where both IT and OT own the outcome, and a conscious choice about how they cooperate. That’s exactly why we developed our cooperation patterns.

Trying to do this alone is the number one mistake we see. If you have one year for your project, you’re far better off spending six months building that shared vision and approach, and six months delivering, than spending a full year moving alone.

And start small, but think big. Neither is optional. Don’t attempt a marathon if you’ve never run a 5K. Small projects bring early wins, but more importantly, they are training in cooperation. Much better to learn that in a low-stakes environment than in your major transformation. Pick that first use case strategically: one that delivers fast success but can grow quickly, and that lays the foundation of your architecture so the next use case becomes easier. Yes, it’s a bit slower. The investment will pay off. And if your management doesn’t understand that, just don’t tell them. They won’t notice.

2. Decouple your IT and OT architecture

Connecting people: yes, absolutely.
Tightly coupling systems: a big fat no.

We’ve lost count of the AI start-ups that proudly tell us they can connect to every machine we have. All they need is a REST API, or OPC UA. Unfortunately, most of our machines don’t speak REST. Or even better: “It works great, as long as you send your data to our API endpoint.” How you make that happen is your problem.

IT/OT convergence doesn’t mean both worlds should become the same. They’re not, and they never will be. So stop trying to turn OT into IT, or the other way round. Instead, design your architecture so that IT and OT can each grow according to their own needs and their own lifecycles (We wrote an article and also have a very interesting video about IT/OT Convergence which you really have to take a look at!)

That is exactly what a modern operational data platform is for. It’s the technical bridge between both worlds. On one side you have connectivity to the shop floor. At the heart of the platform sits contextualisation: ontologies and an understanding of the physical manufacturing world, which is still not that common in IT. And on the other side, connectivity to the rest of the world. We walk through it in detail in our Industrial Data Platform Capability Map video.

Which brings us to the point we’d underline twice: treat context as infrastructure. Context is what turns data into profit. Without it, your dashboards, workflows and AI applications won’t scale beyond the pilot phase. Build it once, as a foundation, not again and again for every one-off.

3. Build the skills, don’t outsource your brain

You don’t need 1,500 experts in every tiny domain. But you do need a couple of good people who can make the right decisions, because architecture is about the stuff that’s hard to change. Without the skills, you’ll choose the wrong thing.

Which skills? Not necessarily understanding a specific protocol. That’s easy to outsource. What matters most:

Understanding the problem you’re trying to solve. No matter how fancy the tool, if it doesn’t help anybody, it’s a waste of money. We do this for the people on the shop floor, not for the technology.

Translating that problem into technology and architecture. If you sit between IT and OT and you don’t do it, who will? You can’t make architectural choices you’ll live with for years, sometimes decades, based on sales pitches and pretty slides.

Can you outsource that? Partly. But ask yourself who the people making those decisions for you are working for, and whether they’ll still be around. Not for months, but for years. Of course the vendor will send an architect, but their goal is to sell more of their own products, and that’s not necessarily your goal. Outsourcing this is dangerous, and as complexity grows it becomes impossible. This is permanent work, not a one-off. And these choices make the difference between a system that evolves quickly and an expensive disaster of a project that never delivers.

The skills to execute. A good partner, integrator or vendor with experience in your problem space is key. But they can’t take on every responsibility. You need your own people to go in, make the change happen, and navigate internal politics. That part you simply cannot outsource.

Two principles follow from this:

• Start as a project, but end as a product. You need long-lived expert teams, not a series of one-offs. Treating digital as a string of projects is a mistake that can cost organisations millions.

• Own your landscape. If you want to move at the speed of IT, you need to own and understand your architecture, and have the freedom to adapt it. If your vendor is the only one who understands your landscape, you won’t get far. Bridging the gap between the sales pitch and reality takes a lot of work and expertise.

People, technology and architecture: together, that’s what gives you the skill to execute.

Final thoughts: Drop the “4.0”?

Maybe it’s time to drop the name altogether. “Industry 4.0” was a label for digitalisation in production back in 2011. It was never a destination. Technology has changed enormously since then, and honestly, we’re a lot further than we were.

But contextualising and connecting everything in a seamless and secure way is simply hard. Don’t give up, especially not now that AI is speeding everything up. Stop now and you’ll be left in the dust by competitors around the world.

Instead, get better at the boring things:

• Architecture

• (Product) ownership

• Lifecycle management

• IT/OT cooperation, to deliver the right thing the right way

If we had to summarise it: understand each other, cooperate in the right way, and scale technically in the right way. That’s what the IT/OT Handbook is all about.

And if you want to go deeper on architecture, cooperation and industrial data platforms with a group of peers, join us at the ITOT.Academy.

The programme is better than ever. There’s even more focus on practical guidance, including where to start with modelling, and we’ve updated the content to better serve the vendors and integrators in the room.

The 2027 cohorts start on:

• 15 January

• 21 May

• 17 September

In this Mini Insider: our book, a brand-new website and video archive, a few places you might have spotted us lately, and some friends worth following.

Next week: The IT/OT Handbook is here 📘

Let’s start with the most important moment of our year: our book releases next week!

We can hardly believe we’re writing that sentence. To mark the occasion, we recorded a “What is The IT/OT Handbook” video. If you’ve been wondering what it’s all about, this is the quickest way to find out.

Get our book

New from us: our Video Archive

We’ve launched a completely new itotinsider.com. Go have a look around!

What you’ll probably like most, though, is our new Video Archive at https://watch.itotinsider.com/. Every video we’ve made now lives in one place. It’s indexed, it’s searchable, and it comes with full transcripts.

You might remember that one podcast episode where someone explained MQTT vs OPC UA really well, but not which episode it was. Now you can simply search for it.

Go to our video archive

ITOT.Academy: 2027 cohorts now open

Our https://itot.academy/ page also got an improved look. More importantly, our 2027 cohorts can now be booked!

The programme is better than ever. There’s even more focus on practical guidance, including where to start with modelling, and we’ve updated the content to better serve the vendors and integrators in the room.

The 2027 cohorts start on:

• 15 January

• 21 May

• 17 September

Book your seat

But wait, there’s more: in a couple of weeks we’ll be launching our IT/OT Academy Deep Dives. More info very soon!

IT/OT Compass: our advisory services

David has been advising both manufacturers and technology vendors for years now, so this isn’t really new. We just wanted to make it ‘official’ ;)

Where do we typically come in? For manufacturers, that’s moderating workshops or helping to build a digital vision and roadmap. For technology vendors, it’s usually about sharpening their go-to-market story and strategy.

Curious? Everything’s on https://itotinsider.com/compass/

Learn more

Spotted in the wild

Over the last weeks we’ve been featured in quite a few media. A big thank you to everyone who invited us! In case you missed them:

From the community

A couple of things from friends of the blog that we think deserve your attention.

Scholar, by Exponential Industry. Our friends at Exponential Industry have launched Scholar, a search tool for industrial technology jobs. You can filter by technology niche, which ranges from industrial automation, PLC and SCADA to robotics, energy storage and advanced manufacturing. You can also filter by location and by company or alumni network. It’s worth a look whether you’re exploring a next step yourself or just curious where industrial tech talent is in demand
→ https://exponentialindustry.com/scholar/

Unplugged — An IIoT Podcast Newsletter. This newsletter offers practical IIoT and industrial automation insights for people working at the IT/OT convergence. You get real practitioner perspectives, emerging trends and highlights from the Unplugged podcast, straight to your inbox.
→ Subscribe for free: https://unpluggediiot.com/subscribe

That’s it for now.
The next time we write to you, our book will be out in the world 🎉

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.

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.

Subscribe now

🚀 See you in the next episode!

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

Spotify Podcasts:

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

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?

Subscribe now

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.

Subscribe now

🚀 See you in the next episode!

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

Spotify Podcasts:

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

Short answer: yes, if you believe the marketing. We’ve all seen the videos: lights-out factories, humanoid robots pulling off backflips. If a machine can do gymnastics and prove theorems, surely it can keep an eye on your reactor too?

Long answer (this article and our new video 😀): most of the sites we visit aren’t there yet, and getting there might be genuinely hard. That doesn’t mean giving up. There’s a lot of useful AI work available even if your plant looks nothing like a Silicon Valley demo reel.

Quick interruption before we get into our new video and article:
📖 We’re publishing this a month before our book, the IT/OT Handbook, comes out, and we need your help beating the Amazon algorithm overlords. If you pre-order (or leave a review once it lands), that genuinely is the only lever we have for visibility, and pre-ordering also gets you into our virtual lounge event.
Pre-order at itotbook.com →

🙋 And really really the last call for our next IT/OT Academy which kicks off September 18 with an updated program.
Join the ITOT.Academy (new cohort in September) →

The dream, from a technology angle

Start with what people actually picture when they say “AI running the plant”: a system that sees everything, understands everything, and can take the physical action needed on the shop floor. That’s not complete fiction. Lights-out warehouses have existed for a while now, taking an order from click to picked, packed and loaded onto the right truck with barely a person in sight.

What makes that possible isn’t just AI, though. It’s a structured, often repetitive environment with automation designed in from day one, paired with a genuinely good digital twin the system can simulate and act on. Car plants (or parts of them) work the same way. And yes, the line between “AI” and “just very clever automation” is getting blurry. Vision systems, how robots get trained, cameras sorting potatoes by grade: this stuff has genuinely changed in the last five years, not just been rebranded.

However… most industrial processes don’t have that luxury.

No greenfield, no perfect digital twin, decades of brownfield reality instead. If that’s you, the good news is that current AI tools happen to be good at something else entirely: knowledge.

Where the real opportunity is: knowledge, not control

We’ve spent years turning signals into data: building historians, contextualising tags, optimising how we handle time series. What we mostly left untouched is everything that doesn’t come from a sensor: manuals, procedures, shift reports, maintenance notes, incident reports, P&IDs, SAP work orders, emails, and the things an experienced operator just knows (low pressure plus high temperature plus high rotation speed means watch out for cavitation). Before generative AI, none of that was something you could automate. You needed a person to hold it all in their head.

Take a maintenance engineer trying to work out why Pump P101 has been losing performance for three weeks. Traditionally, that means:

• finding the pump

• pulling up the P&ID

• querying the historian for anomalies in process conditions over the past weeks

• checking OEE and downtime events

• digging through SAP maintenance history

• finding the manufacturer’s manual

• looking at the P&ID again

• reading the shift reports

• mentally correlating everything

Building software to automate that used to be a Herculean integration project. Now, an agent can (in theory):

• read the shift reports

• query the OEE database

• retrieve the SAP records

• look at the historian trends

• find the pump manual

• understand the P&ID

• combine the evidence into a first-pass analysis, or help the engineer brainstorm

Will it replace the engineer? Almost certainly not, at least not beyond the obvious cases; even with all the data in hand, a proper investigation can still take a dedicated team days or weeks. But it can get them started a lot faster. And that, we think, is where industrial AI’s first real win will come from. Not the autonomous-control dream everyone’s been sold, but autonomous investigation.

From copilot to autonomous investigation

If an agent can do all of that on request, the next question is obvious: what’s stopping it from doing it continuously, on its own? Watching your data around the clock, surfacing an anomaly, drafting a maintenance notification, summarising a shift, finding similar past incidents, recommending a procedure, preparing a work order, or simply routing the right information to the right person.

That’s a far easier problem than closing the loop with autonomous control, and it doesn’t require redesigning your brownfield plant to get there.

What it takes

On the technology side: contextualisation, asset models, naming conventions, DataOps discipline, and increasingly the ontologies and knowledge graphs that let tacit engineering knowledge sit alongside your data rather than only in someone’s head. We’ve published plenty of content about that, for example our Industrial Data Platform Capability Map.

On the organisational side, it’s simpler to state and harder to do: this isn’t something IT or OT can solve alone. If both sides keep working in silos, none of this happens. We’ve written about that at length in our “What is IT/OT convergence?” explainer.

Don’t forget: Starting today is always the better option

Picture two factories, ten years from now. One still has its historian, SAP, manuals, shift reports and engineering documents sitting in their own silos. The other has agents continuously working through those same sources, surfacing anomalies, opportunities and maintenance insights as a matter of course.

You probably don’t want to be the first factory.

If you want to get past the buzzwords and actually dig into digitalising manufacturing, head to itotinsider.com for more free content, itot.academy if you want to work through this together with us, or grab the book at itotbook.com or your favourite bookseller.

Subscribe now

Willem & David

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

Stand up if this sounds familiar

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

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

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

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

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

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

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

The Oprah moment

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

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

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

Why this is the video to watch on cooperation

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

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

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

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

Your cooperation language

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

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

What to actually do about it

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

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

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

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

Patrick would thank you.

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

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

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

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

Willem & David

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

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

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

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

IT/OT convergence.

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

The What: Two Kinds of Convergence

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

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

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

The Why: Three Waves

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

Wave 1: Infrastructure Convergence

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

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

Connectivity is never free.

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

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

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

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

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

Wave 3: Data & AI Convergence

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

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

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

So, Is IT/OT Convergence Real?

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

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

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

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

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

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

Talk soon, Willem & David

Subscribe now

Shareable image:

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

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

What do we even mean by “ontology” here?

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

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

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

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

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

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

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

Modelled or discovered?

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

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

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

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

Democratising context, not just data

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

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

Doesn’t that just mean chaos with extra steps?

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

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

Nail it, then scale it

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

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

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

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

Stay Tuned for More!

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

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

Subscribe now

🚀 See you in the next episode!

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

Spotify Podcasts:

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

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

The $1 trillion question nobody’s asking

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

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

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

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

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

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

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

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

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

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

Stop buying tools. Start buying outcomes.

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

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

His three non-negotiable foundations:

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

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

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

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

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

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

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

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

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

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

Final thoughts

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

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

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

Stay Tuned for More!

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

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

🚀 See you in the next episode!

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

Spotify Podcasts:

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

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

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

Where the structure came from

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

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

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

Step 1: Understand

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

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

Start reading here:

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

• ISA-95 and the Purdue Model explained

• Ceci n’est pas IT/OT convergence

• Let’s talk Manufacturing Execution Systems

Step 2: Cooperate

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

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

Start here:

• IT/OT Cooperation Models

• IT/OT Cooperation Models: A Field Guide

• Ceci n’est pas IT/OT convergence

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

Step 3: Scale and Sustain

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

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

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

The essentials:

• Industrial Data Platform Capability Map (v2)

• What I don’t like about UNS

• The Digital Journey Model

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

The one chart you really need to understand about scaling:

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

Why our framework is a loop, not a ladder

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

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

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

And this is what it looks like as a book…

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

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

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

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

Want to learn more?

• 🙋 Join the ITOT.Academy

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

Subscribe now

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

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

Right, back to the IT/OT Academy…

Next group starts September 18

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

The biggest change is what we cut.

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

What you get

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

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

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

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

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

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

Curious what a seat looks like in practice?

→ Explore the full programme

Why our first 100 joined

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

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

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

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

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

The IT/OT Academy is trusted by learners from

The updated programme

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

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

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

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

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

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

What people are saying

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

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

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

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

Is the Academy for you?

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

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

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

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

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

→ Grab your seat via ITOT.Academy

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

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

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

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

IIoT Platform vs Historian

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

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

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

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

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

The M2M → IIoT → AIoT evolution

Time for a history lesson!

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

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

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

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

The part most people still skip: Context

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

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

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

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

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

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

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

Should you vibe-code your own IIoT platform?

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

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

The problem is in the word “looks.”

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

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

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

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

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

Finding the right use case is harder than it looks

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

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

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

About Cumulocity

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

Learn more about Cumulocity

Stay Tuned for More!

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

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

Subscribe now

🚀 See you in the next episode!

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

Spotify Podcasts:

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

Before we start…

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

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

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

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

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

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

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

From broker to MQTT+

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

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

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

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

Open source in industrial settings

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

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

Subscribe now

The answer right now is no.

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

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

Vibe coding and the architect problem

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

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

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

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

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

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

Contribute or follow along

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

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

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

Stay Tuned for More!

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

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

🚀 See you in the next episode!

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

Spotify Podcasts:

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

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

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

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

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

Fifty projects. One persistent frustration.

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

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

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

The 3 Smart Manufacturing Imperatives

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

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

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

What i3X is

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

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

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

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

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

Why it matters beyond the API.

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

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

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

Extra Resources

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

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

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

Stay Tuned for More!

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

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

Subscribe now

🚀 See you in the next episode!

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

Spotify Podcasts:

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

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

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

Every new technology comes with unknowns.

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

Can We Learn From History?

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

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

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

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

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

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

The Trust Ladder (with APC as an example)

A story about trust…

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

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

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

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

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

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

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

This is where Industrial AI platforms have to prove themselves.

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

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

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

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

The Example (Hill’s Pet Food)

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

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

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

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

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

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

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

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

About TwinThread

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

More about TwinThread

Stay Tuned for More!

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

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

Subscribe now

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

Image to share:

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

Meet Kevin (and dataPARC)

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

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

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

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

What actually makes a historian

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

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

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

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

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

From sensor data to semantic layer

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

That principle has only grown more important.

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

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

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

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

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

Closing thoughts

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

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

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

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

About DataParc

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

More about dataPARC

Stay Tuned for More!

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

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

Subscribe now

🚀 See you in the next episode!

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

Spotify Podcasts:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Subscribe now