Architektur und Funktionen in einem Data Mesh

Last reviewed 2022-10-06 UTC

Ein Data Mesh ist ein Architektur- und Organisations-Framework, das Daten als Produkt behandelt (in diesem Dokument als „Datenprodukte“ bezeichnet). In diesem Framework werden Datenprodukte von den Teams entwickelt, die diese Daten am besten verstehen und die einem organisationsweiten Satz von Data-Governance-Standards folgen. Sobald Datenprodukte im Data Mesh bereitgestellt wurden, können verteilte Teams in einer Organisation Daten schneller und effizienter ermitteln und darauf zugreifen, die für ihre Anforderungen relevant sind. Damit Sie ein so gut funktionierendes Data Mesh erreichen können, müssen Sie zuerst die in diesem Dokument beschriebenen allgemeinen Komponenten der Architektur und die Organisationsrollen einrichten.

Dieses Dokument ist Teil einer Reihe, in der beschrieben wird, wie ein Data Mesh in Google Cloud implementiert wird. Dabei wird davon ausgegangen, dass Sie die Konzepte kennen, die unter Ein modernes verteiltes Data Mesh mit Google Cloud erstellen beschrieben werden.

Die Reihe besteht aus folgenden Teilen:

• Architektur und Funktionen in einem Data Mesh (dieses Dokument)
• Self-Service-Datenplattform für ein Data Mesh entwerfen
• Datenprodukte in einem Data Mesh erstellen
• Datenprodukte in einem Data Mesh ermitteln und nutzen

In dieser Reihe ist das beschriebene Data Mesh innerhalb einer Organisation intern. Es ist zwar möglich, eine Data Mesh-Architektur zu erweitern, um Drittanbietern Datenprodukte zur Verfügung zu stellen. Dieser erweiterte Ansatz wird in diesem Dokument jedoch nicht behandelt. Das Erweitern eines Data Mesh erfordert neben der Nutzung innerhalb einer Organisation weitere Überlegungen.

Architektur

Die folgenden Schlüsselbegriffe werden verwendet, um die in dieser Reihe beschriebenen Architekturkomponenten zu definieren:

• Datenprodukt: Ein Datenprodukt ist ein logischer Container oder eine Gruppierung einer oder mehrerer zugehöriger Datenressourcen.
• Datenressource: Eine Datenressource ist ein physisches Asset in einem Speichersystem, das strukturierte Daten enthält oder eine Abfrage speichert, die strukturierte Daten liefert.
• Datenattribut: Ein Datenattribut ist ein Feld oder Element einer Datenressource.

Das folgende Diagramm bietet einen Überblick über die wichtigsten Architekturkomponenten in einem Data Mesh, das in Google Cloud implementiert ist.

Das obige Diagramm zeigt Folgendes:

• Zentrale Dienste ermöglichen das Erstellen und Verwalten von Datenprodukten, einschließlich Organisationsrichtlinien, die sich auf die Data Mesh-Teilnehmer auswirken, Zugriffssteuerungen (über Identitäts- und Zugriffsverwaltungsgruppen) und die infrastrukturspezifischen Artefakte. Beispiele für solche Zusicherungen und Reservierungen sowie die Infrastruktur, die das Funktionieren des Data Mesh ermöglicht, werden unter Plattformkomponenten und -lösungen erstellen beschrieben.
• Zentrale Dienste stellen den Data Catalog in erster Linie für alle Datenprodukte im Data Mesh und für den Erkennungsmechanismus für potenzielle Kunden dieser Produkte bereit. Informationen zum Registrieren von Datenprodukten im Datenkatalog finden Sie unter Datenprodukte und -Ressourcen in einem Data Mesh beschreiben und organisieren.
• Datendomains machen Teilmengen ihrer Daten als Datenprodukte über klar definierte Datennutzungsschnittstellen verfügbar. Diese Datenprodukte können eine Tabelle, eine Ansicht, eine strukturierte Datei, ein Thema oder ein Stream sein. In BigQuery wäre dies ein Dataset und in Cloud Storage ein Ordner oder Bucket. Es können verschiedene Schnittstellentypen als Datenprodukt bereitgestellt werden. Ein Beispiel für eine Schnittstelle ist eine BigQuery-Ansicht einer BigQuery-Tabelle. Die am häufigsten für Analysezwecke verwendeten Schnittstellentypen werden unter Datenprodukte in einem Data Mesh erstellen erläutert.

Data Mesh-Referenzimplementierung

Eine Referenzimplementierung dieser Architektur finden Sie im Repository data-mesh-demo. Die in der Referenzimplementierung verwendeten Terraform-Skripts veranschaulichen Data Mesh-Konzepte und sind nicht für die Produktion vorgesehen. Sie führen diese Skripts aus, um folgende Aufgaben auszuführen:

