Die Teams hinter einem erfolgreichen Data Mesh

Blogserie | From Data to Business Value with Data Mesh | #4

Autor: Gerald Reif

Um mit einem Data Mesh erfolgreich zu sein, muss man nicht nur die vier Prinzipien (Blog #2) verstehen und deren Technologien (Blog #3) beherrschen, sondern vor allem auch den Menschen miteinbeziehen. Denn ein Data Mesh ist ein soziotechnischer Ansatz, bei dem auch die Organisation auf den zielgerichteten und effizienten Aufbau und Ausbau des Data Mesh ausgerichtet sein muss. In diesem Blogpost stellen wir die dafür benötigten Teams und deren Organisation vor, um mit einem Data Mesh die Transformation zu einer Data-Driven Company zu meistern.

Zentrale Teams als Bottleneck

In vielen Unternehmen wird ein zentrales Data Warehouse (DWH) als Basis für Analysen und Reportings eingesetzt. Soll eine neue Datenquelle gebunden werden oder auch nur ein bestehender Datensatz um eine Tabelle/Spalte erweitert werden, ergeht ein Auftrag an das zentrale DWH-Team. Da das DWH-Team die zentrale Anlaufstelle für alle Reporting- und Datenanalyseanfragen ist, wird die Kapazität in diesem Team häufig zum Bottleneck. In der Praxis haben wir bei dieser Teamorganisation folgende Herausforderungen festgestellt:

  1. Es dauert lange, bis eine neue Datenquelle angebunden ist und die Daten den Analysten zur Verfügung stehen. Das Business kann damit nicht agil auf neue Anforderungen reagieren. 
  2. Das DWH-Team verfügt über grosse Expertise im Umgang mit dem DWH-Produkt. Das Wissen über die Fachlichkeit der Datensätze liegt jedoch bei den Business Units. Der Kommunikations- und Koordinationsaufwand, um qualitativ hochwertige Datensätze aufzubereiten, wird damit sehr gross.
Abbildung 1: die Team-Organisation hinter einem erfolgreichen Data Mesh
Abbildung 1: die Team-Organisation hinter einem erfolgreichen Data Mesh

Die Teams für ein Data Mesh

Beim Data Mesh verfolgt man einen dezentralen Ansatz. Der Fokus liegt dabei darauf, die Domänen zu befähigen, möglichst selbstständig ihre Datenprodukte zu erstellen und zu betreiben. Deshalb ist es sinnvoll, die Aufgaben in folgenden drei Teams zu strukturieren:

  1. Plattform Team: Die Analytics Plattform setzt sich aus mehreren Services zusammen (z.B. Data Lake Storage, Daten Pipelines, Compute Cluster, etc.). Das Plattform Team wählt die notwendigen Services aus und konfiguriert sie entsprechend, damit sie den funktionalen Anforderungen der Domänen und den Sicherheitstechnischen- und Governance-Ansprüchen des Unternehmens entsprechen. Die Domänen können dann via Self-Service eine Instanz der Analytics-Plattform beziehen. 
    Das Plattform Team ist somit für den Aufbau, Weiterentwicklung und Betrieb der Plattform verantwortlich, nicht aber für die Datenprodukte.
  2. Consulting Team: Das Consulting Team besteht aus Experten, die wissen, wie die Analytics-Plattform effizient genutzt wird. Sie beraten die Domänen Teams bezüglich Best Practices. Das Consulting Team spielt auch die Anforderungen der Domänen an das Plattform Team zurück, welches die Analytics-Plattform weiterentwickelt.
  3. Domänen Team: Jedes Domänen Team bestellt beim Plattform Team via Self-Service eine Analytics-Plattform. Das Domänen Team verfügt über das fachliche Wissen, um die Datenprodukte in ihrer Domäne aufzubereiten. Die Domänen Teams sind die Owner der Datenprodukte in ihrer Domäne. Sie sind verantwortlich für den Betrieb der Daten-Pipelines und für die Einhaltung der versprochenen Service Level Agreements. Als Data Owner sind Mitglieder des Domänen Teams dafür zuständig, Zugriffsanfragen auf die eigenen Datenprodukte zu prüfen und bei berechtigtem Interesse zu gewähren. Sollte nicht genügend Expertise über den effizienten Einsatz der Analytics-Plattform in den Domänen vorhanden sein, werden punktuell Experten vom Consulting Team in die Projekte eingebunden. Mit der Unterstützung des Consulting Teams bilden sich damit in den einzelnen Domänen Teams Analytics-Champions heraus, welche Knowhow über die Analytics-Plattform aufbauen.

Plattform, Consulting und Domänen Teams - das sind die drei essenziellen Teams, um ein Data Mesh effizient aufzubauen. Die Datenprodukte werden dezentral von den Teams erstellt und betrieben, welche das fachliche Knowhow in der jeweiligen Domäne besitzen. Ausserdem wird dem Aspekt Rechnung getragen, dass das technische Wissen über den Aufbau der Analytics-Plattform nicht in den Domänen Teams vorhanden sein muss. Abhängig von der Grösse des Unternehmens können die Grenzen der Teams ineinander übergehend gestaltet sein. Zum Beispiel können Mitarbeiter des Consulting Teams beim Aufbau der Analytics-Plattform mitarbeiten, da diese die Services aus Anwendersicht kennen und so sicherstellen können, dass die Domänen Teams nach anerkannten Best Practices arbeiten können. Sollte ein Domänen Team zu wenig Erfahrung im Umgang mit der Analytics Plattform haben, so hilft das Consulting Team mit der Expertise in Data Engineering und Data Science aus.

Weitere Rollen & Teams, die es benötigt

Zusätzlich zu den vorgestellten drei Teams sind noch weitere Rollen/Teams involviert, wenn ein Data Mesh in einem Unternehmen eingeführt wird. Der Data Steward ist zum Beispiel dafür verantwortlich, dass die Data-Governance-Richtlinien des Unternehmens von der Analytics-Plattform und den Datenprodukten eingehalten werden. Das Cloud Foundation Team ist verantwortlich, dass die Cloud Services in die Enterprise IT Architektur integriert werden und sorgt für die sichere Anbindung des On-Premises Rechenzentrums zum Netzwerk des Cloud Providers. Die IT Security stellt sicher, dass durch die Architektur und Konfiguration der Cloud Services keine Sicherheitsrisiken eingegangen werden. 

Fazit

In diesem Blogpost haben wir vorgestellt, wie die drei zentralen Teams (Plattform, Consulting und Domänen Team) organisiert sein sollten, wenn unternehmensweit ein Data Mesh für Datenanalyse, Reporting und Machine Learning eingeführt wird. Wir haben zudem beleuchtet, welche Rolle der Data Steward, das Cloud Foundation Team sowie die IT Security bei der Einführung eines Data Mesh spielen. Sind diese Teams im Unternehmen klar definiert und aufeinander eingespielt, lässt sich der Schritt von einem zentralen DWH hin zu einem dezentralen Data Mesh meistern. Zusammenfassend kann gesagt werden, dass auch dieser Ansatz mit dem Menschen steht und fällt.

Data Mesh Blogserie: 

Blog #1 die Motivation dahinter

Blog #2 ihre vier Prinzipien

Blog #3 die technische Umsetzung

Blog #4 ihre Teams

Dein ipt-Experte

Ich freue mich auf Deine Kontaktaufnahme