Dieser magische Moment, an dem man die erste Zeile eines neuen Computerprogrammes schreibt. Es ist und bleibt der einzige unbeschwerte und unschuldige Moment. Danach beginnen sofort die Komplikationen, Missgeschicke und haare raufende Probleme, in unzähligen Iterationen. Und die Menge an Code wächst und wächst. Ähnlich der Augenblick, an dem man einen Computer zum ersten Mal einschaltet. Ein kurzes Blinken, danach unzählige Logs und fehlgeschlagene Logins, fehlender Speicher und begrenztes Netzwerk.
Seit vielen Jahren läuft die Erstellung von Software nach eben diesem gleichen Muster ab: Code – Build – Run – Test… und dann geht’s wieder von vorne los. Dazu sind Softwareentwickler am Werke, die mit IDEs, Frameworks, Compilern, Libraries, Debuggern etc. hantieren.
Der Fokus des Programmierers liegt in der Regel auf zwei Dingen:
Software und Hardware, das “Programm”, welches Algorithmen enthält und die “Infrastruktur”, die diese Programme ausführt.
Selbstverständlich sind die Umstände der Softwareentwicklung besser geworden:
Wir haben Unit-Tests, git und DevOps, es gibt die Agilen Prozesse, StackOverflow und Slack. Doch im Kern ist die Lösung der Aufgabe “Herstellung von Software” durch ein Team von Developern, den Helden des UX-Designs, den Backend-Kämpfer und Application-Server-Zähmern.
Lean Data
Aber halt! Fehlt da nicht was? Wo in diesem Prozess bleiben eigentlich die beiden fundamentalen Bausteine, ohne die kein Programm irgendeinen wie auch immer gearteten Nutzen hätte, nämlich Input und Output, gemeinsam auch “die Daten” genannt? Welchen Sinn macht eine Programm, welches ohne Input und Output funktioniert?
(Keinen, außer es endet so: https://www.youtube.com/watch?v=2A7vAbq_uIY)
Die Antwort ist, dass Input-Daten im Software-Entwicklungszyklus oft nur eine untergeordnete Rolle als Testdaten spielen. Die Entwickler wählen grade genug Daten für ihre Tests aus. Gleiches gilt für den Output, hier wird nur das nötigste geprüft.
Big Data
Big Data, also die Verarbeitung von bis dato ungewöhnlich große Datenmengen brachte Veränderungen bei der Infrastruktur durch den Auftritt von Scale-Out-Architekturen, Verteilten Systemen wie Hadoop und Cassandra, aber letztendlich auch Amazon AWS S3 und Co. Je nach Lösung müssen Entwicklungsteams sich mit veränderten Paradigmen beim Betrieb ihrer Programme auseinandersetzten. Aber die Teams an sich können ähnlich wie vorher weiterarbeiten, da die neuen Tools versuchen, diese Paradigmen vor ihnen zu verstecken. Beispielsweise erlauben MapReduce und Spark ein einfaches, lineares Programmiermodell, während die Runtime hoch-parallel arbeitet, wovon der Developer zur Entwicklungszeit möglichst nichts merkt. Seine Sicht auf die Daten selbst muss nicht “Big” sein.
Data First: Data Science, Machine Learning
Mit dem Aufkommen von stark daten-getriebenen Lösungen, hier “Data First” genannt, rückt nun der Input und Output ins Zentrum. Bei Training-basierten Ansätzen (also “Machine Learning”) wird ein Modell nach und nach von einem meist zufälligen initialen Zustand immer mehr auf große Mengen an Eingangs- und Ausgangsdaten hin justiert, also “trainiert”.
Das funktioniert in etwa so, als hätten wir beim klassischen Programmieren schon die komplette Menge an Source Code, aber zufällig und sinnlos arrangiert. Durch reine Umformungsoperationen würde daraus das gewünschte Programm. Der Treiber dafür wären ausschließlich Input und Output.
Modelle sind also gewissermaßen die Programme bei Data-First-Anwendungen. Source Code in Form eines Kompilats wird nicht benötigt, um die Modelle herum gibt es kleinere Programme, die im Vergleich zum Modell selbst kaum eine Rolle spielen.
Neue Herangehensweise, neue Entwicklungsteams
Im Gegensatz zu Big Data kommt man bei Machine Learning mit den herkömmlichen Teams und Methoden nicht mehr weiter. Die klassischen Fähigkeiten eines Software-Entwickler müssen durch neue Kompetenzen ersetzt werden: Feature-Engineering, Wahl der Machine-Learning-Methode, Sammlung und Aufbereitung Trainingsdaten, Tuning der Hyperparameter, Loss-Funktionen und Erkennen von Overfitting.
In vielen Fällen geht man sogar noch einen weiteren Schritt zurück:
Anforderungen, als die Fragen, die man einem Programm stellt, muss zuerst Data First neu entwickelt werden. Das betrifft z.B. den Bereich “Advanced Analytics”, wo man neue Erkenntnisse alleine aus Daten herauspressen will, ohne schon eine konkrete Abfrage nach dem SELECT-FROM-WHERE-Muster im Kopf zu haben. Das ist die Domäne des Data Scientisten. Er braucht zwingend die Daten, um seine Werkzeuge darauf ansetzen zu können.
Was bei Big Data kaschiert wurde, tritt nun voll zu Tage:
“Data First” bedeutet, mit klassischen Entwickler-Teams und Projekt-Partner nicht mehr ans Ziel zu kommen. Hier braucht es erfahrene Daten-Arbeiter, Data Engineers, Data Scientists und Kenner von Machine Learning Algorithmen.
Ohne Fachleute, die die Daten in den Mittelpunkt stellen können, geht das nicht. Ein klassisches Software-Entwicklungs-Team ist hier nicht richtig ausgestattet und ausgebildet.
Neuer Entwicklungs-Partner: AISOMA
AISOMA tritt mit dem Data-First Ansatz an, aus Daten Handlungen abzuleiten. Wir konzentrieren uns auf den Input und auf den Output.
Dafür hat AISOMA die richtigen Menschen und Tools an Bord. Was dann für ein System am Ende dabei herauskommt, bestimmt nicht eine gewählte Infrastruktur oder der Code, sondern Ihre Daten. Und die Faszination, für unsere Kunden Aktionen aus reinen Daten abzuleiten, das ist unser magischer Moment. Lassen Sie sich von dieser Magie anstecken.