Wie Datenverträge Ihre organisatorischen Datenprobleme lösen können

Das zentrale Data Warehouse wird in größeren datengesteuerten Unternehmen oft zum Engpass. Absurderweise gilt dies umso mehr, je datengetriebener ein Unternehmen agiert und je schneller ein Unternehmen neue Produkte, Dienstleistungen oder Tools einführt, bewertet und möglicherweise wieder verwirft, da es lange dauert, bis die Daten integriert sind. Dies kann dazu führen, dass übermäßig viele Analysten eingestellt werden, um Daten manuell zu sammeln und in Ad-hoc-Analysen zusammenzuführen. Datenverträge und Datengeflechte sind neue organisatorische Maßnahmen zur Dezentralisierung von Daten und zur Freigabe der Datenerfassung, -umwandlung und -analyse. (tl;dr)

Eine kurze Geschichte des Data Warehousing

Im letzten Jahrhundert waren es im Wesentlichen bestimmte Abteilungen in großen Unternehmen wie die Finanzabteilung, die Daten erzeugten und sich auf sie verließen und erste Datenspeicher zur Analyse dieser Daten aufbauten. Im Laufe der Zeit jedoch, als andere Abteilungen in Unternehmen Tools einführten und die Datenerfassung digitalisierten, begannen auch diese Abteilungen, Daten zu produzieren, die für die Geschäftsentwicklung von Bedeutung sein könnten.

Die Abteilungen produzierten und verwalteten Daten im Wesentlichen in Silos. Um ein Gesamtbild zu erhalten, brauchten die Unternehmen eine zentrale Datenverarbeitungs- und -analyseeinheit, die eine einzige Quelle der Wahrheit mit gemeinsamen Metriken bereitstellte. Auf diese Weise entstanden Data Warehouses. Ein Data Warehouse beherbergt Daten aus verschiedenen operativen Einheiten wie Vertrieb, Marketing, Design, Produktion, Forschung, Finanzen usw. und übersetzt die Daten in ein Format, das sie zentral nutzbar macht.

In dem Maße, in dem Unternehmen datengesteuert werden, beginnen immer mehr Geschäftsbereiche, sich auf Daten zu stützen. Infolgedessen begannen diese Organisationen, große Datenmengen aus jeder Abteilung oder team zu erzeugen, die in Fakten formatiert werden müssen, die ein zentrales Data Warehouse verarbeiten kann.

Mit den jüngsten Fortschritten in der Cloud-Data-Warehouse-Technologie, insbesondere durch nahezu unbegrenzte und unabhängig skalierbare Rechen- und Speicherressourcen, kann das zentrale Data-Warehouse im Prinzip die gewünschte ungetrübte ganzheitliche Sicht auf die Daten eines Unternehmens liefern.

Dies ist der derzeitige Stand der Technik, und viele Unternehmen haben es geschafft, eine solche Dateninfrastruktur zu implementieren. Aber das ist mit Kosten verbunden.

Neue Probleme entstehen

Ein zentrales Data Warehouse modularisiert die data stack nur vertikal - in dem Sinne, dass alle Daten aus allen Geschäftsbereichen das zentrale Data Warehouse passieren müssen. Dies erhöht die Abhängigkeiten und führt damit zu Engpässen. Für jede Datenquelle muss die zentrale team Ressourcen zuweisen und die Details des Innenlebens des Geschäfts der Quelle verstehen. Das kostet Zeit. Dennoch haben einige Unternehmen diese Komplexität in den Griff bekommen, indem sie viel Personal und Geld investiert haben. An diesem Punkt fängt das Problem jedoch erst an.

Die erfolgreichsten Unternehmen von heute bewegen sich schnell und brechen Dinge. Datengesteuert bedeutet, dass Daten genutzt werden, um Innovationen voranzutreiben. So nutzen Produktteams Clickstream-Daten, um Konversionstrichter zu optimieren, die Finanzabteilung identifiziert leistungsstarke Produkte/Zielgruppen/Geschäftsmodelle, das Marketing optimiert Kampagnen, und infolgedessen werden ständig neue Produkte, Geschäftsmodelle und Tools entwickelt, gekauft, bewertet und wieder verworfen, wodurch neue Datenströme, Datenformate und Analyseanforderungen entstehen.

