Wie sind Data Products verbunden?

Data Products sind keine für sich stehenden Bestände. Sie bilden Abhängigkeitsgraphen. Ein Produkt „Order Summary“ verbraucht Daten aus den Produkten „Customer Profile“ und „Inventory“. Ein Modell „Churn Prediction“ hängt von „Usage Metrics“ und „Support Tickets“ ab. Jede Verbindung führt einen Kopplungspunkt ein, der über klare Schnittstellen, Verträge und gemeinsame Metadaten gesteuert werden muss.

Zu verstehen, wie diese Verbindungen arbeiten, über APIs, Ereignisse, Verträge und einen gemeinsamen Datenkatalog, ist der Unterschied zwischen einem stimmigen Datenökosystem und einem Gestrüpp aus Punkt-zu-Punkt-Anbindungen, das niemand vollständig überblickt.

Drei Topologien der Verbindung

Wie Data Products sich miteinander verbinden, folgt einem von drei Mustern. Jedes wägt Einfachheit, Governance und Skalierbarkeit anders ab.

Punkt-zu-Punkt ist die einfachste Topologie. Zwei Produkte verbinden sich unmittelbar: Eines ruft die API des anderen auf oder abonniert dessen Ereignisstrom. Das funktioniert gut, solange eine Organisation weniger als zehn Produkte hat und die Verbindungen stabil sind. Punkt-zu-Punkt-Verbindungen wachsen aber quadratisch: 10 Produkte können bis zu 45 Verbindungen haben, 20 Produkte bis zu 190, 50 Produkte bis zu 2.450. In dieser Größe hat niemand mehr ein vollständiges Bild davon, was wovon abhängt, und jede Schemaänderung an einem Produkt riskiert, Verbraucher zu brechen, von denen Sie nichts wussten.

Hub-and-Spoke führt alle Verbindungen über eine zentrale Integrationsschicht, etwa eine Datenplattform, ein API-Gateway oder eine Integrations-Middleware. Jedes Produkt veröffentlicht Daten an den Hub, jeder Verbraucher liest von dort. Das gibt dem zentralen Team den Überblick über alle Verbindungen und vereinfacht Überwachung und Governance. Der Preis ist das Engpassrisiko: Jede neue Verbindung verlangt, dass das Plattformteam eine Route baut oder einrichtet, und der Hub wird zur einzelnen Stelle, deren Ausfall alles trifft.

Mesh lässt Produkte sich unmittelbar über vereinheitlichte Schnittstellen verbinden, während ein gemeinsamer Katalog die Discovery trägt. Produkte machen ihre Schnittstellen und Verträge im Katalog bekannt; Verbraucher finden sie und verbinden sich, ohne über ein zentrales Team zu gehen. Das ist das am besten skalierende Muster, verlangt aber reife Standards für den Entwurf von Schnittstellen, für die Verwaltung der Verträge und für die Registrierung der Metadaten.

Technische Schnittstellen

Drei Muster von Schnittstellen decken die allermeisten Verbindungen zwischen Data Products ab. Jedes wägt Verzögerung, Kopplung und Betriebsaufwand anders ab.

REST-APIs bieten synchronen Zugriff nach dem Muster Anfrage und Antwort. Ein Dashboard ruft die Customer-API auf, um Profildaten zu holen; die API gibt den aktuellen Datensatz zurück. REST eignet sich gut für Abfragen auf Zuruf, für niedriges bis mittleres Volumen und für Fälle, in denen der Verbraucher den neuesten Stand braucht. Die Kopplung ist mittel: Der Verbraucher hängt vom Schema der API und von deren Verfügbarkeit ab, die Kommunikation ist aber zustandslos und lässt sich zwischenspeichern.

Ereignisströme (Apache Kafka, Google Pub/Sub, Amazon Kinesis) verbreiten Daten asynchron. Wird eine Bestellung aufgegeben, veröffentlicht das Produkt Order ein Ereignis in einem Topic. Das Produkt Inventory verbraucht dieses Ereignis und berechnet die Bestände neu. Das Produkt Fraud Detection verbraucht dasselbe Ereignis und bewertet das Risiko. Erzeuger und Verbraucher sind entkoppelt, keiner weiß vom anderen. Dieses Muster glänzt bei Aktualisierungen in Echtzeit, bei Verteilung an viele Empfänger und in Systemen, in denen mehrere Verbraucher dieselben Daten brauchen. Der Preis ist der Betriebsaufwand: Einen Kafka-Cluster zu betreiben verlangt Können, und ereignisgetriebene Flüsse sind schwerer zu untersuchen als ein synchroner API-Aufruf.

