Die 4 Prinzipien für Data Ownership

Data Ownership ist wahrscheinlich das größte ungelöste Problem im Datenmanagement. Lösen wir es.

Nur Daten, für die sich jemand verantwortlich fühlt, sind Daten, auf denen wir unsere Geschäftsprozesse und Entscheidungen aufbauen können. Dieser Jemand räumt Inkonsistenzen auf und sorgt dafür, dass die Daten vollständig sind. Dieser Jemand stellt sicher, dass alle Pipelines grün sind. Dieser Jemand kümmert sich um gute Dokumentation. Dieser Jemand ist jemand, den du ansprechen kannst, wenn du Fragen hast. Und dieser Jemand bekommt die Anerkennung für den Wert, den andere mit seinen Daten schaffen.

Bist du dieser Jemand?

Glückwunsch. Du machst einen großartigen Job. Aber seien wir ehrlich: Es gibt so viel mehr Daten in deiner Organisation, bei denen dieser Jemand fehlt oder du nicht weißt, ob es ihn überhaupt gibt.

Natürlich dreht sich alles um Ownership. Ownership für Daten ist herausfordernd. Aber zum Glück gibt es heute Methoden und Tools, die dabei helfen.

Die 4 Prinzipien für Data Ownership

Ein paar Prinzipien haben sich in Diskussionen über Data Ownership als hilfreich erwiesen:

OK, schauen wir uns an, was wir damit meinen:

You Build It, You Own It

Wenn Daten in deine Domäne gelangen, wirst du zum Owner. Du definierst die Eingabefelder der Formulare, du baust die APIs, du kontrollierst die eingehende Pipeline. Du weißt, was ein Status-Enum bedeutet. Du kennst die Bedeutung der sechs verschiedenen Timestamp-Spalten. Du weißt, was in Fehler- und Randfällen passiert. Du baust das System, also sind es deine Daten. Es ist dein Job, das zu wissen. Du bist der Data Owner. Keine Ausreden.

Wir empfehlen in der Regel Team-Ownership statt einzelner Personen. Das vermeidet Ärger, wenn jemand im Urlaub ist oder sich die Teambesetzung ändert. In manchen Organisationen gibt es eine Aufteilung in IT-Teams und Business-Teams. Hier empfehlen wir, dass das Team, das am meisten mit den Daten arbeitet, die primäre Ownership-Rolle übernimmt: Bei source-aligned Datenprodukten ist das oft das IT-Team, bei consumer-aligned Datenprodukten oft das Business-Team oder ein Proxy-Team.

Datenprodukte veröffentlichen

Wir haben alle schon in die Enterprise-Datenkataloge geschaut (Collibra, Informatica, DataHub, you name it), und nach dem Blick auf die Zahl automatisch indexierter Data Assets (etwa 2.321.021 Tabellen und Dateien) und die sehr technischen Details (Serialisierung, Dateiformate und Encodings) wird sehr schnell klar: Diese automatisch gecrawlten Assets helfen nicht dabei, Ownership zu übernehmen. Zu technisch und zu viele.

Führen wir also Datenprodukte ein. Es ist schwierig, eine generische Definition für ein Datenprodukt zu finden (ist es eine Tabelle, ein Schema, ein semantisches Modell in Power BI, ein Kafka-Topic, eine API, ein dbt-Projekt, ...). Konzentrieren wir uns deshalb auf den Wert: Daten, die jemand nutzen möchte. Dieser Jemand kann du oder dein Team sein. Es kann eine andere Business-Unit sein. Und es kann ein KI-Agent sein.

Das Wichtigste an Datenprodukten ist: Daten werden nur dann zum Datenprodukt, wenn jemand die Ownership-Rolle für diese Daten übernimmt. Es gibt kein Datenprodukt ohne Owner. Punkt.

Das bedeutet auch: In Unternehmen gibt es keine Millionen von Datenprodukten. Typischerweise gibt es nur ein paar hundert Datenprodukte. Weniger ist besser: Wir bekommen eine überschaubare Zahl von Objekten, die Owner pflegen und kuratieren können.

