Implementing Data Mesh in Manufacturing: Overcoming OT/IT Silos

I’ve spent most of my career on the plant floor side of the fence. I’ve programmed PLCs, tuned SCADA screens, and chased a flaky OPC server at 2 a.m. because a shift supervisor swore the line “just stopped talking to the HMI.” So when our corporate data team showed up with a slide deck about “data mesh” and asked us to treat machine data as a “product,” I rolled my eyes. We’d already survived three ERP rollouts and two historian migrations. We’d also lived through one memorable attempt to force every PLC on site onto a single cloud dashboard. That dashboard fell over the first time a network switch hiccupped.

Six years and two plant expansions later, though, I’ve come around. The buzzword didn’t change my mind — buzzwords never do. Instead, the underlying idea solved a real problem. For a decade I’d fought that problem with duct tape and custom scripts: getting sensor data out of a control cabinet and into the hands of people who could actually use it, without turning every automation engineer on staff into an unpaid IT integrator.

This article covers what data mesh in manufacturing actually looks like in practice, not on a slide, but on a plant floor. First, I’ll explain what data mesh actually means when you’re the one racking panels and writing ladder logic. Then I’ll walk through why manufacturing’s OT/IT split differs from the generic data silos you read about elsewhere. Finally, I’ll show how we used the idea to build a predictive maintenance program out of sensor telemetry that used to sit in a historian, unread, until someone needed it for an incident report.

What Data Mesh in Manufacturing Actually Means When You’re the One Racking PLCs

Strip away the consultant-speak, and data mesh in manufacturing comes down to four ideas. Three of them, in fact, describe things good automation engineers already do instinctively.

The first is domain ownership. The team closest to a piece of equipment understands that equipment’s data better than any central data team ever will. I know what a pressure spike on Line 4’s hydraulic press means. A data scientist three states away doesn’t. So asking that data scientist to build a model without me is really just asking them to guess.

The second is treating data as a product rather than an accident. Our sensor tags historically existed for one reason: a PLC program needed them for interlocking or alarming. Nobody designed them for anyone outside the control cabinet to consume. A data product mindset flips that around. A tag stream gets a name that makes sense outside the panel. It also gets documented units, a known sample rate, and someone accountable for its accuracy. In other words, that’s a mindset shift, not a new piece of software.

Third is self-serve infrastructure. Domain teams — us, the OT folks — get a standard, repeatable way to publish data. So we don’t need to become network engineers or cloud architects every time. Fourth, and finally, is federated governance. Central IT sets the guardrails: security, naming conventions, retention policy. Domain teams, meanwhile, keep control of what their data actually means.

None of that requires ripping out your SCADA system or replacing your historian. What it does require is one agreement. A temperature reading from an extruder isn’t just an internal PLC variable. It’s an asset with a consumer on the other end, and someone on the OT side has to own getting it there cleanly.

Why Manufacturing’s Silos Are Different

Most data mesh literature comes out of retail and financial services. There, “domains” mean things like marketing, claims, or customer service. Those are different departments running the same general IT stack, the same protocols, the same latency expectations. Manufacturing’s silos run deeper. The divide isn’t organizational — it’s architectural.

A Different Kind of Domain

We still design and operate around the Purdue model, which runs from Level 0 up to Level 4: sensors and actuators, then PLCs, then SCADA and HMI, then MES, and finally business systems like ERP at the top. That layered structure exists for good reason. Safety, determinism, and network segmentation aren’t optional in a plant. A control loop running a few milliseconds late can mean a scrapped batch, or worse. ISA-95 formalized much of this, so manufacturing execution systems and enterprise systems could exchange information without every integration project reinventing definitions from scratch.

Layers Built for Safety, Not Access

That same structure keeps a press from double-stroking. But it also makes data easy to lose. A vibration signal starts at the sensor level. It passes through a PLC. A SCADA historian aggregates it. Then it stops, because nobody built a path from Level 2 up to Level 4 that a data scientist or plant manager could actually query. Now multiply that across dozens of machine types and three or four generations of controllers. Add a mix of Allen-Bradley, Siemens, and no-name legacy drives, and you get real fragmentation. One widely cited estimate puts the annual cost of manufacturing data silos in the trillions of dollars globally, once you count redundant systems, manual reconciliation, and decisions made on stale information.