• Trennen Sie Produktdefinitionen von den zugrunde liegenden Daten.
• Erstellen Sie Data Catalog-Vorlagen zum Beschreiben von Produktschnittstellen.
• Taggen Sie Produktschnittstellen mit diesen Vorlagen.
• Gewähren Sie den Produktnutzern Berechtigungen.

Für die Produktschnittstellen werden von der Referenzimplementierung die folgenden Schnittstellentypen erstellt und verwendet:

• Autorisierte Ansichten über BigQuery-Tabellen.
• Datenstreams basierend auf Pub/Sub-Themen.

Weitere Informationen finden Sie im Repository in der README-Datei.

Funktionen in einem Data Mesh

Damit ein Data Mesh-Netzwerk gut funktioniert, müssen Sie klare Rollen für die Personen definieren, die Aufgaben im Data Mesh ausführen. Die Inhaberschaft wird Team-Archetypen oder Funktionen zugewiesen. Diese Funktionen erlauben das wichtigste Nutzerverhalten für Personen, die im Data Mesh arbeiten. Damit Nutzerpfade eindeutig beschrieben werden können, wurden sie Nutzerrollen zugewiesen. Diese Nutzerrollen können anhand der Bedingungen der einzelnen Unternehmen aufgeteilt und kombiniert werden. Sie müssen die Rollen nicht direkt Mitarbeitern oder Teams in Ihrer Organisation zuordnen.

Eine Datendomain ist an einer Geschäftseinheit (Business Unit) oder einer Funktion innerhalb eines Unternehmens ausgerichtet. Gängige Beispiele für Unternehmensbereiche sind die Hypothekenabteilung in einer Bank oder die Kunden-, Vertriebs-, Finanz- oder Personalabteilung eines Unternehmens. Konzeptionell gibt es in einem Data Mesh zwei bereichsbezogene Funktionen: die Teams Datenersteller und Datennutzer. Beachten Sie, dass eine einzelne Datendomain wahrscheinlich beide Funktionen gleichzeitig bereitstellt. Ein Data Domain-Team erzeugt Datenprodukte aus Daten, die ihm gehören. Das Team nutzt außerdem Datenprodukte für geschäftliche Einblicke und um zu erstellen abgeleitete Datenprodukte für die Verwendung anderer Domains.

Zusätzlich zu den domainbasierten Funktionen bietet ein Data Mesh auch eine Reihe von Funktionen, die von zentralisierten Teams innerhalb der Organisation ausgeführt werden. Diese zentralen Teams ermöglichen den Betrieb des Data Mesh durch domainübergreifende Aufsicht, Dienste und Governance. Sie reduzieren den operativen Aufwand für Datendomains bei der Erstellung und Nutzung von Datenprodukten und erleichtern die domainübergreifenden Beziehungen, die für den Betrieb des Data Mesh erforderlich sind.

In diesem Dokument werden nur Funktionen mit einer Data Mesh-spezifischen Rolle beschrieben. In jedem Unternehmen sind mehrere weitere Rollen erforderlich, unabhängig von der für die Plattform verwendeten Architektur. Diese anderen Rollen werden in diesem Dokument jedoch nicht behandelt.

Die vier Hauptfunktionen in einem Data Mesh sind:

• Domainbasierte Daten-Erstellerteams: Sie erstellen und verwalten Datenprodukte über ihren gesamten Lebenszyklus hinweg. Diese Teams werden häufig als Datenersteller bezeichnet.
• Domainbasierte Daten-Nutzerteams: Ermitteln Sie Datenprodukte und verwenden Sie sie in verschiedenen Analyseanwendungen. Diese Teams nutzen möglicherweise Datenprodukte, um neue Datenprodukte zu erstellen. Diese Teams werden häufig als Datennutzer bezeichnet.
• Zentrales Data Governance-Team: Definiert und erzwingt Data Governance-Richtlinien zwischen Datenerstellern, wodurch eine hohe Datenqualität und Datenvertraulichkeit für Nutzer gewährleistet werden. Dieses Team wird häufig als Data Governance-Team bezeichnet.
• Zentrales Team für die Self-Service-Dateninfrastrukturplattform: Bietet eine Self-Service-Datenplattform für Datenersteller. Dieses Team bietet auch die Tools für die zentrale Datenerkennung und Beobachtbarkeit von Datenprodukten, die sowohl Datennutzer als auch Datenersteller verwenden. Dieses Team wird häufig als Datenplattformteam bezeichnet.