Damit Datenprodukte für andere auffindbar sind, veröffentlicht der Owner sie aktiv in einem kuratierten Datenmarktplatz, nicht in einem technischen Data-Asset-Katalog.

Data Contracts durchsetzen

Sprechen wir nun über Data Contracts. Data Contracts spezifizieren, was ein Data Consumer (wieder: eine Person oder ein Agent) vom Konsum der Daten erwarten kann. Sie sind die APIs des Datenprodukts.

Dazu gehören:

• Nutzungsbedingungen
• Schema
• Semantik
• Datenqualität
• SLAs
• Endpunkte

Die Nutzungsbedingungen umfassen die fachliche Beschreibung, den Zweck der Daten, die zulässige Nutzung und die Einschränkungen aus technischer, Compliance- und Data-Governance-Sicht. Bei agentischen Use-Cases ist das extrem hilfreich, um KI-Agenten mitzuteilen, welche Datenprodukte sie für bestimmte Aufgaben nutzen können und in welchen Kontexten diese Daten relevant sind.

Das Schema umfasst die Struktur der Tabellen und Spalten sowie logische und Governance-Details wie Datenklassifizierungen, PII-Markierungen, semantische Beschreibungen, Beispieldaten und Data Lineage.

Tabellen und Spalten lassen sich außerdem mit einem konzeptionellen Business-Datenmodell oder mit Industriestandards verknüpfen. So entstehen zusätzliche semantische Informationen bis hin zu einem vollständigen Knowledge Graph, über den sich verwandte Daten finden lassen (wieder super hilfreich für agentische Use-Cases).

Datenqualitätsregeln und SLAs definieren Datengarantien und fachliche Erwartungen, etwa Non-Null-Anforderungen, Regeln auf Zeilenebene, gültige Wertebereiche, Freshness etc. Quality Engines können diese Regeln lesen, sich mit den Datenbank-Endpunkten verbinden und die Daten validieren. Eine Open-Source-Engine für Datenqualität ist die Data Contract CLI.

Es gibt einen Industriestandard: den Open Data Contract Standard (ODCS), verwaltet von Bitol, einem Linux Foundation AI & Data Projekt. ODCS definiert ein YAML-Format für Data Contracts. Hier ein kompaktes Beispiel:

apiVersion: v3.1.0
kind: DataContract
id: orders
name: Orders
version: 1.0.0
status: active
description:
  purpose: Order data for analytics, reporting, and AI use cases.
  usage: Analyze order volumes and revenue, build dashboards, train forecasting models.
  limitations: Not suitable for real-time use cases. Contains PII, do not use for marketing without consent.
schema:
  - name: orders
    physicalType: TABLE
    description: One row per order. Includes successful and cancelled orders.
    properties:
      - name: order_id
        logicalType: string
        description: Internal order ID. Do not show this to a customer.
        primaryKey: true
        required: true
        unique: true
        examples:
          - 99e8bb10-3785-4634-9664-8dc79eb69d43
      - name: order_timestamp
        logicalType: timestamp
        description: The time when the order payment was successfully confirmed.
        required: true
      - name: order_total
        logicalType: integer
        description: The order total amount in cents, including tax, after discounts.
        required: true
        quality:
          - type: library
            metric: nullValues
            mustBe: 0
    quality:
      - type: library
        metric: rowCount
        mustBeGreaterThan: 100000
        description: If there are less than 100k rows, something is wrong.
slaProperties:
  - property: freshness
    value: "24"
    unit: hours
    description: New orders are available within 24 hours.
team:
  name: sales
  description: This data product is owned by the "Sales" team
servers:
  - server: production
    type: snowflake
    account: my-account
    database: sales
    schema: dp_orders_v1

Ein Data Contract kann für einen bestehenden Datensatz definiert werden. Oder er wird contract-first geschrieben, um die Anforderungen an ein neues Datenprodukt zu definieren, bevor es überhaupt Daten gibt. Sehr mächtig. Aber beide Wege sind in Ordnung.