The Real Cost of Protocol Soup

On top of that, there’s the protocol soup: Modbus, Profinet, EtherNet/IP, DNP3, and whatever proprietary serial protocol your 1998-vintage CNC still speaks. That’s precisely why “just put it in the cloud” was never a serious plan. Even so, the OT/IT silo in manufacturing isn’t laziness, though there’s plenty of that too. It’s the direct result of decades spent building control systems for safety and reliability first. Data accessibility came a distant second, if it came up at all. That history is exactly why data mesh in manufacturing looks so different from data mesh anywhere else.

The Predictive Maintenance Case: Treating Telemetry as a Product

This is where data mesh in manufacturing stopped being theoretical for us. Predictive maintenance forced the conversation. It’s the one use case where the OT team, reliability engineers, and IT all had genuine skin in the game.

How It Used to Work

Each machine’s sensor data — vibration, bearing temperature, motor current draw, cycle time — lived in that machine’s own local historian tags, when anyone captured it at all. When a gearbox failed on Line 2, for example, our reliability team would dig through trend data after the fact. Usually they wrote a root-cause report nobody outside the plant would ever read. We had no way to compare failure patterns across our three sister plants, even though they ran nearly identical equipment. Each plant’s data lived in its own silo. Each used its own naming conventions, its own sample rates, its own storage format. As a result, a model built at Plant A was functionally useless at Plant B. The machines weren’t different. The data pipes were.

Turning Telemetry Into a Shared Product

Data mesh in manufacturing reframed the problem. Each plant became a domain. Each plant’s telemetry from a given asset class — say, the extrusion line drives — became a data product. The plant’s automation team owned publishing it in a consistent, documented format, no matter which site it came from. That meant agreeing on a shared schema across all three sites. Specifically, we settled on the same 7 core telemetry parameters for every rotating asset: vibration RMS, bearing temperature, motor current, motor voltage, cycle count, ambient temperature, and run-hours. We sampled them at the same interval. The units matched across every site. So did the asset hierarchy each tag got mapped to. That way, we could validate a model trained on Plant A’s presses against Plant C’s data, instead of paying a data engineer to spend three weeks reconciling column names.

We didn’t get there by writing a spec and mailing it around. Instead, we got there because automation engineers from each site sat in the room when we defined the schema. Those engineers knew what “good” vibration looked like on a healthy bearing, versus one about to let go. That’s domain ownership doing real work. No central data science team would have known that our gearboxes throw a harmonic signature at roughly 3.5 times running speed a full 7 weeks before failure. That’s shop-floor knowledge. You won’t find it on a sensor’s datasheet.

What Changed Once the Schema Was Set

Once we standardized telemetry as a product with a known contract, predictive modeling got dramatically easier. We could deploy a failure prediction model built on one plant’s presses at another, largely unmodified. Alerts started flagging bearing degradation and motor imbalance days ahead of a fault. Before, we only found out about a failure once the line stopped. Someone had to pull a technician off another job to troubleshoot it cold. Still, I won’t claim perfect prescience. Thresholds needed tuning. A couple of early alerts turned out to be sensor drift rather than real degradation. Even so, a partial win here changes maintenance. It stops being a reactive scramble. It becomes a scheduled event you can plan a parts order and a shift around.

Building the Bridge: What We Actually Did on the Plant Floor

None of this happened by decree. It’s the unglamorous, cable-and-firmware side of data mesh in manufacturing that never makes the slide deck. Here’s the sequence that worked for us, in roughly the order we tackled it.

Edge Gateways First

We started with edge gateways instead of connecting every PLC directly to a corporate network segment. An industrial edge device sat between the control network and everything else. It translated whatever proprietary or legacy protocol a machine spoke into OPC-UA or MQTT. This mattered most for older equipment. For instance, a 15-year-old stamping press didn’t need a control system replacement to start contributing usable data. It just needed a gateway that could read its drive parameters and republish them in a format anything downstream could subscribe to.