Eine optionale zusätzliche Funktion ist die eines Centers of Excellence (COE) für das Data Mesh. Der Zweck des COE ist die Verwaltung des Data Mesh. Das COE ist auch das vorgesehene Schiedgerichts-team, das Konflikte löst, die durch eine der anderen Funktionen ausgelöst wurden. Diese Funktion ist hilfreich, um die anderen vier Funktionen zu verbinden.

Domainbasiertes Daten-Erstellerteam

In der Regel basieren Datenprodukte auf einem physischen Repository mit Daten (entweder einzelnen oder mehreren Data Warehouses, Lakes oder Streams). Eine Organisation benötigt herkömmliche Datenplattformrollen, um diese physischen Repositories zu erstellen und zu verwalten. Diese traditionellen Datenplattformrollen sind jedoch normalerweise nicht die Personen, die das Datenprodukt erstellen.

Zum Erstellen von Datenprodukten aus diesen physischen Repositories benötigt eine Organisation eine Mischung aus Datenexperten wie Data Engineers und Datenarchitekten. In der folgenden Tabelle sind alle domainspezifischen Nutzerrollen aufgeführt, die in Datenerstellerteams benötigt werden.

Rolle	Verantwortlichkeiten	Erforderliche Kenntnisse	Gewünschte Ergebnisse
Datenproduktinhaber	Dient als primärer Geschäftsansprechpartner für das Datenprodukt. Ist für die Definitionen, Richtlinien, Geschäftsentscheidungen und die Anwendung von Geschäftsregeln für die als Produkte bereitgestellten Daten verantwortlich. Dient als Ansprechpartner bei geschäftlichen Fragen Daher repräsentiert der Inhaber die Datendomain, wenn er sich mit den Teams der Datennutzer oder den zentralisierten Teams trifft (Data Governance und Dateninfrastrukturplattform).	Datenanalyse Datenarchitektur Produktverwaltung	Das Datenprodukt erschafft für die Verbraucher Mehrwert. Der Lebenszyklus des Datenprodukts wird robust verwaltet. Sie können beispielsweise entscheiden, wann ein Produkt eingestellt oder eine neue Version veröffentlicht werden soll. Universelle Datenelemente werden mit anderen Datendomains koordiniert.
Technischer Leiter des Datenprodukts	Fungiert als primärer Ansprechpartner für das Produkt. Ist für die Implementierung und Veröffentlichung von Produktschnittstellen verantwortlich. Dient als Ansprechpartner bei technischen Fragen Daher repräsentiert der Leiter die Datendomain, wenn er sich mit den Datennutzerteams oder den zentralisierten Teams (Data Governance und Dateninfrastrukturplattform) trifft. Arbeitet mit dem Data Governance-Team und definiert und implementiert Data Mesh-Standards in der Organisation. Arbeitet mit dem Team der Datenplattform zusammen, um die Plattform gemeinsam mit den technischen Anforderungen zu entwickeln, die von Produktion und Verbrauch generiert werden.	Data Engineering Datenarchitektur Softwaretechnik	Das Datenprodukt erfüllt Geschäftsanforderungen und die technischen Standards des Data Mesh. Die Datennutzerteams verwenden das Datenprodukt und es wird in den Ergebnissen angezeigt, die von der Datenprodukterkennung generiert werden. Die Verwendung des Datenprodukts kann analysiert werden (z. B. die Anzahl der täglichen Abfragen).
Support für Datenprodukte	Dient als Ansprechpartner für Produktionssupport. Ist für die Aufrechterhaltung des Service Level Agreement (SLA) für Produkte verantwortlich.	Software Engineering Site Reliability Engineering (SRE)	Das Datenprodukt erfüllt das angegebene SLA. Datennutzerfragen zur Verwendung des Datenprodukts werden angegangen und geklärt.
Experte (KMU) für Datendomain	Repräsentiert die Datendomain, wenn er mit KMUs aus anderen Datendomains zusammentrifft, um Datenelementdefinitionen und -grenzen festzulegen, die in der gesamten Organisation üblich sind. Hilft neuen Datenerstellern innerhalb der Domain, ihre Produktbereiche zu definieren.	Datenanalyse Datenarchitektur	In Zusammenarbeit mit anderen KMUs aus diversen Datendomains wird ein umfassendes Verständnis der Daten in der Organisation und der dort verwendeten Datenmodelle aufgebaut und gepflegt. Ermöglicht das Erstellen interoperabler Datenprodukte, die dem Gesamtdatenmodell der Organisation entsprechen. Für die Erstellung von Datenprodukten und die Lebenszyklusverwaltung gibt es klare Standards. Die Datenprodukte aus der Datendomain bieten einen geschäftlichen Mehrwert.
Dateninhaber	Ist für einen Inhaltsbereich verantwortlich. Trägt Verantwortung für Datenqualität und -genauigkeit Genehmigt Zugriffsanfragen. Beteiligt sich an der Dokumentation des Datenprodukts.	Alle Fähigkeiten, müssen aber über umfassende Kenntnisse der Geschäftsfunktion verfügen. Jede Fähigkeit, muss jedoch umfassende Kenntnisse über die Bedeutung der Daten und der Geschäftsregeln dieser haben. Jegliche Kompetenzen, müssen jedoch in der Lage sein, die bestmögliche Lösung für Datenqualitätsprobleme zu finden.	Daten, die funktionsübergreifend verwendet werden, sind korrekt. Die Beteiligten verstehen die Daten. Die Datennutzung entspricht den Nutzungsrichtlinien.

