Was ist der Lebenszyklus eines Data Product?

Der Lebenszyklus eines Data Product ist die geordnete Folge von Stufen, die ein Data Product von der ersten Entdeckung eines fachlichen Bedarfs bis zur späteren Ablösung durchläuft. Er ist das Betriebsmodell, das aus „wir haben Datenbestände“ ein „wir haben gesteuerte Produkte, auf die sich das Geschäft stützt“ macht, und er ist die Disziplin, die Organisationen, die Data Products als einmalige Projekte veröffentlichen, von Organisationen trennt, die Daten als verwaltetes Portfolio behandeln.

Ein Lebenszyklus existiert, ob er dokumentiert ist oder nicht. Die Frage ist nur, ob die Stufen ausdrücklich und gesteuert sind oder stillschweigend und aus dem Stegreif. Stillschweigende Lebenszyklen sehen meist so aus: Jemand baut einen Datenbestand, jemand anderes entdeckt ihn und beginnt ihn zu nutzen, die Erwartungen laufen auseinander, die ursprünglich bauende Person geht, der Bestand sammelt nachgelagerte Verbraucher an, die niemand nachhält, und drei Jahre später lässt er sich nicht mehr ändern, weil zu viele Systeme von ihm abhängen und niemand weiß, welche. Ausdrückliche Lebenszyklen sind die Alternative: derselbe Bestand, aber seine Entdeckung, sein Entwurf, sein Bau, sein Betrieb und seine spätere Ablösung sind gewollt und mit Messpunkten versehen.

Der Lebenszyklus im Überblick

Der Lebenszyklus eines Data Product ist ein Prozessmodell und kein Werkzeug. Er legt die Abfolge der Entscheidungen fest, die Artefakte, die bei jedem Schritt entstehen, und die Rollen, die für jede Entscheidung einstehen. Dass es um Daten geht, macht das nicht grundlegend anders als Produktlebenszyklen in anderen Feldern: Er erbt die vertrauten Begriffe (Anforderungen, Entwurf, Bau, Betrieb, Ablösung) und ergänzt Besonderheiten, die für Daten sinnvoll sind:

• Data Products werden lange genutzt, nachdem die ursprünglich fördernde Person weitergezogen ist, deshalb muss der Entwurf genug Metadaten enthalten, damit künftige Verbraucher sie verstehen.
• Data Products sind zusammengesetzt: Ein Produkt verbraucht andere, deshalb pflanzen sich Änderungen durch den Abhängigkeitsgraphen fort, und die Lineage gehört zur Entwurfsfläche.
• Data Products haben SLAs: Aktualität, Qualität, Stabilität des Schemas. Im Lebenszyklus werden SLAs mit den Verbrauchern verhandelt, im Betrieb überwacht und angepasst, während das Produkt reift.
• Data Products sind gesteuerte Bestände: Klassifizierung, Zugriffsregeln und Verantwortung müssen zum Zeitpunkt des Entwurfs bewusst gesetzt und nicht unter regulatorischem Druck nachgerüstet werden.

Die fünf Stufen

Das Modell unten verwendet fünf Stufen. Manche Organisationen unterteilen weiter (der Entwurf zerfällt etwa in Spezifizieren und Vertrag schließen), das Modell mit fünf Stufen trifft aber die Struktur, die die meisten Teams in der Praxis nützlich finden.

1. Entdecken

Der Lebenszyklus beginnt mit einem fachlichen Bedarf, dem Daten dienen sollen, und nicht mit einem Datenbestand, der einen Zweck sucht. Tätigkeiten beim Entdecken: die Verbraucher bestimmen und die Entscheidung oder Fähigkeit, die sie ermöglichen wollen; vorhandene Data Products finden, die den Bedarf bereits decken (Doppelung vermeiden); klären, ob das vorgeschlagene Produkt in die Data-Product-Strategie der Organisation gehört oder ob eine einmalige Abfrage genügt; erste Anforderungen an Aktualität, Feinheit, Qualität und Zugriff aufnehmen.

Die Stufe endet mit einem belegten Bedarf, benannten Verbrauchern, einem vorläufigen Umfang und der Entscheidung, weiterzugehen oder nicht. Auf dieser Stufe werden die meisten Krankheiten des Lebenszyklus gesät: Organisationen, die das Entdecken überspringen, bauen Produkte ohne Verbraucher und erben Verbraucher ohne Verträge.

2. Entwerfen

Der Entwurf macht aus dem Bedarf eine Spezifikation, die eine bauende Person umsetzen und eine verbrauchende sich darauf stützen kann. Artefakte des Entwurfs: das Datenmodell und das Schema (Tabellen, Spalten, Typen, Primärschlüssel, Beziehungen); semantische Definitionen für jedes bedeutungstragende Feld, verankert im Business Glossary; SLAs (Aktualität, Vollständigkeit, Genauigkeit, Stabilität des Schemas); Zugriffsregeln (wer, in welcher Rolle, zu welchem Zweck, mit welcher Maskierung); Tags der Klassifizierung (PII, finanziell, vertraulich, öffentlich); die Zuordnung von Verantwortung und Stewardship; und ein Data Contract, der die Pflichten von Erzeuger und Verbraucher festhält.