Writing Down Data Contracts

Next came data contracts, a fancier name for something simple. We wrote down, in plain language, what each published tag meant, how often it updated, its valid range, and who to call if it looked wrong. That sounds bureaucratic, and a little of it is. But it’s also the difference between a data scientist trusting a feed enough to build a model on it, and that same data scientist quietly ignoring your plant’s data because nobody could tell them what “Tag_447” actually measured.

A Shared Historian Layer

We also built a shared historian layer above the individual plant historians, rather than replacing them. Each site kept its local SCADA historian for real-time control and alarming, which had to stay fast and local for safety reasons. A separate, standardized layer aggregated the published data products for cross-site analytics instead. This kept control-loop-critical data on the OT network, where it belonged. It also let the broader organization query that data without punching new holes through a firewall meant to keep ransomware away from a safety PLC.

Self-Serve Onboarding

Finally, we insisted on self-serve tooling. Nobody should need to file an IT ticket every time a new sensor comes online. Reliability engineers and automation techs got a standard template for onboarding a data product: register the asset, map it to the shared schema, point it at the edge gateway, done. That replaced weeks of waiting on a custom integration project every single time.

Governance Without Grinding Everything to a Halt

Federated governance is where data mesh in manufacturing initiatives either succeed quietly or fail loudly. Manufacturing has extra teeth in this fight, thanks to safety and cybersecurity requirements a marketing department never has to think about.

What Stayed Centralized

Central IT and cybersecurity kept authority over anything that genuinely needed centralized control: network segmentation, patch policy, identity and access management, and the security boundary between the OT network and everything else. That’s non-negotiable. A compromised historian could, in theory, become a path back into a control system. Frankly, nobody on my team wanted authority over firewall rules anyway.

What Stayed With the Plant

On the other hand, we kept authority over what our data meant and whether it was fit to publish. That covers semantics, quality thresholds, and the judgment calls about which anomalies count as real signal versus sensor noise. That split kept the security team from becoming a bottleneck for every new sensor tag. It also stopped the plant floor from surrendering decisions that require real process knowledge to people who’ve never stood next to the machine in question.

We also set up a lightweight review cadence: a monthly half-hour call between plant automation leads and the central data governance group, just to catch schema drift before it became a mess. Skipping this once things are running is tempting. Don’t. Data contracts rot quietly if nobody checks them.

Where We Almost Got It Wrong

Here’s one thing I’d flag for anyone walking into this: access control disputes are where good intentions go to die. Early on, our security team required a full change-control review for every new data product request. It was the same process used for firewall changes on the safety network. That made sense for anything touching Level 0 or Level 1. But it also turned simple sensor onboarding into a two-week paperwork exercise. Eventually, we split the approval path by risk instead. Read-only telemetry publishing to the shared historian layer got a fast, lightweight sign-off. Anything touching write access back into a control network kept the full review. That single change did more for adoption than any amount of internal messaging about “data as a product” ever did.

What Actually Changed on the Floor

I want to be honest about what data mesh in manufacturing actually delivered, rather than oversell it. I’ve read enough vendor case studies promising instant transformation to be suspicious of my own enthusiasm.

To start, the predictive maintenance program didn’t eliminate unplanned downtime. It did reduce the number of surprise failures on equipment we’d instrumented and standardized. It also gave the maintenance planning team real lead time — often more than a week, sometimes just a couple of days — to schedule repairs during planned downtime instead of mid-shift. That’s a real, countable win, even if it’s less dramatic than the headline numbers in vendor pitch decks.

The bigger win, though, was organizational. Automation engineers and IT stopped treating each other as obstacles. When a new sensor project came up, the conversation shifted from “who owns this” to “which schema does this fit into.” That’s a genuinely more productive argument to have. All told, it took us about 7 months from our first cross-plant schema workshop to having all three sites publishing telemetry in a consistent format. That’s slower than any consultant’s slide deck would suggest. It’s also faster than the old way, which was essentially never. That’s the real timeline for data mesh in manufacturing, not the pitch-deck version.

Where This Goes Next