Domainbasierte Daten-Nutzerteams

In einem Data Mesh sind die Personen, die ein Datenprodukt nutzen, in der Regel Datennutzer, die sich außerhalb der Datenproduktdomain befinden. Diese Datennutzer verwenden einen zentralen Datenkatalog, um Datenprodukte zu finden, die für ihre Anforderungen relevant sind. Da es möglich ist, dass mehr als ein Datenprodukt ihre Anforderungen erfüllt, kann es passieren, dass Datennutzer mehrere Datenprodukte abonnieren.

Wenn Datennutzer das erforderliche Datenprodukt für ihren Anwendungsfall nicht finden können, liegt es in ihrer Verantwortung, sich direkt an den Data Mesh-COE zu wenden. Während dieser Beratung können Datennutzer ihre Datenanforderungen ansprechen und sich darüber informieren, wie sie diese Anforderungen von einer oder mehreren Domains erfüllen lassen können.

Bei der Suche nach einem Datenprodukt suchen Datennutzer nach Daten, mit denen sie verschiedene Anwendungsfälle wie nichtflüchtige Analyse-Dashboards und Berichte, einzelne Leistungsberichte und andere Leistungsmesswerte für Unternehmensleistung erreichen können. Alternativ suchen Datennutzer vielleicht nach Datenprodukten, die in Anwendungsfällen von künstlicher Intelligenz (KI) und maschinellem Lernen (ML) verwendet werden können. Um diese verschiedenen Anwendungsfälle zu erreichen, benötigen Datennutzer eine Mischung aus Datenexperten, die so aussieht:

Rolle	Verantwortlichkeiten	Erforderliche Kenntnisse	Gewünschte Ergebnisse
Datenanalyst	Sucht, identifiziert, evaluiert und abonniert Einzeldomain- oder domainübergreifende Datenprodukte, um eine Grundlage für den Betrieb von Business Intelligence-Frameworks zu schaffen.	Analyse Engineering Geschäftsanalysen	Bietet saubere, ausgewählte und aggregierte Datasets für Datenvisualisierungsexperten. Erstellt Best Practices für die Verwendung von Datenprodukten. Domainübergreifende Datasets werden von ihm aggregiert und zusammengestellt, um die Analyseanforderungen seiner Domain zu erfüllen.
App-Entwickler	Entwicklung eines Anwendungs-Frameworks zur Nutzung von Daten aus einem oder mehreren Datenprodukten, entweder innerhalb oder außerhalb der Domain.	Anwendungsentwicklung Data Engineering	Erstellt, stellt bereit und verwaltet Anwendungen, die Daten aus einem oder mehreren Datenprodukten nutzen. Erstellt Datenanwendungen für den Endnutzer.
Experte für die Datenvisualisierung	Übersetzt Fachbegriffe im Bereich Data Engineering und Datenanalyse in Informationen, die geschäftliche Stakeholder verstehen können. Definiert Prozesse zum Ausfüllen von Geschäftsberichten mit Informationen aus Datenprodukten. Erstellt und überwacht Berichte, in denen strategische Geschäftsziele beschrieben werden. Arbeitet zusammen mit Entwicklern innerhalb der Organisation, um Datasets zu entwerfen, die aus genutzten Datenprodukten aggregiert werden. Implementiert Berichtslösungen Wandelt allgemeine Geschäftsanforderungen in technische Anforderungen.	Anforderungsanalyse Datenvisualisierung	Stellt gültige und genaue Datasets und Berichte für Endnutzer bereit. Die Geschäftsanforderungen werden über die Dashboards und Berichte erfüllt, die entwickelt werden.
Data Scientist	Sucht, identifiziert, bewertet und abonniert Datenprodukte für Data Science-Anwendungsfälle. Extrahiert Datenprodukte und Metadaten aus mehreren Datendomains. Trainiert Vorhersagemodelle und stellt diese Modelle zur Optimierung der Domaingeschäftsprozesse bereit. Bietet Feedback zu möglichen Methoden für die Datenkuration und Datenannotation für mehrere Datendomains.	ML Entwicklung Analyseentwicklung	Erstellt Vorhersage- und präskriptive Modelle zur Optimierung von Geschäftsprozessen. Modelltraining und Modellbereitstellung werden zeitnah durchgeführt.