Die Stufe endet mit einem abgezeichneten Vertrag, den bauende Personen umsetzen und verbrauchende annehmen können. Gut gemacht, beseitigt der Entwurf das teuerste Versagen des Lebenszyklus: im Betrieb festzustellen, dass Erzeuger und Verbraucher sich über die Bedeutung der Daten uneins waren.

3. Bauen

Bauen ist die Ingenieursarbeit, das entworfene Produkt zu liefern: die Pipeline umsetzen, die die Daten erzeugt, Katalog und Glossar füllen, die Wächter für Qualität und Aktualität einrichten, Zugriffsregeln und Audit-Protokollierung konfigurieren und das Produkt über die Verbrauchsschnittstelle veröffentlichen (SQL-Endpunkt, API, MCP-Server). Beim Bauen wird auch die Lineage festgehalten, auf Systemebene und im besten Fall auf Spaltenebene, damit spätere Entscheidungen im Betrieb eine Beweisspur haben.

Die Stufe endet mit einem Produkt, das den Vertrag erfüllt und für die Aufnahme von Verbrauchern bereit ist. Wer beim Bauen Lineage, Klassifizierung oder Qualitätsüberwachung überspringt, ist schneller fertig und tritt mit technischen Schulden in den Betrieb, die sich über das restliche Leben des Produkts aufsummieren.

4. Betreiben

Der Betrieb ist die längste Stufe des Lebenszyklus, meist über Jahre. Tätigkeiten: die Pipeline verlässlich laufen lassen; Qualität, Aktualität und Nutzung überwachen; Zugriffsanfragen bearbeiten; auf Störungen und Beschwerden der Verbraucher reagieren; das Produkt über versionierte Vertragsänderungen weiterentwickeln; die Nutzung auswerten; in Abständen prüfen, ob es noch einschlägig und wertvoll ist.

Im Betrieb werden Data Products entweder zu verlässlichen langfristigen Beständen oder sie verfallen still. Der Unterschied liegt darin, ob der Betrieb eine verantwortliche Person und Stewards mit Zeit und Befugnis zur Pflege hat oder ob die Pflege beim Entwicklungsteam hängen bleibt, das es gebaut hat und inzwischen das Nächste baut.

5. Ablösen

Irgendwann überleben Produkte ihren Nutzen oder werden abgelöst. Die Ablösung ist eine Stufe und kein Ereignis. Tätigkeiten: die Abkündigung mit Datum und Nachfolgepfad ankündigen; über die Lineage alle nachgelagerten Verbraucher bestimmen und ansprechen; Verbraucher auf den Nachfolger umziehen; den Audit-Trail abschließen; Metadaten für die regulatorische Aufbewahrung archivieren; das Produkt aus dem Katalog nehmen und Zugriffe entziehen.

Organisationen ohne Ablösungsstufe sammeln einen Friedhof halb abgekündigter Produkte an, die Verbraucher weiter nutzen, weil ihre Entfernung riskiert, etwas zu brechen. Das sind Schulden der Governance, deren Rückzahlung immer teurer wird.

Rollen über den Lebenszyklus

Fünf Rollen kehren über den Lebenszyklus wieder. Es sind nicht immer fünf verschiedene Personen; in kleineren Organisationen spielt eine Person mehrere. Die Verantwortungen sind aber verschieden.

• Verbraucher: benennt den Bedarf beim Entdecken, unterzeichnet den Vertrag beim Entwerfen, meldet Probleme im Betrieb und zieht bei der Ablösung um. Der Verbraucher ist der Grund, warum es das Produkt gibt.
• Product Owner: steht für das Produkt über den ganzen Lebenszyklus ein. Entscheidet über Prioritäten, stimmt SLAs zu, zeichnet Änderungen ab, die Verbraucher betreffen. Oft eine fachliche Rolle und keine aus dem Engineering.
• Domain Steward: Data Steward für das fachliche Gebiet, in dem das Produkt liegt. Verantwortet die Definitionen im Glossar, die Richtigkeit der Klassifizierung und die laufende Qualitätsaufsicht. Sorgt für Beständigkeit, wenn das Entwicklungsteam wechselt.
• Data Engineer: baut die Pipeline, richtet Lineage und Qualität ein, pflegt das Produkt im Betrieb. Die Arbeit im Engineering bliebe ohne ausdrückliche Verträge aus der Entwurfsstufe unsichtbar.
• Data Governance: setzt die Standards der Richtlinien (Taxonomie der Klassifizierung, Zugriffsmodelle, Vertragsvorlagen, Aufbewahrungsregeln). Prüft folgenreiche Produkte. Pflegt den Katalog als Wahrheitsquelle über alle Produkte hinweg.

