Warum eine strukturierte Datendesignstrategie wichtig ist: Ein Beispiel

Hintergrund

In den beiden vorherigen Artikeln haben wir uns auf Überlegungen zum datengesteuerten Design konzentriert, und insbesondere darauf, wie Geschäftsdaten einen latenten Geschäftswert darstellen. Die Kernbotschaft lautete, dass eine strukturierte Datenarchitektur die technische Grundlage darstellt, die die Extraktion dieses inhärenten Werts ermöglicht. Der Schwerpunkt dieser Artikel lag jedoch auf der Einführung der relevanten Themen auf konzeptioneller Ebene. Heute möchte ich die Konzepte anhand eines konkreteren und nachvollziehbareren Beispiels demonstrieren: einer Geschichte darüber, wie man über die Architektur einer Anwendung nachdenken könnte, die einer „Data First“-Mentalität entspricht.

Aber zuerst: Warum sollte mich das interessieren?

Bevor wir uns jedoch direkt auf die Geschichte stürzen, fassen wir noch einmal zusammen, warum Daten heute wichtiger sind als in der Vergangenheit.  Viele Unternehmen sammeln und speichern Daten schon immer, und zwar in erster Linie zum Selbstzweck und aus Governance-Gründen, beispielsweise zu Prüfungs- und Compliance-Zwecken. Aus diesem Grund wurde die Datenerfassung und -speicherung in der Vergangenheit als eine Art „Steuer“ auf Geschäftstätigkeiten betrachtet, die kaum einen direkten operativen Geschäftswert aufwies.

Was sich jetzt geändert hat, ist die umfassendere Erkenntnis, dass die gesammelten Daten genutzt werden können, um Geschäftsprozesse zu optimieren und das Kundenerlebnis zu verbessern. Laut einer aktuellen Umfrage unter digitalen Einzelhandelsunternehmen waren diese beiden Ziele – die Verbesserung der Geschäftsprozesse und des Kundenerlebnisses – für 57 % aller Befragten die Haupttreiber der digitalen Transformation. Unternehmen . Die entscheidende Beobachtung und der Kern der Frage, „warum es wichtig ist“, besteht darin, dass datengesteuerte Workflows sich sowohl auf das Geschäft in nach außen gerichteten Bereichen (wie etwa beim Kundenerlebnis) als auch in den nach innen gerichteten Bereichen, nämlich auf die zentralen Geschäftsprozesse, auswirken. Aus diesem Grund ist eine durchdachte und gezielte Datenstrategie von grundlegender Bedeutung für die Qualität und Kosteneffizienz der wichtigsten Geschäftsabläufe. Wenn die Workflows darüber hinaus so ausgestattet werden, dass sie die beobachteten Datenabfälle an eine Infrastruktur zur Datenerfassung und -analyse übertragen, können die Workflows selbst kontinuierlich analysiert und verbessert werden, was zu ständig anpassbaren und optimierten Geschäfts-Workflows führt.

Nebenbei bemerkt war die größte Sorge dieser Unternehmen im Zusammenhang mit der digitalen Transformation die Gewährleistung der Cybersicherheit dieser digitalen Prozesse. Auch hier kommt diesem Ansatz der Datentelemetrie und -analyse eine Schlüsselrolle zu. Das hebe ich mir aber für einen anderen Artikel auf. 

Die Anwendung: Restaurantbestellung und -lieferung

Um mit unserem Gedankenexperiment fortzufahren, habe ich eine Geschichte ausgewählt, mit der sich viele von uns im heutigen, an das Coronavirus angepassten Lebensstil wahrscheinlich identifizieren können – eine Anwendung, die einen Onlinedienst für die Bestellung und Lieferung von Restaurantessen bereitstellt. Die Essensbestellung erfolgt online bei einem vom Kunden bestimmten Restaurant und der Nutzer kann sich dafür entscheiden, die Bestellung direkt vom Kunden abholen zu lassen oder auch die Lieferung über den Service durchführen zu lassen.

In dieser Geschichte spielen wir die Rolle des Anwendungseigentümers. In dieser Rolle müssen wir viele unterschiedliche Anliegen berücksichtigen, die wir in zwei Bereiche unterteilen: erstens erforderliche operative Aktivitäten und zweitens zukunftsweisende strategische Anliegen.

Der erste Satz – erforderliche Betriebsaktivitäten – beinhaltet Anliegen wie:

• Suche und Charakterisierung von Restaurants inklusive Standort und Öffnungszeiten
• Zusammentragen von Daten zu Menüpunkten und Preisen
• Restaurants über Bestellungen informieren
• Zahlungsabwicklung
• Erfassung von Daten zur Verfügbarkeit von Personalressourcen zum Abholen und Ausliefern von Bestellungen
• Verfolgung der Bestellbereitschaft und des Lieferstatus