Zentrales Data Governance-Team

Dank dem Data Governance-Team können Datenersteller und -Nutzer Daten eigenständig sicher freigeben, aggregieren und berechnen, ohne Compliance-Risiken für das Unternehmen zu verursachen.

Um die Compliance-Anforderungen der Organisation zu erfüllen, besteht das Data-Governance-Team aus einer Mischung von Datenexperten, die so aussieht:

Rolle	Verantwortlichkeiten	Erforderliche Kenntnisse	Gewünschte Ergebnisse
Data Governance-Experte	Bietet Überblick und koordiniert eine einzelne Ansicht der Compliance. Empfehlungen für Mesh-weite Datenschutzrichtlinien zur Datenerfassung, zum Datenschutz und zur Datenaufbewahrung. Stellt sicher, dass die Datenverwalter über Richtlinien informiert sind und darauf zugreifen können. Informiert und berät bei Bedarf über die neuesten Datenschutzbestimmungen. Informiert und berät über Sicherheitsfragen nach Bedarf. Führt interne Audits durch und teilt regelmäßige Berichte zu Risiko- und Kontrollplänen.	Recht KMU Sicherheit KMU Datenschutz KMU	Die Datenschutzbestimmungen in ihren Richtlinien sind auf dem neuesten Stand. Datenersteller werden zeitnah über Richtlinienänderungen informiert. Das Management erhält zeitnah und regelmäßig Berichte zur Richtliniencompliance für alle veröffentlichten Datenprodukte.
Datenverwalter (d. h. innerhalb jeder Domain)	Codiert die von den Data Governance-Experten erstellten Richtlinien. Definiert und aktualisiert die Taxonomie, mit der eine Organisation Datenprodukte, Datenressourcen und Datenattribute mit erkennungsbezogenen und datenschutzbezogenen Metadaten annotiert. Koordiniert verschiedene Beteiligte innerhalb und außerhalb der jeweiligen Domain. Sorgt dafür, dass die Datenprodukte in ihrer Domain den Metadatenstandards und Datenschutzrichtlinien der Organisation entsprechen. Bietet Data Governance-Entwicklern Anleitungen zum Entwerfen und Priorisieren von Features für Datenplattformen.	Datenarchitektur Data Stewardship	Erforderliche Metadaten wurden für alle Datenprodukte in der Domain erstellt und die Datenprodukte für die Domain werden korrekt beschrieben. Die Self-Service-Dateninfrastruktur-Plattform erstellt die richtigen Tools, um Metadatenannotationen von Datenprodukten, Richtlinienerstellung und -überprüfung zu automatisieren.
Data Governance-Ingenieur	Entwickelt Tools, die automatisch Annotationen generieren und von allen Datendomains verwendet werden können. Diese Annotationen werden dann zur Durchsetzung der Richtlinien verwendet. Implementiert Monitoring, um die Konsistenz von Annotationen und Benachrichtigungen zu prüfen, wenn Probleme gefunden werden. Stellt sicher, dass Mitarbeiter in der Organisation durch die Implementierung von Benachrichtigungen, Berichten und Dashboards über den Status von Datenprodukten informiert werden.	Softwaretechnik	Data Governance-Annotationen werden automatisch verifiziert. Daten-Produkte entsprechen Data Governance-Richtlinien. Verstöße gegen Datenprodukte werden zeitnah erkannt.

Zentrales Team für die Self-Service-Dateninfrastrukturplattform

Das Self-Service-Dateninfrastrukturplattform-Team, oder nur das Datenplattformteam genannt, ist für die Erstellung einer Reihe von Komponenten der Dateninfrastruktur verantwortlich. Verteilte-Datendomain-Teams verwenden diese Komponenten, um ihre Datenprodukte zu erstellen und bereitzustellen. Das Datenplattformteam fördert auch Best Practices und führt Tools und Methoden ein, mit denen die kognitive Belastung für verteilte Teams reduziert werden kann, wenn neue Technologien eingeführt werden.

Die Plattforminfrastruktur sollte eine einfache Einbindung von Betriebstools ermöglichen, um globale Beobachtbarkeit, Instrumentierung und Complianceautomatisierung zu ermöglichen. Alternativ sollte die Infrastruktur eine solche Integration erleichtern, um verteilte Teams erfolgreich zu machen.

