Aufbau eines ereignisgesteuerten Datennetzes

Kapitel 4. Föderale Verwaltung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Datengeflecht-Architekturen sind von Natur aus dezentralisiert, und die Verantwortung wird weitgehend an die Eigentümer der Datenprodukte delegiert. Ein Datengeflecht profitiert auch von einem gewissen Grad an Zentralisierung in Form von Kompatibilität der Datenprodukte und gemeinsamen Self-Service-Tools. Unterschiedliche Meinungen, Präferenzen, geschäftliche Anforderungen, rechtliche Beschränkungen, Technologien und technische Schulden sind nur einige der vielen Faktoren, die unsere Zusammenarbeit beeinflussen.

Die föderale Governance ermöglicht es uns, die Entscheidungen, die auf lokaler Ebene getroffen werden sollten, von denen zu trennen, die global und für alle Bereiche getroffen werden müssen. Um Dehghani zu zitieren: "Letztlich haben globale Entscheidungen nur einen Zweck: die Schaffung von Interoperabilität und eines Netzwerkeffekts durch die Entdeckung und Zusammenstellung von Datenprodukten." Wir müssen die gemeinsamen Bausteine und Arbeitsweisen herausfinden, durchsetzen und unterstützen, damit das Datennetz für alle funktioniert.

Die Gründung eines föderalen Governance-Teams ist einer der ersten Schritte, um eine gemeinsame Basis für die Arbeit an für beide Seiten vorteilhaften Lösungen zu finden. Die genauen Aufgaben deines Governance-Teams hängen von deinen eigenen geschäftlichen Anforderungen ab, aber es gibt einige allgemeine Aufgaben, die wir in diesem Kapitel behandeln.

Beim föderalen Regieren geht es darum, ein Gleichgewicht zwischen individueller Autonomie und zentraler Kontrolle von oben nach unten zu finden, zwischen der Delegation von Verantwortung und der Schaffung von übergreifenden Regeln und Richtlinien für Konsistenz und Ordnung. Wie bei jeder effektiven Regierungsform brauchen wir Partizipation, Repräsentation, Diskussionen und gemeinsames Handeln, um etwas zu erreichen.

Tipp

Die Erstellung einer Charta ist ein wichtiger erster Schritt bei der Gründung eines föderalen Governance-Teams. Darin werden die Aufgaben und Zuständigkeiten der Gruppe festgelegt, z. B. die Festlegung von Standards für Datenproduktformate, Qualitätsstufen, Interoperabilität, Sicherheit und unterstützte Technologien. Außerdem werden die Verantwortlichkeiten von Produzenten, Konsumenten und Managern sowie alle anderen sozialen und technischen Aspekte festgelegt.

Die föderale Verwaltung konzentriert sich in erster Linie auf mehrere Hauptbereiche:

Daten Bedenken

Bezieht sich darauf, wie Daten erstellt und innerhalb einer Organisation verwendet werden. Konkret geht es um Datenprodukttypen, Metadaten, Schemata, Unterstützung, Auffindbarkeit, Abstammung, Qualität und Interoperabilität.

Bedenken hinsichtlich der Technologie

Dazu gehören Programmiersprachen, Frameworks und Prozesse, die du in dein Datennetz einbinden möchtest. Die Bewertung deiner bestehenden Technologien auf ihre Eignung und die Prüfung neuer Optionen ist ein wichtiger Bestandteil der föderalen Verwaltung.

Rechtliche, geschäftliche und sicherheitstechnische Bedenken

Bezieht sich auf die Einhaltung gesetzlicher Vorschriften und Sicherheitsprobleme, wie z.B. der Umgang mit Finanzdaten, personenbezogenen Daten und anderen sensiblen Daten. Auch Anforderungen auf Unternehmensebene können eine Rolle spielen, z. B. interne Datensicherheit, Zugriffsrichtlinien und Aufbewahrungspflichten.

Anliegen der Selbstbedienungsplattform

Macht es deinen Nutzern leicht, das Richtige zu tun. Die Nutzer/innen brauchen eine zuverlässige Selbstbedienungsplattform , um Datenprodukte zu erstellen und zu nutzen. Die Vereinfachung von Werkzeugen, die Verringerung von Reibungsverlusten und die Erleichterung der Arbeit für alle sind die Grundpfeiler von Data Mesh. Eine Selbstbedienungsplattform bietet die Möglichkeit, regulatorische und sicherheitsrelevante Richtlinien an der Quelle anzuwenden und einen Einblick in den Datenfluss im Unternehmen zu erhalten.

Jeder dieser Bereiche steht in Beziehung zueinander und bietet eine hilfreiche Linse, durch die du die Prioritäten für dein Governance-Team betrachten kannst. Behalte diese vier Bereiche im Hinterkopf, wenn wir den Rest des Kapitels durchgehen, denn jeder Abschnitt wird sich mit einem oder mehreren dieser Hauptanliegen befassen.

Aber zuerst: Wer darf regieren?

Bildung eines föderalen Governance-Teams

Ein Governance-Team braucht ein Mandat, um seine Arbeit effektiv zu gestalten. Ein Mandat umfasst zwei Hauptkomponenten. Die erste ist eine institutionelle Komponente, bei der die "Oberen" das Datennetz und das Governance-Team unterstützen und den Mitgliedern ein gewisses Maß an Autorität, Eigentum und Verantwortung übertragen. Die zweite Komponente ist eine soziale Komponente, bei der diejenigen, die das Datennetz nutzen sollen, seine Bedeutung erkennen und sich dafür einsetzen. Fehlt eine der beiden Komponenten, wird die Initiative wahrscheinlich fehlschlagen.

Das Governance-Team setzt sich zusammen aus Mitarbeitern aus dem gesamten Unternehmen, die als Vertreter der Teams, Produkte, Technologien und Prozesse fungieren, die für den Aufbau und die Unterstützung eines gut definierten Datennetzes erforderlich sind. Als Vertreter ihrer Kollegen bringt jedes Mitglied Ideen, Anforderungen und Bedenken aus seinem Problembereich ein und arbeitet gemeinsam an einer zufriedenstellenden Lösung.

Vertreter/innen zu finden, ist oft so einfach, wie nach einem Freiwilligen zu fragen, der das Team für einen bestimmten Zeitraum (z.B. drei Monate) vertritt, obwohl er/sie sich mit den Herausforderungen, denen das Team gegenübersteht, gut auskennen muss. Oft werden erfahrene Techniker/innen für diese Rolle ausgewählt, da sie die Bedürfnisse des Teams, den Problembereich und historische Zusammenhänge, wie frühere Reformversuche, am besten kennen. Es gibt oft wichtige technische Gründe, warum frühere Reformversuche fehlgeschlagen sind, und dieser historische Kontext hilft oft dabei, einen Weg zu einer neuen erfolgreichen Lösung zu finden.

Die Größe des föderalen Steuerungsteams hängt von der Größe der Organisation ab, sollte aber so bemessen sein, dass ein effektives einstündiges Treffen möglich ist. Wenn die Gruppe zu klein ist, kann es passieren, dass ihr nicht ausreichend vertreten seid, was zu einer Entfremdung der Teamkollegen führt und das Vertrauen und die Unterstützung beeinträchtigt. Bei einer zu großen Gruppe kann es passieren, dass die Teilnehmer/innen das Gefühl haben, dass ihr Beitrag nicht wirklich wichtig ist oder dass jemand anderes in der Gruppe die schwierigen Entscheidungen treffen wird. Die optimale Größe des föderalen Steuerungsteams zu finden, ist - vielleicht ironischerweise - Sache des föderalen Steuerungsteams. Fange klein an und nimm ruhig mehr Mitglieder auf, wenn du an die Grenzen der Repräsentation stößt.

Tipp

Sammle anonymes Feedback darüber, wie die Gruppe denkt, dass sie funktioniert, sowie Feedback von Teamkollegen und Stakeholdern außerhalb der Gruppe. Dies wird der Gruppe helfen, effektivere Treffen abzuhalten, angemessene Grenzen für die Bereiche der Leitung zu finden und eine effektive Gruppengröße und Satzung festzulegen.

Sobald du ein erstes Gremium hast, kannst du damit beginnen, Standards zu implementieren, um das Datengeflecht zu optimieren.

Umsetzung der Standards

Das föderale Governance-Team ist dafür verantwortlich, eine Reihe von Datenprodukt- und Technologiestandards zu entwickeln. Stell dir die Technologien, die dein Unternehmen unterstützen muss, wie einen Werkzeugkasten mit begrenztem Platz vor. Wenn du den Werkzeugkasten um neue Werkzeuge erweitern willst, musst du sicherstellen, dass der Platz ausreicht und dass es keine anderen geeigneten Werkzeuge gibt, die die Aufgabe genauso gut erledigen können. Eine vernünftige Begrenzung des Werkzeugkastens sorgt dafür, dass der technologische Wildwuchs eingedämmt wird und dass nur Werkzeuge hinzugefügt werden, die eine wesentliche Verbesserung darstellen.

Tipp

Die Errichtung von Einstiegshürden für neue Tools, Sprachen, Standards und Technologien ist wichtig, um den Wildwuchs zu reduzieren, marginale Optionen auszuschließen und sich vor "Allerweltsimplementierungen" zu schützen. Wenn du deinen Werkzeugkasten klein und schlank hältst, ist es viel einfacher, erstklassigen Support für jedes Werkzeug in deiner Self-Service Data Mesh Plattform anzubieten.

