Daten­architektur – Best Practices im Unified Namespace

Viele Digitalisierungsprojekte scheitern nicht an fehlenden Tools. Sie scheitern an fehlender Struktur. Sensoren liefern Daten, Maschinen liefern Daten, ERP und MES liefern Daten. Doch ohne ein tragfähiges Konzept bleiben diese Datenströme isoliert. Genau hier setzt eine Datenarchitektur Unified Namespace an: Sie beschreibt, wie Daten entstehen, fließen, gespeichert und bereitgestellt werden. Dieser Artikel erklärt zunächst, was eine Datenarchitektur klassisch ausmacht. Anschließend zeigt er, warum der Unified Namespace (UNS) das passende Muster für das Industrial IoT ist.

Der Beitrag folgt einem klaren Aufbau. Zuerst klärt er die Definition und die Bausteine. Danach ordnet er die Anforderungen der Fertigung ein. Zum Schluss beschreibt er Best Practices und die Rollen für den Aufbau einer skalierbaren Datenarchitektur.

 

Was ist eine Datenarchitektur?

Eine Datenarchitektur ist der strukturelle Bauplan für den Umgang mit Daten. Sie legt fest, welche Quellen es gibt und wie Daten integriert werden. Außerdem regelt sie Speicherung, Bereitstellung und Governance. Kurz gesagt: Sie beschreibt den Weg vom Rohsignal bis zum nutzbaren Datenprodukt.

Wichtig ist die Abgrenzung zum Datenmodell. Ein Datenmodell definiert die konkrete Struktur einzelner Datensätze. Die Datenarchitektur beschreibt dagegen das große Ganze. Sie ist die Disziplin, die alle Bausteine zu einem konsistenten System verbindet.

Warum ist das relevant? Weil Daten erst durch Struktur zu einem Wert werden. Ein isolierter Messwert bleibt eine Zahl ohne Bedeutung. Erst der Kontext macht ihn nutzbar. Eine gute Datenarchitektur liefert genau diesen Kontext. Sie sorgt dafür, dass jede Anwendung dieselbe verlässliche Datenbasis nutzt.

 

Die Bausteine einer Datenarchitektur

Jede Datenarchitektur besteht aus wiederkehrenden Schichten. Diese Bausteine bauen aufeinander auf:

• Quellen: Hier entstehen Daten. Dazu zählen Sensoren, SPS, Maschinen sowie MES- und ERP-Systeme.
• Integration und Ingestion: Diese Schicht sammelt und normalisiert die Daten. Gateways und Konnektoren überführen Rohdaten in ein einheitliches Format.
• Speicherung: Daten landen in Datenbanken, Historians oder Data Lakes. Die Wahl hängt vom Zugriffsmuster ab.
• Bereitstellung und Analytik: Anwendungen, Dashboards und Modelle greifen auf die Daten zu. Erst hier entsteht sichtbarer Wert.
• Governance und Sicherheit: Diese Querschnittsschicht klärt Zugriff, Qualität und Namenskonventionen. Sie spannt sich über alle Ebenen.

Governance ist keine optionale Ebene. Sie entscheidet, ob eine industrielle Datenarchitektur langfristig konsistent bleibt. Ohne klare Regeln driften Namen und Formate schnell auseinander.

 

Klassische Muster im Überblick

Für diese Bausteine haben sich in der IT mehrere Muster etabliert. Jedes Muster setzt andere Schwerpunkte:

• Data Warehouse: Stark strukturierte Daten für Reporting und BI. Schema und Qualität stehen im Vordergrund.
• Data Lake: Ein zentraler Speicher für Rohdaten in jedem Format. Flexibel, aber ohne inhärente Struktur.
• Data Mesh: Dezentrale Verantwortung. Fachbereiche liefern Daten als eigenständige Produkte.
• Data Fabric: Eine Integrationsschicht über verteilten Quellen. Metadaten verbinden die Systeme logisch.

Diese Muster stammen aus der klassischen IT. Sie adressieren Data Warehouses, Analytik und Cloud-Speicher. Der Kontext der Produktion fehlt ihnen jedoch weitgehend.

Das ist keine Kritik an den Mustern selbst. Für ihren Zweck sind sie ausgereift und bewährt. Sie wurden aber für Geschäftsdaten und Reporting gebaut. Maschinendaten in Echtzeit stellen andere Anforderungen. Genau diese Lücke betrachten wir im nächsten Abschnitt.

 

Datenarchitektur im Industrial IoT

Am Factory Floor gelten andere Regeln als im Rechenzentrum. Daten entstehen in Echtzeit und mit hoher Frequenz. Sie müssen nah an der Maschine verarbeitet werden. Genau daran scheitern klassische IT-Muster oft.

 

Warum klassische IT-Datenarchitekturen scheitern

Klassische Ansätze wurden für Batch-Analytik entworfen. In der Fertigung stoßen sie an drei Grenzen. Erstens die Latenz: Eine Steuerung kann nicht auf einen Cloud-Roundtrip warten. Zweitens die Struktur: Die klassische ISA-95-Pyramide zwingt Daten Ebene für Ebene nach oben. Das kostet Zeit und erzeugt Silos.

