Vom Muster zum Plan - die Genesis eines domänenagnostischen Workflow-Systems

1. August 2026

Manche Ideen entstehen nicht in einem Moment, sondern über Jahrzehnte. Die Idee, Workflows domänenagnostisch zu denken — als Pläne aus einzelnen Schritten, unabhängig davon, worum es fachlich geht — ist so eine. Um zu verstehen, warum, muss ich etwa fünfzehn Jahre zurückgehen.

Vor fünfzehn Jahren: Agenturen und ein Muster

Damals habe ich WPF-basierte Lösungen für Werbe- und Kommunikationsagenturen geschrieben — Anwendungen, die verschiedene Zustände und Abläufe von Aktionen abbildeten. Und diese Anwendungen blieben nicht im Bildschirm: Über Protokolle wie MQTT und OPC UA steuerten sie auch Hardware an, sodass sich multimediale Effekte miteinander komponieren ließen — Bild, Ton, Licht und physische Aktoren als aufeinander abgestimmtes Zusammenspiel. Und je mehr dieser Systeme ich baute, desto deutlicher wurde mir eine Sache: Sie wiederholen sich. Nicht im Detail, aber in ihrer Struktur.

Das Muster war immer dasselbe: Die Anwendung beginnt in einer Art Ruhezustand — einem Screensaver, wenn man so will. Dann wird eine oder werden mehrere Aktionen ausgeführt. Und danach kehrt das System wieder in seinen Ruhezustand zurück und wartet auf den nächsten Anlass.

Wenn sich etwas strukturell wiederholt, dann sollte man es nicht immer wieder neu programmieren, sondern einmal richtig. Also habe ich ein Plugin-System implementiert: Die Struktur — Ruhezustand, Auslöser, Aktionen, Rückkehr — war fest, die konkreten Aktionen waren austauschbare Bausteine: ein Video abspielen, eine Lichtszene schalten, einen Aktor über MQTT oder OPC UA ansteuern. Und das Ganze ließ sich per Konfiguration zusammenstellen statt per Code.

Vor etwa sieben oder acht Jahren: Verlage, Industrie und ein Intermediate-Format

Einige Jahre später beschäftigte ich mich — diesmal für die Publishing-Industrie und Verlage — mit einem scheinbar ganz anderen Problem: dem Import von Nachrichten aus unterschiedlichen Kanälen. Die Aufgabe: Daten aus verschiedensten Quellen entgegennehmen, in ein einheitliches Zwischenformat transformieren und dann irgendwo ablegen — in einer Datenbank, in einer Datei, wo auch immer.

Dazu kamen — in einem ganz anderen Umfeld, der klassischen Industrie mit Logistik und Produktion — ETL-Ingestion-Pipelines: Datenimporte aus CSV-Dateien und Excel-Sheets, wie sie dort zuhauf existieren — Artikelstämme, Stücklisten, Lagerbestände, Lieferdaten von Partnern. Und jedes Mal dieselben Handgriffe: das Import-Schema festlegen, also definieren, welche Spalte auf welches Zielfeld abgebildet wird und in welchem Format die Werte ankommen; die Daten validieren und bereinigen; und das Ergebnis strukturiert in einer Datenbank ablegen. Der einzige Unterschied zwischen zwei Importen lag fast nie in der Mechanik, sondern nur im Schema — im Was, nicht im Wie.

Klingt anders als die Agentur-Anwendungen? Ist es aber nicht. Es ist wieder dasselbe Muster: Ein Auslöser (eine neue Nachricht trifft ein, eine Datei wird angeliefert), eine Kette von Aktionen (extrahieren, transformieren, validieren, speichern), und danach wartet das System wieder auf den nächsten Auslöser. Was ich hier baute, waren im Kern ETL-Strecken — und die Erkenntnis von damals galt unverändert: Die Struktur ist immer gleich, nur die Bausteine ändern sich.

Vor drei Jahren: Die KI kommt

Als vor rund drei Jahren die KI ihren Durchbruch erlebte, lag der nächste Schritt für mich auf der Hand: Ich begann, KI in genau diese Workflows einzubinden. Konkret hieß das: Texte in das Intermediate-Format transformieren, sie übersetzen, Metadaten anreichern oder direkt aus den Texten extrahieren — und das Ergebnis natürlich wieder in der Datenbank ablegen. Aufgaben, für die man früher Speziallogik oder Handarbeit brauchte, wurden nun zu KI-Schritten. Aber am Muster änderte das nichts: Die KI wurde einfach ein weiterer Baustein in der vertrauten Kette — Auslöser, Aktionen, Speichern, Warten.

Doch dabei trat ein altes Problem umso deutlicher zutage: Ich erfand mit jedem Projekt wieder das Rad neu. Dieselben Muster, immer wieder neu implementiert, immer wieder leicht anders — aber nie einmal grundsätzlich gelöst.

Die Konsequenz: der domänenagnostische Plan

Aus dieser Erkenntnis entstand die Überlegung, die mich seither nicht mehr losgelassen hat: Warum nicht ein domänenagnostisches System entwickeln — eines, das nicht für Werbeagenturen gebaut ist, nicht für Verlags- oder Industrie-Pipelines, nicht für KI-Textverarbeitung, sondern für das Muster dahinter?

Ein System, das eine beliebige Aufgabe als Plan begreift: zerlegt in einzelne Schritte, die automatisch ausgeführt werden. Die Struktur — Auslöser, Aktionen, Rückkehr in den Ruhezustand — ein einziges Mal sauber gebaut; die konkreten Bausteine austauschbar und per Konfiguration zu immer neuen Workflows kombinierbar. Ob ein Schritt dabei Daten aus einer Datei liest, einen Text per KI anreichert oder ein Ergebnis in eine Datenbank schreibt, ist für das System selbst unerheblich — es kennt nur den Plan.

Das ist keine Idee eines Moments, sondern die Konsequenz aus fünfzehn Jahren, in denen mir dasselbe Muster in immer neuen Gewändern begegnet ist. Irgendwann hört man auf, das Rad neu zu erfinden — und baut stattdessen die Achse.