Das Datenplattformteam hat ein Modell der geteilten Verantwortung, das es mit den verteilten Domainteams und dem zugrunde liegenden Infrastrukturteam verwendet. Das Modell zeigt, welche Verantwortlichkeiten von den Nutzern der Plattform erwartet werden und welche Plattformkomponenten das Datenplattformteam unterstützt.

Da die Datenplattform selbst ein internes Produkt ist, unterstützt die Plattform nicht jeden Anwendungsfall. Stattdessen veröffentlicht das Datenplattformteam kontinuierlich neue Dienste und Funktionen gemäß einer priorisierten Roadmap.

Das Datenplattformteam verfügt möglicherweise über einen Standardsatz an Komponenten, die sich an Ort und Stelle und in der Entwicklung befinden. Data Domain-Teams können jedoch einen anderen, eindeutigen Satz von Komponenten verwenden, wenn die Anforderungen eines Teams nicht mit denen der Datenplattform übereinstimmen. Wenn Datendomainteams einen anderen Ansatz wählen, müssen sie sicherstellen, dass jede von ihnen erstellte und verwaltete Plattforminfrastruktur den organisationsweiten Richtlinien und Leitlinien für die Sicherheit und Data Governance entspricht. Bei der Datenplattform-Infrastruktur, die außerhalb des zentralen Datenplattformteams entwickelt wurde, kann das Datenplattformteam entweder seine eigenen Entwickler in die Domainteams ausleihen oder in die Domainteams einbetten. Ob das Team der Datenplattform sich für Ausleihen oder Einbetten von Entwicklern entscheidet, hängt möglicherweise von der strategischen Bedeutung der Datendomain-Plattforminfrastruktur für das Unternehmen ab. Über die Einbindung der Infrastruktur von Datendomainteams können Organisationen die erforderliche Ausrichtung und das technische Fachwissen einbringen, um alle neuen Infrastrukturinfrastrukturen zu verpacken, die für die zukünftige Wiederverwendung entwickelt werden.

Möglicherweise müssen Sie die Autonomie der frühen Phasen des Erstellens eines Data Mesh einschränken, wenn Ihr anfängliches Ziel darin besteht, Genehmigungen von Stakeholdern für die vertikale Skalierung des Data Meshs zu erhalten. Das Einschränken der Autonomie birgt jedoch Risiken, einen Engpass im zentralen Datenplattform-Team zu schaffen. Dieser Engpass kann die Skalierung des Data Mesh beeinträchtigen. Daher sollten Entscheidungen zur Zentralisierung sorgfältig getroffen werden. Für Datenersteller ist es möglicherweise besser, ihre technischen Auswahlen aus einer begrenzten Anzahl verfügbarer Optionen zu treffen, als selbst eine unbegrenzte Liste von Optionen zu evaluieren und auszuwählen. Die Autonomie der Datenersteller zu fördern, bedeutet nicht, dass eine unregulierte Technologielandschaft geschaffen wird. Stattdessen besteht das Ziel darin, die Compliance und die Plattformakzeptanz zu fördern, indem das richtige Gleichgewicht zwischen Wahlfreiheit und Standardisierung gefunden wird.

Ein gutes Datenplattformteam ist eine zentrale Quelle für die Weiterbildung und Best Practices für den Rest des Unternehmens. Einige der Aktivitäten mit den größten Auswirkungen, die wir für zentrale Datenplattformteams empfehlen, sind:

• Regelmäßige Überprüfung des Architekturdesigns für neue funktionale Projekte vorantreiben und Vorschlagen gängiger Entwicklungsmethoden über Entwicklungsteams hinweg
• Wissen und Erfahrungen teilen und Best Practices und Architekturrichtlinien gemeinsam definieren
• Sorgen Sie dafür, dass Entwickler die richtigen Tools haben, um gängige Stolperfallen und Probleme mit Code, Programmfehler und Leistungseinbußen zu validieren und darauf hin zu prüfen.
• Das Organisieren interner Hackathons, damit Entwicklungsteams ihre Anforderungen für interne Toolanforderungen publik machen können.

Beispielrollen und -Verantwortlichkeiten für das zentrale Datenplattformteam können Folgendes umfassen:

