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. Um ein solches gut funktionierendes Data-Mesh-Netzwerk zu erhalten, müssen Sie zuerst die übergeordneten Architekturkomponenten und organisatorischen Rollen einrichten, die in diesem Dokument beschrieben werden.

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. Obwohl es möglich ist, Data-Mesh-Architekturen so zu erweitern, dass Datenprodukte Dritten bereitgestellt werden können, wird dieser erweiterte Ansatz nicht in diesem Dokument besprochen. Die Erweiterung eines Data-Mesh-Netzwerks umfasst zusätzliche Aspekte, die über die Nutzung in einem Unternehmen hinausgehen.

Architektur

Die folgenden Schlüsselbegriffe werden zur Definition der in dieser Serie beschriebenen architektonischen Komponenten verwendet:

• 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 ergibt.
• Datenattribut: Ein Datenattribut ist ein Feld oder Element in einer Datenressource.

Das folgende Diagramm bietet einen Überblick über die wichtigsten Architekturkomponenten eines in Google Cloud implmentierten Data-Mesh-Netzwerks.

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 der Infrastruktur, die die Funktion des Data-Mesh-Netzwerks ermöglicht finden sich unter Plattformkomponenten und -lösungen erstellen.
• Zentrale Dienste stellen hauptsächlich den Data Catalog für die verschiedenen Datenprodukte im Data-Mesh-Netzwerk und den Erkennungsmechanismus für potenzielle Kunden dieser Produkte bereit.
• Datendomains machen Teilmengen ihrer Daten als Datenprodukte über klar definierte Datennutzungsschnittstellen verfügbar. Diese Datenprodukte könnten Tabellen, Ansichten, strukturierte Dateien, Themen oder Streams sein. In BigQuery wäre dies ein Datenset, in Cloud Storage wäre es 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 Oberflächentypen werden in Datenprodukte in einem Data-Mesh-Netzwerk erstellen diskutiert.

Data-Mesh-Referenzimplementierung

Eine Referenzimplementierung dieser Architektur finden Sie im data-mesh-demo-Repository. Die in der Referenzimplementierung verwendeten Terraform-Skripts demonstrieren Data-Mesh-Konzepte und sind nicht für den Produktionseinsatz vorgesehen. Wenn Sie diese Skripte ausführen lernen Sie Folgendes:

• Trennen der Produktdefinitionen von den zugrunde liegenden Daten.
• Data Catalog-Vorlagen zum Beschreiben von Produktoberflächen erstellen.
• Taggen von Produktoberflächen mit diesen Vorlagen.
• Produktnutzern Berechtigungen gewähren.

Bei Produktoberflächen erstellt und verwendet die Referenzimplementierung die folgenden Oberflächentypen:

• Autorisierte Ansichten auf BigQuery-Tabellen.
• Datenstreams, die auf Pub/Sub-Themen basieren.

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

Funktionen in einem Data-Mesh-Netzwerk

Damit ein Data Mesh gut funktioniert, müssen Sie klare Rollen für die Personen definieren, die Aufgaben im Data Mesh ausführen. Eigentümerschaft wird Team-Archetypen oder Funktionen zugewiesen. . Diese Funktionen erlauben das wichtigste Nutzerverhalten für Personen, die im Data Mesh arbeiten. Um Kundenerfahrungen klar zu beschreiben, wurden diese Nutzerrollen zugeordnet. Diese Nutzerrollen können je nach Situation des jeweiligen Unternehmens geteilt oder kombiniert werden. Sie müssen die Rollen nicht direkt Mitarbeitern oder Teams in Ihrer Organisation zuweisen.

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. Es ist wichtig zu verstehen, dass in der Regel beide Funktionen gleichzeitig von einer einzigen Datendomain bedient werden. Ein Datendomain-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.

