Die grundlegende Rolle der Datenarchitektur (in einer auf Analytik ausgerichteten Welt)

Es gibt ein Sprichwort beim Militär: „Amateure diskutieren Taktiken, aber Profis studieren Logistik.“ Dieser Gedanke mag manche auf den ersten Blick überraschen, wenn man an Lees Brillanz in Chancellorsville oder Hannibals Genie während der Punischen Kriege denkt. Die Geschichte zeigt jedoch, dass weder Lee noch Hannibal ihre jeweiligen Kriege gewonnen haben. Der Hauptgrund dafür war die Logistik: die Fähigkeit, eine Armee zur richtigen Zeit und am richtigen Ort mit Nahrungsmitteln, Kleidung und Waffen zu versorgen. Trotz brillanter Taktik war es die Logistik, die letztlich über den Sieg entschied. Mit anderen Worten: Durch die Taktik können Sie Ihre Mittel auf dem Spielfeld optimal einsetzen, aber die Logistik ermöglicht Ihnen in erster Linie, auf dem Spielfeld zu sein und zu bleiben.

Mir gefällt der militärische Vergleich, da er meiner Meinung nach Parallelen zu der Art und Weise aufweist, wie datengesteuerte Lösungen heutzutage häufig dargestellt werden. Der Glanz der „Taktiken“ – fortgeschrittene KI-Techniken wie Deep Learning, Random-Forest-Klassifizierung, Gradient Boosting und so weiter – überschattet regelmäßig die weniger attraktive „Logistik“ der Datenarchitektur-Grundlagen, die diese fortgeschrittenen Techniken ermöglichen.

Der erste Schritt in einer Diskussion über Datenarchitektur besteht darin, zu definieren, was der Begriff „Datenarchitektur“ umfasst. Es überrascht nicht, dass die Antwort differenziert ausfällt – sie ist vielschichtig und facettenreich. Um die Diskussion fundiert zu gestalten, ist es sinnvoll, sich die Reise der erfassten Telemetriedaten zunächst einmal vor Augen zu führen. Das folgende Diagramm zeigt eine Datenpipeline auf hoher Ebene und hebt die Berührungspunkte zwischen der Pipeline und der Grundlage der Datenarchitektur hervor.

Der Weg jedes Datenelements beginnt mit seiner Erstellung. Oft folgt darauf eine gewisse Vorverarbeitung, bevor es serialisiert und an einen Datensammler/-aggregator übertragen wird, der sich normalerweise in der Cloud befindet. Als Nächstes kann der Datensammler selbst (nach der Deserialisierung und Aufnahme) einige zusätzliche Verarbeitungs- und Anreicherungsvorgänge durchführen, bevor er die Daten an einen persistenten Datenspeicher liefert und/oder in eine Datenanalyse-Pipeline einspeist. Abschließend werden die angereicherten/analysierten Ergebnisse über eine Visualisierungsplattform der menschlichen Nutzung zugänglich gemacht und können sogar von automatisierten Systemen in Form von Feedback-Eingaben für selbstoptimierende oder selbstreparierende geschlossene Kreislaufsysteme genutzt werden.

Nachdem der Kontext der Datenpipeline geklärt ist, können wir nun zur Frage zurückkehren, was mit „Datenarchitektur“ gemeint ist. Die erste Antwort, auf der oberflächlichsten Ebene, konzentriert sich auf die Datendarstellung und Serialisierungssyntax. Wenn ein Datenereignis beispielsweise ein Objektfeld mit dem Titel „Kunde“ enthält, bestimmt die syntaktische Ansicht, ob diese Daten als Zeichenfolge, als ganzzahlige UUID oder etwas anderes dargestellt werden.

Wenn wir jedoch etwas tiefer graben, geht es bei einer zweiten Antwort um mehr als bloße Syntax. Es geht um die Semantik der Daten, d. h. um eine klar definierte und konsistente Interpretation des Dateninhalts. Nehmen wir noch einmal das Feld „Kunde“ als Beispiel an und gehen Sie davon aus, dass die syntaktische Frage beantwortet wurde – dass das Datenelement tatsächlich als Zeichenfolgenfeld definiert wurde. Als nächstes muss die Datenarchitektur in der Lage sein, die Bedeutungs-/Interpretationsfrage zu beantworten: Handelt es sich bei der Semantik um den Namen einer Einzelperson oder um einen Firmennamen? Wenn es der Name einer Person ist, ist es <Nachname> oder <Vorname> oder beides?  In Kombination mit einer einheitlichen Syntax ermöglicht eine konsistente Semantik der Datenpipeline, Funktionen wie Datenfilterung und -aggregation generisch und robust auszuführen, basierend auf einer kohärenten logischen Interpretation des Dateninhalts. Darüber hinaus kann der Datenspeicher auch problemlos föderierte Datenabfragen über verschiedene Instanzen der Datenerstellungspipeline hinweg durchführen, solange die erstellten Daten einer konsistenten Syntax und Semantik folgen.

