Interne Datenprodukte: ein Praxisleitfaden zu den Teams und Unternehmen, die sich lohnen

Die meisten Texte über interne Datenprodukte bleiben abstrakt: Behandle Daten wie ein Produkt, weise Ownership zu, miss die Nutzung. Was ausgelassen wird: wer es tatsächlich gut gemacht hat, wie das in der Praxis aussah und was der Rest von uns aus dem Scherbenhaufen oder dem Erfolg lernen kann. Diese Shortlist folgt einem einzigen Kriterium: nachweisbarer Einfluss darauf, wie Praktiker in anderen Unternehmen anschließend ihre eigenen internen Datenplattformen gebaut haben. Umsatz und Unternehmensgröße sind nicht der Filter. Dokumentierte Wirkung auf das Feld ist es.

Die Shortlist

Airbnb und das Dataportal

Airbnbs internes Tool zur Data Discovery, zwischen etwa 2017 und 2020 vom Data-Infrastructure-Team gebaut und öffentlich beschrieben, wurde zu einem der am häufigsten zitierten Beispiele für internes Data Cataloging im großen MaMaUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Vollständige Definition ansehen →ßstab. Das Team veröffentlichte detaillierte Engineering-Blogposts, die andere Datenteams direkt als Blaupause nutzten. Die eine Lektion: Ein Data Portal funktioniert nur, wenn Suche und Metadatenqualität gut genug sind, dass Engineers es Slack tatsächlich vorziehen. Airbnb hat gezeigt, dass die Adoption interner Tools ein Produktproblem ist, kein Kulturproblem.

Spotify und der „golden path“

Spotifys Arbeit an einer internen Developer-Plattform hat vielen Datenpraktikern das Konzept des „golden path“ nahegebracht: eine Reihe empfohlener, gut gepflegter Tools und Pipelines, auf die Teams standardmäßig zurückgreifen, statt dazu gezwungen zu werden. Spotifys Backstage, das 2020 öffentlich veröffentlichte Open-Source-Developer-Portal, hat diese Idee operationalisiert. Für Datenplattform-Teams lautet die Lektion: Optionen an den richtigen Stellen zu reduzieren, steigert die Adoption. Backstage hat inzwischen tausende externe Contributors, was den ursprünglichen Designentscheidungen von Spotify eine ungewöhnliche Haltbarkeit gibt.

LinkedIn und die Wurzeln des Data-Mesh-Denkens

Bevor „Data MeshData MeshData Mesh is a decentralized approach to data architecture and organization where domain teams own and serve their data as products, governed by shared standards.Vollständige Definition ansehen →“ zu einer Beratungskategorie wurde, veröffentlichte LinkedIns Engineering-Team ausführliche Beschreibungen, wie es Dateninfrastruktur über halb-autonome Teams hinweg skalierte, mit dem, was es „self-serve“ Data Pipelines nannte. Diese Posts, einige aus 2013 und 2014, beeinflussten direkt Zhamak Dehghanis spätere Formulierung der Data-Mesh-Prinzipien. LinkedIn ist hier nicht als aktuelles Vorbild relevant, sondern als Ursprungspunkt. Das Konzept dezentraler Daten-Ownership mit zentralen Standards kam nicht fertig aus einer Beratung.

Netflix und der Vorrang von Data Contracts

Die Engineering-Blogposts von Netflix haben durchgängig geprägt, wie die Branche über Datenzuverlässigkeit denkt. Der Ansatz zu SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Vollständige Definition ansehen → Registries, Data-Quality-SLAs zwischen produzierenden und konsumierenden Teams und die Idee, Data Pipelines als Konstrukt mit expliziten Producern und Consumern mit vertraglichen Pflichten zu behandeln, wurden zum Standardvokabular der Datenprodukt-Diskussion. Die konkrete Erkenntnis: Netflix hat interne Datenzuverlässigkeit als Engineering-Vertrag zwischen Teams gefasst, nicht als Governance-Richtlinie, die von einer zentralen Funktion herabgegeben wird. Diese Rahmung hat verändert, wie viele Gespräche auf CDO-Ebene aufgebaut sind.

Zhamak Dehghani und das Data-Mesh-Framework