Change Data Capture (CDC) verfolgt Änderungen auf Ebene der Datenbank. Statt zu verlangen, dass das Quellprodukt Ereignisse ausdrücklich veröffentlicht, greifen CDC-Werkzeuge wie Debezium Einfügungen, Änderungen und Löschungen aus dem Transaktionsprotokoll der Datenbank ab und reichen sie als Ereignisse weiter. So bleiben nachgelagerte Produkte im Gleichstand, ohne dass der Code der Quellanwendung geändert wird. CDC ist besonders nützlich, wenn Altsysteme anzubinden sind, die sich nicht so umbauen lassen, dass sie von sich aus Ereignisse veröffentlichen.

Data Contracts

Ein Data Contract ist die Vereinbarung zwischen einem Erzeuger und einem Verbraucher. Er legt genau fest, worauf sich der Verbraucher stützen kann und was der Erzeuger zu liefern zusagt.

Ein Vertrag hat vier Bestandteile. Die Definition des Schemas legt Felder, Datentypen und Prüfregeln fest, in Formaten wie Avro, Protobuf oder JSON Schema. Die Zusagen zur Qualität verpflichten auf Aktualität (Daten nicht älter als X Minuten), Vollständigkeit (mindestens Y % der Zeilen vorhanden) und Genauigkeit (gegen die Quelle geprüft). Die Zusagen im SLA legen Verfügbarkeit (99,9 % Betriebszeit) und Verzögerung (Antwort unter 100 ms) fest. Und die Regel zur Versionierung bestimmt, wie Änderungen eingeführt werden: ergänzende Änderungen (neue optionale Felder) sind abwärtskompatible Nebenversionen; brechende Änderungen (entfernte Felder, geänderte Typen) verlangen einen Sprung der Hauptversion und eine Übergangsfrist.

Ein Data Product „Order“ veröffentlicht zum Beispiel einen Vertrag, der 99,9 % Verfügbarkeit, eine Antwort unter 100 ms und Daten nicht älter als 5 Minuten zusagt. Muss das Team ein Feld umbenennen, gibt es eine neue Hauptversion heraus, hält beide Versionen während eines Übergangsfensters vor und benachrichtigt die Verbraucher über den Katalog. Den Vertrag zu brechen, ohne der Regel zur Versionierung zu folgen, entspricht dem Ausliefern einer brechenden API-Änderung ohne Vorwarnung.

Discovery über Metadaten

Verbindungen funktionieren nur, wenn Verbraucher die Erzeuger finden. Ohne Katalog fällt die Discovery darauf zurück, Kolleginnen und Kollegen in Slack zu fragen, Wikis zu durchsuchen oder das Datenteam anzuschreiben, also auf das Daten-Gegenstück fest verdrahteter IP-Adressen. Über eine Handvoll Produkte hinaus trägt das nicht.

Ein Datenkatalog liefert die Schicht der Discovery. Verbraucher suchen Data Products nach Domäne, Schema, verantwortlicher Person oder fachlichem Begriff. Der Katalogeintrag jedes Produkts enthält Definitionen des Schemas, die Lineage (welche Produkte dieses speisen und welche es verbrauchen), Qualitätswerte, Zugriffsregeln und die aktuelle Version des Vertrags. Wer im Produktmanagement Daten zur Kundenabwanderung sucht, sucht nach „Churn“, findet das Produkt „Churn Prediction“, sieht sich Schema und Qualitätskennzahlen an, prüft, wer es verantwortet, und fordert Zugriff an, alles ohne den Katalog zu verlassen.

Lineage und Wirkungsanalyse

Bilden Data Products einen Abhängigkeitsgraphen, pflanzen sich Änderungen von oben nach unten fort. Ändert das Produkt „Customer“ sein Schema, benennt ein Feld um, wechselt einen Datentyp oder ändert eine Geschäftsregel, ist jeder nachgelagerte Verbraucher betroffen. Ohne verfolgte Lineage hat das Team, das die Änderung macht, keine Möglichkeit zu wissen, wen es bricht.

Die Data Lineage verfolgt diese Abhängigkeiten als gerichteten Graphen. Vor jeder Änderung an einem Data Product sieht sich das Team die Lineage an, um alle nachgelagerten Verbraucher zu bestimmen. Speist das Produkt „Customer“ die Produkte „Order Summary“, „Churn Prediction“ und „Revenue Report“, weiß das Team, dass eine Schemaänderung drei Produkte über zwei Domänen hinweg trifft. Es kann den Umzug abstimmen, die Version des Vertrags anheben und die betroffenen Teams benachrichtigen, alles bevor die Änderung live geht.

