Das Schema: Enabler für Agilität

Zeichnung: Christian Erni
"The mind is like a monkey": Simon Hefti liebt Unstrukturiertheit, wenn es um Daten geht bevorzugt er aber Schemen.
 
"The mind is like a monkey and jumps from tree to tree". Das stimmt sicherlich für meinen Geist; am Liebsten folge ich laufend neuen Gedanken. Mit andern Worten: ich liebe die Unstrukturiertheit, sie beflügelt mich. Deshalb beschäftigt mich seit langem ein Widerspruch. Wenn es um Daten geht, bevorzuge ich die klare Strukturierung, wie sie beispielsweise ein relationales System vorgibt, ein sogenanntes Schema. Ich schätze daran die gedankliche Schärfe, die logische Stringenz: ähnlich wie eine mathematische Formel drückt das Schema knapp und klar aus, was gemeint ist.
 
Nehmen wir ein einfaches Beispiel: den Kunden. Eine gängige Definition lautet: Der Kunde ist eine natürliche oder juristische Person, die Güter oder Dienstleistungen kauft, die eine Firma anbietet. Aber für die datenbasierte Wertschöpfung müssen wir genauer sein. Vielleicht hat der Kunde eine Kunden-Nummer, vielleicht einen Namen, sicher (wie die Definition vorgibt) entweder eine Beziehung zu einer Person oder einer Firma. Der Kunde hat Offerten, Bestellungen, Lieferungen, Zahlungen, und diese wiederum sprechen von Produkten, Liefer- und Zahlungsbedingen und so weiter und so fort. Diese Sachverhalte müssen bekannt sein, wenn die Datenanalyse werthaltig sein soll. Mit anderen Worten: durch das Erstellen des Daten-Schemas wird die Definition des Kunden zunehmend schärfer.
 
Fremdgesteuert und langsam?
Das ist sicher ein grosser Vorteil des Schemas. Es gibt aber auch gewichtige Kritik, im wesentlichen zwei Punkte: Fremdgesteuert und langsam.
 
Fremdgesteuert, weil die Data Governance Abteilung die Bedürfnisse der Analyse nicht kennt oder nicht abdecken kann. Langsam, weil die Umsetzung in einer ohnehin bereits überlasteten IT-Abteilung erfolgen muss.
 
Um beweglich zu bleiben, haben zum Beispiel Data Science Abteilungen begonnen, ihre Datenbestände selbst zu verwalten. Ermöglicht hat dies der Data Lake. Aber bei all meiner Liebe für wenig Strukturen: Dieser Weg funktioniert auch nur, wenn er begleitet wird.
 
Es ist ein wenig wie in der Bibliothek; wenn die Bücher schön in den Regalen eingeordnet sind, dann ist das gesuchte Buch schnell gefunden; aber das Einordnen ist ein aufwändiger Prozess. Und wenn sogar das Ordnungssystem verändert werden soll, kann es gut und gern sein, dass die Bibliothek für einen Monat ganz geschlossen wird, bis die ganze Bibliothek wieder richtig organisiert ist. Ganz klar, dass die Benutzer verärgert sind. Was allerdings ebenfalls ärgert: Man weiss zwar, dass das Buch irgendwo ist, aber man muss die gesamte Bibliothek durchsuchen, bis man fündig wird. Es gilt also, die Bibliothek so zu organisieren, dass beide Ansprüche – kurze Time to Market und schnelles zur Hand haben – erfüllt werden.
 
Spätestens, wenn die Vorbereitung (wo sind meine Daten? Was bedeutet dieses Attribut schon wieder? Und wie verknüpfe ich das mit der Bestellung?) mehr als 50 Prozent der gesamten Analysezeit in
Simon Hefti
Anspruch nimmt, besteht Handlungsbedarf.
 
Daten-Architekt und -Nutzer müssen sich finden
Und glücklicherweise gibt es einen Weg, meinen Widerspruch zwischen Freude am Chaos und Liebe zur Struktur aufzulösen: Der Daten-Architekt und der Daten-Nutzer müssen einen Schritt aufeinander zu machen.
 
Der Daten-Architekt muss verstehen, dass die “Bibliothek” immer geöffnet sein muss, dass mehrere Ordnungssysteme parallel nebeneinander existieren müssen, und dass Neuerscheinungen sofort in der Bibliothek aufgenommen werden müssen.
 
Der Daten-Nutzer muss verstehen, dass die Pflege der Daten, die die Ordnung in der Bibliothek ermöglichen, werthaltige Arbeit ist, die Aufmerksamkeit erfordert.
 
Die Werkzeuge dazu bestehen – apache avro und atlas seien als Stichworte genannt, und auch der Ansatz, den Bau der Data Pipeline grösstenteils automatisiert zu generieren, hilft beiden.
 
Andere Einwände, warum sich die Beiden nicht finden könnten, greifen nicht.
 
Zum Beispiel spielt der Strukturierungsgrad der Daten keine Rolle.
 
Mit unstrukturierten Daten sind Daten wie Bilder und Film, Ton (zum Beispiel Aufnahmen von Gesprächen mit Kunden im Call Center) oder Texte (zum Beispiel Verträge oder Anfragen per E-Mail) gemeint. Ähnlich wie Wasser in Eis-, flüssiger und Dampfform auftreten kann, können Daten in verschiedenen Zuständen auftreten. Um den Aggregatzustand zu ändern, muss Energie aufgewendet werden. Um beispielsweise die Tonalität des Gesprächs zu eruieren, muss (übrigens spannende) Arbeit geleistet werden. Mit anderen Worten: Wenn Daten noch unstrukturiert sind, so wurden sie noch nicht bearbeitet; nichtsdestotrotz gehören sie sowohl in die Bibliothek wie auch in das Ordnungssystem.
 
Auch das Problem von kryptischen oder schlecht einsehbaren Ordnungssystemen lässt sich leicht beheben. Sowohl für gestandene wie für neue Mitarbeiter lohnt es sich, diese Information im Intranet zugänglich und interaktiv nutzbar zu machen. Sind die Metadaten bekannt, so lässt sich eine solche Dokumentation mit Hilfe moderner Browser-Technologien (unter anderem cytoscapejs und klay) leicht generieren.
 
Die Anforderungen an Agilität und Stabilität gleichzeitig zu erfüllen, ist anspruchsvoll. Jede Firma und jede Abteilung, die sich mit Daten befasst, kennt das Thema. Es ist deshalb wichtig, eine Architektur und eine Kultur zu entwickeln, die an den richtigen Stellen streng und strukturiert ist, und gleichzeitig beweglich den Spielraum bietet, den das Geschäft benötigt – die also, übertragen gesprochen, meinem “Affen” erlauben, frei von Baum zu Baum zu springen, aber eben auch Bäume anbietet, an denen sich der Affe überhaupt erst halten kann. (Simon Hefti)
 
Über den Autor:
Simon Hefti ist Gründungspartner von D ONE, dem Beratungsunternehmen für datenbasierte Wertschöpfung. In seiner Dissertation hat er den Ursprung des Sonnenwindes erforscht. Als Unternehmer und Business Scientist begleitet er Kunden aus unterschiedlichsten Branchen in technischen, konzeptionellen und organisatorischen Fragen.