"Single View" auf das eigene Business

by Marc-David Militz Forum: MongoDB Theorie

Moderne Firmen sind heute "datengetrieben". Die Fähigkeit Daten schnell zu bekommen und aufgrund der Daten Entscheidungen fällen zu können ist zu einem Schlüsselvorteil im Wettbewerb geworden. Allerdings verbergen sich geschäftliche Daten oft in Silos und sind fragmentiert. Um daraus einen Vorteil ziehen zu können benötigt man einen "Single View" auf die Daten.

Viele Firmen haben einen komplizierten Prozess um ihre Daten zu managen. Dazu gehören normalerweise unterschiedliche Datenquellen mit unterschiedlichen Datenstrukturen, Eingabe- und Transformation, das laden in eine Datenbank für den Geschäftsbetrieb oder in Applikationen die für den Geschäftsbetrieb unerläßlich sind. Im Anschluß wollen Analytics, Business Intelligence (BI) und Reporting Tools auf diese Daten zugreifen, was dann oft den Einsatz eines Data Warehouses oder Data Lakes notwendig macht. All diese Anwendungs- und Datenbankschichten müssen mit den Sicherheitsrichtlinien in Einklang gebracht werden, den Standards für die Datenverwaltung und anderen Anforderungen des Betriebs entsprechen.

Viel zu oft führt diese Komplexität dazu, daß die Daten in Silos enden. Viele Systeme werden gebaut um die augenblicklichen Anforderungen zu erfüllen, anstatt, durch vorausschauendes Design, auf den aktuellen Status gebracht zu werden um auch die Anforderungen neuer Services in der Zukunft unterstützen zu können. Es kommen auch immer wieder neue Datenquellen hinzu, z.B. durch eine Firmenübernahme oder eine neue Abteilung im Unternehmen. Informationen über eine einzelne "Business Entity", wie einem Kunden, enden so schließlich in dutzenden unterschiedlicher, nicht vernetzter, Systeme.

"Matt Keep", Director of Product and Market Analysis bei MongoDB sagt: "Wir wissen daß Daten überall um uns herum sind. Die Menge wächst um 40% bis 50% jedes Jahr. Mobilgeräte, Internet, Sensordaten, Soziale Netzwerke. All diese Daten in einem Single View zusammenzufassen, wird mehr und mehr zu einer Priorität für Unternehmen. Die Aufgabe ist sehr komplex, Silodaten sind oftmals kaum konsistent und es ist schwer diese verwendbar zu machen. Firmen versuchen schon seit langer Zeit solche Single View zu bauen."
Aus diesem Grund hat man bei MongoDB jetzt einen 10-Stufen-Plan, zur Erstellung eines solchen "Single Views" erstellt, der auf den harten Erfahrungen von vielen Kundenprojekten basiert.

• Schritt 1: Projektumfang und Finanzierung festlegen

Kunden starten solche "Single View" Projekte oft mit sehr ambitionierten Plänen. Es ist gut eine Vision zu haben, aber es ist meist Fehler einfach alle Daten die man hat in solch einen "Single View" zu werfen. Bereits in der ersten Projektphase jede einzelne Information sofort zu bekommen ist wie den Ozean zu kochen zu bringen. Vor dem Rennen sollte man erst mal das Laufen lernen, deshalb ist meist der erfolgreichere Weg sich auf einzelne Geschäftsprobleme zu fokussieren. Mit einem spezifischen Anwendungsfall zu starten hat den Vorteil mit einem definierten Ausschnitt an Daten zu arbeiten. Das macht auch die Erfolgsmessung wesentlich einfacher.
Außerdem werden auf diese Weise die wichtigsten Interessengruppen identifiziert, die von Ergebnis profitieren können. Diese sind wichtig um die Ressourcen zu bekommen, die notwendig sind um das Projekt erfolgreich zu machen.


• Schritt 2: Nutzer der Daten identifizieren

Sobald man das Geschäftsproblem, das man zu lösen versucht, identifiziert hat muß man im nächsten Schritt verstehen wer die Nutzer des "Single Views" sind. Man muß herausfinden, wer sie sind, wie sie arbeiten und wie man ihnen die Arbeit erleichtern kann. Am besten verbringt man Zeit mit ihnen, sieht sich an wie sie nach Daten suchen. Machen sie Text Suchen? Suchen sie nach Kundennummern oder IDs? Hierzu kann man gar nicht genug Informationen sammeln. Beim Versicherer MetLife haben die MongoDB Ingenieure z.B. herausgefunden, daß Call Center Agents bis zu 15 verschiedene Bildschirme aufrufen mußten, bis sie spezifische Kundenfragen beantworten konnten. Dadurch daß man beobachtet hat welche Fragen von den Kunden kamen und wieviel Aufwand es macht diese zu beantworten, war es möglich eine Applikation zu bauen die dieses deutlich vereinfacht hat.


• Schritt 3: Datenquellen identifizieren

Der dritte Schritt hängt oftmals mit dem zweiten zusammen und besteht darin, die benötigten Datenquellen zu identifizieren. Oftmals gibt es die Daten bereits, allerdings muß man herausfinden wo diese sind und wie man rankommt. Dazu kann es notwendig sein, eine bestehende Applikation zu erweitern oder manuelle Prozesse zu digitalisieren.


• Schritt 4: Datenverwalter ernennen

