Patrick Steiner: nicht weil sie es nicht wissen wollen, sondern weil niemand diese Unterscheidung je explizit gemacht hat. Das ist die wichtigste konzeptionelle Verschiebung dieses Gesprächs. Alles andere baut darauf auf. Willkommen zurück zum Databricks Deutschland Podcast. Dem Podcast, in dem wir nicht nur über Daten und KI sprechen, sondern auch über die Menschen, die das Ganze möglich machen. Heute ist es etwas anders als in den anderen Podcasts. Keine Gäste, keine Gesprächspartner, nur ich. Und ein Thema, das mich seit Jahren beschäftigt und das ich bei fast jedem Kundengespräch irgendwann anspreche. Warum schöpfen so viele Datenplattformen nicht ihr volles Potenzial für ihre Unternehmen aus? Obwohl die Technik einwandfrei läuft. Ich bin Patrick Steiner. Wenn man den mandatory voluntary split nicht bewusst macht, verharrt die Datenplattform fast zwangsläufig in einem von mehreren Mustern. Ich nenne sie die fünf Wege, wie Potenzial ungenutzt bleibt. Schauen wir uns die mal an. Erstes Muster, offent workspaces. Ein Projekt endet, der Workspace nicht. Niemand weiß, was darin läuft. Niemand weiß, was es kostet. Senior Manager Solution Engineering bei Databricks Deutschland. Bevor ich anfange, kurz zur Einordnung, weil das für heute schon wichtig ist. Ich habe einige Jahre bei Pivotal verbracht. Das war die Pivotal Software-Ära, Cloud Foundry, Pivotal Labs, Extreme Programming, all diese Dinge. Und danach bei VMware Tanzu. Bei einem typischen Enterprise Databricks Deployment kann unkontrollierter Workspace-Wildwuchs 15 bis 30 Prozent des gesamten Compute Budgets verschlingen. Für Workloads, die niemand mehr als geschäftskritisch identifizieren kann. Zweite Muster, Governance Theater. Unity Catalog ist aktiviert. Zugriffsrichtlinien existieren. Das ist die Community, aus der die Idee Platform as a Product überhaupt erst kommt. Evan Butcher's Artikel aus 2018, Skeleton and Pace mit Team Topologies 2019. Das ist nicht Literatur, die ich nachträglich gelesen habe. Das ist der Kontext, in dem ich gearbeitet habe. Was ich gleich erzähle, basiert nicht auf ein Buch. Es basiert auf dem, was ich dort gesehen habe. Das Compliance-Team hat abgezeichnet. Aber wenn man ein Mitglied des Plattformteams fragt, warum eine bestimmte Richtlinie existiert, stille. Niemand kann es erklären. Niemand reviews sie quartalsweise. Das ist Governance als Checkbox, nicht als lebendiger Vertrauensmechanismus. In DSGVO regulierten Umgebungen, also in jedem deutschen Unternehmen, ist das kein theoretisches Risiko. Das ist ein Auditbefund, der noch nicht geschrieben wurde. und auf dem, was ich seit meinem Wechsel zu Databricks tagtäglich bei Kunden erlebe. Und noch eine Sache. Die Beispiele, die ich bringe, sind absichtlich überspitzt. Das echte Leben ist immer messier, immer nuanzierter. Kunden sind keine Karikaturen. Aber wenn man Muster sehen will, muss man sie erst scharf zeichnen. Dritte Muster, das unsupported Notebook. Ein Data Scientist hat vor zwei Jahren eine geschäftskritische Pipeline in einem Databricks Notebook geschrieben. Die Person hat das Unternehmen verlassen. Niemand sonst versteht den Code. Das Plattformteam kann nicht garantieren, dass es nächsten Monat noch funktioniert und das Unternehmen ist davon abhängig. Viertes Muster, der Data Swamp. Ich erzähle Komposite Geschichten. Keine echten Kunden haben, keine echten Kunden unternehmen. Aber die Muster, die sind real. Die habe ich gesehen. Also, warum schöpfen so viele Datenbankformen nicht ihr volles Potenzial aus für ihre Unternehmen, obwohl die Technik einwandfrei läuft? Ich erinnere mich an einen Kunden, ein großes deutsches Industrieunternehmen, deren Daten wurden ingested, ohne Ownership, ohne Dokumentation, ohne Kuration. Der Katalog enthält 10.000 Tabellen. Niemand kann zuverlässig unterscheiden, was produktiv ist, was experimentell ist und was veraltet ist. Und Analysten, die keine verlässlichen Daten finden, tun genau das, was die Parkform verhindern sollte. Plattformteams zwei Jahre lang die beste Abtime im Konzern hatte. 99,97 Prozent Verfügbarkeit. Keine ungeplanten Ausfälle. Saubere Runbooks. Das Team war stolz drauf und das zu Recht. Technisch war alles in Ordnung. Und trotzdem hatte nicht eine einzige Fachabteilung die Plattform produktiv genutzt. Sie exportieren Daten in eigene Environments und bauen Shadow Pipelines. Und dann das fünfte Muster. Die eigentliche Wurzel aller anderen. Plattform als Projekt. Die Plattform wird wie ein IT Projekt gestartet. Zwölf Monate Implementierung, fixes Budget, Go Live Datum. Wenn ich das in Gesprächen erzähle, nicken die meistens Videos. Manche lachen ein bisschen und dann sagen sie, ja, wir kennen das Problem. Wir arbeiten gerade an Change Management. Das ist der Moment, in dem ich kurz innehalte, denn Change Management ist meistens der richtige Instinkt auf dem falschen Niveau. Change Management setzt voraus, dass das Produkt stimmt und die Menschen das Problem sind. Am Go Live gibt es eine Feier, das Team löst sich auf, sechs Monate später ist niemand mehr verantwortlich. Keine Roadmap, kein Backlog, keine Ownership. Die vier Muster oben sind das, was in dieses Vakuum strömt. Das ist kein technisches Versagen. Databricks funktioniert. Die Subflipsen-Kosten sind okay. Aber was ich immer wieder sehe, ist das Gegenteil. Das Produkt ist das Problem. Die Plattform ist zu schwer zu nutzen als die Alternative. Der Onboarding-Prozess dauert vielleicht sechs Wochen. Dokumentation ist lückenhaft. Und dann schicken wir Schulungen raus und wundern uns, warum die Adoption nicht steigt. Das ist keine Technikfrage. Das ist eine Operating-Model-Frage. Die Cluster laufen, das Potential bleibt ungenutzt, weil niemand je verantwortlich war für das, was mit der Plattform nach dem Go Live passiert. Und das lässt sich nicht durch bessere Dokumentationen lösen und auch nicht durch mehr Schulungen. Es braucht eine strukturelle Entscheidung. Bei Pivotal haben wir das früh gelernt. Nicht aus Büchern, sondern aus schmerzhaften Kundenengagements. Wir haben Cloud Foundry Plattformen ausgerollt, die technisch brillant waren und niemanden interessiert haben. Und irgendwann war dir die Diagnose klar. Eine Plattform, die niemand bewusst gewählt hat, ist keine Plattform. Sie ist teuer gemietete Infrastruktur. Das führt mich zu der Frage, die mir CDOs am häufigsten stellen, wenn die Diagnose sitzt, okay, wer macht das dann konkret? Ich gebe gerne eine präzise Antwort, weil vage Antworten hier niemandem helfen. Die wichtigste Einzelperson in diesem Modell ist jemand, den fast kein Datenplattformteam besetzt hat, der Platform Product Manager. Der Fehler ist nicht eine Plattform zu bauen. Der Fehler ist zu glauben, dass eine fertige Plattform ein funktionierendes Produkt ist. Nicht ein unbenannter Systemadministrator, nicht ein Projektmanager, eine Person, deren Erfolgsmetrik Adoption ist. Nicht Abtime, nicht geschlossene Tickets. Bei Pivotal hatten wir früh gelernt, dass interne Plattformteams ohne Produktdisziplin zwangsläufig die Empathie mit ihren Nutzern verlieren. Warum? Kommen wir jetzt zum Kern. Und hier wird es etwas konzeptioneller. Aber ich verspreche, es bleibt konkret. Die Platform Engineering Literatur und sie ist wirklich gut. Boccia, Skeleton, Pace, Camille Fournier hat eine fast religiöse Grundregel. Adoption muss freiwillig sein. weil die Nutzer nirgendwo anders hingehen können. Die captive audience macht das Team nachlässig. Der Platform PM ist der Mechanismus, der diesen Marktdruck künstlich wieder herstellt. Durch User Research, durch Adoption Metriken, durch Backlog Priorisierung auf Basis von Evidence, nicht von internen Annahmen. Wenn Teams die Plattform nutzen müssen, versiegt die Feedback Loop. Das Plattformteam hört auf, gut sein zu müssen. Es müssen noch Compliance sein. Diese Regel ist richtig für Anwendungsplattformen. Datenplattformen funktionieren anders. Und das ist das Ding, das der Canon nie explizit gemacht hat, weil der Canon nie für regulierte Datenumgebung geschrieben wurde. Die zweite Rolle, die CDOs meistens überrascht, ist der Governance Steward. Das ist nicht das Compliance Team. Das Compliance Team setzt Anforderungen. Der Governance Steward operationalisiert sie auf der Plattform. Unity Catalog Permissions, Lineage Regeln, Datenklassifizierung, Audit Postures. Unity Catalog, Zugriffskontrollen sind nicht optional. DSGVO Anforderungen sind nicht optional. Datenklassifizierungsrichtlinien sind nicht optional. Diese Schicht existiert, weil Regulatoren und Rechtsabteilungen sie verlangen, nicht weil interne Entwickler sie gewählt haben. Eine Datenplattform hat deshalb zwei grundverschiedene Schichten. Das ist eine eigenständige Funktion ohne natürliche Heimat, bis das Plattform als Product Modell sie explizit benennt. Die erste ist der Governance Core, Unity Catalog, Zugriffsrichtlinien, DSGVO Compliance, Datenklassifizierung. Diese Schicht ist zwingend. Man verkauft sie nicht in Kern. Man veröffentlicht sie als Vertrauensvertrag. Das garantieren wir für jedes zertifizierte Datenobjekt in unserem Katalog. Das ist die Schicht, die man durchsetzt, nicht die man vermarktet. In einem deutschen Enterprise Kontext ist dieser Rolle-Slot nicht verhandelbar. Die Frage, wer ist verantwortlich für die DSGVO Compliance dieses Datensatzes, kommt bei Orders. Und wenn man sie nicht beantworten kann, kommt das nicht gut an. Diese Rolle war in Tanzu-Kontext nicht so prominent, weil Anwendungsplattformen diese regulatorische Tiefe in dieser Form nicht haben. In der Datenwelt ist der Governance Steward unverzichtbar. Ein vollständiges Mindesteam sieht also für ein Platform-Product so aus. Platform Product Manager, Governance Steward, Engineering Lead, zwei Platform Engineers. Die zweite ist die Developer Experience Surface, die Lakeflow Vorlagen, Genie, AIBI, die Notebook-Standards, der Golden Pass. Diese Schicht muss freiwillig bleiben. Sie muss so gut sein, dass Teams sie wählen, weil sie besser ist als die Alternative. Das selbe Muster entfaltet sich in zwei Richtungen. Entweder wird alles verpflichtend gemacht, 4 bis 5 Personen, nicht 15. Das ist der Startpunkt, nicht das Ziel. Und dann braucht dieses Team eine Schutzfunktion von oben, den Plattform Champion. Das ist die Führungskraft in den meisten Gesprächen der CDO selbst, die das Plattformteam durch die erste Phase schützt, bevor Adoptionmetriken stark genug sind, ⁓ sich selbst zu verteidigen. Dann entsteht Governance-Theater auf der einen Seite und Widerstand auf der anderen. Oder alles bleibt optional. Dann entsteht eine Compliance-Lücke in der Governance-Schicht und eine Adoption-Lücke in der Experience-Schicht. Bei Tanzu war dieser Split einfacher. Eine Anwendungsplattform trägt diese regulatorische Last nicht in der gleichen Form. Bei Datenplattformen muss man das Modell erweitern. Ohne diese Rolle habe ich gesehen, wie gute Plattformteams im zweiten Budget-Quartal aufgelöst wurden. Nicht weil sie schlecht waren, sondern weil niemand ihre Arbeit in der Sprache erklärt hatte, die CFOs verstehen. Das ist kein Softskill-Problem, das ist ein Strukturproblem. Und es hat eine Lösung. Sie heißt Plattform-Champion. Und sie muss benannt sein, bevor das erste Quartal beginnt. Und die meisten Organisationen tun es nicht. Ich will noch über Messung sprechen, weil das der Punkt ist, an dem sich die meisten Gespräche entscheiden. Ich habe gesehen, wie Plattformteams gefeiert wurden für 99,99 Prozent Verfügbarkeit, während intern niemand die Plattform benutzte. Das ist das Zeichen des falschen Maßstabs. Es gibt zwei Tiers und sie sind nicht gleichwertig. Tier 1 ist der Hygienetier. Plattformverfügbarkeit über 99,5 Prozent als Basis. Compliance Pass Rate bei 100 % auf den verpflichtenden Kontrollen. Excess Provisioning SLAs unter 24 Stunden. Diese Metriken sind in den Zahlen Beispiele, aber vom Inhalt her nicht verhandelbar. Aber das Erfüllen dieser Metriken ist kein Erfolg. Es ist die Voraussetzung überhaupt mitspielen zu dürfen. Darum kommen wir zu Tier 2. die eigentlichen Erfolgsmetriken, Adoption Rate, der Anteil potenzieller Plattformnutzer, die die Plattform diesen Monat aktiv gewählt haben, Time to First Value, wie viele Tage zum Workspace Zugang, vom Workways Zugang bis zur ersten Pipeline in Production. Use case, productionization, die Anzahl der Geschäftsuse cases, die dieses Quartal über die Plattform in Produktion gegangen sind. Self-Service rate, welcher Anteil der Standardanfragen ohne manuelle Beteiligung des Plattformteams erledigt wird. Das ist die Unterscheidung. die ich im Nachhinein bei Pivotal und bei Tanzu als den fundamentalsten Unterschied zwischen gut geführten und weniger gut geführten Plattformen verstehe. Die einen messen den Boden und nennen ihn die Decke. Die anderen messen den Boden, stellen fest, dass sie ihn erfüllen und messen dann, was eigentlich zählt. Konkrete Zahlen dazu. 40,9 Prozent der Plattformteams können nach ihrem ersten Jahr keinen messbaren Wert demonstrieren. Nicht, weil die Plattform technisch hinter ihren Möglichkeiten geblieben ist, sondern weil sie Tier-1-Metriken gemessen und das als Erfolg kommuniziert haben. Der CFO-taugliche Satz lautet, Abteilen ist Pflicht. Use-Case-Velocity ist die Kür. Und hier denke ich an einen anderen Kunden. Wieder ein Corp Hosset, kein echter Name. Das Plattformteam hatte das perfekte Tier-1-Metrik und präsentierte das stolz im Quarterly Business Review. Availability, Tickets Closed, Mean Time to Resolution, alles grün. Und gleichzeitig, wenn man in die Usage Logs angeschaut hat, was niemand tat, stagnierte die tatsächliche Adoption bei unter 20 Prozent der potenziellen Nutzer. zwei Quartale in Folge. Das Team hat sich auf den Boden konzentriert und war gar nicht auf die Idee gekommen, die Decke zu messen. Nicht aus Unwillen, sondern weil niemand je gesagt hat, dass die Decke das eigentliche Ziel ist. Das veränderte sich, oder das verändert sich, wenn man den Plattform-PM einsetzt und die Erfolgsmetriken umschreibt. Die erste Adoption-Messung ist fast immer eine unangenehme Überraschung. Aber eine unangenehme Überraschung, die man kennt, ist handhabbar. Eine, die man nicht misst, bleibt ein stiller Risikofaktor im nächsten Budget-Zyklus. Ich komme zum Ende und ich will es nicht verkomplizieren. Eine Datenplattform ist kein Werkzeug, das man kauft und vergisst. Sie ist ein Produkt mit Kunden, mit einem Backlog, mit einer Verantwortlichen, mit Metriken, die messen, ob dieses Produkt tatsächlich genutzt wird und ob es dem Unternehmen nützt. Was mich Am meisten überrascht, wenn ich dieses Gespräch mit CDOS führe, ist wie oft der Moment des Erkenntens eintritt, bevor ich fertig bin. Die meisten wissen es eigentlich schon. Sie haben eine diffuse Diagnose, die Plattform wird nicht genutzt wie erwartet. Aber sie haben nicht die Sprache dafür gehabt. Mandatory Core versus Voluntary Surface. Plattform PM versus Plattform Admin. Adoption als Metrik versus Abtime als Metrik. Das ist das, was ich aus Jahren bei Pivotal und Tanzu mitgenommen habe und was mich heute in Gesprächen mit Datenteams begleitet. Die technische Frage ist fast nie das Problem. Die Organisationsfrage ist fast immer das Problem. Und die Organisationsfrage hat eine Antwort. Sie ist nicht einfach, aber sie ist konkret. Eine Datenplattform ist kein IT-Projekt. Sie ist ein Produkt. Und ein Produkt ohne Verantwortliche ist nur teure Infrastruktur, die darauf wartet, zur Fußnote zu werden. Liebe Hörer, damit sind wir schon auch diesmal am Ende dieser Folge vom Databricks Deutschland Postcard angekommen. Vielen Dank fürs Einschalten. Vielen Dank fürs bis zum Ende hören. Wenn ihr Fragen habt oder mit eurem eigenen Team über diese Operating Model sprechen wollt, findet mich auf LinkedIn. Ich freue mich drauf. Wir hören uns beim nächsten Mal. Und immer daran denken, gute Daten, gute Entscheidungen.