Rolle	Verantwortlichkeiten	Erforderliche Kenntnisse	Gewünschte Ergebnisse
Produktinhaber der Datenplattform	Schafft ein System von Dateninfrastrukturen und -Lösungen, mit denen verteilte Teams Datenprodukte entwickeln können. Senkt die technische Einstiegshürde, stellt sicher, dass Governance eingebunden ist, und minimiert die gemeinsame technische Last für die Dateninfrastruktur. Arbeitet mit Führungskräften, Inhabern von Datendomains, Data Governance-Teams und Technologieplattforminhabern zusammen, um die Strategie und Roadmap für die Datenplattform festzulegen.	Datenstrategie und -vorgänge Produktverwaltung Stakeholder-Management	Etabliert ein System erfolgreicher Datenprodukte. In der Produktion gibt es eine robuste Anzahl von Datenprodukten. Es gibt eine Reduzierung in der Zeit bis zum Minimum Viable Product und der Zeit bis zur Produktion für Datenprodukt-Releases. Ein Portfolio von allgemeinen Infrastrukturen und Komponenten ist vorhanden, das die häufigsten Anforderungen für Datenersteller und Datennutzer erfüllt. Datenersteller und Datennutzer haben einen hohen Zufriedenheitswert.
Daten Platform Entwickler	Erstellt wiederverwendbare Self-Service-Dateninfrastruktur und -Daten-Lösungen für die Datenaufnahme, -speicherung, -verarbeitung und -nutzung durch Vorlagen, bereitstellbare Architektur-Blueprints, Entwicklerleitfäden und andere Dokumentation. Außerdem werden Terraform-Vorlagen, Datenpipeline-Vorlagen, Containervorlagen und Orchestrierungstools erstellt. Entwicklung und Verwaltung zentraler Datendienste und Frameworks zur Standardisierung von Prozessen für funktionsübergreifende Bedenken wie Datenfreigabe, Pipelineorchestrierung, Logging und Monitoring, Data Governance, Continuous Integration und kontinuierliche Bereitstellung (CI/CD) mit eingebetteten Leitplanken, Sicherheits- und Compliance-Berichten und FinOps-Berichten.	Data Engineering Softwaretechnik	Es gibt standardisierte, wiederverwendbare Infrastrukturkomponenten und Lösungen, mit denen Datenersteller Daten aufnehmen, speichern, verarbeiten, kuratieren und weitergeben können, zusammen mit der notwendigen Dokumentation. Die Releases der Komponenten, Lösungen und der Endnutzerdokumentation entsprechen der Roadmap. Nutzer berichten von einer hohen Kundenzufriedenheit. Es gibt robuste freigegebene Dienste für alle Funktionen im Data Mesh. Bei freigegebenen Diensten gibt es eine hohe Verfügbarkeit. Die Supportantwortzeit ist kurz.
Plattform- und Sicherheitstechniker (ein Vertreter der zentralen IT-Teams, z. B. Netzwerke und Sicherheit, der in das Datenplattformteam eingebettet ist)	Stellt sicher, dass Datenplattformabstraktionen auf unternehmensweite Technologie-Frameworks und -Entscheidungen ausgerichtet sind. Unterstützt technische Aktivitäten durch den Aufbau der Technologielösungen und -dienste in ihrem Kernteam, die für die Bereitstellung der Datenplattform erforderlich sind.	Infrastrukturtechnik Softwaretechnik	Plattforminfrastrukturkomponenten werden für die Datenplattform entwickelt. Die Releases der Komponenten, Lösungen und der Endnutzerdokumentation entsprechen der Roadmap. Die zentralen Data Platform-Entwickler melden eine hohe Kundenzufriedenheit. Der Zustand der Infrastrukturplattform verbessert sich für Komponenten, die von der Datenplattform verwendet werden (z. B. Logging). Zugrunde liegende Technologiekomponenten haben eine hohe Verfügbarkeit. Wenn Daten Platform-Entwickler Probleme haben, ist die Reaktionszeit des Supports kurz.
Unternehmensarchitekt	Stimmt die Data-Mesh- und Datenplattformarchitektur auf die unternehmensweite Technologie und Datenstrategie ab. Bietet Beratungs- und Designautorität und Sicherheit für Datenplattform- und Datenproduktarchitekturen, um Ausrichtung auf die Strategie und die Best Practices auf Unternehmensebene zu gewährleisten.	Datenarchitektur Lösungsiteration und Problemlösung Konsenserstellung	Es wird ein erfolgreiches System erstellt, das eine robuste Anzahl von Datenprodukten enthält, für die die Zeit reduziert wird, um Minimum Viable Products zu erstellen und diese Produkte in der Produktion zu veröffentlichen. Architekturstandards wurden für kritische Datenwege eingerichtet, z. B. durch Festlegen gängiger Standards für die Metadatenverwaltung und Datenfreigabearchitektur.

Weitere Überlegungen zu einem Data Mesh

