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.
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.
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:
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:
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.
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.
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.
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:
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.
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.