Standards sollten per Vorschlag eingeführt werden, mit einer detaillierten Erklärung, warum die neue Option besser ist als das, was bereits im Werkzeugkasten vorhanden ist. Eine neue Option kann einen dringend benötigten Anwendungsfall abdecken, für den es in der Toolbox nichts gibt. Oder die neue Option ist kategorisch besser als etwas, das bereits im Einsatz ist. Der Vorschlagende muss eine Geschichte erzählen und mit Beispielen belegen, warum seine Empfehlung gut ist und welche Auswirkungen sie auf die Auswahl der Werkzeuge und Optionen hat.

Es ist sehr wichtig, einen vorgeschlagenen Standard oder eine Technologie zu testen, bevor ihr sie in euren erstklassigen, sanktionierten Werkzeugkasten aufnehmt. Achte darauf, dass die Erprobung die Bedeutung der Technologie hervorhebt, dass sie besser ist als etwas, das es bereits gibt, und welche Kompromisse sie angesichts der aktuellen Werkzeuge und Unterstützung mit sich bringt.

Warnung

Achte darauf, dass Testsysteme nicht "vorübergehend" (aber in Wirklichkeit dauerhaft) in die Produktion überführt werden. Es ist wichtig, neue Technologien und Frameworks in Systemen außerhalb des kritischen Pfads zu testen, damit du sie umschreiben oder aufgeben kannst, ohne dass es zu Verzögerungen im Betrieb kommt.

Gehen wir einige der wichtigsten Standards durch, die dein Governance-Team festlegen muss.

Unterstützung von multimodalen Daten Produkttypen

Wie bereits in "Datenprodukte sind multimodal" beschrieben , muss dein federated governance Team entscheiden, welche Datenprodukttypen und Ports du unterstützt und welche nicht. Ereignisströme sind der wichtigste Datenprodukttyp, der in diesem Buch behandelt wird, aber du kannst auch andere unterstützen, wie z. B. stapelweise berechnete Parquet-Dateien in einem Cloud-Datenspeicher, auf die wir in Kapitel 9 näher eingehen werden.

Die Unterstützung mehrerer Datenprodukttypen bietet den Eigentümern von Datenprodukten zusätzliche Optionen, geht aber auf Kosten einer deutlich höheren Komplexität für die Governance- und Self-Service-Tools. Es ist wichtig, die Opportunitätskosten und den Arbeitsaufwand zu verstehen, der für die Unterstützung der einzelnen Datenprodukttypen erforderlich ist.

So musst du zum Beispiel sicherstellen, dass Sicherheit, Verschlüsselung, Zugriffskontrollen, Interoperabilität der Datenprodukte und die Integration von Self-Service-Datenplattformen berücksichtigt werden. Es kann viel Arbeit bedeuten, einen neuen Datenprodukttyp hinzuzufügen, und wenn sich diese Investition nur geringfügig auszahlt, kann es sinnvoller sein, das Datenprodukt stattdessen mit einem bestehenden (wenn auch etwas suboptimalen) Typ bereitzustellen.

Wenn du der Meinung bist, dass die Unterstützung eines neuen Datenprodukttyps sinnvoll ist, solltest du einen Vorschlag erstellen und ihn auf der Verbandsversammlung zur Diskussion stellen. Mehr über Vorschläge erfährst du unter "2. Vorschläge verfassen".

Das Ziel ist nicht, die Eigentümer von Datenprodukten einzuschränken, sondern sicherzustellen, dass die zur Verfügung gestellten Tools unterstützt werden, den Governance-Anforderungen entsprechen, einfach zu nutzen sind und die notwendigen Geschäftsfälle abdecken. Füge der Toolbox keine neuen Tools um der Vielfalt oder Neuartigkeit willen hinzu, vor allem, wenn es bestehende und gut unterstützte Möglichkeiten gibt, ausreichenden Zugang und Nutzung zu bieten.

Unterstützende Datenproduktschemata

Schema-Frameworks sind praktisch Programmiersprachen für Daten. Genauso wie du eine Anwendung mit Code komponierst, komponierst du ein Datenproduktschema mit seinem eigenen Code. Wie dieser Code genau aussieht und welche Optionen du am besten wählst, wird in Kapitel 6 näher erläutert. Überlege dir zunächst, wie viele und welche Art von Schemata und Formaten du unterstützen willst. Zu den zwei häufigsten Überlegungen gehören:

Ereignis-Schemata

Apache Avro, Protocol Buffers (Protobuf) und JSON Schema sind die am häufigsten verwendeten Formate für Ereignisse. Jedes dieser Formate hat seine eigenen Kompromisse, insbesondere in Bezug auf die Durchsetzung von Typen, die Möglichkeiten der Schemaentwicklung, Standardwerte, Aufzählungen und die Dokumentation.

Dateiformate

Stapeldateien, die in eine Cloud Speicherung Bucket geschrieben werden, folgen traditionell den Konventionen für Big Data-Dateien, wie CSV, JSON, Avro, Protocol Buffers, Parquet undORC - um nur einige zu nennen. Außerdem gibt es neuere Open-Source-Technologien, die auf diesen grundlegenden Dateiformaten aufbauen, wie Apache Iceberg, Apache Hudi und Delta Lake. Jede dieser Technologien bietet dateisystemähnliche Funktionen auf höherer Ebene, wie z. B. verstecktePartitionierung, Transaktionen und Verdichtung, und kann die Verwendung vonBatch-hosted Datenprodukten einfacher machen, allerdings auf Kosten einer engeren Kopplung an dieTechnologie.

Am besten ist es, wenn du dich auf ein einziges Ereignisschema oder Dateiformat für jeden Datenprodukttyp festlegst. Zum Beispiel Avro für Streams und Parquet für batch-berechnete Dateien in deinem Data Lake. Erweitere die Unterstützung anderer Formate nur, wenn es absolut notwendig ist. Ein einziges Format vereinfacht die Werkzeuge und das Nutzererlebnis erheblich und hält gleichzeitig die Komplexität und das Risiko gering.

Tipp

Wenn du mehrere Dateiformate oder Ereignisschemata unterstützen musst, stelle sicher, dass die Eigentümer von Datenprodukten leicht verständliche Anweisungen finden, welches Schema sie verwenden sollten und warum. Wenn du das nicht tust, kommt es zu Reibungsverlusten, wenn benachbarte Teams ihre Datenprodukte mit völlig unterschiedlichen Schemata implementieren, was die Nutzung und Verwendung für die gemeinsamenKunden erschwert.

Als Nächstes wollen wir uns einige der Fragen und Bedenken zur Programmiersprache ansehen.

Unterstützende Programmiersprachen und Frameworks

Ein gängiger Ansatz für die Erstellung von Datenprodukten ist die Verwendung einer Sprache, die bereits in der Quelldomäne verwendet wird. Das Team ist dann bereits mit dieser Sprache vertraut, was sowohl die Erstellung als auch den Support des Datenprodukts vereinfacht. Eine andere Möglichkeit ist, eine Sprache (oder ein Tool) zu wählen, die/ das in einem anderen Teil des Unternehmens verwendet wird, weil sie/es sich vielleicht besser für die Erstellung des Datenprodukts eignet. In Kapitel 8 werden wir uns mit den Besonderheiten des Bootstrappings bestehender Daten in ereignisgesteuerte Datenprodukte befassen.

Manchmal nutzen Entwickler die Erstellung von Datenprodukten als Gelegenheit, um eine neue esoterische Sprache auszuprobieren, unabhängig davon, ob sie offiziell unterstützt wird. Damit ist dieser Entwickler bis weit in die Zukunft hinein für Support und Wartung verantwortlich und das Produkt ist gefährdet, wenn niemand anderes die Sprache erlernt. Mit der Zeit wird der Entwickler, der das Datenprodukt entwickelt hat, wahrscheinlich zu neuen Projekten oder Arbeitsmöglichkeiten wechseln, was das Risiko weiter erhöht.

Es ist wichtig, dass du nur Datenprodukte in Sprachen einführst, die gut genutzt werden oder von deiner Organisation offiziell unterstützt werden. Wenn du der Meinung bist, dass eine Sprache es wert ist, breiter eingesetzt zu werden, solltest du einen Vorschlag erstellen (siehe "2. Entwerfen von Vorschlägen") und ihn mit dem föderalen Governance-Team diskutieren.

Die Entscheidung, welche Sprachen (und Frameworks) für die Erstellung von Datenprodukten unterstützt werden sollen, basiert größtenteils auf denselben Kriterien wie die Erstellung jedes anderen Dienstes. Zu diesen Faktoren gehören:

Soziale Faktoren

Ist es eine bekannte Technologie? Sind unsere Entwickler mit ihr vertraut? Gibt es andere in der Branche, die sie verwenden, und haben sie damit Erfolg? Werden die Leute mit ihr arbeiten wollen? Wird sie für neue Mitarbeiter/innen attraktiv sein und können wir Mitarbeiter/innen mit diesen Fähigkeiten auf dem Markt finden?

Technologie-Faktoren

Löst sie unsere Probleme auf einfache und effektive Weise? Handelt es sich um eine bewährte Technologie, die auch in den kommenden Jahren weiterentwickelt und verbessert werden kann?

Integrationsfaktoren

Ist es einfach zu unterstützen? Lässt sie sich gut in unsere bestehenden Entwicklungs-, Test-, Build- und Deployment-Pipelines integrieren? Gibt es Linters, Debugger, Speicheranalysatoren, Testwerkzeuge und andere Tools zur Produktivitätssteigerung, die sich damit integrieren lassen?

Event Broker Kunden

Verfügt dein Event Broker über leistungsstarke Clients, die in der Sprache deiner Wahl geschrieben sind? Kannst du Veranstaltungen schnell genug produzieren und konsumieren?

Unterstützende Werkzeuge

Funktionieren deine Sprache und dein Framework gut mit deinen Ereignisschemata(Kapitel 6)? Unterstützen sie Codegeneratoren? Kannst du Testevents erzeugen, um die Ein- und Ausgaben deiner Datenprodukte zu testen?

