Das fehlende Stück zur Daten-Demokratisierung ist handlungsorientierter als ein Katalog.

Organisationen versuchen, datengestützte Entscheidungsfindung zu implementieren und zielen darauf ab, Einblicke in die Hände der Mitarbeiter zu bekommen.

In letzter Zeit, mit der Einführung von Self-Service-BI und Datenentdeckung, beginnen diese Organisationen, die Anzahl der Datenverbraucher zu maximieren und die Abhängigkeit von einem zentralen Datenteam zu verringern.

Leider erfordert die Vorbereitung und Modellierung der Daten nach wie vor dieses zentrale Datenteam, das in einem bestimmten Umfang nicht erwartet werden kann, jedes Geschäftsdomäne, jedes Geschäftsziel und jedes Quellsystem-Datenmodell zu beherrschen. Damit sind sie auch von den Geschäfts- und IT-Teams abhängig.

Heute surfen wir eine dritte Welle der Daten-Demokratisierung, einer, bei der Organisationen auch die Anzahl der Datenproduzenten maximieren. Da Daten in der gesamten Organisation vorhanden sind, bedeutet das, dass jeder sowohl Datenverbraucher als auch -produzent werden könnte, und die Einblicke, die sie für andere schaffen, zurückfüttern, um sie erneut zu verwenden oder weiterzuentwickeln.

Durch die engen Zusammenarbeiten zwischen Geschäfts- und Datenexperten in Datenproduktteams beseitigen Organisationen den Engpass eines zentralen Datenteams und verbessern gleichzeitig die Qualität der Daten, indem sie die Geschäftslogik einbeziehen. Da dies viele Datenübergaben mit sich bringt, sehen wir den aufkommenden Bedarf, Produktdenken auf Daten anzuwenden, das darauf abzielt, die Zusammenarbeit all dieser Personen zu streamlinen, während Kosten, Sicherheit und viele weitere Aspekte kontrolliert bleiben.

Was ist ein Datenprodukt?

Produktdenken auf Daten anzuwenden, führt zu dem Begriff Datenprodukte. Aber hier wird es knifflig: Es gibt noch keinen Konsens darüber, was ein Datenprodukt ist. Oder wie Sanjeev Mohan, ein ehemaliger Forschungs-VP für Big Data & Advanced Analytics, es folgendermaßen beschrieb: „Jeder in meinen Kreisen hatte eine andere Auffassung davon, was ein Datenprodukt ist.“ Nur um einige Beispiele zu geben:

• Jean-Georges Perrin von Bitol beschreibt ein Datenprodukt als ein Bündel von Datenverträgen

• Jochen Christ von datamesh manager definiert ein Datenprodukt als eine logische Einheit, die alle Komponenten zum Verarbeiten und Speichern von Domänendaten für analytische oder datenzentrierte Anwendungsfälle enthält und sie anderen Teams und Ausgabepunkten zur Verfügung stellt

• Gartner verweist auf Datenprodukte als ein Set von Daten, Metadaten, Semantiken und Vorlagen.

  
  

  

Ich selbst fasse es grob zusammen als „die Daten und alles, was Sie benötigen, um sie unabhängig zu nutzen“. Was auch impliziert, aber grob ignoriert, dass Sie in der Lage sein müssen, das Datenprodukt zu erstellen, also dass Sie Daten verarbeiten können.

Unabhängig von der Definition, selbst unabhängig von der Perspektive des Anbieters der Definition, impliziert der Begriff Datenprodukt immer die Kombination von technischer und geschäftlicher Verantwortung, Verschiebung der Verantwortlichkeiten nach links, früh in der Entwicklungskette, und die Ermächtigung von Datenverbrauchern, das Datenprodukt zu konsumieren.

Das passiert gerade jetzt…

Datenproduktdenken tritt gerade auf. Einige Organisationen setzen voll auf Datenmesh, andere beginnen pragmatisch damit, die Verantwortung für die Datenaufnahme an die IT-Teams zu verschieben. Anstelle des zentralen Datenteams, das Daten aus allen operativen Systemen aufnimmt, werden die IT-Teams, die diese Tools aufbauen und warten, verantwortlich, ihre modellierten Daten mit dem zentralen Datenteam zu teilen.

