Seminar T-Systems DIH – Architektur souveräner Datenräume

Das Seminar ordnet die DIH-Bausteine in eine durchgängige Datenraumarchitektur ein. Betrachtet werden Teilnehmer, Identitäten, Kataloge, Connectoren, Verträge, Policies, Datenübertragung, Anwendungsschicht und Betriebsdienste sowie deren Zusammenspiel in föderierten Ökosystemen.

Inhaltsübersicht

1. Einordnung und Zielsetzung
2. Lernziele
3. Zielgruppe und Voraussetzungen
4. Schrittweise Seminarinhalte
   1. Datenräume als föderiertes System
   2. DIH-Produkt- und Plattformbausteine
   3. Vertrauensarchitektur und Teilnehmeridentität
   4. Connector-, Katalog- und Vertragsarchitektur
   5. Anwendungs-, Compute- und Integrationsschicht
   6. Cloud- und Netzwerkarchitektur
   7. Security, Monitoring und Betriebsfähigkeit
   8. Zielarchitektur und Entscheidungsdokumentation
5. Praxisübungen
6. Arbeitsweise und Qualitätskontrollen

Lernziele

• Zentrale Architekturprinzipien souveräner und dezentraler Datenräume erklären
• DIH-Komponenten fachlich und technisch voneinander abgrenzen
• Daten-, Kontroll- und Vertrauensflüsse in Architekturdiagrammen darstellen
• Cloud-, Netzwerk- und Integrationsentscheidungen anhand von Anforderungen treffen
• Eine belastbare Zielarchitektur mit Sicherheits- und Betriebsanforderungen entwickeln

Zielgruppe und Voraussetzungen

Zielgruppe: Enterprise- und Solution-Architektur, Data Architecture, Cloud Architecture, Security Architecture, technische Projektleitung und Dataspace-Konzeption.

Voraussetzungen: Fundierte IT-Grundkenntnisse zu APIs, Cloud-Plattformen, Identitäten und Datenintegration. Vorkenntnisse zu Data Spaces sind hilfreich, werden jedoch nicht vorausgesetzt.

Seminarinhalte

Die Inhalte werden in einer aufeinander aufbauenden Reihenfolge erarbeitet. Jeder Schritt verbindet fachliche Einordnung, technische Details, Kontrollfragen und eine anwendungsbezogene Aufgabe.

Schritt 1: Datenräume als föderiertes System

Zunächst wird das Datenraumprinzip von zentralen Plattform- und Data-Lake-Ansätzen abgegrenzt. Der Fokus liegt auf verteilter Verantwortung, interoperablen Diensten und der Kontrolle über Nutzungsbedingungen.

• Teilnehmer und Rollen im Ökosystem
• Dezentrale Datenhaltung
• Föderierte Dienste
• Souveränität gegenüber reinem Zugriffsschutz

Praxisaufgabe: Modellierung eines einfachen Datenökosystems mit Provider, Consumer und Operator.

Schritt 2: DIH-Produkt- und Plattformbausteine

Die Produktfamilie wird als Architekturportfolio betrachtet. Plattform und Workbench, Connect & Integrate, Build & Operate, LivingLab, Digital.ID und Motion Data werden ihren Aufgaben zugeordnet.

• Plattform- und Administrationsdienste
• Souveräner Datenaustausch
• Eigener Datenraum und Anwendungsschicht
• Vertrauens- und Identitätsdienste
• Datenprodukte und Analyseangebote

Praxisaufgabe: Zuordnung von Anforderungen zu geeigneten DIH-Bausteinen.

Schritt 3: Vertrauensarchitektur und Teilnehmeridentität

Vertrauen wird als Kombination aus geprüften Organisationen, digitalen Nachweisen, Zertifikaten und technischen Identitäten beschrieben. Die Rolle von Verifiable Credentials und standardisierten Vertrauensrahmen wird eingeordnet.

• Organisationsidentität
• Digitale Nachweise und Signaturen
• Zertifikats- und Schlüsselmaterial
• Authentisierung und Autorisierung
• Lebenszyklus von Vertrauensinformationen

