Enterprise-Ready ist eine andere Liga: die Datenplattform des ORF

Worum es in dieser Folge geht

Das ist die zweite von zwei Folgen aus dem ORF in Wien. In der ersten habe ich mit Carina Rogl über die Datenstrategie gesprochen, heute geht es um die Technik dahinter. Mir gegenüber saß Thorsten Steuer, seit zweieinhalb Jahren Data Architekt beim ORF. Er war der erste Neuzugang im neuen Datenteam und sollte dort für Struktur sorgen.

Vorgefunden hat er das, was in fast jedem gewachsenen Haus steht: Excel, SAP, Oracle, SQL-Datenbanken und viele große und kleine Insellösungen. Das Wissen war genauso fragmentiert. Der eine Power-User hatte ein PowerShell-Skript, der andere ein Python-Skript, irgendwo lief vielleicht noch ein Perl-Skript von vor 20 Jahren. Eine übergreifende Vision, wie diese Daten zusammengehören, gab es nicht. Dabei, sagt Thorsten, macht der ORF eigentlich nichts anderes, als Daten zu produzieren.

Die Storyline

Der erste Use Case

Cloud-Technologien waren im Haus vorher eher eine Nische. Thorstens erster Auftrag war deshalb auch ein Beweis: ein analytischer Use Case für Social Media, also welche Posts wie viele Likes und Shares bekommen, umgesetzt in der Cloud und übersetzt in eine moderne Visualisierung. Da war er gerade zwei Wochen im Team. Carina war eine Woche im Urlaub, und als sie wiederkam, standen die Daten bereit. Ihr Kommentar: Dann gehe sie öfter auf Urlaub.

Thorsten ordnet das selbst ein. So schnell ging es nur, weil es ein POC war, ohne SSO-Integration und ohne Governance. Es ging darum zu zeigen: Wir können das technisch.

Nicht arrogant rüberkommen

Ich wollte wissen, wie man aufgenommen wird, wenn man als Neuer Sachen anders machen und Standards einführen will. Thorstens Antwort war eine Haltung:

Ich habe die Weisheit nicht mit dem Löffel geschluckt und ich kenne das Unternehmen auch nicht gut genug.

Meistens haben gewachsene Lösungen einen guten Grund, warum sie so gebaut wurden. Also erst verstehen, warum jemand ein Problem mit einem PowerShell-Skript gelöst hat, und dann den Wert einer anderen Technologie darlegen. Und manches lohnt sich gar nicht: Wenn die Betreuung des Oracle-Servers noch zehn Jahre läuft, braucht es kein riesiges Migrationsprojekt.

Der Server ist nicht umsonst

Ein Haus, das stark von On-Prem geprägt ist, hält die Cloud oft für unsicher und teuer. Thorsten dreht das Argument um. In der Cloud sieht man sehr genau, was etwas kostet.

Dann sagt man ja, der Server ist umsonst. Dann denkst du, nein, der Server ist nicht umsonst.

Später im Gespräch rechnet er vor, was On-Prem wirklich bedeutet: Hardware beschaffen, ein Kühlraum, Patch-Management, Netzwerk, Observability. Und mindestens eine Person, die sich um die Server kümmert, damit es keine Security-Vorfälle gibt.

Zweieinhalb Leute, eine Plattform

Heute hat der ORF eine fertige Plattform. Dass sie nicht aus einzelnen Open-Source-Lösungen zusammengestückelt ist, hat einen einfachen Grund: das Team.

Wer Airflow, Trino und weitere Technologien selbst zusammensteckt, braucht laut Thorsten fast für jede Technologie ein FTE. Die Strategie hatte die Richtung Lakehouse vorgegeben. Bei rund 6.000 Mitarbeitenden war für ihn außerdem klar, auf einen etablierten Anbieter zu setzen, weil irgendwann jemand das nächste Governance-Feature braucht und es dann schon da ist. Ein Beispiel: Der Coding-Agent kommt beim Hersteller mit. Ihn selbst für die eigene Plattform zu bauen, wäre wieder ein eigenes FTE.