Die Entscheidung, welche Sprachen unterstützt werden sollen und wie umfangreich die Unterstützung sein soll, liegt bei deiner Organisation und deinem Governance-Team. Wähle Sprachen, mit denen dein Unternehmen vertraut ist und die Event-Broker unterstützt.

Standards und Anforderungen für Metadaten

Ein gutes Datennetz erfordert gut definierte Metadaten für jedes Datenprodukt. Die Nutzer des Datennetzes sollten in der Lage sein, die Datenprodukte, die sie für ihre geschäftlichen Anwendungsfälle benötigen, zu finden und zu identifizieren ( ). Der Eigentümer eines Datenprodukts muss bei der Registrierung des Datenprodukts alle erforderlichen Metadaten angeben, um das Datenprodukt im Netz veröffentlichen zu dürfen. Die Durchsetzung der Metadatenanforderungen ist wichtig, um sicherzustellen, dass nur gut definierte und gut unterstützte Datenprodukte anderen zur Verfügung gestellt werden, damit wir nicht die Fehler früherer Datenstrategien wiederholen, wie sie in "Schlechte Daten: Die Kosten der Untätigkeit" beschrieben.

Es gibt mehrere Bereiche, die für ein gesundes Datengeflecht wichtig sind. In diesem Abschnitt gehen wir auf jedes dieser Felder ein und geben dir einige grundlegende Beispiele, die du für dein eigenes Governance-Team berücksichtigen kannst.

Domain und Besitzer

Der erste Punkt ist das Eigentum. Wem gehört das Datenprodukt? Und woher stammt es? Zu diesen Metadaten gehören der Namensraum der Domäne und der Name des Besitzers des Datenprodukts. Der Name des Datenprodukteigentümers ist eine einzelne Person, die das Datenprodukt aus dieser Domäne vertritt.

Gestaffelte Servicelevel

Ein Datenprodukt braucht Unterstützung und Betriebszeitgarantien. Aber in welchem Umfang? Wenn das Datenprodukt ausfällt, welche ist die angemessene Vorgehensweise? Viele Unternehmen organisieren ihre Anwendungen bereits in einem abgestuften System, wobei die höchste Stufe einen 24-Stunden-Rufbereitschaftsdienst und die niedrigste Stufe einen einfachen Best-Effort-Support bietet. Du solltest dasselbe System auf Datenprodukte anwenden und denselben Support und dieselben Garantien bieten wie für jede andere Dienstleistung oder jedes andere Produkt der gleichen Stufe. Im Folgenden findest du ein Beispiel für ein vierstufiges System:

Stufe 1

Datenprodukte, die für den Betrieb deines Unternehmens von entscheidender Bedeutung sind und bei denen ein Ausfall oder eine Störung erhebliche Auswirkungen auf den Kunden oder die Finanzen des Unternehmens hat. Datenprodukte, die betriebliche Echtzeitanwendungen unterstützen, fallen oft in diese Kategorie.

Stufe 2

Datenprodukte, die für das Unternehmen wichtig, aber weniger kritisch als Tier 1 sind. Ein Ausfall in dieser Stufe kann zu einer Beeinträchtigung des Kundenerlebnisses führen, verhindert aber nicht, dass die Kunden mit deinem System interagieren können. Die Datenprodukte dieser Ebene werden oft auch für betriebliche Echtzeitanwendungen genutzt.

Stufe 3

Datenprodukte, die sich auf Hintergrundaufgaben und -vorgänge im Unternehmen auswirken können, aber für die Verbraucher wahrscheinlich nicht sichtbar sind und sie nicht wesentlich beeinträchtigen. Ein Ausfall auf dieser Ebene kann aber dennoch ein Eingreifen erfordern, wenn das Datenprodukt zeitkritische Anwendungsfälle unterstützt.

Stufe 4

Datenprodukte, die das größte Zeitfenster für die Wiederherstellung haben. Für diese Datenprodukte ist ein Bereitschaftsdienst nicht unbedingt erforderlich; sie können bis zum nächsten Arbeitstag warten, um gelöst zu werden.

Betriebszeit und Verfügbarkeit sind nicht die einzigen Faktoren, die beim Service Level eines Datenprodukts eine Rolle spielen. Du musst deine Datenprodukte auch überwachen, um sicherzustellen, dass sie ihre SLAs einhalten. Darauf gehen wir im Abschnitt "Überwachung und Alarmierung" näher ein.

Klassifizierungen der Datenqualität

Die Qualität der Daten, die von bereitgestellt werden, sollte ebenfalls kategorisiert werden, ähnlich dem Ansatz des SLA-Tier-Systems. Eine Möglichkeit ist es, die Medaillenklassifizierungen Bronze, Silber und Gold zu nutzen, die häufig in Data Lake-Architekturen verwendet werden. Schauen wir uns die einzelnen Klassifizierungen an:

Bronze

Unstrukturierte und rohe Daten, die nicht aus dem ursprünglichen Quellformat umgewandelt wurden. Sie können stark an das interne Datenmodell des Quellsystems gekoppelt sein und Felder enthalten, die bereinigt oder gesäubert werden müssen. Es können auch Daten enthalten sein, die gut strukturiert und definiert sind, deren Qualität aber unregelmäßig ist oder für die die Dateneigentümer einfach keine höhere Garantie geben können.

Silber

Gut strukturierte Daten mit starker Typisierung und in der Regel bereinigt und standardisiert. Normalerweise sind die Daten so denormalisiert, dass sie in ihrem jetzigen Zustand hinreichend nützlich sind, wobei die häufigsten Beziehungen zwischen Fremdschlüsseln verbunden und aufgelöst wurden, um die Nutzung für die Verbraucher zu erleichtern. Es wurden Typprüfungen und Einschränkungen vorgenommen, um ein Mindestmaß an Datenqualität zu gewährleisten (z. B. bestehen 99,99 % der Ereignisse die Qualitätsprüfungen). Der Kontext des Ereignisses ist klar definiert und dokumentiert, ebenso wie die Typprüfungen und Einschränkungen. Wenn ein Verbraucher seine eigenen, strengeren Beschränkungen für die Daten festlegen möchte, sollte er sich am besten mit dem Eigentümer des Datenprodukts in Verbindung setzen, um die Möglichkeiten zu prüfen.

Gold

Die höchste Qualitätsstufe. Datenprodukte mit der Qualitätsstufe Gold ( ) werden oft als "verbindlich" bezeichnet und sind so konzipiert, dass man sich uneingeschränkt auf sie verlassen kann. Die Datenprodukte werden streng geprüft und überwacht, wobei die Typenprüfung und die Einschränkungen die der Silber-Qualitätsstufe übertreffen (z. B. bestehen 99,9999 % der Ereignisse die Qualitätsprüfungen). Gold-Datenprodukte sind oft komplexer und bestehen aus umfangreichen Aggregationen und Transformationen, die einen erheblichen Mehrwert bieten und von den Verbrauchern nur schwer selbst repliziert werden können.

Hinweis

Die Klassifizierung der Datenqualität ist getrennt von der Klassifizierung der Datenprodukte (quellenorientiert, aggregatorientiert und verbraucherorientiert) und befasst sich nur mit der Datenqualität.

Es steht dir frei, alternative Klassifizierungsmodelle zu wählen, wie du es für richtig hältst. Wichtig ist nur, dass die Nutzer/innen deines Datennetzes die Modellierung leicht verstehen und auf ihre eigenen Datenprodukte anwenden können, damit ein gemeinsames Verständnis zwischen Datenproduzenten und -konsumenten gewahrt bleibt.

Datenschutz, Finanzen und benutzerdefiniertes Tagging

In Zusammenarbeit mit Sicherheits- und Finanzverantwortlichen kann das Governance-Team Tags für Datenprodukte entwickeln, um die spezielle Behandlung zu automatisieren. Du kannst zum Beispiel ein abgestuftes System für Sicherheitsklassifizierungen einführen, ähnlich wie bei den SLAs. Du kannst auch Tags verwenden, die sich auf die Art der im Ereignisstrom enthaltenen Daten beziehen, wie z. B. Finanzdaten, personenbezogene Daten oder regionsbezogene Tags.

Die Unterstützung von Tags auf Datenprodukten erleichtert die Anwendung von Governance-Regeln, da sie für jedes einzelne Tag angewendet werden können. Ein Verbraucher, der ein Datenprodukt mit einem Finanz-Tag nutzen möchte, muss zum Beispiel nachweisen, dass er die Anforderungen seines Unternehmens an den Umgang mit Finanzdaten erfüllt. Tags ermöglichen auch eine einfachere Überprüfung der Datennutzung auf Verbraucherbasis.

Abhängigkeiten von vorgelagerten Metadaten

Vorgelagerte Dienste und Datenprodukte haben jeweils ihre eigenen SLAs, Datenqualitätsstufen und andere Garantien. Jeder Dienst oder jedes Datenprodukt, das von vorgelagerten Diensten oder Datenprodukten abhängt, muss diese Abhängigkeiten berücksichtigen, wenn er seine eigenen Garantien festlegt. So kann ein Dienst beispielsweise keinen Tier-1-Support anbieten, wenn er von Datenprodukten mit Tier-4-Garantien abhängt. Wir werden später in diesem Kapitel unter "Datenproduktabhängigkeit" mehr über die Abhängigkeit erfahren .

Als Teil deiner Governance-Anforderungen kannst du Mindestanforderungen an die Datenqualität und SLAs für deine Produktionsanwendungen festlegen, unabhängig davon, ob es sich um operative, analytische, Service- oder Datenproduktanwendungen handelt. Eine gängige Konvention ist es, nur Dienste mit Tier-1- oder Tier-2-SLA-Garantien für die Produktion zuzulassen.