Der zweite Bereich der Sorgen betrifft weniger den alltäglichen Betrieb, ist aber nicht weniger wichtig. Wenn diese Probleme im Vorfeld berücksichtigt werden, kann das Unternehmen flexibel und anpassungsfähig sein und sich kontinuierlich verbessern. Beispiele für diese Art von Bedenken sind:

• Wie lässt sich die Nachfrage prognostizieren? Dabei kann es sich einfach um die Gesamtnachfrage nach Tageszeit/Woche handeln, aber auch um eine feinere Aufschlüsselung, beispielsweise pro Restaurant.
• Welche Art von Tools, Prozessen oder Arbeitsabläufen liefern meinen Lieferanten (Restaurants) Geschäftseinblicke?
• Wie können die Preise – entweder für das Essen oder für die Lieferung – dynamisch angepasst werden?
• Angenommen, meine Anwendung wird in der öffentlichen Cloud gehostet. Wie können meine Betriebskosten für die Infrastruktur optimiert werden?

Dies ist natürlich nur eine Teilmenge der gesamten Bandbreite unserer Anliegen, aber selbst diese kleinere Menge reicht aus, um eine gute Diskussion zu ermöglichen, die die Bedeutung einer strukturierten Datenarchitektur zur Unterstützung einer erweiterbaren Datenverarbeitungs-Pipeline hervorhebt.

Datenarchitektur oder Datenpipeline/Henne oder Ei

In unserer imaginären Rolle als Anwendungseigentümer können wir bei der Betrachtung unserer allgemeinen Datenstrategie mit der Aufzählung unserer Geschäftsabläufe beginnen und die Datenverarbeitungsanforderungen jedes einzelnen ermitteln. Ein Beispiel hierfür ist der Workflow, der geöffnete Restaurants in der Nähe lokalisiert und dann Menüoptionen und Preise für jedes Restaurant präsentiert. Dazu müssten die Restaurants nach Standort und Öffnungszeiten gefiltert und dann Menüoptionen für ein speziell ausgewähltes Restaurant gesucht werden, möglicherweise auch gefiltert nach der Verfügbarkeit von Lieferfahrern. Und wir könnten dies für jeden Arbeitsablauf tun – Zahlungsabwicklung, Zuordnung von Fahrern zu Lieferungen usw.

Oder, ebenso sinnvoll, wir könnten unsere Überlegungen mit den grundlegenden Daten-„Atomen“ beginnen, also den Datenbausteinen, die benötigt werden. Wir würden die wichtigen Datenatome identifizieren und aufzählen und dabei besonders auf eine einheitliche Darstellung und konsistente Semantik dieser Datenatome sowie auf das zur Unterstützung unserer Geschäftsabläufe erforderliche Metadatenvokabular achten. Beispiele für Datenatome in unserer Beispielanwendung wären: Standortdaten für Restaurants, Kunden und Fahrer; Lebensmittel, die für Menüs und Rechnungen benötigt werden; Zeit, die zum Filtern und Verfolgen der Lieferqualität verwendet wird; und Zahlungsinformationen im Zusammenhang mit Zahlungsabläufen für Kunden und Fahrer.

Welchen dieser beiden potenziellen Ausgangspunkte – die Datenverarbeitungs-Pipeline der Workflows oder alternativ die Daten-„Atome“ – wir für unsere Datenstrategie verwenden sollen, ist eine Henne-Ei-Frage. Beide Perspektiven sind nützlich und, was noch wichtiger ist, sie sind voneinander abhängig. Wir können nicht über die Datenverarbeitungspipeline nachdenken, ohne über die zugrunde liegenden Datenatome nachzudenken, und wir können auch die Datenarchitektur entwickeln, ohne die Anforderungen der Verarbeitungspipeline zu berücksichtigen. Dennoch würde ich im Allgemeinen einen Ansatz empfehlen, bei dem man zunächst die Workflows durchläuft, um die Datenatome aufzuzählen, sich dann aber dem strukturierten Entwurf der Datenarchitektur widmet, bevor man mit dem detaillierten Entwurf der Datenpipeline beginnt. Dies liegt daran, dass die Arbeitsabläufe dynamischer sind. Im Zuge der Geschäftsentwicklung werden Arbeitsabläufe hinzugefügt und geändert, während die zugrunde liegenden Daten über mehr Historie und Trägheit verfügen. Aus diesem Grund profitiert die Datenarchitektur stärker von vorausschauender Planung.

Anwendung einer ganzheitlichen Datenarchitektur und eines Pipeline-Ansatzes auf konkrete Beispiele