Und schließlich: Wenn man noch tiefer gräbt, ist es in vielen Fällen wichtig, über eine dritte Funktion in der Datenarchitektur zu verfügen: ein Vokabular, um die Telemetrie zu kontextualisieren und über die Daten selbst nachzudenken – das Metadatenvokabular. Dies ist insbesondere im Zusammenhang mit den Anforderungen an die Datenverwaltung im Unternehmen wichtig, sei es für die Einhaltung von Vorschriften, das Auditing oder sogar für interne Arbeitsabläufe, die ein ganzheitliches Verständnis der in einem Data Warehouse verwalteten Daten erfordern. Die Metadaten liegen häufig in Form von Anmerkungen zu den Daten vor. Diese Anmerkungen weisen die gleiche syntaktische und semantische Konsistenz auf wie die Daten selbst. Beispielsweise würden Metadatenfelder wahrscheinlich verwendet werden, um die Identität der Datenquelle und den Zeitrahmen der Datenverarbeitung für alle erfassten Daten aufzuzeichnen, um die gesetzlichen Anforderungen zur Datenaufbewahrung zu erfüllen.

Eine weitere Möglichkeit, Metadatenfelder im Lexikon eines Datenbeschreibungsschemas zu verwenden, besteht darin, über Aspekte der Datenfelder selbst nachzudenken, wie etwa die Ordinalzahl eines Datenelements oder die Datenschutzsensibilität. Um noch einmal auf unser Beispiel mit dem Datenfeld „Kunde“ zurückzukommen: Metadatenanmerkungen im Datenschema könnten das Datenelement als eindeutig kennzeichnen, während zusätzliche Anmerkungen im Kontext eines Datenstroms (wie etwa bei Einkaufstransaktionen im Einzelhandel) Datenelemente als erforderlich und Singleton kennzeichnen könnten. Mit anderen Worten würden Metadaten verwendet, um anzugeben, dass das Feld „customerID“ eindeutig sein muss (als primärer Datenbankschlüssel verwendbar) und dass jedem Einkaufsereignis genau eine „customerID“ zugeordnet sein muss. Der Nutzen der Gesamtheit der Metadatenfunktionen im Kontext der Datenpipeline liegt in der Tatsache, dass sie genutzt werden können, um Anmerkungen zur Datenkonformität hinzuzufügen, ein Lexikon zur Datenanreicherung bereitzustellen und flexible Governance-Workflows für das Data Warehouse zu ermöglichen.

Zusammenfassend ist die Antwort auf die Frage also: Die Frage „Was ist Datenarchitektur?“ besagt, dass es zumindest darum geht, einen Rahmen bereitzustellen, der sowohl syntaktische als auch semantische Konsistenz für die erfassten Daten ermöglicht. Darüber hinaus sollte eine robuste Datenarchitektur auch eine Metadatenstrategie umfassen, die leistungsstark genug ist, um nicht nur Einschränkungen für die Daten festzulegen, sondern auch die Möglichkeit zu bieten, über die Daten selbst nachzudenken. 

Wenn man sich explizit auf eine Datenarchitektur konzentriert und sie gut umsetzt, ähnelt sie in vielerlei Hinsicht einer guten militärischen Logistikinfrastruktur. Ebenso wie im militärischen Kontext stellt es eine Grundlage dar, die die Effizienz und Robustheit aller Komponenten der darauf aufbauenden Systeme vervielfacht, sodass die sichtbareren Systeme ihre maximale Wirkung entfalten können. Im Kontext eines Datenverarbeitungssystems bietet die Datenarchitektur-Grundlage die Basis für flexiblere und leistungsfähigere Modelle zur Datenverwaltung, einen einfacheren Datenaustausch zwischen Datenquellen mithilfe eines robusten Data Warehouse und einen reaktionsschnelleren Ansatz zur Aufnahme neuer Datenfeeds für mehr Geschäftsflexibilität.