If you’re an automation or controls engineer watching a data mesh in manufacturing initiative head your way, get into the room early. Do it before anyone designs a schema without you. You know things about your equipment’s failure modes that no data catalog will ever capture on its own. That knowledge is exactly what makes a domain-owned data product trustworthy, instead of just another dashboard nobody checks.

In short, data mesh in manufacturing isn’t a replatforming project. It isn’t something IT can hand down as a mandate and expect the floor to follow. It’s a working agreement between the people who understand the machines and the people who understand the pipelines, with clear ownership on both sides. Get that agreement right, and predictive maintenance stops being a pilot project that quietly dies after the demo. Instead, it becomes something the plant actually depends on.

Frequently Asked Questions

What is data mesh in manufacturing, in plain terms?

Each plant or production domain owns and publishes its own operational data, like machine telemetry, as a well-documented product. Nobody dumps everything into one central data lake that no one maintains. IBM’s overview lays out the four core principles this idea rests on: What Is a Data Mesh? (IBM)

How is this different from a traditional centralized data warehouse or historian?

A centralized model puts one team in charge of ingesting, cleaning, and modeling everyone else’s data. That team becomes a bottleneck as data sources multiply. A domain-owned approach, by contrast, spreads that responsibility to the teams who understand the data best, held together by shared standards. PwC’s manufacturing analysis walks through this shift from centralized platforms toward domain-driven ownership: Reimagining Manufacturing: From Centralised Platforms to Domain-Driven Intelligence (PwC)

Do I need to replace my PLCs or SCADA system to do this?

No. Most of the work happens at the edge and in how you publish data, not inside the control system itself. Edge gateways that translate legacy protocols into OPC-UA or MQTT are the typical bridge. This breakdown of IT/OT convergence practices covers it well: IT/OT Convergence: A Complete Guide to Overcoming Data Silos (Avenga)

How does ISA-95 fit into a data mesh approach?

ISA-95 gives you a shared vocabulary and a layered reference model for where data lives and how it should move between manufacturing and business systems. It doesn’t dictate a data mesh. But it does give domain teams a common language for defining boundaries and data contracts. ISA maintains the standard itself: ISA-95 Standard: Enterprise-Control System Integration (ISA)

What kind of return can I realistically expect from predictive maintenance built this way?

Results from data mesh in manufacturing vary by asset type and by how mature your baseline maintenance program already is. That said, industry research consistently points to fewer unplanned failures and better-planned maintenance windows, not an overnight end to downtime. Deloitte’s research on predictive maintenance in smart factories offers a good, grounded starting point: Predictive Maintenance and the Smart Factory (Deloitte)

Who should own the data — the plant floor team or corporate IT?

Neither one exclusively. Federated governance means the plant team owns what the data means and whether it’s accurate. IT and security own the platform, network boundaries, and access controls instead. Most friction comes from trying to make one side own both.

References

1. IBM. “What Is a Data Mesh?” — https://www.ibm.com/think/topics/data-mesh
2. PwC India. “Reimagining Manufacturing: From Centralised Platforms to Domain-Driven Intelligence.” — https://www.pwc.in/assets/pdfs/consulting/technology/data-and-analytics/govern-your-data/insights/reimagining-manufacturing-from-centralised-platforms-to-domain-driven-intelligence.pdf
3. Avenga. “IT/OT Convergence: A Complete Guide to Overcoming Data Silos.” — https://www.avenga.com/magazine/best-practices-for-it-ot-convergence-in-manufacturing/
4. International Society of Automation (ISA). “ISA-95 Standard: Enterprise-Control System Integration.” — https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
5. Automation World. “Is the Purdue Model Still Relevant?” — https://www.automationworld.com/factory/iiot/article/21132891/is-the-purdue-model-still-relevant
6. Deloitte. “Predictive Maintenance and the Smart Factory.” — https://www2.deloitte.com/us/en/pages/operations/articles/predictive-maintenance-and-the-smart-factory.html
7. Scientific Reports (Nature). “Optimized Predictive Maintenance for Streaming Data in Industrial IoT Networks Using Deep Reinforcement Learning and Ensemble Techniques.” — https://www.nature.com/articles/s41598-025-10268-8