Die Auswahl lief pragmatisch. Thorsten und ein Kollege haben den Social-Media-Use-Case parallel auf zwei Plattformen umgesetzt, über Testzugänge, die man bei den großen Anbietern leicht bekommt. Am Ende haben sie die Kosten verglichen, und die Plattform, die besser funktioniert hat, war glücklicherweise auch die günstigere. Ein kleinerer, sehr innovativer Anbieter fiel raus, weil ihm Governance-Features fehlten. Und beim Compliance-Check hat das CISO-Office vier oder fünf ISO-Zertifizierungen verlangt, daran sind zwei weitere Anbieter gescheitert.

Nutzbar ist nicht Enterprise-Ready

Benutzbar war die Plattform nach drei, vier Monaten. Eine andere Abteilung, die schon auf das Tool gewartet hatte, konnte darauf erste Use Cases ausprobieren. Danach kam der aufwendige Teil: eine Schutzbedarfsanalyse mit dem CISO-Office, die Abstimmung mit dem Datenschutzbeauftragten, ein Register-Prozess und Themen wie das Recht auf Löschung. Dazu ein Penetrationstest mit einem externen Partner, Intrusion-Detection-Systeme und die Frage, welche Log-Events wann einen Alarm auslösen.

Geholfen hat eine erfahrene Person im Team, die selbst schon auf der anderen Seite stand und Penetrationstests gemacht hat. Thorsten sagt offen, dass er das allein bei weitem nicht so ordentlich hinbekommen hätte. Und das bei einer einzigen Plattform. Mit vier verschiedenen Tools wäre er nach eigener Einschätzung wahrscheinlich nie fertig geworden.

Enterprise-Ready ist was anderes, als ich tu mal irgendwas in Docker-Compose hochziehen. Das ist einfach eine komplett andere Liga.

Heute laufen CI/CD-Workflows durch alle Stages, die Rechtevergabe zwischen zentral und den Teams ist geklärt, Daten kommen meist über Python oder über den Kafka-Cluster rein. Klick-Konfiguration von Hand braucht es nicht mehr.

Die Broadcast-ID aus technischer Sicht

In der ersten Folge hat Carina die Broadcast-ID als den größten Hebel beschrieben. Thorsten erklärt, warum sie technisch innovativ ist. Sie ist dezentral: Es gibt kein System in der Mitte, das IDs verteilt, sondern jedes System stellt seine IDs selbst aus. Sie hat ein URI-Format, ähnlich einer URL, und trägt ihre Bedeutung in sich: erst die Entität, etwa Creation, also der Beitrag, dann das System, dann die Nummer.

Damit wird das Master-Data-Management-Problem an der Quelle gelöst, statt hinten ein System zu kaufen, das per Match & Merge und Approximation versucht, dieselben Beiträge zusammenzuführen. Die Fachabteilungen, die die Systeme besitzen, besitzen auch die ID und die Logik dahinter. Der Trade-off: Eine dezentrale ID braucht mehr Kommunikation und macht von mehr Systemen abhängig. Wie gut der ORF damit fährt, wird sich nach Thorstens Einschätzung in zwei bis drei Jahren zeigen.

Die Idee stammt von der ARD, kopieren ließ sie sich trotzdem nicht. Bundeslandsendungen etwa sind beim ORF als Platzhalter geplant, und ein Platzhalter ist kein Content, der ausgestrahlt wird. Also bekommt er keine Creation-ID, sondern wird als Publication-Plan-Entität geführt, die dann auf die Creation verweist. Für Thorsten ist ein Standard deshalb eher ein Stadtplan als eine Blaupause. Den Stadtplan einer anderen Stadt kann man nicht über Wien legen, aber man kann sich abschauen, wo Bushaltestellen und Fußgängerzonen sinnvoll sind.