Es gibt mehrere Architekturoptionen für eine Analysedatenplattform, die jeweils unterschiedliche Voraussetzungen haben. Zum Aktivieren jeder Data Mesh-Architektur empfehlen wir, dass Ihre Organisation die in diesem Abschnitt beschriebenen Best Practices befolgt.

Plattformfinanzierung einwerben

Wie im Blogpost „If you want to transform start with finance“ erläutert, ist die Plattform nie abgeschlossen: Sie basiert immer auf einer priorisierten Roadmap. Daher muss die Plattform als Produkt finanziert werden, nicht als Projekt mit einem festen Endpunkt.

Der erste Nutzer des Data Mesh trägt die Kosten. Normalerweise werden die Kosten zwischen dem Unternehmen, das die erste Datendomain bildet, um das Data Mesh zu initiieren, und dem zentralen Technologieteam geteilt, in dem in der Regel das zentrale Datenplattformteam untergebracht ist.

Damit Finanzteams die Finanzierung für die zentrale Plattform genehmigen, empfiehlt es sich, für den Mehrwert der zentralisierten Plattform zu argumentieren, der im Laufe der Zeit realisiert werden wird. Dieser Wert ergibt sich aus der Neu-Implementierung der gleichen Komponenten in einzelnen Bereitstellungsteams.

Minimale funktionsfähige Plattform für das Data Mesh definieren

Damit Sie die minimal funktionsfähige Plattform für das Data Mesh definieren können, empfehlen wir Ihnen, einen oder mehrere Geschäftsfälle als Pilotprojekt durchzuführen und zu iterieren. Suchen Sie für Ihr Pilotprojekt nach benötigten Anwendungsfällen und für die es einen Kunden gibt, der bereit ist, das resultierende Datenprodukt zu übernehmen. Die Anwendungsfälle sollten bereits Finanzierung für die Entwicklung der Datenprodukte haben, aber es sollte ein Bedarf an Beiträgen von technischen Teams bestehen.

Das Team, das das Pilotprojekt implementiert, muss das Data Mesh-Betriebsmodell verstehen, das nun erläutert:

• Das Unternehmen (d. h. das Datenerstellerteam) ist Inhaber des Rückstands, des Supports und der Wartung.
• Das zentrale Team definiert die Self-Service-Muster und unterstützt das Unternehmen bei der Erstellung des Datenprodukts. Es übergibt das Datenprodukt jedoch an das Unternehmen, damit es fertig ausgeführt wird und fertig ist.
• Das Hauptziel ist der Beweis für das Geschäftsmodell (Domains erstellen, Domains konsumieren). Das sekundäre Ziel besteht darin, das technische Betriebsmodell zu bestätigen (Self-Service-Muster, die vom zentralen Team entwickelt wurde).
• Da die Ressourcen des Plattformteams begrenzt sind, verwenden Sie das Modell Trunk- und Branch-Teams, um Wissen zu bündeln, aber dennoch die Entwicklung spezialisierter Plattformdienste und -produkte zu ermöglichen.

Außerdem empfehlen wir Folgendes:

• Planen Sie Roadmaps, anstatt Dienstleistungen und Features auf natürliche Weise weiterzuentwickeln.
• Definieren Sie minimalen Funktionen für eine funktionsfähige Plattform, die Datenaufnahme, Speicherung, Verarbeitung, Analyse und ML umfassen.
• Betten Sie Data Governance in jeden Schritt ein, nicht als separaten Workstream.
• Richten Sie die Mindestfunktionen für Governance, Plattform, Wertstrom und Änderungsmanagement ein. Mindestfunktionen sind diejenigen, die 80 % der Geschäftsfälle erfüllen.

Koexistenz des Data Mesh mit einer vorhandenen Datenplattform planen

Viele Organisationen, die ein Data Mesh implementieren möchten, haben wahrscheinlich bereits eine Datenplattform, z. B. einen Data Lake, ein Data Warehouse oder eine Kombination aus beiden. Bevor ein Data Mesh implementiert wird, müssen diese Organisationen einen Plan für die Weiterentwicklung ihrer vorhandenen Datenplattform erstellen, wenn das Data Mesh dann wächst.

Diese Organisationen sollten Faktoren wie die folgenden berücksichtigen:

• Die Datenressourcen, die im Data Mesh am effektivsten sind.
• Die Assets, die auf der vorhandenen Datenplattform bleiben müssen.
• Ob Assets verschoben werden müssen oder ob sie auf der vorhandenen Plattform verwaltet werden können und dennoch Teil des Data Mesh sind.

Nächste Schritte

• Weitere Informationen zum Entwerfen und Betreiben einer Cloud-Topologie finden Sie unter Google Cloud-Architektur-Framework.
• Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.