Neben den domainbasierten Funktionen hat ein Data Mesh auch eine Reihe Funktionen, die von zentralisierten Teams im Unternehmen ausgeführt werden. Diese zentralen Teams ermöglichen den Betrieb des Data Mesh, indem sie domainübergreifende Einsichten, Services und Governance bereitstellen. 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. Es gibt noch einige weitere Rollen, die in jedem Unternehmen erforderlich sind, unabhängig von der für die Plattform eingesetzte Architektur. Diese anderen Rollen werden jedoch in diesem Dokument 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 oft als Datenersteller bezeichnet.
• Domainbasierte Daten-Nutzerteams: Ermitteln Sie Datenprodukte und verwenden Sie sie in verschiedenen Analyseanwendungen. Diese Teams können Datenprodukte aufnehmen, um neue Datenprodukte zu erstellen. Diese Teams werden oft als Datennutzer bezeichnet.
• Zentrales Data-Governance-Team: Definiert und erzwingt Data-Governance-Richtlinien unter Datenerstellern, was eine hohe Datenqualität und Vertrauenswürdigkeit der Daten für Verbraucher sichert. Dieses Team wird oft als Data-Governance-Team bezeichnet.
• Zentrales Team für die Self-Service-Dateninfrastrukturplattform: Bietet eine Self-Service-Datenplattform für Datenersteller. Dieses Team stellt auch Tools für die zentrale Datenerkennung und die Beobachtbarkeit von Datenprodukten bereit, die sowohl von Datennutzern als auch von Datenerstellern verwendet werden. Dieses Team wird oft als Datenplattformteam bezeichnet.

Eine optionale Zusatzfunktion, die Sie berücksichtigen sollten, ist die eines Kompetenzzentrums (Center of Excellence, COE) für das Data Mesh. Der Zweck eines COE besteht darin, die Datenverwaltung im Data Mesh zu ermöglichen. Das COE ist auch das vorgesehene Schiedgerichts-team, das Konflikte löst, die durch eine der anderen Funktionen ausgelöst wurden. Diese Funktion ist nützlich, um die anderen vier Funktionen zu verbinden.

Domainbasiertes Daten-Erstellerteam

In der Regel basieren Datenprodukte auf einem physischen Daten-Repository (ein oder mehrere Data Warehouses, Data Lakes oder Streams). Eine Organisation benötigt traditionelle Datenplattformrollen, um diese physischen Repositories zu erstellen und zu erhalten. Diese traditionellen Rollen für Datenplattformen sind jedoch in der Regel nicht identisch mit den 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 von Daten-Produzententeams 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 Produktmanagement	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	Dient als primärer technischer Ansprechpartner für das Produkt. Ist für die Implementierung und Veröffentlichung von Produktoberflächen 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.	Softwareentwicklung 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, ihren Produktumfang 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 die Erstellung interoperabler Datenprodukte, die mit dem allgemeinen Datenmodells des Unternehmens übereinstimmen. Es gibt klare Standards für die Erstellung von Datenprodukten und die Verwaltung des Lebenszyklus. 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. Leistet einen Beitrag zur Dokumentation des Datenprodukts.	Jegliche Fähigkeit, muss jedoch umfassende Kenntnisse der Geschäftsfunktion haben. 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 von funktionsübergreifenden Bereichen verwendet werden, sind korrekt. Stakeholder verstehen die Daten. Die Datennutzung erfolgt gemäß 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 Datenkonsumenten nutzen einen zentralen Data Catalog, 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 einen Anwendungsfall nicht finden können, liegt es in ihrer Verantwortung, sich direkt an das 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	Stellt Datenvisualisierungs-Experten saubere, kuratierte und aggregierte Datasets bereit. 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 für die Nutzung von Daten über einen oder mehrere Datenprodukte, 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 die Endnutzernutzung.
Fachkraft für Datenvisualisierung	Übersetzt die Data Engineering- und Datenanalyse-Fachsprache in Texte, die geschäftlichen Stakeholder verstehen können. Definiert Prozesse zum Ausfüllen von Geschäftsberichten mit Informationen aus Datenprodukten. Erstellt und überwacht Berichte zur Beschreibung strategischer Geschäftsziele. Arbeitet zusammen mit Entwicklern innerhalb der Organisation, um Datasets zu entwerfen, die aus genutzten Datenprodukten aggregiert werden. Implementiert Lösungen zur Berichterstellung. 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 von Domain-Geschäftsprozessen bereit. Bietet Feedback zu möglichen Methoden für die Datenkuration und Datenannotation für mehrere Datendomains.	ML Entwicklung Analyseentwicklung	Erstellt prädiktive und präskriptive Modelle zur Optimierung der Geschäftsprozesse. Das Modelltraining und die Modellbereitstellung erfolgen pünktlich.

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-Fachkraft	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äßig Berichte zu Risiken- und Kontrollplänen.	Recht KMU Sicherheit KMU Datenschutz KMU	Die Datenschutzbestimmungen in Richtlinien sind auf dem neuesten Stand. Datenersteller werden rechtzeitig ü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)	Kodiert 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	Die erforderlichen 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 Engineer	Entwickelt Tools zur automatischen Generierung von Daten-Annotationen, die von allen Datendomains verwendet werden können, und nutzt diese Annotationen zur Durchsetzung der Richtlinien. Implementiert Monitoring, um die Konsistenz von Annotationen und Warnungen beim Auftreten von Problemen zu prüfen. 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-Anmerkungen werden automatisch geprüft. Daten-Produkte entsprechen Data Governance-Richtlinien. Verstöße gegen Datenprodukte werden rechtzeitig 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 Datenplattform-Team nutzt ein Modell der gemeinsamen Verantwortung zusammen mit dem Team für verteilte Domains und dem Team der zugrunde liegenden Infrastruktur. 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 sie nicht alle Anwendungsfälle. Stattdessen veröffentlicht das Datenplattform-Team 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.