Dehghani, früher bei ThoughtWorks, veröffentlichte das ursprüngliche Data-Mesh-Konzept 2019 und baute es zu einem Buch aus („Data Mesh“, O'Reilly, 2022). Was man auch von Data Mesh als Vorschrift halten mag, sein Einfluss darauf, wie CDOs Platform Thinking rahmen, ist unbestreitbar. Das Domain-Ownership-Modell, das Prinzip Data as a Product und die Idee föderierter Governance sind heute Grundvokabular in CDO-Stellenbeschreibungen und in Datenstrategie-Gesprächen auf Vorstandsebene. Dehghani ist relevant, weil sie Praktikern eine gemeinsame Sprache gegeben hat, und eine gemeinsame Sprache verändert, was in Budgetzyklen genehmigt wird.

Uber und der Databook-Katalog

Uber hat Databook gebaut und dokumentiert, eine interne Metadaten-Plattform, die Dataset-Ownership, Qualitätsmetriken und Lineage im großen Maßstab sichtbar machte. Die um 2019 bis 2020 veröffentlichten Engineering-Posts waren aus einem bestimmten Grund bemerkenswert: Uber zeigte, wie man institutionelle Verantwortlichkeit an Datensätze knüpft, indem Ownership-Informationen direkt neben den Daten selbst angezeigt werden. Wenn ein Dataset einen namentlich genannten Owner hat, der für jeden Consumer sichtbar ist, verändert sich das Gespräch über Qualität. Dieser Accountability-Mechanismus gilt heute als Basisfunktion ausgereifter interner Datenplattformen.

JP Morgan Chase und der stille Enterprise-Fall

Anders als die Tech-Unternehmen oben steht JP Morgan Chase für den Beweis im Großkonzern. Das Haus hat öffentlich über seine internen Data-Marketplace-Initiativen und seine Investitionen in Data-Engineering-Talent in einem Umfang gesprochen, den wenige Organisationen erreichen (das Haus hat offengelegt, jährlich Milliarden für Technologie auszugeben, konkrete Budgetaufschlüsselungen für Datenplattformen sind allerdings nicht unabhängig verifiziert). Die Lektion von JP Morgan Chase ist organisatorisch, nicht technisch: Sie zeigt, dass Platform Thinking für interne Daten dediziertes Product-Management-Headcount braucht, nicht nur Engineering-Talent. Mehrere ihrer Datenplattform-Verantwortlichen sind in CDO-Rollen bei anderen Instituten gewechselt, was ein vernünftiger Näherungswert für Einfluss ist.

Das Muster: was diese Vorreiter teilen

Betrachtet man diese sieben Einträge, ist eines durchgängig. Keiner von ihnen hat die Adoption der internen Datenplattform als Kommunikations- oder Change-Management-Problem behandelt. Sie haben es als Produktdesign-Problem behandelt. Airbnb hat die Suchqualität optimiert. Spotify hat Entscheidungsmüdigkeit reduziert, indem es einen Standardpfad kuratiert hat. Netflix hat Verträge zwischen Teams geschrieben. Uber hat Ownership-Informationen dort platziert, wo Consumer sie sehen kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen. Die Unternehmen, die sich schwertaten (und es gibt viele, die aber weniger veröffentlichen), haben typischerweise Plattformen gebaut, die technisch vollständig waren, aber den Leuten, die sie nutzen sollten, zu viel Aufwand abverlangten.

Das zweite Muster: Jeder Eintrag hier hat veröffentlicht. Engineering-Blogposts, Open-Source-Releases, Konferenzvorträge. Diese Transparenz ist zum Teil der Weg, auf dem sie Einfluss aufgebaut haben, sie sagt aber auch etwas über die Unternehmenskultur aus, die diese Plattformen überhaupt möglich gemacht hat. Teams, die gut bauen, sind meist Teams, die klar genug denken, um es aufzuschreiben.

Die Lektion für CDOs ist nicht, dass Sie Ihre Architekturentscheidungen veröffentlichen müssen. Sie ist, dass die Disziplin, sie klar genug aufzuschreiben, um sie veröffentlichen zu können, dieselbe Disziplin ist, die tendenziell Plattformen hervorbringt, die Menschen tatsächlich nutzen.

Wen man beobachten sollte: die Teams, die Tooling für Data Contracts bauen, insbesondere jene, die an offenen Standards statt an proprietären Implementierungen arbeiten, werden die nächste Runde dieser Diskussion bestimmen.

Die Unternehmen, die dauerhafte interne Datenplattformen gebaut haben, haben das nicht getan, indem sie zuerst in Governance-Frameworks investierten. Sie haben investiert, um die Erfahrung des Findens und Vertrauens von Daten gut genug zu machen, dass Engineers die Plattform wählten, ohne dazu aufgefordert zu werden. Das ist die Designaufgabe, die ein Data-Catalog-Projekt von einem Datenprodukt unterscheidet.