Um auf unser Beispiel zurückzukommen: Nehmen wir an, dass wir als Anwendungseigentümer einen recht umfassenden Überblick über die wichtigsten geschäftskritischen Arbeitsabläufe und die Datenatome haben, die zu ihrer Unterstützung erforderlich sind. Zu Beginn dieser Diskussion hatten wir einige der grundlegenden Datenelemente identifiziert, die für unsere Arbeitsabläufe erforderlich sind: Standort, Zeit, Lebensmittel und Zahlungsinformationen. Und um es noch einmal aus früheren Artikeln zusammenzufassen: Die Datenarchitektur sollte drei wichtige Ziele ermöglichen: Einheitlichkeit der Syntax, Konsistenz der Semantik und ein Metadatenvokabular für die Argumentation und Verwaltung der Daten. Wir können diese Prinzipien nun anwenden, um Überlegungen zur Datenarchitektur für die spezifischen Datenatome zu diskutieren, die im heutigen Beispiel aufgezählt sind.

Wenn Sie näher auf das Standortdatenatom eingehen, berücksichtigen Sie jedes der drei wichtigsten Ziele der Datenarchitektur.

• Erstens: Was ist die einheitliche Syntax zur Datendarstellung ?
  Ein erster Gedanke könnte darin bestehen, den Standort anhand der Straßenadresse darzustellen, da Restaurants und Kunden ihren Standort typischerweise auf diese Weise darstellen. Bedenken Sie jedoch, dass bei der Verfolgung von Zustellern Standortanforderungen bestehen – diese sind oft unterwegs, möglicherweise auf einer großen Autobahn oder an einem Ort, der nicht genau durch eine Straßenadresse beschrieben ist. Stattdessen wäre die Angabe von Längen- und Breitengrad möglicherweise eine bessere Möglichkeit, den Standort für diesen Arbeitsablauf darzustellen. Dieses Format würde auch für Restaurant- und Kundenstandorte funktionieren. Da Fahrer jedoch normalerweise zu einem Restaurant oder zum Standort eines Kunden navigieren müssen, muss es dennoch eine Möglichkeit geben, den Standort des Fahrers (Breiten-/Längengrad) mit dem Standort des Kunden (Straßenadresse) zu verknüpfen. Daher wäre es möglicherweise eine überlegtere Lösung, alle Standortdaten nach Längen- und Breitengrad zu normalisieren (die erforderliche „kanonische“ Darstellung), dabei aber die Möglichkeit zu haben, Straßenadressen bei der ersten Angabe der Adresse in Längen- und Breitengrade umzuwandeln (ein „Aufnahme“-Workflow).
• Die zweite Überlegung betrifft die konsistente Semantik . 
  Vorausgesetzt, der Standort ist als Breiten-/Längengrad normalisiert, ist dies relativ unkompliziert, da es sich dabei um einen etablierten Standard mit eindeutiger Interpretation handelt. Ein weiterer Aspekt konsistenter Semantik betrifft jedoch die Präzision – die implizite Genauigkeit der Daten. Da GPS- und Kartendaten grundsätzlich eine begrenzte Genauigkeit aufweisen, können wir den Standort je nach Qualität der Datenquelle entweder mit einer konstanten Genauigkeit (z. B. auf die nächste Bogensekunde genau, also ungefähr 100 Fuß) oder mit variabler Genauigkeit angeben. Wenn wir uns aus Flexibilitätsgründen für Letzteres entscheiden, müssen wir die Genauigkeit jeder Standortdateninstanz mithilfe der im Folgenden beschriebenen Metadaten kommentieren.
• Das dritte Ziel der Datenarchitektur besteht in der Fähigkeit, die gesammelten Datenelemente zu kommentieren und anzureichern.
  Im Falle des Standorts kann dies, wie bereits erwähnt, die Genauigkeit der Daten umfassen. Darüber hinaus möchten wir den Standort möglicherweise aus Gründen der Benutzerfreundlichkeit mit einer Straßenadresse versehen, insbesondere damit die aufgenommenen Adressdaten erhalten bleiben. Dies ist insbesondere dann wichtig, wenn mehrere Straßenadressen demselben Längen- und Breitengrad zugeordnet sind, wie zum Beispiel bei einem Apartmentkomplex. Eine weitere Anreicherung kann ein Zeitstempel sein, der angibt, wann das Standortdatenfeld erfasst wurde. Dies kann für einen Fahrer in Bewegung relevant sein, da Standortdaten dort schnell veralten.

Wir haben nur über die Anforderungen für den Standort gesprochen und könnten jetzt eine ähnliche Übung für jedes der anderen Datenfelder durchgehen. Anstatt jedoch alle Problembereiche für jedes einzelne Datenatom aufzuzählen, werde ich stattdessen einige wichtige Beobachtungen hervorheben:

• Bezüglich des Zeitdatenatoms : Die Darstellung eines Zeitwerts ist bekanntermaßen schwierig. Es kann sowohl syntaktisch variieren (z. B. 24-Stunden-Format vs. 12 Stunden plus AM/PM) und semantisch (z. B. das Konzept von Zeitzonen und Variationen bei der Beobachtung der Sommerzeit). Daher muss die Zeitdarstellung wahrscheinlich kanonisiert werden (z. B. durch Normalisierung auf GMT oder Sekunden „seit Epoche“ für Unix/Linux-Benutzer).
• Die Dateninstanzen für Lebensmittelartikel können sehr unterschiedlich sein und unterschiedliche Anforderungen haben. Da die Datenatome häufig eine freie Form haben, ist ein kanonisches Metadatenvokabular nützlicher als der Versuch einer einheitlichen Syntax. Einige Metadatenfelder wären für statische Eigenschaften pro Artikel, wie „muss kalt gehalten werden“ oder „enthält Nüsse“, aber andere Metadatenfelder würden für Informationen pro Instanz (pro Bestellung) zum Lebensmittel erforderlich sein, wie „Schärfegrad“ oder „bevorzugte Gewürze“. In beiden Fällen erfordert das Entwurfsziel eine einheitliche Syntax und konsistente Semantik für die Metadatenfelder, sodass sie für alle Menüelemente gemeinsam genutzt werden können.
• Weitere wichtige Überlegungen betreffen die Datenkonformität und -verwaltung. Ein Aspekt ist die Richtlinie zur Datenaufbewahrung, wonach einige Felder – wie etwa die IP-Adresse eines Kunden oder der Standortverlauf eines Fahrers – nur für einen kurzen Zeitraum gespeichert werden können. Eine weitere häufige Überlegung besteht darin, dass für einige Felder Sicherheits- oder Datenschutzbeschränkungen gelten können. Ein Beispiel hierfür sind Zahlungsinformationen . Die Metadatenerweiterung ist für beide Fälle eine Lösung. Metadaten sollten verwendet werden, um eine IP-Adresse oder einen Standortwert mit einer Datenablaufzeit für die Datenaufbewahrung zu versehen. Bei Zahlungsinformationen können Metadaten verwendet werden, um Sicherheitsanforderungen mitzuteilen – etwa die Notwendigkeit der Verschlüsselung ruhender Daten – oder um Geolokalisierungsbeschränkungen des persistenten Datenspeichers anzugeben.

Dieses Beispiel hat zwar nur an der Oberfläche gekratzt, aber es hat viele der Probleme aufgezeigt, die mit realen Szenarien verbunden sind. In der realen Welt wäre der Prozess der Durchdenkung der Datenstrategie hier jedoch nicht beendet, sondern iterativ und fortlaufend. Während die Datenelemente in die Datenverarbeitungs-Pipelines eingespeist werden, die die Geschäftsabläufe verkörpern, würden iterative Anpassungen und Verbesserungen an der Datenarchitektur vorgenommen. Wenn vorhandene Workflows verbessert und neue Workflows hinzugefügt werden, stellen wir fest, dass neben neuen Datenatomen auch zusätzliche Anforderungen an die Datenarchitektur für vorhandene Datenatome gelten.

Abschließende Gedanken

Obwohl dieses Beispiel der Kürze halber gestrafft wurde, veranschaulicht es dennoch die wichtigsten Prinzipien rund um die Zuordnung von Workflows zu ihren Auswirkungen auf die Datenarchitektur. Der Prozess beginnt immer mit der Betrachtung der Geschäftsanforderungen – des Kundenerlebnisses und der Geschäftsprozesse, die zur Erfüllung dieser Anforderungen erforderlich sind. Die Geschäftsprozesse wiederum definieren die Elemente eines Geschäftsvokabulars. Auf der nächsten Spezifitätsebene werden die Prozesse einer Datenpipeline zugeordnet, die ein Datenvokabular nutzt. 

Das Schlüsselprinzip besteht darin, dass die robuste Datenarchitektur – die Syntax, Semantik und Anmerkungen definiert – eine Grundlage bildet, auf der die Datenpipeline effizient erweitert und neue Workflows problemlos hinzugefügt werden können. Auf der Abstraktionsebene bedeutet dies, dass vorhandene Geschäftsprozesse problemlos geändert und neue oder entstehende Geschäftsprozesse schnell online gebracht werden können. Wenn es hingegen in einem dieser Bereiche (Datenvokabular, Datenarchitekturrahmen oder die Verknüpfung dieser Bereiche mit den Geschäftsanforderungen) nicht gelingt, wohlüberlegte Entscheidungen zu treffen, führt dies letztlich zu einem instabilen und fragilen System, das sich nicht flexibel an neue Geschäftsanforderungen anpassen kann.