Zusammenfassung
- Definiert Datenprodukte als APIs, die eine klare Dokumentation erfordern.
- Erklärt, dass Datenverträge Nutzungsbedingungen und Lebenszyklus abdecken.
- Betont Abstammung und Metadaten die Verwaltung dynamischer Daten.
- Unterstützt die Governance, indem Daten in ihrer ursprünglichen Umgebung gespeichert bleiben.
Kapitel
Apropos Verträge: Auch hier gibt es noch keine allgemeingültige Definition. Wie stellen Sie sich Datenverträge vor? Wir betrachten ein Datenprodukt als API für, äh, Daten.
Und wie bei APIs möchten Sie eine Dokumentation, die klarstellt, worauf Sie sich einlassen, richtig? Und was das alles bedeutet. Und meines Wissens nach sind alle verschiedenen Ausprägungen von Datenverträgen, die derzeit entstehen, sehr ähnlich, mit einigen geringfügigen Unterschieden.
Ich denke, dass die zugrunde liegende Idee, zu beschreiben, was es ist, wie es verwendet werden kann, zu welchen Bedingungen es bereitgestellt wird, ob es sich um eine Querabrechnung handelt, in allen Verträgen Standard ist. Das SQL-Skript, das sich beispielsweise hinter einem Join oder einem Datensatz befinden kann, wird bereitgestellt, und Datenverträge haben einen Lebenszyklus, richtig?
Wie bei Datenprodukten wird es die Möglichkeit geben, verwalten Datenprodukt von seiner Entstehung bis zu seiner Löschung am Ende seiner Nutzungsdauer zu verwalten . Daten sind keine statische Angelegenheit. Eine der Fragen, die oft gestellt wird, lautet: Habe ich meine Daten am richtigen Ort?
Aber, nun ja, vielleicht heute, aber haben Sie über Abstammung nachgedacht und haben Sie über Metadaten nachgedacht? Haben Sie darüber nachgedacht, was diese Daten tatsächlich bedeuten und wie sie klassifiziert werden? Denn dies hat Auswirkungen darauf, wer Zugang zu einigen dieser Datensätze oder einigen der Datenprodukte erhält, wie lange sie diese nutzen können und zu welchen Zwecken.
Hier kommt der Vertrag ins Spiel, richtig? Damit soll sichergestellt werden, dass die Bedingungen, zu denen das Datenprodukt bereitgestellt wird, bei der Lieferung des Datenprodukts auch tatsächlich eingehalten werden.
Aber wo Daten gespeichert sind und wie sie verwaltet werden, ist komplex, wenn die Daten komplex und unübersichtlich sind, und wir versuchen, all das zu vereinfachen. Nach unserer Auffassung sollten Daten also an ihrem natürlichen Speicherort bleiben. Wenn Sie also Salesforce-Daten verwenden, lassen Sie sie in Salesforce, richtig?
Wenn Sie diese Daten in ein dashboard integrieren möchten dashboard Sie präsentieren, dann extrahieren wir die für das dashboard benötigten Daten dashboard Salesforce und fügen sie dort ein. Wir haben jedoch festgestellt, dass die Leute riesige Datensümpfe, sogenannte Data Lakes, anlegen, die mit allen möglichen Daten verschmutzt sind. Ich mag Datensümpfe. Ich mag das Wort.
Was wir also tun möchten, ist, das Ganze so sauber und einfach wie möglich zu halten, indem wir die Daten dort belassen, wo sie natürlich hingehören, und dann die Möglichkeit bieten, die Governance darüber zu legen.