Praxisaufgabe: Entwurf einer Vertrauenskette für die Aufnahme eines neuen Teilnehmers.

Schritt 4: Connector-, Katalog- und Vertragsarchitektur

Der Datenzugriff entsteht aus auffindbaren Angeboten, Vertragsdefinitionen, Verhandlungen und technischen Übertragungen. Die Steuer- und Datenebene werden getrennt betrachtet.

• Asset und Datenangebot
• Föderierter Katalog
• Contract Definition und Contract Negotiation
• Policy-Auswertung
• Transferprozess

Praxisaufgabe: Zeichnung eines Sequenzdiagramms vom Finden eines Assets bis zum Datentransfer.

Schritt 5: Anwendungs-, Compute- und Integrationsschicht

Datenraumfähige Anwendungen benötigen Laufzeitumgebungen, Schnittstellen und kontrollierte Verbindungen zu Backend-Systemen. Compute Nodes, App-Orchestrierung und Integrationsadapter werden in die Gesamtarchitektur eingeordnet.

• Anwendungsbereitstellung
• API- und Dateiintegration
• ERP-, PLM- und ALM-Anbindung
• Semantische Transformation
• Secret- und Konfigurationsmanagement

Praxisaufgabe: Ausarbeitung einer Integrationsskizze für ein bestehendes ERP-System.

Schritt 6: Cloud- und Netzwerkarchitektur

Die cloud-agnostische Bereitstellung wird anhand von Sicherheitszonen, Mandantentrennung, Konnektivität und Betriebsverantwortung bewertet. Hybrid- und Multi-Cloud-Szenarien werden berücksichtigt.

• Cloud-Auswahlkriterien
• Netzwerkzonen und Endpunkte
• Ingress, Egress und Firewall-Regeln
• Namensauflösung und Zertifikate
• Hochverfügbarkeit und Skalierung

Praxisaufgabe: Bewertung zweier Bereitstellungsvarianten anhand eines Kriterienkatalogs.

Schritt 7: Security, Monitoring und Betriebsfähigkeit

Eine Zielarchitektur gilt erst dann als vollständig, wenn Betriebsbeobachtung, Störungsanalyse, Wiederanlauf und Verantwortlichkeiten integriert sind.

• Schutzbedarfsanalyse
• Logging, Metriken und Dashboards
• Alarmierung und Incident-Prozesse
• Backup- und Wiederanlaufkonzept
• Release- und Änderungsmanagement

Praxisaufgabe: Ergänzung eines Architekturdiagramms um Betriebs- und Sicherheitsbausteine.

Schritt 8: Zielarchitektur und Entscheidungsdokumentation

Alle Bausteine werden in einer Zielarchitektur zusammengeführt. Architekturentscheidungen werden mit Annahmen, Alternativen, Risiken und Konsequenzen dokumentiert.

• Kontext- und Containerdarstellung
• Nichtfunktionale Anforderungen
• Architekturentscheidungen
• Roadmap und Übergangszustände
• Abnahmekriterien

Praxisaufgabe: Erstellung eines Architecture Decision Records für die Connector-Bereitstellung.

Praxisübungen

• End-to-End-Architektur für einen branchenübergreifenden Datenaustausch
• Sequenzdiagramm für Katalogsuche, Vertragsverhandlung und Datenübertragung
• Entscheidungsmatrix für Cloud-, Connector- und Integrationsoptionen

Arbeitsweise und Qualitätskontrollen

Vortrag, moderierte Analyse, Systemdemonstration, strukturierte Checklisten und praktische Übungen werden miteinander kombiniert. Konfigurationen und Konzepte werden jeweils gegen Vollständigkeit, Konsistenz, Sicherheit, Nachvollziehbarkeit und Betriebsfähigkeit geprüft. Übungsfälle enthalten auch Fehlersituationen, damit Diagnose- und Entscheidungswege nicht nur im Idealzustand nachvollzogen werden.