Vor ein paar Wochen habe ich etwas theoretischer auf die Entwicklungen der letzten zwei Jahre rund um KI und LLMs geschaut („Was haben ein Hammer und ein LLM (nicht) gemeinsam?“). Mir ging es darum zu erklären, dass ein LLM nicht die „böse KI“ ist, die uns unsere Jobs wegnimmt. Vielmehr stellt es aus der Perspektive des Human-Computer-Interaction-(HCI)-Designs die konsequente Weiterentwicklung von User Interfaces dar: von Lochkarten über Command Lines, GUIs und NUIs bis hin zu LLMs. Letztlich ist es ein intuitiver Weg, mit einem Computer zu kommunizieren und dieses „Werkzeug“ effizient zu bedienen.
ETL – eine Geschichte
Für diesen Beitrag möchte ich in eine spezielle Nische eintauchen: ETL – Extract, Transform, Load. Eine zentrale Disziplin beim Aufbau und Betrieb von Data Warehouses und Lakehouses. Hier wird Software entwickelt, die Daten transportiert, transformiert, integriert und in ihrer Qualität sichert.
Bis vor etwa fünf Jahren folgte diese Disziplin stark der allgemeinen Entwicklung der HCI. Als Softwareentwicklungsdisziplin nutzte man dafür geeignete Sprachen auf passenden Plattformen: COBOL oder PL/SQL, Bash-Skripte, die Dateien kopieren oder orchestrieren, und natürlich SQL, das bis heute hervorragende Aggregationen liefert.
Mit der Zeit erkannte man das Potenzial und entwickelte dedizierte ETL-Software. Es entstanden Entwicklungsumgebungen und Frameworks, die alles unter einem Dach konsolidierten. Statt vieler einzelner Komponenten gab es nun komplette Suites – oft mit grafischen Oberflächen. Man programmierte und skriptete weniger und definierte stattdessen Graphen, die Prozessschritte und Datenflüsse visualisierten.
20 Jahre lang arbeiteten BI-Entwickler:innen genau so: spezialisiert auf Datenmodellierung und Tools der Anbieter. Dank des Low-Code-Ansatzes mussten sie jedoch keine voll ausgebildeten Softwareentwickler:innen sein. Entscheidend waren das Verständnis von Datenflüssen, der Fachlichkeit und das Lösen vielfältiger Optimierungsprobleme.
Was passierte nun vor fünf Jahren?
LLMs waren noch nicht praxisreif, aber die ETL-Welt wurde durcheinandergerüttelt. Cloudanbieter boten die ideale Basis für Data Lakes: günstiger, skalierbar, flexibel. Aber sie boten keine monolithischen Suites. Stattdessen viele kleine Tools, die miteinander integriert werden wollten. Keine Low-Code-Oberflächen, sondern Python, Spark, Scala.
Gefühlt ein Rückschritt. Während die Softwarewelt immer weiter Richtung „weniger Code, mehr Framework“ wanderte, schien die ETL-Nische einen anderen Weg einzuschlagen. Viele BI-Spezialist:innen fragten sich:
„Muss ich jetzt Softwareentwickler werden?“
„Lohnt sich das alles, wenn wir statt Standardlösungen wieder selbst bauen müssen?“
Was hat es mit dem Trend auf sich?
… Um das zu verstehen, lohnt ein Blick darauf, warum ETL so wurde, wie es war. Grafische Tools waren ein offensichtlicher Trend – aber nicht der einzige Grund.
Wer sich mit Prozessdesign, Prozessoptimierung und Modellierungssprachen wie BPMN, EPK, UML, DFD oder PAP beschäftigt hat, erkennt schnell: grafische ETL-Tools sind im Kern nichts anderes als Datenflussdiagramme (DFDs).
Betrachtet man zudem die Zeit, in der große Unternehmen begonnen haben, stark in Prozesse und deren Modellierung zu investieren, fällt auf, dass die Erfolgsphase graphbasierter ETL-Tools eng mit diesem Trend zusammenhängt.
Vielleicht war ETL also lange Zeit nicht deshalb grafisch, weil es intuitiv ist, sondern weil es den dominierenden Zeitgeist traf. Das ist meine persönliche These – wissenschaftlich nicht belegt, aber faktisch lässt sich festhalten:
- Man ist in proprietären Toolwelten gefangen.
- Compiler übersetzen die Grafen ohnehin wieder in Code – oft nicht optimal.
- Versionierung, Kollaboration und Annotationen funktionieren nur eingeschränkt.
- Selbst nach 20 Jahren haben die Oberflächen teilweise gravierende Bugs.
- Performanceoptimierungen verlangen kreative Workarounds innerhalb der Suite-Beschränkungen.
Kurzum: Es gibt gute Gründe für den aktuellen „Rückschritt“ hin zu mehr Code. Und so befinden wir uns seit einigen Jahren in einer Phase des „more code“ statt „low code“ – verbunden mit der Herausforderung, Mitarbeitende für diese Reise zu befähigen.
Gäbe es da nicht …
… eine ganz neue Form der Mensch-Computer-Interaktion: eine, bei der ich fachliche Anforderungen in natürlicher Sprache formuliere und am Ende ein funktionierendes Stück Software erhalte. Eine Form, die ohne grafisches Design und ohne „Wenn-Dann“-Compiler auskommt, die riesige Bausteine erzeugen.
Ihr wisst, worauf es hinausläuft.
Die aktuelle Lücke – sinkender ETL-Entwicklungskomfort – kann durch ein nutzerfreundliches Interface gefüllt werden, das barrierefrei zugänglich ist und Code erzeugt, der:
- toolunabhängig ist,
- moderne Versionierung unterstützt,
- kollaborativ weiterentwickelt werden kann,
- und sich performanceoptimieren lässt (oder es bereits ist).
LLMs könnten unsere grafische Oberfläche ersetzen. Ich modelliere nicht mehr visuell – ich schreibe oder beschreibe den Code. In beiden Fällen entsteht ETL-Code. Aber vielleicht ist der neue Weg einfacher – und das Ergebnis besser.
Quo Vadis
Soweit die Vision. Funktioniert das heute schon – oder sind wir noch Jahre entfernt?
Nach dem Clickbait meines letzten Blogbeitrags (der Hammer) nutze ich heute das Instrument des Cliffhangers. Im nächsten Beitrag werde ich versuchen, aus einer fachlich-textuellen Beschreibung mittels KI einen vollwertigen ETL-Prozess zu erzeugen – und dasselbe mit einer einfachen Handzeichnung.
Bis dahin: Schaut gern in die anderen Cattle-Crew-Blogbeiträge. Es gibt bereits einiges zu LLMs und Vibe Coding.
Hier nur ein paar Beispiele:
Zeitreihenanalysen im Controlling
Vibe Coding – Teil 1: Mit KI zum eigenen Homeserver
Vibe Coding – Teil 2: Linux-Server mit KI konfigurieren
KI im Kundeneinsatz: Ein Reality Check der Pyramid-Funktionalität
Was haben ein Hammer und ein LLM (nicht) gemeinsam?
Open Data in Aktion: Mit KI Abwasserdaten analysieren
RAG or not to RAG, Teil 1: Wann braucht es einen RAG-Ansatz
RAG or not to RAG, Teil 2: Prozesse und Aufwand in der Praxis
Was steckt hinter RAG und Semantischer Suche?
RAG und Semantische Suche in der Praxis
