Florian Seidl, cts Group

BU Manager Industrieinformatik · 13. August 2026 · 8 Min. Lesezeit

Industrial Data Fabric: Was sie ist, was sie nicht ist — und was sie wirklich bringt

„Industrial Data Fabric" ist einer dieser Begriffe, die alles und nichts bedeuten. Bevor wir darüber reden, was so eine Schicht kann, lohnt die unbequemere Frage: Was ist sie eigentlich — und, mindestens ebenso wichtig, was ist sie nicht?

Jeder Anbieter meint etwas anderes, wenn er „Data Fabric" sagt. Daraus entsteht ein guter Teil der Verwirrung in Datenprojekten — und mancher Fehlkauf. Beginnen wir deshalb mit der Definition.

Kurz gesagt ist eine Industrial Data Fabric (IDF) eine Fundament- und Konnektivitätsschicht zwischen OT (Operational Technology, die Technik der Produktion) und IT (Information Technology). Sie macht aus fragmentierten Produktionsdaten eine zusammenhängende, kontextualisierte Schicht. Kein neues System obendrauf — eine Schicht darunter.

Klingt abstrakt? Am schärfsten wird das Bild über die Abgrenzung. Deshalb zuerst das, was eine IDF ausdrücklich nicht ist.

Was sie nicht ist

Und sie ersetzt keines dieser Systeme. Sie legt sich nicht über sie, sondern darunter. Wer Ihnen eine „Data Fabric" verkauft, die den Prozess steuert oder das MES ablöst, verkauft etwas anderes.

Was sie ist

Ihr Kern ist eine reine Konnektivitätsschicht: Messaging, Datenempfang, Interconnectivity. Ein Fundament zwischen IT und OT — kein Ersatz für eines von beiden. Aus dieser Rolle folgen ein paar Eigenschaften, die eine belastbare IDF ausmachen:

Tools wie AspenTech inmation setzen dieses Prinzip um. Aber die IDF ist ein Architekturmuster, kein Produkt — welches Werkzeug es umsetzt, entscheidet der Bestand, nicht die Marke. cts arbeitet hier bewusst systemunabhängig.

Was sie kann

Der praktische Unterschied liegt im Verbindungsmodell. Statt jede Verbindung einzeln zu bauen — MES an Prozessleitsystem, Linie an Cloud, Standort an Standort — entsteht eine Schicht, über die diese Verbindungen standardisiert laufen. Eine IDF kann als Übersetzungs- und Standardisierungsschicht wirken: Sie übersetzt eine Standard-Nachricht in das, was das jeweilige Zielsystem versteht.

Der Effekt zeigt sich weniger im ersten Schritt als in jedem weiteren:

Was sie bringt

Der eigentliche Nutzen ist kein einzelner Wert, sondern eine Verschiebung: weg von einmaliger, manueller Integrationsarbeit — hin zu einem skalierbaren, wiederholbaren Modell, das jeden weiteren Use Case beschleunigt.

Dort, wo sich dieser Effekt messen ließ, ist er allerdings deutlich:

Und damit es ehrlich bleibt: Die erste Implementierung braucht Zeit und Setup. Der Gewinn liegt in der Wiederholung, nicht im ersten Schritt. Wer nur einen einzigen Datenpunkt einmal anbinden will, für den lohnt der Aufwand nicht.

Nach 18 Jahren auf der OT-Seite — mit SPS, Prozessleitsystemen und Datenintegration — und rund zehn Jahren mit Konnektivitätssoftware bin ich an einem Punkt angelangt, der für einen Techniker fast unbequem ist: Die Technik ist nicht mehr der Engpass. Sie existiert längst.

Was fehlt, ist selten die Fähigkeit — sondern jemand, der den Weg schon gegangen ist. Viele Hürden, die vor Jahren schwer waren, sind heute leicht, weil sie in anderen Projekten bereits gelöst wurden. Man muss nicht bei null anfangen. Und ehrlich gesagt finde ich das die interessantere Nachricht als jede Funktionsliste.

Wann sie sich lohnt — und wann nicht

Eine IDF ist nicht für jeden der richtige Weg. Für eine einzelne, abgeschlossene Integration oder eine überschaubare Systemlandschaft ist sie überdimensioniert. Ihren Wert entfaltet sie dort, wo Daten über viele Systeme und mehrere Standorte hinweg zusammenkommen müssen — und wo jeder weitere Use Case auf demselben Fundament aufsetzen soll.

Der Begriff wird weiter unscharf verwendet werden — daran ändert kein Blogbeitrag etwas. Aber Sie haben jetzt den Test dafür. Wo bei Ihnen die Grenze zwischen „Fundament" und „noch ein System" verläuft, lässt sich am besten am konkreten Fall klären. Genau das tun wir in Berlin.