Wer ist nun für den Data Contract verantwortlich? Typischerweise besitzt der Data Product Owner den Data Contract für sein Datenprodukt. Die Spezifikation kann aber eine gemeinsame Aufgabe sein: Mach einen Workshop mit deinen Data Consumern und diskutiert ihre Erwartungen an die Daten, Feld für Feld. Und schreibt auf, was die Fachexperten diskutieren: Das ist die Semantik, die du festhalten willst.

Sei dein erster Kunde

OK, jetzt wissen wir, wie wir Datenprodukte mit Data Contracts spezifizieren. Aber die Kernfrage ist noch offen: Warum sollte überhaupt jemand die Ownership-Rolle für ein Datenprodukt übernehmen?

Nun, eine Antwort ist: Weil dein Chef es sagt. Und das ist fair. Management-Unterstützung und -Aufmerksamkeit sind ein wichtiger Teil des Adoptionsprozesses.

Aber sprechen wir auch über intrinsische Motivation: Purpose. Welchen Zweck könnte dein Datenprodukt für dich stiften? Ja. Bauen wir das erste Datenprodukt für dein eigenes Team, mit deinen eigenen Domänendaten und einem schönen Dashboard. Damit du bessere Entscheidungen treffen und großartige KI-Features in deiner Domäne bauen kannst. Verbinde Claude mit deinem Datenprodukt, um mit deinen Daten zu chatten. Baue einen agentischen Loop mit deinen Daten, um eine Slack-Nachricht zu bekommen, wenn in deiner App etwas Bedeutsames passiert.

Du verstehst die Idee. Baue ein Datenprodukt für dich selbst, das Wert schafft. Das ist ein großartiger Purpose! Iteriere, bis du zufrieden bist. Wenn du stolz darauf bist, veröffentliche es im Datenmarktplatz für andere. Ernte Ruhm und soziale Anerkennung. Dein Datenprodukt schafft Wert für dein Business. Anderen zu helfen ist auch ein großartiger Purpose.

Tools, die helfen

Es gibt ein paar Tools, die dir helfen, Ownership zu übernehmen.

Zum Spezifizieren des Datenprodukts sind zunächst zwei Tools interessant:

ODCS Excel Template. Ja, nutze Excel, um einen Data Contract zu entwerfen. Es ist wahrscheinlich das Tool mit der besten User Experience für Business-User. Schicke es per E-Mail an andere und iteriere. Wenn du zufrieden bist, konvertiere es mit dem Konverter der Data Contract CLI von und nach YAML.

Data Contract Editor. Wenn du einen Web-Editor bevorzugst, nutze den Open-Source Data Contract Editor, der auch einen visuellen Editor für Entity-Relationship-Diagramme, formularbasierte Felder für alle ODCS-Properties und Linting mitbringt. Vollständig anpassbar für eigene Properties und Abschnitte.

Data Product Builder. Zum Implementieren des Datenprodukts nutze Coding Agents wie Claude Code und OpenAI Codex. Der Data Contract sagt ihnen, was sie bauen sollen. Skills beschreiben das Wie, passend zum Tech-Stack und zu den Data-Governance-Richtlinien deiner Organisation. Ein Datenmarktplatz sagt ihnen, welche Upstream-Datenprodukte sie nutzen sollen. Sobald der Data Contract steht, dauert die Implementierung eines konformen Datenprodukts nur wenige Minuten.

Data Contract CLI. Um zu testen, ob das implementierte Datenprodukt der Spezifikation und den Zusagen des Data Contracts entspricht, nutze das Open-Source-Tool Data Contract CLI. Integriere es in Airflow, GitHub Actions, Databricks Jobs etc., um sicherzustellen, dass dein Datenprodukt immer die zugesagte Datenqualität liefert.

Entropy Data. Unser kommerzielles Tool, das all diese Tools zusammenbringt, um Data Product Owner dabei zu unterstützen, ihre Ownership-Rolle ernst zu nehmen. Entropy Data bietet außerdem einen herstellerneutralen Datenmarktplatz in einer einfach zu bedienenden Webanwendung.

Starte kostenlos oder erkunde die interaktive Demo.