Der Industrial Unified Namespace (UNS) wird häufig als technische Architektur aus Message Brokern und Integrations-Gateways verstanden. In der Praxis ist er jedoch primär ein organisatorisches Betriebsmodell für industrielle Daten. Ein Unified Namespace regelt nicht nur den Datentransport, sondern legt verbindlich fest:
- wer Daten bereitstellt,
- wer sie strukturiert und kontextualisiert,
- wer sie nutzen darf,
- wer Verantwortung für Qualität, Sicherheit und Weiterentwicklung trägt.
Der UNS ersetzt dabei weder SCADA noch MES. Er ist applikationsneutral, ereignisgetrieben und strategisch ausgelegt und etabliert einen dauerhaften, unternehmensweiten Datenraum. Genau deshalb sind eine klare Organisationsstruktur und eindeutig definierte Rollen im Unified Namespace erfolgskritisch. Dieser Artikel richtet sich an technische IT/OT-Architekten und zeigt, warum Organisationsstruktur und Rollen im Unified Namespace eine zentrale Voraussetzung für skalierbare industrielle Datenarchitekturen sind.
Klassische IT/OT Rollen im Wandel
In produzierenden Unternehmen sind die Rollen zwischen IT und OT historisch gewachsen und waren lange Zeit klar getrennt.
Corporate IT-Teams sind traditionell für Unternehmensnetzwerke, Server, Security und Compliance verantwortlich. Ihr Fokus liegt auf Skalierbarkeit, Standardisierung und dem sicheren Betrieb zentraler IT-Plattformen.
OT-Teams – dezentral in den Werken organisiert – verantworten Maschinen, Anlagen, Steuerungen sowie Betrieb und Instandhaltung. Priorität haben Verfügbarkeit, Sicherheit der Produktion und lokale Optimierung.
Diese Rollentrennung erzeugt einen Zielkonflikt: IT optimiert auf Standardisierung und langfristige Stabilität, OT auf pragmatische Lösungen nahe an der Produktionsrealität. Zentrale Security-Vorgaben oder neue IT-Standards werden in der OT häufig als potenzielles Risiko für stabile Produktionsprozesse wahrgenommen. Umgekehrt gelten werksspezifische OT-Lösungen aus IT-Sicht als schwer wartbar und nicht skalierbar. Das Ergebnis sind funktionierende, aber isolierte IT- und OT-Silos mit begrenzter Skalierbarkeit.
IT/OT-Konvergenz verändert Teamstrukturen
Mit zunehmender IT/OT-Konvergenz stoßen diese klassischen Silos an ihre Grenzen. Moderne Industrie-4.0 Umgebungen erfordern eine enge Verzahnung von Infrastruktur, Datenarchitekturen und Betriebsprozessen. Zentral integrierte IT/OT-Teams übernehmen dabei häufig eine Schlüsselrolle. Sie definieren globale Standards und unternehmensweite Use-Cases. Diese Teams bestehen aus IT- und OT-Experten, agieren meist projektgetrieben und bewusst getrennt vom operativen Tagesbetrieb der Werke. Eine detaillierte Beschreibung dieser Evolution finden Sie hier.
Der Unified Namespace als Katalysator für die IT/OT-Konvergenz
Der Unified Namespace (UNS) wirkt in diesem Kontext als Katalysator. Als zentrale Single Source of Truth für Unternehmensdaten verbindet er Infrastruktur-, Daten- und Betriebsaspekte in einer gemeinsamen Architektur. Dadurch werden organisatorische Abhängigkeiten sichtbar, die zuvor in getrennten IT- und OT-Silos verborgen waren. Unternehmen sind gezwungen, Rollen und Verantwortlichkeiten neu zu definieren – weg von isolierten Zuständigkeiten, hin zu abgestimmten, integrierten Betriebsmodellen.
Organisationsstruktur und Rollen im Unified Namespace (UNS)
In der Praxis orientiert sich das Rollenmodell im Industrial Unified Namespace (UNS) an den bestehenden Organisations- und Verantwortungsstrukturen. Entscheidend ist dabei weniger die formale Teamzuordnung als die saubere Trennung von Infrastrukturverantwortung, Governance und fachlicher Datenhoheit. Bewährt hat sich eine Aufteilung in drei klar abgegrenzte Rollen:
- Corporate IT-Team als UNS Enabler: Verantwortlich für UNS Infrastruktur, Plattformbetrieb und IT-Security.
- Zentrales IT/OT-Team als globaler Daten-Owner: Verantwortlich für Architektur, Governance, Enterprise-IT-Integration sowie den globalen Enterprise Namespace.
- Dezentrale OT-Teams als lokale Daten-Owner: Verantwortlich für OT-Integration, den lokalen Fabrik-Namespace sowie operative, werksspezifische Use-Cases.
Diese Rollen können organisatorisch getrennt sein, sollten jedoch in einer UNS-Plattform wie i-flow zusammenarbeiten. Der UNS fungiert dabei als architektonisches Rückgrat, über das globale Enterprise und lokale Fabrik Namespaces logisch gekoppelt sind.
1. Corporate IT Team als UNS Enabler
Das Corporate IT-Team übernimmt im UNS-Rollenmodell die Rolle des Enablers und Infrastruktur-Providers. Es stellt die technische Grundlage für den Unified Namespace bereit und verantwortet dessen stabilen, sicheren und skalierbaren Betrieb. Zu den Kernaufgaben gehören:
- Netzwerkarchitektur: Design und Betrieb zentraler sowie dezentraler Werksnetzwerke, Segmentierung, sichere Standortanbindungen und WAN-/DMZ-Konzepte.
- Betrieb der Infrastruktur: Cloud- und On-Prem-Infrastruktur inklusive Virtualisierung, Container- und Orchestrierungsplattformen (z. B. Kubernetes).
- IT-Security: Vorgaben und Betrieb von Security-Mechanismen wie Zero-Trust-Architekturen, Zertifikats- und Identitätsmanagement, rollenbasierter Zugriffskontrolle sowie Transport- und Datenverschlüsselung.
- Monitoring und Incident Management: Zentrales Monitoring der Infrastruktur und UNS Plattformkomponenten sowie strukturierte Incident- und Patch-Prozesse.
- Lifecycle-Management: Wartung, Updates und Security-Patching aller Infrastruktur- und Plattformkomponenten.
Bewusst ausgeschlossen ist die fachliche Verantwortung für Produktionsdaten: Das Corporate IT-Team ist der UNS-Plattform Enabler, besitzt jedoch weder die Daten noch definiert es deren Struktur, Bedeutung oder Semantik.
2. Zentrales IT/OT Team als globaler Daten-Owner
Das zentrale IT/OT-Team bildet den architektonischen Kern des Unified Namespace. Es verantwortet nicht die Infrastruktur, sondern die logische und semantische Integrität des UNS auf Unternehmensebene. Zentrale Aufgaben dieses Teams sind:
- Strategie und Architektur
- Entwicklung einer unternehmensweiten UNS-Strategie im Einklang mit den Geschäftszielen
- Definition der Gesamtarchitektur des Unified Namespace (z.B. Topologie, Verantwortlichkeiten)
- Enterprise Namespace
- einheitlicher Strukturen über Werke, Linien und Anlagen hinweg
- Naming Conventions, Topic-Hierarchien und Payload-Strukturen
- semantischer Modelle (z. B. entlang ISA-95, Companion Specifications)
- Governance
- welche Topics sind global verbindlich
- welche Payloads und Versionen gelten
- wie Änderungen, Erweiterungen und Migrationen geregelt werden
- Sicherstellung von Vergleichbarkeit und Wiederverwendbarkeit globaler Use-Cases (z. B. OEE, Energie, Qualität, Traceability)
- Enablement und Support
- Schulung interner Teams und Stakeholder
- Unterstützung bei Architekturfragen und Standardkonformität
- Weiterentwicklung und Optimierung des UNS-Gesamtsystems
- Enterprise-IT-Integration: Integration des UNS mit zentralen IT-Systemen (z. B. ERP, MES, BI, Data Lakes)
Wichtig: Die Governance definiert Standards und Regeln, nicht die konkrete Umsetzung im Werk. Ziel ist Standardisierung im globalen Namespace ohne operative Einschränkung im lokalen Namespace.
3. Dezentrale OT-Teams als lokale Daten-Owner
Dezentrale OT-Teams verantworten den lokalen Werks-Namespace und damit die konkrete Abbildung der realen Anlagen- und Prozesswelt. Sie sind Eigentümer der operativen Daten und deren fachlicher Bedeutung. Ihre Kernaufgaben umfassen:
- OT-Integration: Anbindung von Maschinen, Anlagen und Steuerungen (z. B. via OPC UA, Beckhoff TwinCat).
- Umsetzung globaler Modelle im lokalen Kontext: Abbildung der global definierten Namespace- und Datenmodelle auf reale Maschinen, Signale und Zustände.
- Datenqualität und Semantik: Sicherstellung korrekter Signalinterpretation, Ereignisdefinitionen und Zustände.
- Lokale Use-Cases: Umsetzung werksindividueller Use-Cases innerhalb des lokalen Namespaces wie Linienoptimierung, Instandhaltung oder lokale KPIs.
Der lokale Namespace ermöglicht es den Werken, schnell, autonom und innovationsfähig zu agieren, ohne den globalen Enterprise Namespace zu kompromittieren. Genau diese Balance aus lokaler Verantwortung und globaler Konsistenz ist ein zentrales Erfolgsprinzip des Unified Namespace.
Zusammenfassung: Rollen als Fundament des UNS
Die folgende Tabelle gibt einen kompakten Überblick über das bewährte Rollenmodell im Unified Namespace und die klar abgegrenzten Verantwortlichkeiten.
| Rolle | Primäre Rolle im UNS | Zentrale Verantwortlichkeiten | Bewusst ausgeschlossen |
|---|---|---|---|
| Corporate IT-Team | Enabler & Infrastruktur-Provider | Betrieb von Cloud- und On-Prem-Infrastruktur Container- und Plattformdienste Netzwerkarchitektur und Segmentierung IT-Security, IAM, Zertifikate und Verschlüsselung Monitoring, Incident- und Lifecycle-Management |
Keine fachliche Verantwortung für UNS Daten Keine Definition von Datenmodellen oder Semantik Keine OT-Signalinterpretation |
| Zentrales IT/OT-Team | Globaler Daten-Owner & Governance | Definition der UNS-Strategie und Architektur Gestaltung des globalen Enterprise Namespace Naming, Topics, Payloads und Semantik Governance und Versionierung Globale Use-Cases und Enterprise-Integration |
Kein Infrastruktur Betrieb Keine direkte Maschinenanbindung Keine lokale Signalverantwortung |
| Dezentrale OT-Teams | Lokaler Daten-Owner & operative Umsetzung | Verantwortung für den lokalen Fabrik-Namespace Anbindung von Maschinen und Anlagen Umsetzung globaler Modelle im lokalen Kontext Sicherstellung von Datenqualität Lokale, werkspezifische Use-Cases |
Keine Definition globaler Standards Keine unternehmensweite Governance Kein Betrieb zentraler Komponenten |
Schnittstellen & Verantwortungsübergaben (RACI-Ebene)
Die beschriebenen Rollen bilden das organisatorische Fundament. Für einen stabilen Betrieb müssen Verantwortlichkeiten jedoch über Schnittstellen hinweg geregelt sein. Genau hier unterscheidet sich ein tragfähiges UNS-Betriebsmodell von einer rein konzeptionellen Architektur. Das folgende RACI-Modell dient als architektonische Leitplanke für typische UNS-Aktivitäten.
| Aktivität | Corporate IT-Team | Zentrales IT/OT-Team | Dezentrale OT-Teams |
|---|---|---|---|
| Bereitstellung & Betrieb der UNS-Plattform | R / A | C | I |
| Definition globaler Namespace-Struktur | I | R / A | C |
| Einführung eines neuen globalen Topics | I | R / A | C |
| Definition von Naming, Topics & Payloads | I | R / A | C |
| Versionierung & Migration globaler Datenmodelle | I | R / A | C |
| Abbildung globaler Modelle im Werk | I | C | R / A |
| Anbindung von Maschinen & Steuerungen | I | C | R / A |
| Sicherstellung lokaler Datenqualität | I | C | R / A |
| Nutzung von UNS-Daten für lokale Use-Cases | I | C | R / A |
| Integration in zentrale IT-Systeme | C | R / A | I |
Legende: R = Responsible, A = Accountable, C = Consulted, I = Informed
Verantwortungsübergaben entlang des Datenlebenszyklus
Die Zuständigkeiten im UNS folgen dem natürlichen Lebenszyklus industrieller Daten:
Infrastruktur → Governance: Nach Bereitstellung der Plattform durch die IT liegt die Verantwortung für Struktur, Topics und Semantik beim zentralen IT/OT-Team.
Governance → Werk: Mit der Freigabe globaler Modelle übergibt die Governance die Verantwortung für die konkrete Umsetzung an die Werke. Die technische Integration von Signalen ist lokal verankert.
Werk → Enterprise-Nutzung: Sobald Daten im definierten Format publiziert werden, liegt die fachliche Verantwortung beim Werk. Zentrale Consumer können diese Daten nutzen, ohne die Entstehung im Detail kennen zu müssen.
Warum RACI-Modelle im UNS unverzichtbar sind
Ohne explizite Verantwortungsübergaben entstehen zwangsläufig:
- implizite Zuständigkeiten („IT kümmert sich schon“)
- Governance-Überlastung durch operative Themen
- lokale Umgehung globaler Standards
- politische Konflikte zwischen Zentrale und Werk
Change- & Eskalationsprozesse
Der Unified Namespace ist ein dauerhaftes Betriebsmodell. Besonders im Enterprise Namespace müssen Änderungen daher kontrolliert, versionierbar und konfliktarm erfolgen. Governance zeigt sich nicht in Richtlinien, sondern im operativen Umgang mit Changes.
Änderungen im Enterprise Namespace unterliegen klarer Verantwortung:
- Topics, Strukturen und Payloads im Enterprise Namespace dürfen ausschließlich durch das zentrale IT/OT-Team definiert, geändert oder freigegeben werden.
- Dezentrale OT-Teams setzen diese Vorgaben im lokalen Fabrik-Namespace um, ändern sie jedoch nicht eigenständig auf Enterprise-Ebene.
Versionierung statt Breaking Changes ist dabei ein zentrales Architekturprinzip:
- Änderungen werden als neue Versionen eingeführt (z. B. v1, v2), bestehende Strukturen werden nicht überschrieben.
- Alte und neue Versionen können parallel betrieben werden, bis alle Consumer migriert sind.
- Breaking Changes im laufenden Betrieb sind im Enterprise Namespace ausgeschlossen.
Eskalationen folgen klaren Pfaden:
- Abweichungen vom Standard erfolgen bewusst und ausschließlich im lokalen Namespace, ohne den Enterprise Namespace zu verändern.
- Datenqualitätsprobleme sind eine lokale (Level-3-)Verantwortung und werden nicht zentral korrigiert.
- Performance- oder Security-Konflikte zwischen IT und OT werden auf Governance-Ebene priorisiert und entschieden.
Erfolgskriterien im Unified Namespace
Ein Unified Namespace scheitert häufig an organisatorischen Fehlmustern. Entscheidend ist daher nicht nur das Zielbild, sondern die Fähigkeit, frühzeitig zu erkennen, wann ein UNS funktioniert – und wann nicht.
Typische organisatorische Anti-Pattern sind:
- Der Enterprise Namespace wird faktisch von der IT kontrolliert und fachliche Entscheidungen werden zentralisiert.
- Governance wird zu detailliert und verlagert operative Entscheidungen auf die Enterprise-Ebene – lokale Innovation wird ausgebremst.
- Werke umgehen den Enterprise Namespace, weil Standards als zu schwergewichtig oder unflexibel wahrgenommen werden.
- Der UNS wird als Projekt eingeführt, nicht als dauerhaftes Betriebsmodell mit klarer Ownership.
Diese Muster führen zu Akzeptanzverlust, Schattenlösungen und langfristig zur Erosion des Enterprise Namespace.
Erfolgreiche UNS-Architekturen lassen sich dagegen klar messen:
- Time-to-Use-Case: Wie schnell lassen sich neue Anwendungen auf Basis bestehender Daten umsetzen?
- Wiederverwendungsgrad: Wie häufig werden bestehende Topics und Datenmodelle unverändert genutzt?
- Anteil lokaler Sonderlösungen: Wie oft müssen globale Standards umgangen werden?
- Datenqualität: Stabilität, Vollständigkeit und Konsistenz der Enterprise-Daten.
Ein funktionierender Unified Namespace ist nicht der mit den meisten Regeln, sondern der, der globale Konsistenz im Enterprise Namespace mit lokaler Handlungsfähigkeit im Werk verbindet. Genau daran entscheidet sich sein Erfolg im Betrieb.
Fazit
Der Unified Namespace ist kein technisches Integrationsprojekt, sondern ein organisatorisches Betriebsmodell für industrielle Daten. Sein Erfolg hängt entscheidend von klar definierten Rollen, sauberen Verantwortungsübergaben und einer stabilen Governance ab. Erst diese organisatorische Klarheit macht den UNS zu einem skalierbaren, unternehmensweiten Datenrückgrat für IT- und OT-Architekturen.
