Why Factory AI Fails Without a Data Foundation
Meet PLCnext Technology, a networking powerhouse bridging IT and OT with ease. Powered by open Linux-based controllers, it supports industrial protocols like OPC UA, MQTT, PROFINET, and PROFIBUS and various more protocols, giving your machines full communication fluency across legacy and modern systems alike. From edge to cloud, PLCnext Technology keeps your data flowing seamlessly.
Explore PLCnext TechnologyIn this episode of Unplugged: An IIoT Podcast, hosts Phil Seboa and Ed Fuentes sit down with Alexander Kruger, co-founder and CEO of United Manufacturing Hub (UMH), to talk about why most industrial AI projects stall before they start, what a real data foundation looks like on the shop floor, and how open source tooling is reshaping factory data architecture from the ground up.
Alexander started as a mechanical engineer who ended up building machines, then pivoted into software. Eight years ago, he and his co-founder Jeremy launched a boutique systems integration and consulting firm, partnering with McKinsey on manufacturing digitalization projects. The work sounded impressive on paper. In practice, it meant laying cables, installing HPCs, and building Grafana dashboards.
The recurring problem was access to context. "You go into factories with the McKinsey team saying, we have two weeks, what's the OEE?" Alexander recalls. "And then you're standing in front of the machines asking, how should I get it? The data is still in the PLC. We need to ask the vendor." That frustration became the founding motivation for UMH: make access to data and context easier for the people trying to build something useful with it.
When Alexander started, connectivity required heavy retrofitting. Machines were older, interfaces were locked behind vendor negotiations, and the whole IoT platform wave (PTC's ThingWorx, for example) was promising big and delivering little. Two things shifted. First, the technical barriers dropped. PLCs now ship with open interfaces, and you can connect to most equipment with the right tooling without vendor gatekeeping. Second, the relevance of data infrastructure climbed, driven in large part by AI hype. Organizations that once ignored the foundation now recognize they need it, even if many still lack clarity on what "data foundation" means in practical terms.
The automation engineers on the shop floor always understood the value. "They always knew," Alexander says. "I have a lot of unplanned downtime in this area, and I need more data points to drill down into why." The difference now is that leadership cares too.
Alexander is blunt about what separates successful implementations from failed ones: you start with the use case, not the technology. "A lot of our customers start with an obvious use case they just never got around to implementing," he explains. Energy monitoring across metering points, real-time downtime analysis, or granular OEE broken down to the machine level.
From there, he outlines a five-step process. First, map all data sources and identify what information each machine can provide. Second, define what a data product looks like per asset class (CNC machines, fillers, pasteurizers), regardless of vendor, age, or revision. Third, structure and connect the data. Fourth, automate the serving layer to push data to applications, whether that's Grafana, a Microsoft Fabric stack, or something else. Fifth, layer in the context that automation engineers carry in their heads. The infrastructure follows the use case, not the other way around.
Phil asks whether factories in Germany and Europe are deploying AI in real production or still talking about it at conference level. Alexander's answer is measured. "Everybody thinks AI is this omnipresent world model which you can pipe data into, and it tells you where to improve production. Production is way too complicated for that."
What he sees working is more practical: applying IT-native AI capabilities to OT problems. Maintenance workers and automation engineers get vibe-coded front ends, HMIs built by AI, and MES workflows generated from natural language. "Everybody knows business logic and processes and what to automate, but they don't know React, JavaScript, and microservice architecture," he says. AI bridges that gap. It puts tools in the hands of the people who understand the process but lack the programming skills.
He's careful to add a safety caveat. Agentic workloads operating inside connected factories raise real security concerns. "Giving the AI the data without giving up the access and the control, and having a lot of guardrails and checks in between which can't be AI automated, is the key to success."
When Ed asks about the technology stack that supports all of this, Alexander makes a case for boring, proven tools over shiny new ones. "I think the more boring technologies are actually better."
For data transport, UMH runs on Kafka. Unlike MQTT, Kafka guarantees end-to-end transactions. "You want to finish that work order? It goes and finishes, or it pushes it back and tells you it didn't work," Alexander explains. For storage and context modeling, they use Postgres, a database well suited for relational data (products to batches, batches to machines, machines to areas) that manufacturers deal with daily.
The key insight: neither technology is new or exciting, but both are rock-solid, well-tooled, and vendor-agnostic. You can host them on AWS, Azure, Google, or on your own hardware. Alexander argues this independence matters more than features. "Think about lock-in resistance so that you actually have the technology that serves you for decades."
They've deliberately hidden the complexity. Kafka runs inside Docker containers in UMH so that OT users never see or configure it directly. "People got confused about why you're putting Kafka on a shop floor," Alexander admits. "Now it's just inherently bundled inside the Docker container. You communicate with OPC UA or MQTT, but have all the guarantees and throughput of Kafka hidden."
The conversation turns to containerization and how Kubernetes solves problems that OT has been wrestling with for years. Traditional high availability in manufacturing means running two identical systems side by side with hardwired heartbeat integrations. Alexander points out that IT solved this decades ago. The split-brain problem (what happens when the heartbeat connection fails and both systems think the other is down) is handled natively in Kubernetes.
"There comes so much free resilience with this approach versus going VM on a Windows server and then somehow putting high availability on top, where it was never designed for that," he says.
Ed asks what traps people fall into when getting started. Alexander calls it "death by a thousand cuts." On the surface, the process looks simple: connect machines, format data, push it somewhere, use it. In practice, you face unstable network connections, OT switches that behave unpredictably, protocol connectors that need to handle connection drops and reconnections, back-pressure scenarios when a downstream database goes offline, and the challenge of giving OT staff tooling to model thousands of tags across hundreds of machines in a governable, versionable way.
Then there's scale. Once you get one plant working, you need to replicate across 50. Monitoring, standards compliance, and deployment orchestration all become their own problems.
UMH is open source by design. Alexander ties this directly to the people he's seen drive change inside large organizations: frustrated engineers who build their own solutions with Grafana and open source tools because corporate IT's two-year platform rollout never solved their problems. "I would look specifically top down for those people who already built something and then try to learn from them," he says. "This is also the reason we're open source. We believe in those forerunner power users who will change the organization from within."
The UMH learning hub (learn.umh.app) provides education on technologies from a problem-first perspective, so users can build on proven patterns instead of repeating mistakes.
Alexander sees the next phase as AI-native OT software. His co-founder Jeremy already spends $5,000 a month on cloud credits for AI tooling, a signal of how deeply AI runs through their development process. The vision: hand UMH a machine handbook PDF and have agents configure the data pipelines, bridges, and models automatically, with humans correcting and monitoring.
They already have a UMH skill for Cline (a coding agent), and they're building a dedicated CLI for Q2 2026 that wraps enterprise governance, authentication, and encryption around an agentic interface. "This then combined with the existing UMH Cline skill should be a game changer about speed and efficiency," Alexander says.
Alexander and the UMH team are building from a position that most industrial software companies do not occupy: they started as system integrators, ran into the same problems their customers face, and built the tooling to solve them. The data infrastructure layer (connectivity, modeling, serving, and storage) remains the hardest and most underappreciated part of any factory digitalization project. UMH's bet is that open source, Kafka, Postgres, and AI-native tooling can make that layer fast enough and simple enough for the people who actually run factories to own it themselves.
Alexander Kruger is the co-founder and CEO of United Manufacturing Hub (UMH). He trained as a mechanical engineer in Germany before co-founding a systems integration firm focused on manufacturing digitalization. That experience led him to build UMH, an open source data infrastructure platform that helps manufacturers connect machines, model data with context, and serve it to applications and AI workloads. Alexander is based in Germany and speaks regularly on factory data architecture, the unified namespace, and AI readiness in manufacturing.
PLCnext Technology is the open ecosystem for industrial automation from Phoenix Contact. It brings together open hardware, modular engineering software, a global community, and a digital software marketplace to bridge the worlds of IT and OT.
Digitalization and globalization are placing new demands on industrial automation. The precisely tailored design of the open automation system is just as important as flexible, modular expansion. In addition to standard programming of PLC systems in accordance with IEC 61131-3, parallel programming and the combination of programming languages such as C/C++, C#, and Matlab® Simulink® in real time is also possible with PLCnext Control. Accelerate your application development process with the free basic version of PLCnext Engineer, or use your familiar programming environment.
With simple cloud integration, the option to use open source software, and the ever-expanding expertise of the PLCnext Community, you will benefit from new forms of collaboration. The resulting solution apps, software modules, runtime systems, and function extensions are available in the PLCnext Store and save an enormous amount of time and money when creating applications. This makes PLCnext Technology the ideal ecosystem for your modern automation challenge.