Drittens die Kopplung. Ohne zentrales Muster verbinden Teams Systeme direkt miteinander. So entstehen viele Punkt-zu-Punkt-Verbindungen. Jede neue Anwendung braucht eine eigene Schnittstelle. Die Zahl der Verbindungen wächst dann quadratisch. Eine skalierbare Datenarchitektur sieht anders aus.

Ein Beispiel verdeutlicht das Problem. Ein Historian, ein Dashboard und ein MES wollen denselben Maschinenwert. Ohne zentralen Layer fragt jedes System die Steuerung direkt ab. Die Steuerung trägt so die Last aller Abfragen allein. Jeder neue Consumer erhöht diese Last weiter. Das Quellsystem wird zum Flaschenhals.

 

Die Anforderungen der Fertigung

Eine industrielle Datenarchitektur muss vier Kernanforderungen erfüllen. Sie unterscheiden die Fertigung klar von reiner IT:

• Echtzeit: Daten müssen mit minimaler Verzögerung verfügbar sein.
• Edge-Nähe: Verarbeitung geschieht nah an der Maschine, nicht nur zentral.
• Kontext: Ein Messwert allein reicht nicht. Semantik und Herkunft gehören dazu.
• IT/OT-Konvergenz: Produktion und IT müssen dieselben Daten nutzen.

Der letzte Punkt ist entscheidend. Ohne eine gemeinsame Datenbasis bleiben IT und OT getrennte Welten. Wie diese Annäherung gelingt, beschreibt unser Beitrag zur IT/OT-Konvergenz im Detail.

 

Datenarchitektur Unified Namespace: das OT-native Architekturmuster

Der Unified Namespace beantwortet genau diese Anforderungen. Er ist kein Produkt, sondern ein Architekturmuster. Eine Datenarchitektur Unified Namespace stellt alle Daten in einem zentralen, kontextualisierten Layer bereit. Jedes System publiziert und abonniert Daten über diesen Layer. Was ein UNS genau ist, erklärt unser Beitrag Was ist der Unified Namespace.

 

Von der ISA-95-Pyramide zum Publish/Subscribe-Layer

Der Kern des Wandels ist einfach beschrieben. Aus einer starren Hierarchie wird eine flache Datenschicht. In der ISA-95-Pyramide klettern Daten Ebene für Ebene. Im UNS greift jede Ebene direkt auf einen gemeinsamen Layer zu. Dieser Layer ist die Single Source of Truth (SSOT).

Jede Ebene wird zum gleichberechtigten Teilnehmer. Ein MES liest denselben Wert wie ein Dashboard. Neue Consumer kommen hinzu, ohne die Quelle zu verändern. Genau das macht die Architektur skalierbar. Wie die Daten dabei strukturiert werden, zeigt unser technischer Leitfaden zur Datenmodellierung.

Der Transport dieser Daten läuft über ein Nachrichtenprotokoll. Meist kommen MQTT oder NATS zum Einsatz. Beide entkoppeln Sender und Empfänger sauber. Welches Protokoll besser passt, hängt vom Use Case ab. Die Details vergleicht unser Beitrag zu NATS vs. MQTT im Unified Namespace.

 

UNS im Vergleich zu Data Lake und Data Mesh

Der UNS erfindet die Datenarchitektur nicht neu. Er überträgt bewährte Ideen in den OT-Kontext. Vom Data Mesh übernimmt er die lose Kopplung und dezentrale Verantwortung. Vom Data Lake unterscheidet er sich klar. Ein Data Lake sammelt Rohdaten passiv. Der UNS stellt kontextualisierte Daten aktiv in Echtzeit bereit.

Dieser Unterschied ist wichtig. Ein reiner Datensee ohne Struktur wird schnell zum Datensumpf. Welche Lehren sich daraus ziehen lassen, beschreibt unser Beitrag zu den Lehren aus dem Data-Lake-Hype.

Der UNS ersetzt den Data Lake nicht. Er ergänzt ihn sinnvoll. Der Layer verteilt Daten in Echtzeit an alle Consumer. Ein Historian oder eine Zeitreihen-Datenbank speichert sie langfristig. Beide Ebenen erfüllen unterschiedliche Aufgaben. Wie sich Historian und Time-Series-DB unterscheiden, zeigt unser Beitrag zu Time-Series-DB vs. Historian.

 

Best Practices für eine skalierbare Datenarchitektur

Ein Muster allein garantiert keinen Erfolg. Entscheidend ist die konsequente Umsetzung. Die folgenden Prinzipien haben sich für eine skalierbare Datenarchitektur bewährt.

 

Prinzipien-Checkliste

Diese fünf Prinzipien bilden das Fundament. Sie gelten unabhängig vom eingesetzten Broker:

• Single Source of Truth: Jeder Datenpunkt existiert genau einmal zentral.
• Lose Kopplung: Systeme kennen einander nicht. Sie kommunizieren nur über den Layer.
• Event-getrieben: Daten werden bei Änderung publiziert, nicht wiederholt abgefragt.
• Edge-Normalisierung: Kontext entsteht nah an der Quelle, nicht erst in der Cloud.
• Governance: Namenskonventionen und Zugriffsregeln stehen von Anfang an fest.