In den frühen Phasen der Erstellung eines Data Mesh müssen Sie möglicherweise die Autonomie einschränken, wenn es Ihr anfängliches Ziel ist, die Genehmigung der Stakeholder für die Vergrößerung des Data Mesh einzuholen. 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. Zentralisierungsentscheidungen sollten 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 Produktmanagement Stakeholder-Management	Etabliert ein Ökosystem 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. Erstellt außerdem Terraform-Vorlagen, Datenpipeline-Vorlagen, Containervorlagen und Orchestrierungstools. 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. Releases von Komponenten, Lösungen und Endnutzerdokumentation an der Roadmap ausrichten. Nutzer berichten von einer hohen Kundenzufriedenheit. Es gibt robuste gemeinsame Dienste für alle Funktionen im Data Mesh. Bei freigegebenen Diensten gibt es eine hohe Verfügbarkeit. Die Antwortzeit des Supports ist kurz.
Platform and Security Engineer (ein Vertreter des zentralen IT-Teams, z. B. im Bereich Netzwerk oder Sicherheit, der in das Datenplattformteam eingebunden ist)	Stellt sicher, dass Datenplattform-Abstraktionen mit unternehmensweiten Technologie-Frameworks und -Entscheidungen abgestimmt sind. Unterstützt technische Aktivitäten durch Entwicklung der Technologielösungen und -dienste im Kernteam, die für die Bereitstellung der Datenplattform erforderlich sind.	Infrastrukturtechnik Softwaretechnik	Plattform-Infrastrukturkomponenten werden für die Datenplattform entwickelt. Releases von Komponenten, Lösungen und Endnutzerdokumentation an der Roadmap ausrichten. Die Entwickler der zentralen Datenplattform 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 Konsensbildung	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 zum Data Mesh

Es gibt mehrere Architekturoptionen für eine Analysedatenplattform, die jeweils unterschiedliche Voraussetzungen haben. Wir empfehlen, dass Ihre Organisation bei allen Data-Mesh-Architekturen 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. Entsprechend muss die Plattform als Produkt und nicht als Projekt mit einem festen Endpunkt finanziert werden.

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, übergibt dieses nach Abschluß der Erstellung aber an da Unternehmen, das es dann ausführt und besitzt.
• 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.
• Bestimmen Sie die Mindestfunktionen für Governance, Plattform, Wertstrom und das Veränderungsmanagement. Mindestfunktionen sind diejenigen, die 80 % der Geschäftsfälle erfüllen.

Die parallele Bereitstellung des Data Mesh mit einer bestehenden 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 Unternehmen sollten unter anderem die folgenden Faktoren 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.