Wenn der Aufbau der anfänglichen Infrastruktur zum Extrahieren, Transformieren, Harmonisieren und Modellieren der Daten aus allen Quellen bereits mehrere Monate oder oft sogar Jahre in Anspruch genommen hat, wird das zentrale Data Warehouse team nun ständig mit Änderungsanfragen überlastet sein und die Teams müssen möglicherweise länger auf die Daten warten, als das neue Produkt oder die zu analysierende Funktion überhaupt benötigt.

Die absurde Folge davon ist, dass die Geschäftsteams ihre Analysten damit beauftragen, die Daten, die sie aus ihren neuen Tools extrahieren, manuell zu verbinden, um Ad-hoc-Analysen durchzuführen. Das kostet mehr Zeit, macht die Metriken zwischen den Geschäftsbereichen weniger vergleichbar und verursacht zusätzliche Kopfschmerzen, wenn diese Art von Analysen regelmäßig durchgeführt werden muss. Unternehmen versuchen, dies zu kompensieren, indem sie eine übermäßige Anzahl von Analysten einstellen, um ihre Daten im Griff zu behalten. In einigen Fällen haben wir gesehen, dass das Vertrauen in das zentrale Data Warehouse team schwindet und neue Initiativen gestartet werden, um eine neue (natürlich bessere, weil neue Tools verwendende) zentrale Dateninfrastruktur ins Leben zu rufen, die leider aufgrund von Ressourcenknappheit die gleichen Probleme haben wird und sogar mit den alten Strukturen koexistieren kann.

Datenverträge sind die Rettung

Die häufigste Methode zur Bewältigung der Komplexität ist die Modularisierung. Indem man den Geschäftsbereichen die Verantwortung für ihre eigene data stack überträgt, können sie schneller auf ihre sich ändernden Bedürfnisse reagieren. Der Aufbau einer eigenen Datendomäne, bestehend aus einem vollständigen Stack von ETL, Data Warehouse und BI-/Data Science-Tools, ist natürlich weniger komplex als der Aufbau desselben für ein ganzes Unternehmen. Anstatt nur vertikal, d.h. Betrieb, ETL, DWH, teilt die Analytics-Modularisierung die Verantwortung nun auch horizontal entlang der Grenzen der Geschäftsbereiche auf.

Aber würde uns das nicht zurück in die alten Silozeiten führen? Ja, das würde es, und deshalb ist eine weitere Zutat erforderlich: Datenkontrakte. Wie bei der Modularisierung üblich, tauschen die Module (die Datendomäne) Daten über definierte Schnittstellen (Datenverträge) aus. Sie stellen sicher, dass unternehmensweite KPIs definiert werden können und eine ganzheitliche Analyse weiterhin möglich ist.

Aber wie soll das wirklich helfen? Würde es den Prozess nicht sogar verlängern, wenn zuerst die Datendomänen und dann die Infrastruktur für den Datenaustausch zwischen den Domänen mit Hilfe von Verträgen aufgebaut würden? Nein, es hilft sogar in zweierlei Hinsicht:

Datenverträge sind also der Schlüssel zur Modularisierung. Sie sollten definieren

• ein Geschäftsobjekt, das ausgetauscht werden soll (z. B. Transaktionen, Kunden, Ereignisse usw.)
  
• die Attribute des Geschäftsobjekts
• das Geschäftsobjekt + Attribute definieren im Grunde das Schema einer Tabelle in der Exportschicht Ihres Domains Data Warehouse
• den Zeitpunkt der Lieferung
• Historisierungsmodus
• sowie Datenqualität und Überwachungsparameter im Hinblick auf Genauigkeit, Eindeutigkeit, Gültigkeit, Vollständigkeit oder Aktualität der Daten).

Hinweis: Ob Sie ein Geschäftsobjekt/eine Tabelle pro Vertrag oder mehrere zulassen, ist Geschmackssache.

Datendomänen und Datenverträge bilden zusammen das Konzept eines Datennetzes, einer Architektur für Datenplattformen, die das Dateneigentum dezentralisiert und auf Teams verteilt, die Daten als unabhängiges Produkt auf der Grundlage des Geschäftsbereichs behandeln. Es wurde erstmals von Zhamak Deghani von ThoughtWorks beschrieben und umfasst vier Kernprinzipien:

• Vereinheitlichung verschiedener Datenquellen, um eine einzige Quelle der Wahrheit zu schaffen, unabhängig von den Unterschieden oder der fehlenden Kommunikation zwischen verstreuten Datensätzen.
  
• Schutz der Daten durch Governance.
• Höchste Datenqualität, unabhängig vom Volumen.
• Ermöglicht die Selbstbedienung ohne die Hilfe der Daten team und ermöglicht eine unabhängige Datenverwaltung.

Zu beachtende Fallstricke bei Datenverträgen

Auch wenn dieser neue Ansatz für die Unternehmensdateninfrastruktur vielversprechend ist, müssen einige Herausforderungen sorgfältig gemeistert werden.

Datenverträge und Datengeflechte reduzieren nicht die Komplexität der Daten in Ihrem Unternehmen. Sie machen sie jedoch durch Modularisierung besser handhabbar. Es werden immer noch viele Mitarbeiter benötigt, insbesondere dezentralisierte Dateningenieure. Allerdings werden die Datenverfügbarkeit und die Geschwindigkeit verbessert und die Notwendigkeit für bestimmte Rollen, wie z. B. Analysten, die Ad-hoc-Analysen durchführen, verringert.

Während die einzelnen Bereiche über interne Leistungsindikatoren (Key Performance Indicators, KPIs) verfügen werden, besteht ein Bedarf an zentralisierten KPIs ähnlich der Data-Warehousing-Architektur für eine Vogelperspektive des gesamten Unternehmens. Dies sollte einer der ersten Schritte beim Aufbau des Datennetzes sein, da sie die Voraussetzung für die Datenverträge sind

Es kann eine gute Idee sein, eine zentrale Datendomäne zu schaffen, die Geschäftsobjekte aus Quelldomänen sammelt und diese anderen Domänen zur Verfügung stellt. Diese Domäne ist dann in der Lage, KPI zu harmonisieren und auch gemeinsame Berichtsebenen und KPI bereitzustellen.

Datenverträge sollten zu Beginn definiert werden, können aber zu Verzögerungen bei der Implementierung führen, da verschiedene Einheiten auf die Definition dieser Verträge warten. Ich würde einen agileren Ansatz empfehlen, bei dem mit der Implementierung frühzeitig begonnen wird, um mögliche Fehler in den Verträgen zu erkennen, bevor alle Verträge abgeschlossen sind.

Die Beibehaltung der Autonomie der einzelnen Geschäftsbereiche ist entscheidend. Schränken Sie nicht einige Tools auf data stack auf eine zentrale team ein, weil Sie denken, dass die Bereiche nicht über das nötige Wissen verfügen (z. B. kann nur team X den Luftstrom verwalten). Nutzen Sie Bildung, um die Bereiche zu befähigen.

Weisen Sie auch nicht einfach Leute in einer zentralen team zu, um Aufgaben für eine bestimmte Geschäftseinheit zu erledigen, z.B. den einen Data Engineer für das Marketing usw.. Die Leute, die die data stack für das Marketing aufbauen,müssen Teil dieser Einheit sein, an ihren "all hands" teilnehmen, mit ihren Gruppenleitern sprechen, ihre OKRs teilen usw.. Sie müssen das Geschäftsmodell der Einheit vollständig leben und verstehen.

Außerdem sollten nicht nur die Dateningenieure des Bereichs für die Datenqualität verantwortlich sein. Der gesamte Bereich, einschließlich der Produktentwickler, ist verantwortlich.

Das Datennetz ermöglicht im Prinzip volle Autonomie für die Datenbereiche auch in Bezug auf die verwendeten Werkzeuge. Es gibt auch technische Implementierungen wie Trino/Starburst, die föderierte Abfragen über verschiedene Datentechnologien hinweg ermöglichen. Es kann Situationen geben, in denen eine bestimmte Technologie für ein bestimmtes Referat sinnvoll ist, aber im Allgemeinen und insbesondere, wenn mit einer neuen Infrastruktur begonnen wird, würde ich dringend empfehlen, für alle Referate die gleiche technische Grundlage zu verwenden. Dies erleichtert die Ausbildung und die Erstellung gemeinsamer Richtlinien und kann auch die Leistung drastisch verbessern, wenn Daten bereichsübergreifend zusammengeführt werden müssen. Datenvernetzung ist ein organisatorisches Konzept, kein technisches.