Diese Prinzipien greifen ineinander. Lose Kopplung ohne Governance führt zu Wildwuchs. Governance ohne SSOT bleibt wirkungslos. Sicherheit gehört dabei von Beginn an dazu. Konkrete Maßnahmen fasst unser Beitrag zu sicheren UNS-Architekturen zusammen.

 

Die Muster im direkten Vergleich

Welches Muster passt zu welchem Ziel? Die folgende Grafik stellt die fünf Ansätze gegenüber. Sie bewertet sie nach den Kriterien der Fertigung.

Der Vergleich zeigt ein klares Bild. Warehouse und Lake punkten bei der Analytik. Beim Thema Echtzeit und OT-Tauglichkeit fallen sie zurück. Der UNS verbindet Kontext, lose Kopplung und Echtzeit. Damit ist er das OT-native Muster für die Fertigung.

Die Muster schließen sich nicht aus. In der Praxis ergänzen sie sich oft. Der UNS bildet das Echtzeit-Rückgrat für die Produktion. Ein Data Warehouse übernimmt weiterhin das Reporting. Entscheidend ist, jedem Muster die passende Aufgabe zuzuweisen. So entsteht eine industrielle Datenarchitektur ohne unnötige Brüche.

 

Vom Pilot zum Rollout

Eine skalierbare Datenarchitektur entsteht selten auf einen Schlag. Bewährt hat sich ein schrittweises Vorgehen. Teams starten mit einem klar umrissenen Pilot. Danach weiten sie den Layer auf weitere Linien und Standorte aus. Die einzelnen Reifegradstufen beschreibt unser Beitrag zur Evolution des UNS vom Pilot zum globalen Rollout.

Wichtig ist die Reihenfolge. Governance und Namenskonventionen entstehen im Pilot, nicht erst beim Rollout. So bleibt die Architektur beim Wachstum konsistent. Ein früh definierter Standard spart später viel Aufwand. Nachträgliche Korrekturen an vielen Standorten sind teuer.

 

Wer unterstützt beim Aufbau einer skalierbaren Datenarchitektur?

Der Aufbau ist ebenso eine Team- wie eine Technologiefrage. Ohne klare Rollen bleibt selbst das beste Muster Theorie. Es braucht Menschen, Prozesse und eine passende Plattform.

 

Rollen im Team und passende Partner

Intern braucht ein Projekt mehrere Rollen. Ein Datenarchitekt entwirft die Struktur. OT-Verantwortliche kennen die Maschinen und Protokolle. IT-Verantwortliche sichern Betrieb und Governance. Diese Rollen müssen eng zusammenarbeiten.

Extern helfen Partner und Plattformen. Sie bringen Erfahrung aus vielen Projekten mit. Außerdem liefern sie die technische Basis für den Layer. Welche Rollen im Detail zusammenspielen, beschreibt unser Beitrag zu Organisation und Rollen im UNS.

Die richtige Plattform nimmt dem Team viel Arbeit ab. Sie stellt fertige Konnektoren für gängige Protokolle bereit. Außerdem sorgt sie für einheitliche Governance über alle Standorte. So kann sich das Team auf die eigentliche Wertschöpfung konzentrieren. Es baut Anwendungen, statt Schnittstellen zu pflegen.

 

i-flow als Fundament der Datenarchitektur

i-flow liefert genau dieses Fundament. Die Plattform trennt Konfiguration und Ausführung sauber. Im zentralen i-flow Hub konfigurierst du die gesamte Architektur an einer Stelle. Die eigentliche Verarbeitung läuft dezentral über i-flow Edges. Diese laufen nah an der Maschine und normalisieren Daten direkt an der Quelle.

Dieses Prinzip passt exakt zu einer Datenarchitektur Unified Namespace. Die zentrale Konfiguration sorgt für Governance und Konsistenz. Die dezentrale Ausführung sorgt für Echtzeit und Edge-Nähe. So entsteht eine industrielle Datenarchitektur, die mitwächst. Wer den Einstieg sucht, findet Orientierung in unserem Leitfaden zu Industrial DataOps im UNS.

 

Fazit

Eine tragfähige Datenarchitektur entscheidet über den Erfolg der Digitalisierung. Sie verbindet Quellen, Integration, Speicherung, Bereitstellung und Governance zu einem System. Klassische IT-Muster stoßen in der Fertigung an ihre Grenzen. Der Unified Namespace schließt diese Lücke. Er überträgt bewährte Ideen in den OT-Kontext und liefert das passende Muster. Drei zentrale Erkenntnisse

1. Struktur schlägt Tools: Datenwert entsteht durch eine klare Datenarchitektur, nicht durch einzelne Werkzeuge.
2. Der UNS ist das OT-native Muster: Eine Datenarchitektur Unified Namespace verbindet Kontext, lose Kopplung und Echtzeit.
3. Zentral konfigurieren, dezentral ausführen: Dieses Prinzip macht eine skalierbare Datenarchitektur erst möglich.