Zentral, dezentral und die Data Heroes

Wie bei Carina geht es auch technisch um den Data-Mesh-Gedanken. Es gibt lokale Data Heroes, aktuell vor allem zwei Abteilungen: eine, die seit 20, 30 Jahren Quoten auswertet, und die Online-Abteilung. Sie bekommen einen eigenen Workspace, alle zwei Wochen gibt es ein Community-Meeting, und das Plattform-Team liefert Bausteine wie CI/CD-Templates. Andere Abteilungen sind weiter weg, etwa dort, wo die Hardware im Vordergrund steht. Wenn dort auf den Vorschlag, etwas selbst zu ownen, ein klares Nein kommt, wird es eben verschoben.

Die Grenze zieht Thorsten klar. Zentral sind Infrastruktur, Compliance, Rechtekonzept und die Vorgaben, welche Tools wie benutzt werden, also alles, was use-case-unabhängig ist. Was use-case-spezifisch ist, gehört ins Team.

Um mehr Menschen auf die Plattform zu holen, will das Team das Abstraktionslevel erhöhen. Der eingebaute Agent führt durch die Plattform, man kann ihn in natürlicher Sprache um Daten und Visualisierungen bitten. Dazu gibt es eine Sandbox mit eigenem Budget, in der alle ausprobieren dürfen, um die Angst vor dem Tool zu nehmen. Low-Code hält Thorsten durch AI-Coding-Tools inzwischen für verzichtbar. Es braucht aber eine Validierung, bevor etwas in Produktion geht.

Lock-in ist eine Budgetfrage

Ich habe Thorsten gefragt, wie viel Abhängigkeit vom Anbieter er sich eingekauft hat. Seine Antwort: Lock-in ist immer eine Frage des Budgets. Mit einem Team von fünf Leuten könnte man komplett souverän sein. Ansonsten trifft man bewusste Entscheidungen. Für Transformationen setzt der ORF auf das Open-Source-Framework dbt statt auf das proprietäre SQL-Tool der Plattform, weil das kaum wehtut. Beim Coding-Agent und der Integration der Komponenten nimmt das Team den Lock-in bewusst in Kauf, mit einer Exit-Strategie im Hintergrund. Und Thorsten wettet darauf, dass Coding-Agents künftige Migrationen deutlich billiger machen.

Was ein Knowledge Graph nicht löst

Auch beim ORF wollten alle einen Knowledge Graph. Das Team hat aber gemerkt, dass die Technologie weniger kann, als der Hype verspricht. Knowledge Graphs und Ontologien sind im Kern Schema-Mapping. Man kann abbilden, dass das Feld Vorname in Datenbank Y dasselbe bedeutet wie in Datenbank Z. Man kann aber nicht prüfen, ob Max Mustermann in Datenbank 1 derselbe ist wie in Datenbank 2. Dieses Matching löst die Broadcast-ID, nicht der Graph.

Graphen sind für Netzwerkanalysen gemacht. Ob ein bestimmter Gast in einer bestimmten Sendung war, ist eine einfache SQL-Abfrage, vorausgesetzt, die Metadaten stimmen. Und genau diese Qualität hat das Haus noch nicht. Einen POC hält Thorsten erst dann für sinnvoll, wenn es einen konkreten Use Case aus dem Journalismus und die passende Datenqualität gibt.

Den größten Wert der ganzen Debatte sieht er woanders: Leute machen sich Gedanken über ein Unternehmensdatenmodell. Dafür braucht es nicht gleich eine vollständige Ontologie. Man kann mit einem Bild anfangen, auf dem die Datentöpfe stehen, und fragen, wie sie zusammenhängen. Das ist eine fachliche Diskussion, keine technologische.

Keine allwissenden Agenten