Die Anforderungen an die vorgelagerte Datenqualität sind nicht ganz so streng - es ist durchaus möglich, dass du ein Tier-1-Gold-Datenprodukt mit einem Tier-1-Bronze-Datenprodukt betreiben kannst. Tatsächlich werden Bronze-Daten in der Regel auf diese Weise in ein hochwertiges Gold-Datenprodukt umgewandelt.

Du kannst bei der Erstellung eines Datenprodukts vorgelagerte Prüfungen erzwingen, wie wir in Kapitel 5 näher erläutern werden.

Beispiel für die Zusammenfassung von Metadaten

Abbildung 4-1 zeigt ein Beispiel ( ) für das, was ein Nutzer sehen kann, wenn er Informationen über ein Datenprodukt nachschlägt. In Kapitel 5 werden wir uns eingehender mit der Katalogisierung von Metadaten befassen, aber im Moment kannst du sie dir wie eine schreibgeschützte Datenbank vorstellen, in der du die verfügbaren Datenprodukte und ihre Eigenschaften nachschlagen kannst.

Der Name des Datenprodukts, der Bereich und der Nutzer sind obligatorische Metadaten, die zum Zeitpunkt der Veröffentlichung erstellt werden. Ein Beschreibungsfeld ist ebenfalls enthalten, um den Kontext zu beschreiben und das Datenprodukt von anderen ähnlichen Produkten zu unterscheiden. Metadaten über den Service, die Qualität und die Sicherheitsstufen sind ebenfalls vorhanden, ebenso wie Tags, die personenbezogene, finanzielle und regionale Informationen beschreiben.

Abbildung 4-1. Ein Beispiel für Datenprodukt-Metadaten, die du als Nutzer des Datennetzes erwarten kannst

Das Schema-Feld in den Metadaten wird von der Schema-Registry bezogen, einer Komponente, die Schemata für Ereignisströme speichert und verwaltet und ein wesentlicher Bestandteil der Self-Service-Datenplattform ist. Im Abschnitt "Die Schemaregistrierung" gehen wir näher darauf ein. Auch der Name des Brokers und der Name des Themas werden herangezogen, um die digitale Adresse des Datenprodukts zu erhalten.

Metadaten helfen uns, fundierte Entscheidungen darüber zu treffen, welche Datenprodukte für unsere Anwendungsfälle verfügbar sind. Die Kompatibilität zwischen den Datenprodukten ist wichtig, damit wir Daten aus verschiedenen Quellen zusammenführen können, und ist Gegenstand des nächsten Abschnitts.

Sicherstellung der Kompatibilitätund Interoperabilität bereichsübergreifender Datenprodukte

Es gibt viele Faktoren, die Datenprodukte zwischen verschiedenen Bereichen aggregieren, zusammenführen und vergleichen. Im Rahmen der zu Beginn dieses Kapitels beschriebenen Datenprobleme bleiben Interoperabilität und Benutzerfreundlichkeit zwei der Hauptanliegen der föderalen Governance. Regeln und Richtlinien für gemeinsame Entitäten, Zeitzonen, Aggregationsgrenzen und die technischen Details von Ereignismappings, Partitionen und Streamgrößen fallen alle in den Zuständigkeitsbereich des Governance-Teams. Werfen wir jetzt einen Blick auf diese Bereiche.

Gemeinsame Entitäten definieren und nutzen

Einer der ersten wichtigen Schritte ist es, die minimalen Einheiten zu definieren, die in vielen Bereichen deines Unternehmens verwendet werden. Schauen wir uns zunächst ein Beispiel an.

Ein E-Commerce-Unternehmen definiert eine gemeinsame Entität Item mit zwei Feldern: long id und long upc_code. Von den Eigentümern der Datenprodukte wird erwartet, dass sie die Entität Item in jedem Datenprodukt verwenden, das auf ihre E-Commerce-Artikel verweist, sei es Order, Inventory entry oder Return. Jede dieser verwandten Entitäten verwendet eine gemeinsame und standardisierte Version von Item, so dass die Verbraucher nicht mehr ähnliche und doch unterschiedliche Darstellungen derselben Daten interpretieren müssen.

Gemeinsame Entitäten schließen nicht aus, dass du weitere Informationen über diese Entität in dein Datenprodukt einfügst. Es steht dir frei, deine Datenprodukte um weitere Informationen über Item zu erweitern, wie z. B. size und color im Falle eines Kleidungsstücks oder weight und serving_size im Falle eines Lebensmittels. Betrachte eine gemeinsame Entität als Anknüpfungspunkt zwischen Datenprodukten in anderen Domänen und als erweiterbare Basis für das Datenmodell der Entität.

Event Stream Keying und Partitionierung

Die Interoperabilität von Event-Streaming Datenprodukten wird durch die Partitionsanzahl des Streams, den Schlüssel des Ereignisses und den Partitionszuweisungsalgorithmus beeinflusst (siehe Kapitel 3). Ein Ereignisstrom enthält eine oder mehrere Partitionen, und jedes Ereignis wird auf der Grundlage des Partitionszuweisungsalgorithmus, des Ereignisschlüssels und der Anzahl der Partitionen einer Partition zugewiesen. Hier sind einige nützliche Tipps zur Interoperabilität:

Anzahl der Partitionen

Das Zusammenführen und Aggregieren von Daten Produkten aus mehreren Streams kann viel weniger rechenintensiv sein, wenn die Anzahl der Ereignispartitionen gleich groß ist. Event-Stream-Prozessoren wie Kafka Streams und Flink können Event-Streams zwar automatisch nach Bedarf neu partitionieren, aber das erfordert mehr Rechenleistung und kann höhere Kosten verursachen. Versuche es mit einem T-Shirt-Sizing-Ansatz, um die Anzahl der Partitionen zu standardisieren, z. B. x-small=1, small=4, medium=8, large=16, x-large=32, xx-large=64, jumbo=256. Als Teil deiner Selbstbedienungsplattform (die wir im nächsten Kapitel behandeln) kannst du den Nutzern des Datennetzes Anweisungen für die Wahl der Partitionsanzahl auf der Grundlage des Schlüsselraums, des Volumens der Ereignisse und der Bedürfnisse der Verbraucher bei der Wiederverarbeitung geben.

Tipp

Wenn du ein Datenprodukt erstellst, das auf einer gemeinsamen Entität basiert, überprüfe die Partitionsanzahl anderer Datenprodukte, die ebenfalls auf dieserEntität basieren- wenn sie alle dieselbe Partitionsanzahl verwenden, solltest du sie ebenfalls nutzen.

Ereignisschlüssel

Für den Ereignisschlüssel eignet sich am besten mit einem primitiven Wert, wie string, int oder long. Die eindeutige ID der gemeinsamen Entität ist die beste Wahl für die Interoperabilität.

Algorithmus für die Partitionszuweisung

Dieser Algorithmus nimmt den Ereignisschlüssel als Eingabe und gibt die Partitions-ID zurück, in die das Ereignis geschrieben werden soll. Event-Producer-Clients verschiedener Programmiersprachen und Frameworks können inkompatible Algorithmen verwenden, was dazu führt, dass Event-Streams nicht miteinander kompatibel sind, obwohl sie denselben Event-Schlüssel und dieselbe Partitionsanzahl verwenden. Während die Verwendung eines einzigen Frameworks wie Kafka Streams sicherstellt, dass deine Partitionszuordnung konsistent ist, musst du ein wenig recherchieren, um andere Frameworks als Teil deiner Self-Service-Plattform zu bewerten.

Warnung

Sei vorsichtig bei Hot Partitions, bei denen eine unverhältnismäßig große Anzahl von Ereignissen einer einzigen Partition zugewiesen wird. Zum Beispiel können 99% aller Ereignisse einer einzigen Partition zugewiesen werden, während die übrigen Partitionen nur 1% der Daten erhalten. Dies ist in der Regel auf einen extrem engen Schlüsselraum zurückzuführen, kann aber auch an einem ungeeigneten Partitionszuweisungsalgorithmus liegen.

Es ist wichtig, sich von Anfang an Gedanken über die Kompatibilität von Schlüsseln und Partitionen zu machen, denn viele der Datenprodukte, die du erstellst, werden eine Zeit lang bestehen bleiben. Eine Änderung der Partitionen ist möglich, erfordert aber oft das Umschreiben der Daten in einen neuen Ereignisstrom und die Migration der Konsumenten. Halte dich an die T-Shirt-Größen, gib Empfehlungen für die Auswahl der Partitionsgrößen auf der Grundlage der Bedürfnisse der Verbraucher (z. B. Wiederaufbereitung, Parallelisierung) und definiere einen gemeinsamen Algorithmus für die Partitionszuweisung auf der Grundlage deiner verfügbaren Client-Frameworks.

Zeit und Zeitzonen

Datenprodukte können mit einem Fenster oder einem Zeitraum verbunden sein. Ein aggregiertes Datenprodukt kann beispielsweise Daten über einen bestimmten Zeitraum darstellen, z. B. eine stündliche oder tägliche Aggregation. Als Teil eines Standards zur Gewährleistung der Interoperabilität sollte eine primäre Zeitzone wie UTC-0 für alle zeitbasierten Datenprodukte festgelegt werden. Für die Verbraucherinnen und Verbraucher ist es viel einfacher, verschiedene zeitbasierte Datenprodukte zu kombinieren, wenn sie sich nicht mit der Umrechnung von Zeitzonen und der Sommerzeit auseinandersetzen müssen.

Tipp