Ohne wirklich die Anzahl der Datenproduzenten zu maximieren, können diese quellenorientierten Datenprodukte durch die Stabilisierung von Datenpipelines einen Wert bringen. Dies könnte sogar der Endzustand für kleinere Organisationen sein, in denen zentrale Datenteams die gesamte Geschäftstätigkeit weiterhin erfassen können.

… aber es fehlt etwas

Die Verwaltung einer erhöhten Anzahl von Datenproduzenten, möglicherweise über die gesamte Organisation verteilt, hat sich als Herausforderung erwiesen. Erstens müssen Datenprodukte, die in der gesamten Organisation erstellt wurden, für alle auffindbar gemacht werden. Aktuelle Datenkataloge konzentrieren sich jedoch auf Datenbestände und deren Felder, nicht auf Datenprodukte.

Zweitens verlagert Produktdenken die Verantwortung für die Erfassung von Metadaten früher in der Entwicklungskette. Hier kommen die Datenverträge ins Spiel, die es Ihnen ermöglichen, Metadaten im Voraus bereitzustellen. Diese Datenverträge beschränken sich nicht auf Schemametadaten, sondern können auch SLA-Informationen, Versionierung und vieles mehr enthalten. Ein weiterer Konflikt besteht darin, dass das detaillierte Informationsniveau dieser Datenverträge nicht mit dem der Datenkataloge übereinstimmt und möglicherweise einen anderen Ort erfordert, um angezeigt zu werden.

Drittens sollte der Überblick über ein Datenprodukt als Kombination aus Daten, Metadaten und Geschäftslogik Ihnen ermöglichen, einfach zwischen all diesen Entitäten zu navigieren. Auch dies ist etwas, wofür derzeitige Lösungen nicht konzipiert sind.

Diese drei Herausforderungen führen dazu, dass Organisationen mit der Governance von Datenprodukten kämpfen. Und dann haben wir noch nicht einmal über Prozesse gesprochen..

Wie regeln Sie, wer in der Lage ist, ein neues Datenprodukt zu erstellen? Wie kann jemand Zugriff auf ein Datenprodukt anfordern? Oder auf Werkzeuge und Infrastruktur, um eines zu erstellen? Und wie kann jemand einen solchen Antrag genehmigen und implementieren? Diese Prozesse riskieren, zum neuen Engpass zu werden, da sie erneut stark von zentralen Teams abhängen, um Lösungen zu erstellen oder zu steuern.

Automatisierung ist der Schlüssel, um diese Falle zu vermeiden und den Datenprodukteigentümern zu ermöglichen, ihre Verantwortung reibungslos zu übernehmen.

Und das ist das Datenproduktportal!

Eine neue Kategorie von Werkzeugen drängt auf die Szene: Datenproduktenkataloge. Wir verwenden lieber den Begriff „Portal“ und das ist genau das, was wir unser neuestes Open-Source-Projekt — Das Datenproduktportal — nennen! Diese kleine Wortänderung von „Katalog“ zu „Portal“ betont, dass ein solches Werkzeug nicht nur einen Überblick bietet, sondern es ermöglicht, in allen Werkzeugen Ihrer Datenlandschaft zu navigieren.

Im Kern bietet unser Portal Ihnen einen Überblick über bestehende Datenprodukte und deren Datensätze und verwaltet die Prozesse darum: Zugriffsanfragen und Genehmigung, ein neues erstellen, … Doch durch die Kraft von Integrationen können Sie

• Zu einem Datenkatalog navigieren, um detailliertere Beschreibungen zu besuchen

• Zu Ihrem Datenproduktenentwicklungswerkzeug, wie Conveyor, geleitet werden, um Datenprodukte zu erstellen und auszuführen und sogar die Infrastruktur zu verwalten

• Zugriff verwalten und Vorschauen oder sogar vollen Zugriff auf die Daten erhalten

Das Portal ist das fehlende Puzzlestück, um die Entwicklung von Datenprodukten in Ihrer Organisation zu skalieren, und seltsamerweise ist es das zentrale Stück, vielleicht sogar Ihr Ausgangspunkt. Ein weiterer Grund, das Datenproduktportal als Open-Source-Initiative anzubieten, um heute mit dem Denken über Datenprodukte zu beginnen!

Möchten Sie mehr erfahren?

Neugierig darauf, mehr über das Open-Source-Datenproduktportal zu erfahren? Besuchen Sie die Projektseite hier oder das GitHub-Repo hier!