Bei Agenten ist der ORF wie die meisten Häuser noch am Anfang. Thorsten erinnert an eine Gartner-Abschätzung, nach der bis 2027 rund 80 Prozent der GenAI-Use-Cases produktiv sein sollten. Auf einer Konferenz vor zwei Wochen hieß es dagegen, dieses Jahr seien nur 18 Prozent produktiv. Beim ORF gibt es erste agentische Workflows, etwa einen Recherche-Agenten, der Web- und Wiki-Suche kombiniert. Kontext bekommen sie bislang meist, indem jemand ein PDF oder ein Bild hochlädt. Und das menschliche Element muss beim ORF ohnehin immer dabei sein.

Ich bin mir sehr sicher, dass es nicht der allwissende Agent geben wird, der ein Interface hat, der alle Probleme löst, sondern es wird sehr viele spezifische Agenten geben, die von den Leuten gewartet werden müssen, die sehr nah am Prozess sind.

Damit landet er wieder beim Data Mesh und beim Skill Gap. Die Fachbereiche können mit ChatGPT arbeiten, aber einen agentischen Workflow zu designen und zu evaluieren ist etwas anderes. Agenten sind probabilistisch. Reicht es, wenn acht von zehn Antworten korrekt sind? Was passiert bei den anderen zwei? Dafür gibt es noch keine Best Practices.

Was Thorsten heute anders machen würde

Auf die Frage, was er als Erstes bauen würde, wenn er noch einmal anfangen könnte, sagt Thorsten: erst einmal innehalten. Unterschätzt hat er, die Fähigkeiten im Haus richtig einzuschätzen. In den ersten ein, zwei Jahren wäre eine Low-Code-Lösung vielleicht besser gewesen, weil die Einstiegshürde eher dem Skill-Level der Fachbereiche entspricht. Wer Data Mesh ernst nimmt, muss diese Hürde so niedrig wie möglich halten und das Engineering-Herz manchmal zur Seite legen. Gleichzeitig zahlt sich die größere Plattform gerade aus, weil Feature-Requests kommen, die eine kleinere Lösung nicht hätte tragen können.

Aber die guten Ingenieure sind immer die, die das Business verstehen.

Privat probiert Thorsten neue Standards und Plattform-Features aus und schreibt darüber auf LinkedIn. Außerdem organisiert er das Data Engineer Meetup in Wien mit. Sein Filmtitel für die Folge ist Into the Wild: erst einmal irgendwo reinkommen, wo sich alles wild anfühlt, und unterwegs herausfinden, wo die Value Propositions liegen. Und dazu der Grundgedanke des Films, dass Glück nur echt ist, wenn man es teilt. Für Thorsten gilt das auch für Daten.

Warum mich das besonders umtreibt

Ich habe in einem meiner letzten Vorträge gesagt, dass neue Technologie oft die Lazy-Antwort ist. Wir versuchen, Probleme mit etwas Neuem zu lösen, ohne uns die Prozesse anzuschauen. Thorstens Punkt mit dem Innehalten trifft genau das. Man kann das schnellste Auto kaufen, aber wenn die Fahrerinnen und Fahrer die Kurven noch nicht fahren können, reicht vielleicht eines mit weniger PS. Erst ein ehrliches Skill-Assessment, dann die Technik.

Gleichzeitig mag ich, wie pragmatisch der ORF bei der Auswahl war. Einen Account bei den großen Anbietern holen, denselben Use Case parallel bauen, Kosten vergleichen, entscheiden. Sonst kauft man sich ein riesiges Auto mit hohen SaaS-Kosten, auf die man sich committed hat, und am Ende kann es niemand nutzen.

Und plant die Enterprise Readiness ein. Wer seiner Geschäftsführung eine Plattform in drei Monaten verspricht, muss dazusagen, dass Compliance und Security danach noch einmal so lange dauern können. Schreibt mir, wie lange das bei euch gedauert hat. Und wer die Strategie dahinter hören will: Die erste Folge mit Carina Rogl ist die Grundlage für diese hier.