Was ein Datenraum wirklich leistet – und was nicht

Was ist eigentlich ein Datenraum? 

Sinnvoller als die Definition ist zunächst die Frage nach dem Problem. Datenbanken, Data Warehouses, Data Lakes – an Konzepten zur Datenhaltung mangelt es nicht. Warum also noch ein weiteres? 

Die Antwort liegt in der Zahl der Beteiligten. Klassischer Datenaustausch ist bilateral: zwei Parteien einigen sich, schließen eine Schnittstellenvereinbarung, tauschen Zugangsdaten aus. Mit jedem neuen Partner wächst aber die Zahl der benötigten Vereinbarungen um ein Vielfaches, und der bürokratische Aufwand wird schnell größer als der Nutzen. Genau hier setzt das Konzept des Datenraums an – und es beruht auf drei Kerngedanken: 

Erstens: eine Architektur, keine Plattform. Einige zentrale Dienste organisieren Vertrauen und Auffindbarkeit, der Betrieb selbst läuft dezentral. Bei jedem Teilnehmer sitzt eine Softwarekomponente – der Konnektor –, die mit den Konnektoren der anderen Nutzer eine gemeinsame Sprache spricht, Nutzungsbedingungen aushandelt und den Austausch abwickelt – automatisiert und nach einheitlichen Standards. Der Aufwand pro neuem Partner sinkt damit dramatisch. 

Zweitens: Datensouveränität. Die Daten fließen nicht durch den Datenraum hindurch und werden dort nicht gespeichert. Er stellt nur die Verbindung her, der Transfer läuft direkt zwischen Geber und Nehmer. Genau deshalb gibt es das Konzept: Viele Organisationen wollen Daten teilen, aber unter keinen Umständen die Hoheit darüber abgeben.  

Drittens: Vertrauen und Sicherheit. Ein Datenaustausch ohne zentrale Instanz funktioniert nur, wenn jeder Teilnehmer sicher sein kann, mit wem er es zu tun hat. Dafür weisen sich die Beteiligten über Zertifikate aus, die von den zentralen Vertrauensdiensten des Datenraums verwaltet werden – erst ein Onboarding, in dem die Echtheit der teilnehmenden Organisation geprüft wird, dann die Teilnahme. Sicherheit ist damit keine nachgelagerte Frage, sondern eine tragende Säule der Datenraum-Spezifikation. 

Woher das Konzept kommt 

Die Wurzeln liegen in Europa, bei Gaia-X. Ursprünglich ging es darum, dem Übergewicht außereuropäischer Cloud-Anbieter etwas entgegenzusetzen – nicht durch eigene Rechenzentren, sondern durch ein Regelwerk für souveräne Datennutzung auch auf fremder Infrastruktur. Aus dieser Initiative heraus entstand das Konzept der Datenräume. Entstanden sind dabei zunächst Spezifikationen, keine Software. Parallel dazu hat die International Dataspace Association Standards für den Datenaustausch entwickelt, auf die sich die technischen Umsetzungen beziehen. 

Die technische Grundlage bilden heute die Eclipse Dataspace Components, entwickelt unter dem Dach der in Brüssel ansässigen Eclipse Foundation, von der über 450 Open-Source-Projekte betreut werden. Praktisch alle Datenräume, die wir uns angesehen haben, bauen darauf auf. Sie liefern aber nur das Fundament und müssen für den konkreten Anwendungsfall ausgestaltet werden – und sie sind jung: Wer heute einen Datenraum baut, arbeitet mit einer Technologie, die sich noch spürbar weiterentwickelt. Übrigens: Die Idee ist europäisch, die Nutzung nicht zwingend. In etablierten Datenräumen der Automobilbranche sind längst auch außereuropäische Unternehmen beteiligt. 

Der Konnektor: Agent der eigenen Organisation 

Das zentrale Element der Datenraum-Architektur ist der Konnektor. Man kann ihn als Server beschreiben, der Daten sendet und empfängt. Anschaulicher ist das Bild eines Agenten, der im Datenraum stellvertretend für die eigene Organisation handelt. Über eine Steuerungsschnittstelle lässt sich diesem Agenten auftragen, bei einem anderen Konnektor den Datenkatalog abzufragen, eine Nutzungsvereinbarung auszuhandeln und die gewünschten Daten zu beziehen. Innerhalb des Konnektors lassen sich mehrere Nutzerinnen und Nutzer mit unterschiedlichen Rechten anlegen. Man agiert im Datenraum also nie als Einzelperson, sondern immer über den Konnektor der eigenen Organisation. 

Selbst betreiben oder als Dienst einkaufen? 

Als Organisation hat man drei Möglichkeiten, einen Konnektor in das eigene System zu integrieren: 

• Connector as a Service – ein Dritter betreibt den Konnektor, man bindet nur die eigenen Daten an; besonders attraktiv für kleinere Organisationen.  
• Eigenbetrieb – Betreiber stellen den Konnektor häufig als Container-Image bereit, man hostet ihn selbst; oft der pragmatische Mittelweg.  
• Eigenentwicklung – technisch möglich, praktisch selten, und je nach Datenraum aus Sicherheitsgründen mit einem Audit verbunden.  