Besonders wichtig ist das für die aufsichtsrechtliche Berichterstattung. Fragt eine prüfende Person, woher diese Zahl im Compliance-Bericht stammt, liefert die Lineage eine prüfbare Kette vom Bericht zurück über jede Umformung bis zum Quellprodukt. Ohne Lineage lautet die Antwort: „Wir glauben, sie kommt irgendwo aus dem Warehouse.“

Qualität über den Graphen

Die Qualität nimmt ab, während Daten durch den Abhängigkeitsgraphen wandern. Ein Data Product, das drei vorgelagerte Produkte verbraucht, erbt jedes Qualitätsproblem aus allen dreien. Hat das Produkt „Customer“ 98 % Vollständigkeit und das Produkt „Inventory“ 97 %, startet das Produkt „Order Summary“, das beide verbindet, mit einem theoretischen Höchstwert von etwa 95 % Vollständigkeit, und das noch bevor seine eigene Verarbeitung weitere Lücken einführt.

Die Abwehr ist, die Qualität an den Verbindungspunkten zu überwachen. Die Prüfung des Schemas fängt strukturelle Änderungen ab, bevor sie sich fortpflanzen: Ein geänderter Feldtyp in der Quelle wird bei der Aufnahme zurückgewiesen, statt nachgelagerte Berechnungen still zu verfälschen. Prüfungen der Aktualität stellen sicher, dass vorgelagerte Daten tatsächlich innerhalb des SLA-Fensters angekommen sind; ein Dashboard, das Daten von vor zwei Stunden zeigt, während das SLA fünf Minuten zusagt, weist auf eine gebrochene Verbindung hin. Schwellen für die Vollständigkeit schlagen an, wenn eine Lieferung auffällig klein ist: 1.000 Zeilen zu erhalten, wo 100.000 die Norm sind, deutet eher auf eine fehlgeschlagene Extraktion hin als auf einen schwachen Tag.

Muster mit Sicherungsschalter verhindern, dass ein einziges schlechtes vorgelagertes Produkt den gesamten nachgelagerten Graphen verdirbt. Liefert das Produkt „Customer“ plötzlich fehlerhafte Daten, hält der Sicherungsschalter die Weitergabe an „Order Summary“, „Churn Prediction“ und „Revenue Report“ an, statt schlechte Daten durchfließen zu lassen. Die nachgelagerten Produkte liefern veraltete, aber richtige Daten, bis das vorgelagerte Problem behoben ist, und das ist fast immer besser, als frische, aber falsche Daten zu liefern.

Wo Dawiso hineinpasst

Dawiso liefert die drei Schichten, die Verbindungen zwischen Data Products in großem Maßstab tragen.

Discovery. Der Datenkatalog lässt Verbraucher Produkte finden und verstehen, ohne herumzufragen. Suche nach Domäne, Schema, fachlichem Begriff oder verantwortlicher Person. Qualitätswerte und Vertragsversionen prüfen, bevor eine Abhängigkeit gebaut wird.

Gemeinsame Definitionen. Das Business Glossary stellt sicher, dass „Kunde“ über alle Produkte hinweg dasselbe bedeutet. Verweisen das Produkt „Customer“ der CRM-Domäne und der „Revenue Report“ der Finanz-Domäne beide auf den „aktiven Kunden“, liefert das Glossar eine einzige maßgebliche Definition und verhindert damit die nachgelagerten Verknüpfungen, die still falsche Zahlen erzeugen, weil zwei Teams denselben Begriff verschieden festgelegt haben.

Abhängigkeiten verfolgen. Die Data Lineage zeigt, wie Produkte verbunden sind, welche von einer Änderung getroffen würden und wo Qualitätsprobleme entstehen. Vor jeder Schemaänderung sieht sich das Team die Lineage an, um den Wirkungsradius zu verstehen.

Über das Model Context Protocol (MCP) können KI-Agenten den Katalog von Dawiso abfragen, um verfügbare Data Products zu entdecken, Qualitätswerte zu prüfen, den Abhängigkeitsgraphen zu verstehen und die Wirkung vorgeschlagener Änderungen einzuschätzen. Damit werden das Orchestrieren von Verbindungen und die Wirkungsanalyse automatisierbar.

Fazit

Die Verbindung von Data Products ist in erster Linie kein technisches Problem, sondern ein Problem der Metadaten. Die technischen Schnittstellen (APIs, Ereignisse, CDC) sind längst etabliert. Der schwere Teil ist, Verbindungen auffindbar, gesteuert und widerstandsfähig zu machen, über gemeinsame Metadaten, klare Verträge und das Verfolgen von Abhängigkeiten, das zeigt, wer von wem abhängt.