Falls zutreffend, solltest du den Aggregationszeitraum und zeitzonenbezogene Informationen als Teil der Metadaten des Datenprodukts angeben. Diese Informationen helfen deinen Kunden bei der Entscheidung, ob und wie sie die Daten mit ihren anderen Datenprodukten zusammenführen müssen.

Nachdem wir uns mit der Kompatibilität von Datenprodukten beschäftigt haben, ist es nun an der Zeit, sich mit der sozialen Seite zu befassen. Wie treffen wir wirksame Entscheidungen über die Standards und Anforderungen unserer Datennetze?

Wie sieht ein Governance-Treffen aus?

Es würde den Rahmen dieses Buches sprengen, alle Aspekte eines effektiven Meetings zu behandeln, aber es gibt ein paar Hinweise, die dir den Einstieg erleichtern sollen. Erstens solltest du dich an bewährte Methoden halten, die für alle technischen Meetings gelten. Zweitens solltest du rechtzeitig eine Einladung verschicken und eine Tagesordnung für das Treffen aufstellen. Drittens: Stelle sicher, dass du einen Vorsitzenden und jemanden hast, der Notizen macht und die Punkte festhält, die erledigt werden müssen. Es ist üblich, die Verantwortlichkeiten und Aufgaben zu wechseln, um eine gleichmäßige Vertretung zu gewährleisten.

Es ist sehr wichtig, dass die Leute, die an den operativen Systemen arbeiten, mit denjenigen, die an den analytischen Systemen arbeiten, in einem Besprechungsraum zusammenkommen. Du wirst überrascht oder vielleicht auch enttäuscht sein, wie selten das geschieht. Die Isolierung der "Datenteams" von den "Ingenieurteams" ist schon lange ein Problem in der IT-Branche, wie wir in "Bad Data" beschrieben haben: Die Kosten der Untätigkeit".

Warnung

Wie bei jedem Treffen können Personen mit einer starken Persönlichkeit oder einer lauten Stimme versuchen, das Gespräch zu dominieren. Stelle sicher, dass du einen Vorsitzenden hast, der das Treffen leitet und dafür sorgt, dass jeder die Möglichkeit hat, ungestört zu sprechen. Wenn die Sitzung hitzig und unproduktiv wird, mache eine 5-minütige Pause oder vertage die Sitzung für denTag.

In der Anfangsphase eurer Datenverflechtung solltet ihr euch häufig treffen. Ihr werdet viele Dinge zu besprechen, zu lösen, zu unterstützen und zu standardisieren haben. Mit der Zeit werdet ihr euch weniger häufig treffen.

Aber was sind die wichtigsten Aufgaben, auf die sich das Governance-Team konzentrieren sollte? Gehen wir die fünf Hauptbereiche durch und besprechen, wie sie sich auf das Datengeflecht beziehen.

1. Bestehende Probleme identifizieren

Die erste Aufgabe des Governance-Teams besteht darin, zu ermitteln, wo die Probleme liegen. Dein Team sollte sich aus Personen aus dem gesamten Unternehmen zusammensetzen, die einen guten Überblick über die Technologie- und Datenlandschaft haben. Ein basisdemokratischer Bottom-up-Ansatz zur Meldung von Problemen und Fragen funktioniert in der Regel am besten. Bitte deine Kolleginnen und Kollegen, die Bereiche zu benennen, in denen sie Probleme haben, die Hindernisse und Hürden, mit denen sie konfrontiert sind, und was sie gerne tun würden - sei es im Hinblick auf die Geschäftsanforderungen oder die Vereinfachung der betrieblichen Komplexität.

Tipp

Lass alle ihre Hauptprobleme und -fragen auf Karten oder Klebezetteln auflisten. Dann kannst du ähnliche Probleme in Gruppen zusammenfassen, um die Bereiche zu finden, in denen du die größten Verbesserungen erzielen kannst.

Die Identifizierung von Problemen ist der erste Schritt, um das Datengeflecht für alle zu verbessern. Zu den häufigsten Problemen gehören fehlende Self-Service-Tools, inkonsistente Daten in bestehenden Produkten und fehlende Richtlinien für doppelte Daten, Informationssicherheit, personenbezogene Daten und Finanzdaten. Sobald die Probleme identifiziert sind, kannst du Prioritäten setzen und Ressourcen für die Lösung dieser Probleme bereitstellen.

2. Vorschläge verfassen

Der nächste Schritt ist die Ausarbeitung eines Vorschlags, der das Problem umreißt, erklärt, warum es wichtig ist, es zu lösen, die Herausforderungen und Chancen benennt und eine mögliche Lösung aufzeigt. Ein Vorschlag ist vergleichbar mit einer Gesetzesvorlage, wie sie in den Parlamenten vieler demokratischer Systeme eingebracht wird. Er schlägt Änderungen vor, nennt Details und legt den Geltungsbereich fest - alles in einer einzigen diskutierbaren Einheit.

Nicht nur das Governance-Team kann Vorschläge zur Überprüfung erstellen - jeder in der Organisation kann einen erstellen. Die besten Ergebnisse erzielst du, wenn du dich an die Leute wendest, die die Probleme erkannt haben - sie haben in der Regel eine Idee, wie man die Dinge verbessern kann, und brauchen nur jemanden, der die notwendige Arbeit organisiert und fördert. Die Vorschläge sollten sich auf die Lösung konkreter Probleme konzentrieren, die für die Nutzer/innen des Datennetzes von praktischer Bedeutung sind.

Einige Beispiele für Vorschläge könnten sein:

• Verschlüsselung auf Feldebene einführen, um den Zugriff auf einige sensible Informationen in einem Datenprodukt zu beschränken

• Regelungen für den Umgang mit Datenprodukten über mehrere Cloud-Einsätze hinweg umsetzen

• Hinzufügen von benutzerdefinierten Tags zu den Metadaten von Datenprodukten zur Verbesserung der Suchfunktionalität

• Füge Datenprodukten Namespacing hinzu, um Sicherheitszugriff auf Namensraumebene zu ermöglichen

• Einführung eines zentralen Authentifizierungs- und Autorisierungsdienstes zur Vereinheitlichung des Identitätsmanagements für alle Cloud-Dienste in der Self-Service-Plattform

Auch wenn die Vorschläge ein breites Spektrum an Anliegen abdecken können, sollten sie in den meisten Fällen zu einer Verbesserung der Selbstbedienungswerkzeuge und -plattformen führen, die den Nutzer/innen des Datennetzes zur Verfügung stehen. Es ist schön und gut, einen neuen Prozess vorzuschreiben, aber wenn er nicht in die Tools und Dienste integriert ist, die die Nutzer/innen des Datennetzes tagtäglich nutzen, besteht eine gute Chance, dass er nicht befolgt oder genutzt wird.

Tipp

Vorschläge sollten veranschaulichen, wie eine erfolgreiche Lösung des Problems aussehen kann. Die Erstellung eines Prototyps, der genau zeigt , wie die Lösung funktionieren wird, sorgt dafür, dass die Ideen in der Praxis und nicht in der Theorie verankert sind. Entwickle Experimente, führe Versuche durch, vergib Forschungsaufträge, untersuche Optionen und stelle Prototypen von technologischen Lösungen her, bevor du sie für den allgemeinen Gebrauch einführst.

3. Überprüfung der Vorschläge

Das föderale Governance-Team prüft die Vorschläge, um die Realisierbarkeit der Lösung und die erforderlichen Implementierungsressourcen zu bestimmen. Die Art und Weise, wie du diese Vorschläge prüfst, ist von Team zu Team unterschiedlich, vor allem wenn es um Fernarbeit, Zeitzonen und andere Verteilungsfaktoren geht. Eine Möglichkeit, die sich bewährt hat, ist, dass die Mitglieder des föderalen Governance-Teams die Vorschläge einzeln durchgehen, sich Notizen machen oder Bedenken markieren, bevor sie sich in einer größeren Gruppe zusammensetzen. Wenn ihr alle in einem Raum versammeln könnt, egal ob digital oder physisch, fällt es euch vielleicht leichter, Fragen zu stellen, Optionen zu diskutieren und einen gemeinsamen Plan zu entwickeln. Ihr könnt euch auch asynchron treffen und beschließen, nur dann zusammenzukommen, wenn es genügend Unstimmigkeiten oder Unklarheiten gibt.

Tipp

Halte die Überprüfungen offen und integrativ. Lade Personen aus deinem Unternehmen ein, von denen du glaubst, dass sie dir helfen können, indem sie zusätzliche Informationen und Zusammenhänge liefern. Möglicherweise musst du sie explizit ausfindig machen und einladen, da die meisten Leute ziemlich beschäftigt sind. Verlass dich nicht darauf, dass immer dieselben Personen jeden Vorschlag prüfen, damit du nicht den Eindruck erweckst, dass niemand sonst willkommen ist, einen Beitrag zur föderalen Governance zu leisten.

Das Hauptziel der Prüfung sollte darin bestehen, die vorgeschlagene Lösung zu validieren, Prototypen zu überprüfen, übersehene Aspekte zu identifizieren und die Grenzen des Arbeitsaufwands abzuschätzen. Die Überprüfung kann dazu führen, dass der Vorschlag abgelehnt wird - entweder wird er zur weiteren Bearbeitung an den Ersteller zurückgeschickt oder aufgrund anderer unüberwindbarer Probleme ganz abgelehnt. Eine akzeptierte Prüfung erfordert einen letzten Schritt - die Planung und Durchführung der Umsetzungsarbeiten.

4. Umsetzung von Vorschlägen