Die ersten drei Schritte dienen der Erforschung unseres "Single View" Projektes. Dabei geht es nur darum einen Rahmen von Anforderungen zu definieren. Im vierten Schritt treten wir in die Entwicklungsphase ein indem wir Datenverwalter ernennen, die für die Daten in den Quellsystemen verantwortlich sind. Die Datenverwalter sind Schlüsselpersonen für das "Single View" Projekt und die weitere Wartung. Die Datenverwalter wissen in welchen Tabellen man die Daten findet, wie diese formatiert sind und wie man sie extrahiert. Sie wissen auch ob es einen sauberen Weg gibt an die Daten heran zu kommen, ohne das Quellsystem zu stören.


• Schritt 5: das "Single View" Modell entwickeln

Dieser Schritt ist essentiell für die weiteren, aber es nicht so schwierig, wenn man die vorherigen Schritte erfolgreich abgeschlossen hat. Es ist wichtig exakt festzulegen welche daten verpflichtend und welche optional sind. Dann muß man herausfinden was indexiert werden muß um Abfragen zu beschleunigen. An dieser Stelle helfen Datenbanken mit einem flexiblen Datenmodell ganz extrem weiter. Alle optionalen Felder können im weiteren Verlauf jederzeit hinzugefügt werden, an dieser Stelle sind erstmal die verpflichtenden Daten essentiell.


• Schritt 6: Daten laden und standardisieren

Sobald man sein "Single View" Datenmodell definiert hat muß man festlegen wie die Daten im "Single View" dargestellt werden. Für die einzelnen Attribute müssen standardisierte Namen festgelegt werden. Felder aus unterschiedlichen Systemen haben oft unterschiedliche Namen z.B. "DoB", "Date of Birth", "Birthdate". Solche Felder müssen vereinheitlicht werden. Alle Daten aus den Quellsystemen müssen auf diese Standards transformiert werden, schon ab dem initialen Laden. Der initiale Ladevorgang kann in Batches erfolgen, was aber immer beliebter wird sind Technologien wie Apache Kafka. Damit wird es möglich die Daten im "Single View" nahezu in Echtzeit zu aktualisieren.


• Schritt 7: Übereinstimmen, zusammenführen und abstimmen

Trotz der Standardisierung der Daten benötigt man noch Algorithmen um die Daten aus unterschiedlichen Systemen zusammen zu bringen. Ein Kunde einmal als "Herr Militz", "Marc Militz" oder "Marc-David Militz" auftauchen. Diese Daten müssen übereinstimmen, zusammengeführt und abgestimmt werden. An dieser Stelle ist es hilfreich eindeutige Identifikationsmerkmal wie Kreditkartennummern oder Telefonnummern zu haben. Datensätze mit ähnlichen Attributen können zu Clustern zusammengefügt werden und durch das Vergleichen der Attribute kann man herausfinden ob es sich um die gleiche Person handelt. Dieser Prozeß muß anschließend automatisiert werden.


• Schritt 8: Architektur Design

Mit dem Design der Architektur beginnt das Deployment des "Single View" Projektes. Die darunterliegenden Systeme müssen den Performance- und Sicherheitsanforderungen entsprechen. Hier müssen nun Maßnahmen zum Datenschutz und zur Verfügbarkeit des Systems implementiert werden.


• Schritt 9: konsumierende Systeme modifizieren

In diesem Schritt sieht man sich die Daten-konsumierenden-Systeme an und stellt sicher, daß diese nur noch auf den "Single View" zugreifen. Normalerweise empfiehlt es sich hierfür RESTful APIs bereit zu stellen, über die die Daten abgerufen werden können.


• Schritt 10: Wartungsprozesse implementieren

Geschäftsanwendungen sind niemals statisch, Sie ändern sich laufend und müssen an die Geschäftsprozesse angepaßt werden. Man kann das perfekte Datenmodell erstellen und stellt nach fünf Tagen fest daß man es ändern muß. Aus diesem Grund braucht man ein flexibles Datenmodell, mit den man sich an die Veränderungen der Quellsysteme leicht anpassen kann. Es ist notwendig die vorherigen Schritte konstant immer wieder zu wiederholen, dazu braucht man Change-Management-Prozesse um sicher zu gehen das der "Single View" aktuell bleibt. Die Datenverwalter müssen dies überwachen und eng mit den Entwicklern des "Single View" zusammenarbeiten.


• Reifegrade des "Single View"

Wenn der "Single View" sich einmal bewiesen und etabliert hat, dann werden die Nutzer schnell unternehmungslustiger in der Anwendung. Es gibt sogar Fälle in denen neue Features zuerst im "Single View" implementiert werden. Anschließend werden in einer Rückwärts-Beladung die Quellsysteme versorgt.

Business Case: AO.com
https://www.mongodb.com/blog/post/aocom-turns-to-mongodb-to-build-a-single-customer-view

MongoDB Whitepaper: 10-Step Methodology to Creating a Single View of your Business
https://www.mongodb.com/collateral/10-step-methodology-to-creating-a-single-view-of-your-business

Qualiero bietet eine Vielzahl interessanter Classroom Trainings zu solchen Themen an.
z.B. Data Mining und Data Science mit MongoDB und Apache Spark
https://www.qualiero.com/lerninhalte/classroom-trainings/data-mining-und-data-science-mit-mongodb-und-apache-spark.html

Copyright: Alle Grafiken in diesem Beitrag stammen von MongoDB