// Case Study
From data islands to a factory-wide backbone.
A large European food producer · Data engineering · Industry 4.0
When I joined, there was no shared data infrastructure to speak of. Machine data, quality records and production numbers lived in scattered spreadsheets and a patchwork of small databases, one per team, per line, per problem. People worked hard, but everyone ran their own projects and the systems didn’t talk to each other. Anyone who wanted to build something on top of that data, whether a report, an analysis or an AI model, first had to go hunting for it, then hope that what they found was right.
That was the real blocker. An external AI partner was building applications for the business, but scattered, unstructured data made every one of them slower and shakier than it should have been.
So a team was formed to fix the foundation, and I had a strong hand in shaping how it came together. We started by experimenting, and a fair amount of what we tried turned out to be the wrong road. Those wrong turns taught us more than the wins did, and they’re the reason the architecture we settled on held up.
The shape we landed on split cleanly by where the work lived. Ignition ran on the factory floor: pulling data off the machines, storing it in a historian, organising it into a unified namespace, and publishing everything to an MQTT broker. Sparkplug B let devices that couldn’t be wired straight into Ignition join over MQTT instead. A company data lake ingested from that MQTT stream, and another team connected it to the rest of the business’s data sources. OutSystems handled the office side and anything living outside the plant network: reporting, analysis, document processing, and client-facing portals. We also built applications to talk directly to the equipment that runs a food plant: weighbridges, checkweighers, and the like.
One lesson worth passing on: Ignition is open enough that you can build almost anything inside it, so we did, at first, and it bit us. As the logic grew, we moved the heavier pieces out into microservices, running on Kubernetes, and it got far more maintainable. Same story with reporting: we tried it in Ignition, decided it belonged elsewhere, and moved it. Pick the right layer for each job rather than making one platform do everything.
By the time I left, Ignition was running on all five production sites, with roughly half a million tags flowing across the gateways. One site had a full visualisation of every line, SCADA-like but without the control, so people could finally see production as it happened.
The tags and the sites are the easy things to count. What actually changed is quieter: data stopped being something you had to hunt for. Reporting got easier, insight got easier, and any new project that needed data could plug into a foundation that was already there instead of starting from a scavenger hunt. And a plant that can see its own lines is a plant that can start chipping away at downtime and lost efficiency.
The win isn’t a dashboard or a clever app. It’s the structured backbone underneath. Get that right and everything you build on top is easier.