Datenformate und Data Governance 

Technisch kann ein Konnektor praktisch alle Datenformate transportieren. Diese an sich positive Eigenschaft kann bei nicht vorhandenen Standards auch zum Problem werden: Legt jeder Datengeber sein Format selbst fest, können Datennehmer gezwungen sein, die Daten selbst zu konvertieren und Lücken ausgleichen. Dann hat man das Skalierungsproblem der bilateralen Verträge nur von der vertraglichen auf die technische Ebene verschoben. 

Um das zu vermeiden, braucht es Data Governance – keine technische, sondern eine organisatorische Instanz, die Beteiligte zusammenbringt, Anwendungsfälle moderiert und Ergebnisse regelmäßig als Standards veröffentlicht. In etablierten Datenräumen finden sich umfangreiche Festlegungen, wie beispielsweise ein einzelnes Bauteil zu beschreiben ist und wie der Abrufendpunkt aussehen muss. Das wirkt kleinteilig, ist aber die eigentliche Wertschöpfung.  

Wann lohnt sich ein Datenraum? 

Ein Datenraum ist deutlich komplexer als ein API-Portal. Wenn es nur wenige Datengeber und viele reine Konsumenten gibt, lässt sich derselbe Zweck einfacher erreichen: Jeder stellt seine Daten über eine eigene Schnittstelle bereit, eine gemeinsame Seite verweist darauf. Datensouveränität hat man dabei ebenfalls, und die Hürde für Abnehmende ist niedriger – eine simple Schnittstelle fragt man mit ein paar Zeilen auf der Kommandozeile ab.  

Seine Stärke spielt der Datenraum dort aus, wo viele Beteiligte zugleich Daten geben und nehmen. In der Automobilbranche etwa tauschen Hersteller und Zulieferer entlang der Lieferkette laufend Angaben zum Lagerbestand und Bedarf aus, damit just in time produziert werden kann – und derselbe Abnehmer bezieht dasselbe Bauteil von mehreren konkurrierenden Zulieferern, idealerweise in identischer Struktur. Der Austausch läuft in viele Richtungen, wiederholt sich ständig, und jeder neue Partner lässt sich anbinden, ohne mit allen bestehenden neu zu verhandeln. Eine Sammlung einzelner Portale bildet das nicht ab. 

Den Ausschlag gibt also nicht die Technik, sondern das abgestimmte Verhalten: gemeinsam definierte Anwendungsfälle, verbindliche Standards, Austausch in mehrere Richtungen – dazu ein Anreiz, der Beteiligung erzeugt. Der kann regulatorisch sein oder wirtschaftlich: Ich muss den Austausch ohnehin organisieren, oder ich verkaufe meine Produkte besser, wenn ich teilnehme. Wo dieser Anreiz vorhanden ist, funktionieren Datenräume nachweislich. 

Was das für InfraSpace heißt 

Aus Recherche und Marktgesprächen hat sich für uns eine schärfere Einsicht in die Anforderungen von Datenräumen ergeben: 

• Die Technik ist nicht der Engpass. Ein System hinzustellen ist machbar. Das wahrscheinlichste Ergebnis eines rein technischen Vorgehens wäre aber: ein paar angebundene Datenquellen, ein paar zufriedene Abnehmer – und danach ein Datenfriedhof, der vor allem Kosten verursacht. 
• Es braucht einen Mix aus Anwendungsfällen. Gemeinwohlorientierte Fälle sind Teil unseres Projektauftrags und bergen viel Potenzial für Forschung und Verwaltung. Gibt es aber nur solche Fälle, stellt sich die Frage nach dem Aufwand. Erfahrungen aus anderen Branchen legen nahe, mit wirtschaftlich starken Anwendungsfällen zu starten und die offeneren Themen darauf aufzubauen.  
• Die Teilnehmerstruktur ist entscheidend. Absehbar wird die  DB InfraGO AG der mit Abstand größte Datengeber sein. Umso wichtiger ist es, weitere Eisenbahnverkehrs- und Infrastrukturunternehmen als aktive Teilnehmer zu gewinnen. Wir werden gemeinsam mit unseren potentiellen Datengebern und –nehmern herausfinden, in welcher Form InfraSpace den größten Nutzen für sie bringen kann. 
• Ein Datenraum löst kein Datenqualitätsproblem. Er regelt, wie Daten ausgetauscht werden, nicht ob sie gut sind. Viele Hoffnungen an das Projekt betreffen aber genau die Qualität und Struktur der Daten. Dafür braucht es Data Governance. 

Wie es weitergeht 

Die zentrale Erkenntnis dieser Projektphase in einem Satz:  Ein Datenraum ist kein Produkt, das man kauft, sondern ein Vorhaben, das man um Anwendungsfälle und Data Governance herum baut. An den Anwendungsfällen wird intensiv gearbeitet, die Data-Governance-Seite ist die nächste große Baustelle – und über beides werden wir in nächster Zeit ausführlich in der Projektwerkstatt berichten.