Ein akzeptierter Vorschlag muss dann in detaillierte Arbeitsschritte umgewandelt werden. Unterteile den Vorschlag in einzelne Schritte, um die Änderungen am Datennetz zu entwickeln, zu testen, einzusetzen und zu validieren. Verwende dein bestehendes Arbeitsticket-System, um jeden Arbeitsschritt detailliert zu beschreiben, einschließlich einer Beschreibung der zu erledigenden Arbeit, wie der Erfolg aussieht und einer Schätzung des Zeit- und Arbeitsaufwands für die Umsetzung.

Tipp

Die Umsetzung eines Vorschlags ist identisch mit dem Prozess der Implementierung von Funktionen für jedes andere Produkt. Auch wenn du am Anfang deiner Reise durch das Datennetz vielleicht auf einen Produktmanager für die Self-Service-Datenplattform verzichten kannst, wirst du feststellen, dass er eine wichtige Rolle spielt, um die Dinge zu erledigen.

Du brauchst auch jemanden, der die Arbeit macht! Je nach Unternehmen hast du vielleicht eine oder mehrere Personen mit der Umsetzung der Tickets für die Data Mesh-Plattform beauftragt. Alternativ kannst du den Ersteller des Vorschlags bitten, die Arbeitsstunden zur Verfügung zu stellen, da er sich wahrscheinlich am besten mit der Lösung auskennt.

Wie auch immer du die Arbeit umsetzen willst, konzentriere dich darauf, iterative Verbesserungen in einem angemessenen Zeitrahmen zu realisieren. Wie jedes andere Produkt muss auch dein Datengeflecht deinen Kolleginnen und Kollegen dabei helfen, ihre Probleme mit dem Datenzugang, der Datennutzung und der Veröffentlichung zu lösen. Wenn du es versäumst, Vertrauen in deine Datenvernetzungsplattform aufzubauen, werden die Leute sie einfach nicht nutzen und stattdessen auf ihre eigenen Ad-hoc-Datenzugriffsmechanismen zurückgreifen. In diesem Fall ist dein Datennetz nichts weiter als Zeitverschwendung.

5. Archivierung von Vorschlägen

Bewahre alle angenommenen und abgelehnten Vorschläge zusammen mit Notizen (oder aufgezeichneten Videos) über ihre Diskussion an einem allgemein zugänglichen Ort auf, z. B. in einer Cloud. Die Mitarbeiter/innen sollten in der Lage sein, den Status der Vorschläge einzusehen und zu erfahren, welche Vorschläge aus welchen Gründen angenommen oder abgelehnt wurden. Transparenz ist wichtig, denn sie gibt Aufschluss darüber, warum eine Technologie oder Entscheidungangenommen oder nichtangenommen wurde.

Die archivierten Vorschläge machen die Bedienung auch einfacher. Du kannst die vorhandenen Vorschläge durchsuchen, um herauszufinden, ob etwas Ähnliches schon einmal vorgeschlagen wurde, und wenn ja, mit welchem Ergebnis. Der ursprüngliche Grund, etwas nicht anzunehmen, ist vielleicht nicht mehr gültig, sodass es sich lohnt, einen neuen Vorschlag zu machen.

Im nächsten Abschnitt werfen wir einen Blick auf die Sicherheits- und Zugriffskontrollen. Beides ist wichtig, um einen verlässlichen Rahmen für Eigentum und Sicherheit zu schaffen und um sich vor unbefugtem Zugriff und versehentlicher Veränderung der Datenprodukte der anderen zu schützen.

Datensicherheit und Zugriffsrichtlinien

Die Sicherheits- und Zugangskontrollmaßnahmen deines Datennetzes hängen stark von den rechtlichen und geschäftlichen Anforderungen deines Unternehmens ab. Eine Bank hat zum Beispiel viel höhere Anforderungen an die Sicherheit und die Zugriffskontrolle als eine anonyme Messageboard-Website. Da es sich hier um ein weites Feld handelt, gehen wir davon aus, dass du dich an "gute Sicherheitspraktiken" hältst, und konzentrieren uns stattdessen auf einige wichtige Konzepte und Techniken, die speziell für die Erstellung und Nutzung ereignisgesteuerter Datenprodukte gelten.

Tipp

Defense in depth (Verteidigung in der Tiefe) sollte dein Leitprinzip sein, wenn es um Sicherheit und Zugriffskontrollen geht. Es gibt kein Patentrezept, um deine Daten vor unbefugter Nutzung zu schützen, sei es durch einen wohlmeinenden, aber unbefugten Kollegen oder durch einen externen Eindringling. Standardmäßige Zugangsbeschränkungen, die obligatorische Authentifizierung von Nutzern und Diensten sowie die Sicherung und Verschlüsselung privater, finanzieller und anderer sensibler Daten tragen dazu bei, den Explosionsradius zu verringern und die Folgen abzumildern.

Das Identitätsmanagement ist eine grundlegende Komponente der Datensicherheit, da alle Benutzer- und Dienstberechtigungen damit verknüpft sind. Wir werden dieses Thema im nächsten Kapitel unter "Dienst- und Benutzeridentitäten" genauer betrachten . Jetzt wollen wir erst einmal einige der wichtigsten Sicherheitsprinzipien untersuchen, die dein Governance-Team in deinem Datengeflecht umsetzen und unterstützen kann.

Datenproduktzugriff standardmäßig deaktivieren

Datenprodukte sollten nur für registrierten Verbrauchern zur Verfügung stehen. Wenn du nicht als Verbraucher des Datenprodukts registriert bist, kannst du es nicht lesen. Dieses Prinzip stellt zwar eine Hürde dar, verglichen mit der Möglichkeit, ein Datenprodukt für jeden, der es haben möchte, nur zum Lesen freizugeben, aber es zwingt Nutzer/innen und Dienste dazu, sich als explizite Verbraucher/innen zu registrieren. Wir müssen wissen, wer was liest, damit alle Änderungen und Anfragen sowohl nach oben als auch nach unten weitergegeben werden können.

Erwägen Sie eine Ende-zu-Ende-Verschlüsselung

Je nach Sicherheitsanforderungen musst du deine Produktdaten verschlüsseln, bevor du sie im Event Broker veröffentlichst. Die Daten bleiben im Event Broker verschlüsselt, so dass Unbefugte nicht durch eine Hintertür auf die Daten auf der Festplatte zugreifen können. Ein registrierter Verbraucher mit den zugewiesenen Entschlüsselungsschlüsseln kann die Daten lokal für den eigenen Gebrauch konsumieren und entschlüsseln.

Tipp

Die Ver- und Entschlüsselung von Daten zu vereinfachen, ist eine Funktion der Self-Service-Plattform. Es ist jedoch Sache des Governance-Teams, die Anforderungen und unterstützten Anwendungsfälle zu bestimmen.

Für den Umgang mit sensiblen Daten ist oft eine Ende-zu-Ende-Verschlüsselung erforderlich. Die Verschlüsselung der Daten auf der Produzentenseite bietet zusätzliche Sicherheit während der Netzwerkkommunikationund der Speicherung der Daten und stellt sicher, dass der Cloud-Provider des Event Brokers die unverschlüsselten Datennicht irgendwie lesen (oder durchsickern lassen)kann. Darüber hinaus dient die Ende-zu-Ende-Verschlüsselung als "Defense in Depth" - es ist möglich, dass jemand Zugang zu deinen Ereignisdaten erhält, aber ohne die Entschlüsselungsschlüssel nicht in der Lage ist, die Originaldaten zu entschlüsseln und zu verwenden.

Abbildung 4-2 zeigt einen Produzenten und einen Konsumenten-Client, die eine Ende-zu-Ende-Verschlüsselung verwenden. Der Produzent hat die Daten verschlüsselt, bevor er sie in den Ereignisstrom schreibt, und den Schlüssel an einen Schlüsselverwaltungsdienst (KMS) weitergegeben. Ein Verbraucher, der das Datenprodukt lesen möchte, muss sich vom KMS Zugang zu den Entschlüsselungsschlüsseln verschaffen und sie dann auf jedes Ereignis anwenden, das er aus dem Datenstrom liest.

Abbildung 4-2. Ende-zu-Ende-Verschlüsselung bei der Arbeit in einem Datenprodukt, das als Ereignisstrom dient

Ein KMS bietet dir einen Mechanismus zum sicheren Erstellen, Teilen, Speichern und Rotieren deiner Schlüssel. Du kannst zwar auch ohne formale Unterstützung durch eine Self-Service-Datenplattform anfangen, aber wenn du viel verschlüsselst, wirst du wahrscheinlich in die Optimierung dieses Prozesses investieren müssen.

Du musst nicht immer das gesamte Ereignis verschlüsseln - manchmal reicht es aus, nur die sensiblen Felder zu verschlüsseln. Schauen wir uns das mal an.

Verschlüsselung auf Feldebene

Die Verschlüsselung auf Feldebene bietet die Möglichkeit, bestimmte Felder zu verschlüsseln, so dass nur ausgewählte Verbraucher auf die Daten zugreifen können. Personenbezogene Daten, Konten und Finanzdaten sind häufige Anwendungsfälle für die Verschlüsselung auf Feldebene. Wenn du zum Beispiel eine Überweisung modellierst, kannst du die Felder user und account auf Feldebene verschlüsseln, aber die Felder amount und datetime unverschlüsselt lassen. Verbraucher mit Entschlüsselungsberechtigung können auf die entschlüsselten Informationen zugreifen, um Kontostände abzurechnen, während ein Analysesystem ohne Entschlüsselungsberechtigung immer noch nachvollziehen kann, wie viel Geld in einem bestimmten Zeitraum bewegt wird - und das alles mit demselben Datenprodukt. Tabelle 4-1 zeigt die Verschlüsselung der Felder email, user, und account eines Ereignisses.

Tabelle 4-1. Verwendung der Verschlüsselung auf Feldebene zur teilweisen Verschlüsselung eines Ereignisses

