Industrial Data Fabric: what it is, what it is not — and what it really delivers
“Industrial Data Fabric” is one of those terms that means everything and nothing. Before we talk about what such a layer can do, the more uncomfortable question is worth asking: what is it actually — and, just as important, what is it not?
Every vendor means something different when they say “Data Fabric.” A good deal of the confusion in data projects comes from that — and the occasional bad purchase. So let us begin with the definition.
In short, an Industrial Data Fabric (IDF) is a foundation and connectivity layer between OT (Operational Technology, the technology of production) and IT (Information Technology). It turns fragmented production data into one coherent, contextualised layer. Not a new system on top — a layer underneath.
Sounds abstract? The picture gets sharpest through contrast. So first, what an IDF explicitly is not.
What it is not
Not a process control system
It is not a classic OT system, no SCADA (Supervisory Control and Data Acquisition), no PLC and no DCS (Distributed Control System). It does not control or regulate the process.
Not an MES
It is not a Manufacturing Execution System. It does not execute production orders and does not replace the execution layer.
Not an HMI layer
It is not a classic operator interface (HMI, Human-Machine Interface) as in SCADA. Visualisation is possible — but it is not the core.
Not just a historian
A historian stores values; an IDF connects and contextualises them and makes them available across systems.
And it replaces none of these systems. It sits not on top of them, but underneath. Anyone selling you a “Data Fabric” that controls the process or replaces the MES is selling something else.
What it is
At its core it is a pure connectivity layer: messaging, data reception, interconnectivity. A foundation between IT and OT — not a replacement for either. From that role follow a few properties that make a dependable IDF:
Vendor-neutral
No built-in cloud dependency, no lock-in to a single vendor. It stays open to the existing installed base.
Centrally managed, run locally
Autonomous instances per site, technically self-sufficient — connected into one central level. One system enterprise-wide, instead of many islands.
Extensible
Where a native standard interface is missing, a custom driver reads it. Scripting (for example in Lua) on every component normalises data at the edge.
Built for enterprise scale
Connectivity across many sources and sites, without extra tools — with a web toolset for visualisation and apps on top.
Tools like AspenTech inmation put this principle into practice. But the IDF is an architectural pattern, not a product — which tool implements it is decided by the installed base, not the brand. cts works deliberately system-independent here.
What it can do
The practical difference lies in the connection model. Instead of building each connection individually — MES to process control, line to cloud, site to site — a layer emerges over which these connections run in a standardised way. An IDF can act as a translation and standardisation layer: it translates a standard message into whatever the respective target system understands.
The effect shows less in the first step than in every one after it:
What it delivers
The real benefit is not a single number, but a shift: away from one-off, manual integration work — towards a scalable, repeatable model that speeds up every further use case.
Where this effect could be measured, though, it is clear:
faster delivery of new use cases in a pharma project — comparing a 2025 project with a 2020 reference, after the shared connectivity layer was built. [CLEARANCE REQUIRED: figure from the AspenTech Optimize 2026 presentation. Have Florian Seidl confirm before external use — including the methodology footnote (2025 project vs. 2020 reference). Do not publish until then.]
And to keep it honest: the first implementation takes time and setup. The gain lies in the repetition, not in the first step. For anyone who only wants to connect a single data point once, the effort is not worth it.
After 18 years on the OT side — with PLCs, process control systems and data integration — and around ten years with connectivity software, I have reached a point that is almost uncomfortable for a technical person: the technology is no longer the bottleneck. It has existed for a long time.
What is missing is rarely the capability — it is someone who has already walked the path. Many hurdles that were hard years ago are easy today, because they have already been solved in other projects. You do not have to start from scratch. And honestly, I find that the more interesting message than any feature list.
When it is worth it — and when it is not
An IDF is not the right path for everyone. For a single, self-contained integration or a manageable system landscape it is oversized. It shows its value where data has to come together across many systems and several sites — and where every further use case is meant to build on the same foundation.
From experience: the fastest way to test a “Data Fabric” in a proposal is to ask what it does not do. Does it control the process? Does it replace the MES? Then we are not talking about a foundation layer, but about another system on top — and the silo question all over again.
The term will keep being used loosely — no blog post will change that. But now you have the test for it. Where the line runs for you between “foundation” and “yet another system” is best clarified on the concrete case. That is exactly what we do in Berlin.
What the data knew before the technician did
From theory into the plant: concrete cases where connected data turned into tangible value.
Read the post →We will be discussing this at Pharma MES Europe 2026
In Berlin, cts Group and Xenium AG show when an Industrial Data Fabric holds up — and when a simpler path is the better one.
Book a meeting at the stand
