Leider unbrauchbar
Vor Kurzem war ich bei einem Kunden, bei dem man das Dilemma in seiner vollen Pracht sehen konnte. Der Kunde hatte mit viel Zeit und Geld eine tolle Simulations- und Planungslösung gebaut. Diese Lösung war in der Lage, die gesamte Produktion des Kunden über Jahre und unterschiedlichste Szenarien hinweg zu simulieren, angefangen bei den erforderlichen Rohkomponenten bis hin zum Verkauf und der anschließenden Wartung der Produkte. Eine tolles Stück Software! Leider hat es ihnen letzten Endes nichts genutzt. Die Datenbestände, die sie als Input für ihre Simulationen und Planung zur Verfügung hatten, waren qualitativ so schlecht, dass die Ergebnisse leider nicht zu gebrauchen waren. Schade, denn es war eine tolle Anwendung.
Wie konnte das passieren? Der Kunde hatte eine wunderbar ausgearbeitete Anwendungsarchitektur, von der EAM-Ebene bis hinunter auf die einzelnen Anwendungen, inklusive Schnittstellen, Technologie-Management und allem, was dazugehört. Der Teil war tipptopp. Auf der Datenarchitekturseite sah es allerdings anders aus. Das war eher Ödland. Niemand wusste so genau, welche Daten wie durch die Systeme flossen, welche Systeme für welche Daten führend waren, welche Daten in welcher Qualität wo vorlagen, und so weiter. Daten waren ein wenig überspitzt ausgedrückt einfach etwas, was halt da ist. Ende. Auf der analytischen Seite sah es etwas anders aus, weil Daten dort traditionell eine große Rolle spielen. Aber auf der transaktionalen Seite: Fehlanzeige.
Schlecht gealterte Traditionen
Das hat jetzt nichts damit zu tun, dass der Kunde seinen Job schlecht gemacht hätte. Eher im Gegenteil. Aus meiner Sicht hat er eine ganze Menge Dinge ziemlich gut gemacht. Nur bei den Daten sah es nicht gut aus. Damit befindet sich der Kunde aber in bester Gesellschaft der meisten Unternehmen. Wir sind so fixiert auf die Anwendungen, dass wir die Daten darüber komplett vernachlässigen.
Das ist ein Überbleibsel aus lange vergangenen Zeiten. Bis etwa zur Jahrtausendwende hatten wir es in der IT meist mit großen, monolithischen Anwendungen zu tun, die weitestgehend isoliert auf ihrem Datenbestand gearbeitet haben. Datenaustausch gab es wenig, und wenn, dann via nächtlicher Batch-Datentransfers. Mussten mehrere Anwendungen tatsächlich viele Daten untereinander austauschen, dann hat man alle Anwendungen einfach auf dem gleichen Datenbankschema arbeiten lassen und das Problem so gelöst.
In einem solchen Setup reicht es, wenn ich auf die Anwendungen schaue und Daten als einen integralen Teil davon verstehe. Das strukturierende Element sind die Anwendungen. Das ist naheliegend, denn die ganze Logik steckt in den Anwendungen und der Blick der User in die IT geht durch die User Interfaces der Anwendungen. Der eher seltene Datenaustausch ist einfach: Einmal in der Nacht eine Datei exportiert, von A nach B geschoben und dort wieder eingelesen. Das ist überschaubar. Da reicht es, eine Import- oder Exportschnittstelle an der Anwendungsgrenze zu skizzieren.
Alles verteilt und überall
Diese Zeiten sind aber lange vorbei. Spätestens seit Mitte der 2000er herrschen Online-Schnittstellen, meist auf Einzelsatzebene, beim Datenaustausch zwischen Systemen vor. Die Systeme sind kleiner und mehr geworden, bis hin zu ganz vielen Microservices. Alle Daten sollen sofort überall sein. Die Folge davon sind hochkomplexe Datenflüsse durch eine verteilte Systemlandschaft mit immer mehr Anwendungen. Dabei ist nicht mehr klar, welche Attribute eines Datensatzes in welcher Anwendung hinzugefügt oder geändert werden und ob es für den nächsten Datensatz nicht vielleicht eine andere Anwendung ist. Es ist auch nicht mehr klar, wie diese Daten durch die Systeme wandern und von woher die einzelnen Teile eines Datensatzes ursprünglich kommen, den eine Anwendung per API-Call oder Datenbankzugriff zu Gesicht bekommt. Alles höchst verworren und kompliziert.
Das neue Gold
Gleichzeitig hat man entdeckt, dass gut genutzte Daten einen Wettbewerbsvorteil darstellen. Indem ich die ganzen im Unternehmen verteilten Daten miteinander in Beziehung setze, kann ich mit den Methoden des Machine Learning und der künstlichen Intelligenz für mein Geschäft relevante Erkenntnisse daraus ziehen. Indem ich die richtigen Daten zur richtigen Zeit in meinen Anwendungen verfügbar habe, kann ich in den Anwendungen bessere Entscheidungen treffen und Kundenzufriedenheit erhöhen. Das funktioniert aber nur, wenn die Datenqualität stimmt. Falsche Daten führen zu falschen Entscheidungen und sie steigern auch keine Kundenzufriedenheit.
Um der Datenqualität zu Leibe rücken zu können, müssen wir aber erst einmal wissen, woher die Daten ursprünglich stammen. Welche Attribute werden von welchen Anwendungen erfasst? Wie reisen die Daten durch die Landschaft? Wo werden sie verändert? Welche neuen Daten werden daraus abgeleitet? Und so weiter. Erst wenn wir das verstanden haben, können wir wirksam an der Qualitätsschraube drehen. Dafür reicht es aber nicht aus, nur auf die Anwendungen zu schauen. Dafür müssen wir in gleicher Intensität auf die Daten schauen.
Enttäuschte Gesichter
Das führt dann zu enttäuschten Gesichtern. Der Kunde will voller Enthusiasmus KI in seinem Unternehmen einführen. Man fragt ihn, wie es denn um die erforderliche Datenverfügbarkeit und -qualität stünde. Betretenes Schweigen. Dann irgendwann ein gemurmeltes „Nicht so gut“. Man erklärt dem Kunden, dass die Qualität der Ausgaben, die eine KI-Lösung erzeugt, ganz stark von der Qualität und Verfügbarkeit der erforderlichen Eingabedaten abhängt. Man erklärt ihm, dass er dafür erst einmal seine Datenflüsse verstehen und eine gute Dateninfrastruktur aufbauen muss, um die Möglichkeiten von KI im eigenen Unternehmen zu heben. Da sind sie dann, die enttäuschten Gesichter. Da hat man sich auf coole, hippe, trendy KI-Lösungen gefreut und dann so etwas. Datenarchitektur. Dateninfrastruktur. Wie uncool ist das denn?
Gute Daten braucht das Land
Aber wie es ein Sprecher (ich weiß den Namen leider nicht mehr) auf den Hamburger IT-Strategietagen so treffend gesagt hat: „Ein mittelmäßiges KI-Modell liefert mit sehr guten Daten wesentlich bessere Antworten als ein Spitzenmodell mit mittelmäßigen Daten“. Auch ohne KI sind wir bei unseren Entscheidungen durch die Qualität der Daten beschränkt, die uns zur Verfügung steht. Entsprechend: Gute Daten braucht das Land.
Das funktioniert aber nicht, wenn wir uns immer nur auf die Anwendungen fixieren. Wir müssen Daten zu IT-Bürgern erster Klasse machen und sie aus ihrer dunklen Ecke hinter den Anwendungen herausholen. Wir müssen genauso in Daten denken wie in Anwendungen. Data lineage. Data quality. Data pipelines. Data contracts. Und so weiter. Dinge, die für Datenexperten selbstverständlich sind, aber immer noch viel zu wenig im allgemeinen IT-Wissen verankert sind. Es wird Zeit, dass wir das ändern. Denn ohne gute Daten geht es nicht mehr.
Mit dem Schwerpunkt dieser Ausgabe der IT Spektrum versuchen wir, die Lücken ein wenig zu füllen. Wir haben einige Beiträge gesammelt, die das Thema „Daten“ von verschiedenen Seiten beleuchten, und versuchen, ein paar neue Impulse anzubieten. Ich wünsche Ihnen auf jeden Fall eine anregende und erkenntnisreiche Lektüre!
Uwe Friedrichsen
Herausgeber