Feldname	Original Ereignis	Teilweise verschlüsseltes Ereignis
E-Mail	[e-mail]	n2Zl@p987NhB4.L0P
Benutzer	abellemare	9ajkpZp2kH
Konto	VD8675309	0PlwW81Mx
Betrag	$777.77	$777.77
datetime	2022-02-22:22:22:22	2022-02-22:22:22:22

Du kannst auch eine formatbewahrende Verschlüsselung verwenden, um das Format der Ereignisdaten beizubehalten. In diesem Fall haben wir für die Felder email, user und account eine formatbewahrende Verschlüsselung verwendet - mit denselben alphanumerischen Zeichen, Abständen und der Anzahl der Zeichen wie in den Originalfeldern, aber ohne dass Benutzer ohne Entschlüsselungsberechtigung irgendwelche personenbezogenen Daten sehen können.

Tipp

Einer der Vorteile der Verschlüsselung auf Feldebene ist, dass sie feinere Zugriffskontrollen für die Verbraucher ermöglicht. Deine Kunden können Entschlüsselungsschlüssel nur für die Daten anfordern, die sie benötigen, und nicht für die gesamte Nutzlast.

Die formatbewahrende Verschlüsselung ist besonders nützlich, um Daten nachträglich zu verschlüsseln, weil du die Schemata mit den nachgelagerten Verbrauchern nicht neu aushandeln musst. Im Gegensatz dazu führt eine nicht-formaterhaltende Verschlüsselung oft zu Missbildungen, wie z. B. die Umwandlung einer long Bankkontonummer in eine 64-stellige string oder die Verschlüsselung eines komplexen, verschachtelten Objekts in ein Array aus gehashten Bytes.

Die Verschlüsselung sensibler Daten, ob Ende-zu-Ende oder auf Feldebene, kann uns auch dabei helfen, eine andere wichtige Governance-Anforderung zu erfüllen: das Recht, vergessen zu werden und unsere Daten löschen zu lassen.

Datenschutz, das Recht auf Vergessenwerden und Krypto-Shredding

Die Allgemeine Datenschutzverordnung (GDPR) ist (unter anderem) ein Gesetz, das den sorgfältigen Umgang, die Speicherung und die Löschung von Daten vorschreibt. Sie ist ein hervorragendes Beispiel für eine gesetzliche Vorgabe, an die sich dein Unternehmen möglicherweise halten muss, um auf der richtigen Seite des Gesetzes zu bleiben. Und wenn du ein Datengeflecht aus nützlichen Datenprodukten erstellen willst, ist es sehr wahrscheinlich, dass du es mit persönlichen, Konto- und Finanzdaten zu tun haben wirst, für deren Schutz du zusätzliche Schritte und Vorsichtsmaßnahmen ergreifen musst.

Artikel 17 der Datenschutz-Grundverordnung schreibt vor, dass Einzelpersonen die Möglichkeit haben, die Löschung aller ihrer personenbezogenen Daten ohne unnötige Verzögerung zu verlangen. Auf den ersten Blick scheint diese Bestimmung im direkten Widerspruch zu den Grundsätzen eines Datennetzes zu stehen: die Veröffentlichung genau definierter Datenprodukte, die andere Teams und Dienste nach eigenem Ermessen nutzen können. Ereignisgesteuerte Datenprodukte scheinen das Problem noch zu verschlimmern, da die Verbraucher die Daten in ihre eigenen lokalen Datenspeicher und Caches einlesen.

Crypto-Shredding ist eine Technik, mit der du sicherstellen kannst, dass Daten durch Überschreiben oder Löschen der Verschlüsselungsschlüssel unbrauchbar gemacht werden. Kurz gesagt: Du überlässt dem Endnutzer die volle Kontrolle darüber, wann er seine Schlüssel löschen will, und machst seine Daten kryptografisch unbrauchbar, sobald die Schlüssel gelöscht sind. Du kannst Crypto-Shredding mit jeder Form der Verschlüsselung verwenden, einschließlich Ende-zu-Ende und Feldverschlüsselung.

In der Zwischenzeit wenden sich die Verbraucher der verschlüsselten Datenprodukte einfach an das zentrale KMS und beantragen den Zugang zu den Entschlüsselungsschlüsseln. Wenn der Verbraucher die richtigen Berechtigungen hat, werden die Entschlüsselungsschlüssel an ihn zurückgegeben und er kann die Daten nach Bedarf entschlüsseln und verarbeiten.

Warum machen wir das so? Können wir die Daten im Datenprodukt nicht einfach aussortieren und direkt löschen? Wäre das nicht viel sicherer?

Das Löschen von Produktdaten ist nach wie vor eine vernünftige Wahl, aber es gibt einige Komplikationen, die Verschlüsselung und Krypto-Shredding zu einer wichtigenÜberlegung machen:

Große Mengen an Daten

Große Datenmengen können in Sicherungskopien, Bandlaufwerken, kalten Cloud-Speichern und anderen teuren und schwer zugänglichen Medien gespeichert sein. Es kann sehr teuer und zeitaufwändig sein, alle historischen Daten einzulesen, selektiv zu löschen und dann wieder in die Speicherung zu schreiben. Mit Crypto-Shredding vermeidest du, dass du jeden einzelnen alten Datensatz in deinem Unternehmen durchsuchen musst.

Teilweise verschlüsselte Daten sind immer noch nützlich

Oft reicht es aus, nur die personenbezogenen Daten eines Nutzers zu löschen, um die Anforderungen von Artikel 17 der DSGVO zu erfüllen. Die verbleibenden Daten können für bestimmte Anwendungsfälle, wie z. B. die Erstellung von analytischen Aggregationen, noch von Nutzen sein. Wir können die verbleibenden Daten an Ort und Stelle belassen und trotzdem einen begrenzten Nutzen aus ihnen ziehen.

Daten über mehrere Systeme hinweg

Durch das Löschen der Entschlüsselungsschlüssel werden gleichzeitig alle Datenzugriffe über alle Verbraucherdienste hinweg ungültig. Wir müssen uns keine Gedanken darüber machen, wann die Daten gelöscht werden, vor allem nicht bei Systemen, die ihre Daten nur langsam löschen.

Weitere Verteidigung in der Tiefe

Krypto-Shredding bietet eine zusätzliche Sicherheitsebene zur Vermeidung von Datensicherheitsvorfällen. Das Durchsickern verschlüsselter Daten ist weitaus weniger schädlich als das Durchsickern unverschlüsselter Daten und trägt dazu bei, sowohl das Risiko als auch die Auswirkungen einer Verletzung der Datensicherheit zu verringern.

Krypto-Shredding schützt dich nicht vor Verbrauchern, die entschlüsselte Daten oder die Entschlüsselungsschlüssel fahrlässig aufbewahren. Du kannst dem entgegenwirken, indem du dafür sorgst, dass die Verbraucher klare und einfache Sicherheitsrichtlinien befolgen müssen, z. B. dass sie die Entschlüsselungsschlüssel nur 10 Minuten lang aufbewahren dürfen, bevor sie sie löschen und erneut beim KMS anfordern müssen. Mithilfe der Zugriffskontrollliste kannst du außerdem verfolgen, welche Dienste den Zugriff für die Datenentschlüsselung anfordern, so dass dein Sicherheitsteam dieEinhaltung der Richtlinien überprüfen kann.

Die Regeln und Vorschriften für die Sicherung und den Umgang mit Daten sind ein wichtiger Bestandteil der Aufgaben des Governance-Teams. Diese Belange sind für die Lebensfähigkeit und das Überleben einer Organisation von grundlegender Bedeutung und können nicht ad hoc von einzelnen Datenproduktverantwortlichen umgesetzt werden. Vergewissere dich, dass du und dein föderales Governance-Team ein solides Verständnis der rechtlichen und geschäftlichen Anforderungen für den Umgang mit deinen Daten haben, damit ihr die Sicherheitsanforderungen der Self-Service-Datenplattform steuern könnt.

Die nächste verwandte Komponente ist die Datenproduktlinie. Zugriffskontrollen und Verschlüsselung helfen zwar dabei, die gesetzlichen Anforderungen an den Umgang mit Daten zu erfüllen, aber es ist auch wichtig, alle vor- und nachgelagerten Abhängigkeiten eines Datenprodukts zu kennen. Werfen wir einen genaueren Blick auf die Datenabfolge, um zu sehen wie sie unser Datengeflecht verbessern kann.

Daten Produktlinie

Mit Lineage können wir nachverfolgen, welche Dienste ein Datenprodukt lesen und schreiben, einschließlich der Frage, ob der Verbraucher-Client den Stream aktiv liest. Grundlegende Lese- und Schreibberechtigungen sowie Client-Identitäten geben uns ein ziemlich gutes Bild, das wir nutzen können, um Abhängigkeiten und Lineage zu verfolgen. Wir können feststellen, welche Systeme und Nutzer Zugang zu sensiblen Daten haben und welche nicht, und welche Wege und Pfade die Daten auf ihrem Weg von einem Client und Produkt zum nächsten nehmen.

Bei einem ereignisgesteuerten Datennetz, das auf Open Source Apache Kafka basiert, werden die Zugriffskontrollen im Event Broker selbst eingerichtet. Viele SaaS-Anbieter bieten auch übergeordnete Funktionen in Form von rollenbasierten Zugriffskontrollen (RBAC) an, mit denen du Rollen anhand von Regeln und Personas zusammenstellen kannst. In jedem Fall sind Berechtigungen wichtig, um den Überblick zu behalten und Linien zu konstruieren.