Governance auf jeder Stufe

Governance ist keine eigene Stufe. Sie läuft über alle fünf und bringt auf jeder bestimmte Artefakte hervor:

• Entdecken: Prüfung auf vorhandene Produkte (Doppelung vermeiden), erste Einschätzung der Klassifizierung, Bestätigung durch die fördernde Stelle. Die Suche im Katalog und der Gang durch die Lineage sind die Werkzeuge dafür.
• Entwerfen: Glossarbegriffe an jedem Feld, Data Contract entworfen und unterzeichnet, Zugriffsregeln festgelegt, Klassifizierung abgeschlossen, SLA vereinbart. Das ist die dichteste Stufe der Governance.
• Bauen: Lineage automatisch als Teil der Pipeline erfasst, Klassifizierung durch die Umformungen weitergereicht, Vertrag an der Verbrauchsschnittstelle durchgesetzt, Audit-Protokollierung eingeschaltet.
• Betreiben: Qualität und Aktualität gegen die SLAs überwacht, Vertragsänderungen vorgeschlagen und geprüft, Übergaben der Verantwortung nachgehalten, Governance-Prüfungen in Abständen.
• Ablösen: Lineage abgefragt, um Verbraucher zu finden, Abkündigungen protokolliert, letzter Stand des Audit-Trails gesichert, archivierte Metadaten nach Richtlinie aufbewahrt.

Anti-Muster im Lebenszyklus

Vier Anti-Muster kehren in Organisationen wieder:

• Erst bauen. Jemand im Engineering baut einen Datenbestand, erklärt ihn zum „Data Product“ und überspringt Entdecken und Entwerfen vollständig. Verbraucher finden ihn von selbst, bilden sich ihre eigenen Erwartungen, und das Produkt sammelt von Tag eins technische und vertragliche Schulden an.
• Ewiger Betrieb. Produkte werden gestartet, aber nie abgelöst. Jahre vergehen; der Katalog sammelt halb funktionierende Produkte mit unklarer Verantwortung. Neue Verbraucher tun sich schwer, das richtige zu finden, weil es fünf plausible gibt.
• Governance im Nachhinein. Klassifizierung, Lineage und Verantwortung kommen dazu, wenn eine Aufsicht oder eine Prüfung sie verlangt. Die Metadaten werden nachgerüstet, oft ungenau, und die verantwortliche Person erfährt erst bei Antritt, dass ihr die Verantwortung ohne ihr Zutun zugewiesen wurde.
• Lebenszyklus als Schauspiel. Ein förmlicher Lebenszyklus wird veröffentlicht, aber es entstehen keine echten Artefakte: Entwurfsdokumente sind Folien, Betriebsprüfungen sind Kalendereinträge, zu denen niemand erscheint. Der Lebenszyklus besteht nur dem Namen nach und liefert keine wirkliche Governance.

Der Blick der Plattform

Reife Organisationen setzen den Lebenszyklus über eine Plattform für Data Products in Betrieb, also über ein einheitliches System, das jede Stufe mit dem passenden Werkzeug stützt. Entdecken über die Suche im Katalog; Entwerfen über Vertragseditoren, die aus einem gesteuerten Glossar schöpfen; Bauen über Metadaten-APIs und das Erfassen der Lineage; Betreiben über Dashboards zu Nutzung und Qualität; Ablösen über Abläufe zur Abkündigung. Die Plattform ist nicht der Lebenszyklus, aber sie ist das, was ihn über ein kleines Team disziplinierter Fachleute hinaus skalierbar macht.

Organisationen, die die Plattform an die erste Stelle setzen, sind die mit Hunderten gesteuerter Data Products im Betrieb und zweistelligen Zahlen von Teams, die sie erzeugen, bei gleichbleibender Qualität. Die handwerklich arbeitenden Organisationen kommen über einige Dutzend Produkte nicht hinaus und verlieren beim Wachsen die Beständigkeit. Der Unterschied liegt darin, ob der Lebenszyklus in gemeinsamen Werkzeugen steckt oder von jedem Team neu durchlebt wird, das ein neues Produkt anfasst.

Fazit

Der Lebenszyklus eines Data Product ist das Betriebssystem jeder Organisation, die will, dass Daten sich wie ein verwalteter Bestand verhalten und nicht wie ein Rückstau einmaliger Projekte. Den Lebenszyklus gibt es stillschweigend auch dann, wenn er nicht entworfen wurde, und die stillschweigende Fassung kostet mehr und bringt schlechtere Ergebnisse als die ausdrückliche. Das reife Muster ist, alle fünf Stufen erstrangig zu behandeln, klare Rollen zuzuweisen und das Ganze mit einer Plattform zu unterlegen, die die richtigen Artefakte der Governance von selbst festhält. Genau das macht aus „wir veröffentlichen Datenbestände“ ein „wir führen ein Portfolio von Data Products, auf das sich das Geschäft stützt“.