Source-Aligned oder Consumer-Aligned — die Unterscheidung klingt nach Data-Mesh-Theorie, entscheidet aber in der Praxis darüber, wer für welche Daten wie weit verantwortlich ist. Diese Seite erklärt beide Typen und zeigt das konkreteste Praxis-Setup, das ich im Podcast dazu gehört habe: die Data Landing Zones der ZEISS Group.
Die Theorie in zwei Sätzen
Source-Aligned Data Products sitzen nah am Quellsystem und stellen dessen Daten stabil und unverbogen bereit. Consumer-Aligned Data Products sitzen nah am Konsumenten und sind für einen konkreten Use Case gebaut.
Laura V., die bei der ZEISS Group die Data-Mesh-Journey mitgestaltet, ordnet es in ihrer Folge so ein: „laut Theorie hat man ja die Source-Aligned-Domänen und dann irgendwann die Customer-Aligned-Domänen. Die Source-Aligned-Domänen sind sehr nah an der Quelle. Die Customer-Aligned sehr dezentral, wirklich an den Fachbereichen, decken vielleicht ein paar sehr spitze Use Cases ab." (Bei ZEISS fällt auch mal „Customer-Aligned" statt „Consumer-Aligned" — gemeint ist dasselbe: der interne Daten-Kunde.)
Warum die Trennung sinnvoll ist:
- Stabilität: Source-Aligned-Produkte ändern sich mit dem Quellsystem, nicht mit jeder Use-Case-Mode. Darauf lässt sich bauen.
- Wiederverwendung: Ein sauberes Quell-Produkt speist viele Konsumenten-Produkte — statt dass jeder Use Case eigene Extraktionen baut.
- Verantwortung: Jede Zone hat einen klaren Owner mit klarer Grenze.
Die Praxis bei ZEISS: drei Zonen statt zwei
In der Umsetzung hat ZEISS Digital Partners die Zwei-Typen-Theorie um eine Mittelschicht erweitert. Vanessa G. beschreibt es in ihrer Folge so: „Wir haben ja drei Arten von Data Landing Zones in unserem Data-Mesh-Konzept. Die Source-Aligned Data Landing Zones, die sehr nah am Source-System sind. […] dann gibt es noch diese hybriden Data Landing Zones, die sind zwischen dem Konsumenten und den Source-Systems […] Und dann gibt es auch noch die Consumer-Aligned Data Landing Zones, die sehr kundenorientiert sind, wo dann auch schon viele Quellsysteme reinkommen können."
| Zone | Nähe | Typischer Inhalt | Konsument |
|---|---|---|---|
| Source-Aligned | am Quellsystem | Rohdaten eines Systems, sauber bereitgestellt | andere Domänen, hybride Zonen |
| Hybrid | dazwischen | verknüpfte, angereicherte Daten mehrerer Quellen | Fachdomänen, Analytics-Teams |
| Consumer-Aligned | am Fachbereich | Use-Case-spezifische Produkte aus vielen Quellen | ein konkreter Anwendungsfall |
Ihr eigenes Team arbeitet Source-Aligned am Marketing-Stack: „In unserem Fall sind wir eben Source-Aligned, also wir sind sehr nah am Marketing-Tool direkt dran und unsere Kunden können dann selbstständig ihre Daten wieder mit anderen Domänen verknüpfen." Die „Kunden" sind dabei interne Kollegen der ZEISS-Gruppe — Consumer-Aligned heißt nicht Endkunde, sondern Daten-Konsument.
Die unterschätzte Pointe: Verantwortungsgrenzen
Der operative Grund, warum sich die Zonen-Logik lohnt, ist nicht Architektur-Ästhetik — es ist die Haftungsgrenze. Bei ZEISS endet die Verantwortung des Source-Aligned-Teams am Rand der eigenen Data Landing Zone: Das Team garantiert das Datenset bis zur Übergabe; ab da übernimmt der Konsument. Ohne diese Grenze skaliert das Modell nicht — sonst ist das Quell-Team plötzlich für jeden nachgelagerten Use Case support-pflichtig.
Dieselbe Logik taucht bei PowerCo auf, wenn Data Products modular gedacht werden: „Ein Dataprodukt kann ein anderes Dataprodukt konsumieren oder mehrere Dataprodukte konsumieren […] und kann dann wiederverwendet werden in einem anderen Dataprodukt" (PowerCo-Folge). Source-Aligned-Produkte sind die Basis-Bausteine dieser Kette — und ihre Wiederverwendungsrate ist bei PowerCo die zentrale Effizienz-Kennzahl.
Ehrliche Einordnung: Wie verbreitet ist das Vokabular?
Transparenz gehört zu einem Leitfaden dazu: In über 320 Podcast-Folgen mit Datenverantwortlichen ist mir das Begriffspaar Source-/Consumer-Aligned fast ausschließlich bei ZEISS begegnet — dort dafür konsequent gelebt. Die meisten Organisationen bauen faktisch dieselbe Schichtung (Quell-Produkte, angereicherte Produkte, Use-Case-Produkte), nennen sie aber anders oder gar nicht. Lass dich also nicht vom Vokabular stressen: Entscheidend ist nicht, ob du die Begriffe benutzt, sondern ob die Verantwortungsgrenzen definiert sind.
Ein pragmatischer Test für dein Setup:
- Kannst du für jedes Data Product sagen, ob es an einer Quelle oder an einem Use Case hängt?
- Ist definiert, wo die Verantwortung des bereitstellenden Teams endet?
- Können Konsumenten Quell-Produkte selbstständig verknüpfen — oder braucht jede Kombination ein Projekt?
Wenn du dreimal Ja sagst, hast du die Substanz der Source-/Consumer-Aligned-Logik — egal wie es bei euch heißt.
Weiterlesen
- Wie implementiert man Data Products? — vom Business-Intent zum Betriebsmodell
- Organisation & Rollen — wer Source- und Consumer-Zonen verantwortet
- Data-Products-Pillar — der Gesamtüberblick
- Data Mesh — das Organisationsmodell hinter den Zonen