Es gibt zwei Haupttypen von Data Lineage, die du für deine eigenen Implementierungen in Betracht ziehen kannst. Die erste ist die topologiebasierte Datenabfolge, die die Abhängigkeiten zwischen Diensten und Datenprodukten zu einem bestimmten Zeitpunkt aufzeigt. Die zweite Art ist die datensatzbasierte Lineage, die die Ausbreitung eines Datensatzes durch die Dienste verfolgt. Schauen wir uns beide nacheinander an.

Topologie-basierte Abstammung

Die topologiebasierte Abstammung zeigt die Abhängigkeiten zwischen Datenprodukten und ihren Verbrauchern als Diagramm an, wobei Pfeile vom Datenprodukt zu den registrierten Verbrauchern zeigen. Neue Datenprodukte erscheinen als Knotenpunkte im Diagramm, ebenso wie die Konsumenten der Datenprodukte. Das Diagramm kann zeigen, welche Clients aktiv Ereignisse konsumieren, mit welcher Geschwindigkeit, ob sie aktuell sind oder ob sie historische Daten wiedergeben. Es ist auch möglich, der Topologie Informationen und Metadaten zu Diensten und Datenprodukten hinzuzufügen, um den potenziellen Nutzern des Datennetzes eine andere Art der Entdeckung zu ermöglichen.

Eine Topologie-basierte Abstammung ist relativ einfach zu erhalten, da Berechtigungen und Client-Identitäten für die Informationssicherheit bereits unerlässlich sind und offen gesagt einfach gute Praktiken sind. Du könntest sogar deine eigenen erstellen, indem du deine Client-Identitäten und Berechtigungen in eine Datei einträgst und sie mit einem Graph-Framework deiner Wahl in einen Graphen umwandelst.

Die meisten Lineage-Tools konzentrieren sich heute auf eine topologiebasierte Lineage, in der Regel mit einer attraktiven und interaktiven Grafik, auf die du klicken kannst, um zusätzliche Informationen wie Upstream- und Downstream-Abhängigkeiten zu sehen. Während viele von ihnen nur die aktuelle Topologie anzeigen, haben andere damit begonnen, Point-in-Time-Lineage anzubieten, bei der du die Lineage zu einem bestimmten Zeitpunkt untersuchen und herunterladen kannst.

Die Topologie-basierte Abstammung ist nützlich, um zu verfolgen, welche Verbraucher auf welche Datenprodukte zugegriffen haben. Im Falle von fehlerhaften Daten in einem Produkt kannst du auch feststellen, welche nachgelagerten Verbraucher betroffen sind, damit Ausgleichsmaßnahmen eingeleitet werden können. Und schließlich kann der Eigentümer eines Datenprodukts anhand des Verlaufsdiagramms einfach feststellen, wer seine Datenprodukte nutzt, um sich mit ihm über anstehende Änderungen abzustimmen.

Aufzeichnungsbasierte Abstammung

Die aufzeichnungsbasierte Historie konzentriert sich auf die Verfolgung eines einzelnen Datensatzes durch seine Geschichte, wobei aufgezeichnet wird, wo er sich befindet, in welchen Systemen er verarbeitet wird und mit welchen abgeleiteten Ereignissen er möglicherweise in Verbindung steht. Der Verlauf eines Datensatzes sollte dem Prüfer einen umfassenden Überblick über den Lebenszyklus eines Ereignisses geben, so dass eine weitere Untersuchung möglich ist. Die Umsetzung der Record-based Lineage ist weitaus komplexer, da es viele Eckfälle zu berücksichtigen gibt. Das Record-Based Lineage kann zusammen mit dem Topology-Based Lineage verwendet werden, wird aber eher seltener eingesetzt.

Eine einfache Umsetzungsmöglichkeit besteht darin, den Weg eines Ereignisses vom Datenprodukt zum Verbraucher aufzuzeichnen. Auf jeder Etappe werden dem Datensatz eine eindeutige Service-ID, die Verarbeitungszeit und andere notwendige Metadaten angehängt, normalerweise in der Kopfzeile. Allerdings ist es in der Regel viel schwieriger, den Verlauf eines Datensatzes in großem Maßstab zu erfassen, da es mehrere wichtige Faktoren gibt, die dies erschweren:

Mehrere Verbraucher der gleichen Ereignisse

Ein Datensatz kann von vielen verschiedenen Nutzern verwendet werden, was zu mehreren Kopien desselben Ereignisses führt, von denen jede ihre eigene Abstammung hat.

Nicht alle Verbraucher senden Ereignisse aus

Einige Verbraucher senden keine Ereignisse und können stattdessen den Zugriff auf Daten über eine REST-API bereitstellen. Sie müssten zusätzliche Schritte unternehmen, um ein Protokoll der aufgenommenen Datensätze zu erstellen und sicherzustellen, dass die Daten für Abfragen verfügbar sind.

Ereignisse zusammenfassen und verbinden

Eine Aggregation kann aus einer großen Anzahl von Ereignissen bestehen, so dass es unpraktisch ist, alle mit ihrer Zusammensetzung verbundenen Datensätze zu verfolgen. Das Gleiche gilt für Joins, obwohl Joins in der Praxis meist nur eine kleine Anzahl von Ereignissen umfassen.

Komplexe Transformationen

Verbraucher können ziemlich komplexe Anwendungsfälle haben, bei denen sich Eingabeereignisse nicht so einfach auf die Ausgabe übertragen lassen.

Eine Alternative zur Speicherung der Datensatzreihenfolge im Datensatz ist die Verwendung einer externen Datenbank. Jeder Dienst muss dem Endpunkt die Ereignisse melden, die er konsumiert, verarbeitet und weitergegeben hat. Diese Option macht es einfacher, die Nutzung des Datensatzes zu verfolgen, wenn mehrere Dienste das Datenprodukt verbraucht und genutzt haben, auch wenn nach der Nutzung keine neuen Ereignisse mehr gesendet werden.

Es löst jedoch nicht die Probleme im Zusammenhang mit Joins, Aggregationen und komplexen Transformationen und hinterlässt eine potenzielle Lücke in der Datensatzabfolge. Außerdem musst du in Client-Tools investieren, die den Status jedes Datensatzes automatisch an den zentralen Dienst melden und dabei auch die Skalierung, Ausfälle und die Unterstützung von Client-Sprachen berücksichtigen.

Es ist wichtig, dass du dir überlegst , warum du Lineage willst und welche Probleme du damit lösen willst. Es gibt keine pauschale Lösung für Lineage. Eine Bank hat weitaus höhere Anforderungen an das Lineage-System als ein Laden, der Socken verkauft. Du musst also sicherstellen, dass dein Governance-Team die tatsächlichen Anforderungen seiner Organisation genau kennt. Es gibt Lineage-Lösungen, die die in diesem Abschnitt behandelten Probleme lösen können, aber sie erfordern viel Zeit und Mühe - Zeit und Mühe, die du vielleicht besser anderweitig verwenden solltest.

Wenn du nicht genau weißt, welche Probleme deine Lineage-Lösung lösen soll, läufst du Gefahr, etwas völlig Unwichtiges zu bauen. Du musst herausfinden, welche Prüfungen du brauchst und welche Risiken für deine Systeme bestehen, und dann einen detaillierten Vorschlag vorlegen, wie eine Lineage-Lösung dir helfen kann, deine Anforderungen zu erfüllen.

Zusammenfassung

Die föderale Verwaltung umfasst ein großes Gebiet.

Das Datengeflecht erfordert ein Governance-Team, das dabei hilft, Ordnung in die verschiedenen Technologien, Domänen, Datenmodelle und Anwendungsfälle des Unternehmens zu bringen. Governance ist ein intensives soziales Engagement, bei dem du mit deinen Kolleg/innen zusammenarbeitest und effektive Lösungen für die Hürden bei der Umsetzung des Datengeflechts findest. Als Teil des Governance-Teams konzentrierst du dich auf die Identifizierung gemeinsamer Standards, Frameworks, Sprachen und Tools, um die Anwendungsfälle des Data Mesh zu unterstützen.

Das Governance-Team arbeitet mit technischen Fachleuten zusammen, um Verbesserungsmöglichkeiten für die Self-Service-Plattform zu identifizieren. Wenn du willst, dass sich jeder in deinem Unternehmen an die Richtlinien zur Datenverschlüsselung hält, ist es viel einfacher, dafür zu sorgen, dass sie standardmäßig in die Datenproduktplattform integriert sind und nicht von jedem Team selbst umgesetzt werden müssen. Außerdem sorgt das Governance-Team dafür, dass diejenigen, die das Datengeflecht nutzen, gehört werden, dass auf ihre Beschwerden eingegangen wird und dass Erfolgsgeschichten geteilt und vorgelebt werden.

Bei der föderalen Governance geht es auch darum, die Datennutzung zu verfolgen und sicherzustellen, dass sie den rechtlichen Anforderungen und guten Praktiken im Bereich der Informationssicherheit entspricht. Du brauchst strenge Zugriffskontrollen, um sicherzustellen, dass du weißt, welche Systeme und Personen Zugriff auf welche Daten haben, aber du musst abwägen, ob deine Teams bei Bedarf auf die meisten Daten zugreifen können. Möglicherweise müssen die Daten auch verschlüsselt werden, entweder teilweise oder vollständig, und sie müssen auf unbestimmte Zeit archiviert werden, auch dies hängt von deinenAnforderungen an die Datenverarbeitung ab.

Schließlich geht es bei der Governance auch darum, die Richtung für die Implementierung der Selbstbedienungsplattform vorzugeben. Das Governance-Team sollte zusammen mit seinen technischen Experten die Funktionen der Selbstbedienungsplattform kodifizieren und optimieren, damit es für die Nutzer/innen einfach ist, das Richtige zu tun, und es ihnen schwer fällt, das Falsche zu tun. Darauf gehen wir im nächsten Kapitel näher ein.