Einer der größten Vorteile von Data Warehouses ist natürlich die Verfügbarkeit historischer Daten. Dennoch können Sie sich dafür entscheiden, die Historie nur innerhalb der Domain-Warehouses zu haben und nicht in die Datenverträge aufzunehmen. Dies würde nur eine Analyse des Gesamtbildes auf der Grundlage des aktuellen Status ermöglichen, was durchaus in Ordnung sein kann. Planen Sie hier jedoch sorgfältig. Es könnte sich herausstellen, dass eine Verbraucherdomäne, z. B. ein Reverse-ETL zu Ihrem CRM, nicht nur den heutigen Status der Kunden benötigt, sondern auch, welche Kunden seit gestern gelöscht worden sind. Seien Sie sich bewusst, dass eine spätere Änderung des Historisierungsmodus viel Ärger bedeutet.

Datenverträge müssen natürlich im Laufe der Zeit geändert werden, wenn neue Daten produziert werden oder die Verbraucher andere Bedürfnisse haben. Berücksichtigen Sie dies bei Ihrer Planung und bereiten Sie sich auf die Versionierung vor. Möglicherweise müssen Sie verschiedene Versionen aktiv haben, da nicht alle Verbraucher zur gleichen Zeit wechseln werden. Dies würde erfordern, dass Sie die Versionierung in Ihr Projekt/Datensatz/Tabellennamen-Namensschema aufnehmen. Stellen Sie sicher, dass Sie ein klar kommuniziertes Verfallsschema haben, z. B. dass Sie nur die letzten beiden Versionen bereitstellen oder die alte Version nach X Monaten aufgeben.

Es ist vielleicht verlockend, 1:1-Verträge zu schließen, d. h. zwischen einer datenproduzierenden und einer datenverbrauchenden Domäne. Dies vereinfacht auch die Versionskontrolle, da alte Versionen nicht unbedingt noch aktiv sein müssen. Wenn Sie mit einer zentralen Domäne arbeiten und die meisten Verbraucherdomänen mit dieser verbunden sind, können 1:1-Verträge machbar sein. Wenn Sie jedoch direkte Punkt-zu-Punkt-Verbindungen fördern, steigt die Anzahl der Verträge quadratisch an und kann schnell unpraktikabel werden. Im Allgemeinen würde ich mich für Verträge auf Exportebene entscheiden, die alle Geschäftsobjekte definieren, die eine Domäne exportiert. Es gibt einen weiteren Vorteil von Verträgen auf Exportebene: Wenn Sie bereits einen Vertrag mit einer Verbraucherdomäne definiert haben, können Sie diesen normalerweise sofort für eine zweite Domäne verwenden, ohne einen neuen Vertrag zu definieren und die Tabellen in der Exportschicht zu implementieren. Dies kann den Prozess stark beschleunigen.

Zum Mitnehmen

Datenverträge und Datengeflechte sind zu einem heißen Thema in Unternehmen geworden, die die Vorteile, Kosten und Risiken eines Wechsels zu einer dezentralen Architektur für die gemeinsame Nutzung und Analyse von Daten abwägen. Es ist eine Abkehr vom zentralen Data Warehousing, das de facto die Nutzung von Unternehmensdaten für wichtige Geschäftsentscheidungen ermöglicht hat. Data Mesh steckt zwar noch in den Kinderschuhen, geht aber bereits einige der grundlegenden Probleme der zentralen Datenhaltung an und könnte daher für Unternehmen von Vorteil sein, die stark auf Daten angewiesen sind und sich gleichzeitig schnell weiterentwickeln.

Diese Umstellung auf die Behandlung von Daten als Produkt ist ein soziotechnisches Konzept, das seine Tücken hat. Wenn es jedoch erfolgreich umgesetzt wird, hat es das Potenzial, die Art und Weise zu verbessern, wie Unternehmen Daten sammeln, nutzen und analysieren. Wenn Sie Fragen oder Kommentare haben, lassen Sie es uns wissen.

Thomas Handorf

CEO, 9fwr