Ein Datenprodukt hat erkennbare Nutzer
Eine Tabelle wird nicht durch einen neuen Namen zum Produkt. Nutzer benötigen eine verständliche Bedeutung, verlässliche Aktualisierung und einen Ansprechpartner. Für ein Datenprodukt „Lieferfähigkeit“ muss beispielsweise klar sein, welche Bestände enthalten sind und wie Reservierungen behandelt werden. Qualitätsziele sollten sich am Bedarf der nutzenden Prozesse orientieren.
Verantwortung verteilen, Grundlagen gemeinsam halten
Wenn jede Domäne Zugriff, Formate und Betrieb völlig anders löst, entsteht neuer Integrationsaufwand. Gemeinsame Plattformdienste können Bereitstellung und Rechteverwaltung erleichtern. Übergreifende Regeln beschreiben beispielsweise Identitäten, Schutzklassen und notwendige Metadaten. Die Fachdomäne bleibt für Bedeutung und Qualität zuständig, statt diese Verantwortung an die Plattform abzugeben.
Der Ansatz braucht ausreichende Fähigkeiten
Ein kleines Unternehmen mit wenigen Datenquellen benötigt nicht zwangsläufig mehrere autonome Datenteams. Dezentralisierung verursacht Abstimmungs- und Betriebsaufwand. Data Mesh ist besonders interessant, wenn mehrere fachlich eigenständige Bereiche viele Datenprodukte betreuen können. Fehlen Kapazität und klare Verantwortung, ist ein gut geführtes zentrales Team möglicherweise die tragfähigere Lösung.
Beispiel: Vertrieb und Logistik brauchen denselben Bestand
Die Logistik veröffentlicht ein Datenprodukt mit Definition, Aktualitätsziel und bekannten Einschränkungen. Der Vertrieb verwendet es für Lieferzusagen. Ein Qualitätsalarm meldet verspätete Aktualisierungen, statt veraltete Zahlen unbemerkt weiterzugeben. So wird der Nutzen der Produktverantwortung an einer konkreten Zusammenarbeit sichtbar.
Womit Sie sinnvoll beginnen können
- Zuerst Nutzer, Bedeutung und Qualitätsbedarf eines Datenprodukts klären.
- Gemeinsame technische Grundlagen von fachlicher Verantwortung unterscheiden.
- Dezentralisierung nur mit ausreichenden Teams und Betriebsfähigkeiten ausweiten.