Hören Sie auf, Workflow-Infrastruktur zu bauen

Die meisten Teams, die operative Automatisierung bauen, stecken den Großteil ihres Engineering-Aufwands in Dinge, die nicht ihre Geschäftslogik sind: fehlgeschlagene Schritte erneut versuchen, festlegen, wann Arbeit läuft, den Zustand eines lang laufenden Prozesses nachverfolgen, sicherstellen, dass eine Aktion nicht doppelt auslöst, und sauber wiederherstellen, wenn etwas mittendrin abstürzt. Nichts davon ist die Regel, die entscheidet, was zu tun ist. Es ist die Infrastruktur, die dafür sorgt, dass die Regel zuverlässig ausgeführt wird, und sie von Hand zu bauen ist einer der häufigsten Gründe, warum Automatisierungsprojekte aus dem Budget laufen.

Die Infrastruktur-Steuer

Stellen Sie sich ein Team vor, das eine einfache operative Regel automatisiert: Wenn die Bestellung eines Kunden mehr als 48 Stunden unversandt liegt, wird ein Alarm gesendet und ein Support-Ticket eröffnet. Die Regel selbst ist ein Satz. Um sie zuverlässig umzusetzen, braucht es einen Scheduler, der die Bedingung regelmäßig prüft, eine Methode, um nachzuverfolgen, welche Bestellungen bereits einen Alarm ausgelöst haben, damit dieselbe Bestellung nicht doppelt auslöst, einen Retry-Pfad für den Fall, dass die Ticketing-API kurzzeitig ausfällt, einen Mechanismus, um die laufende Prüfung wiederherzustellen, falls der Prozess mitten im Lauf neu startet, und ein Logging, das gut genug ist, um die Frage »hat das für Bestellung 4471 tatsächlich ausgelöst« zu beantworten. Das sind fünf getrennte technische Probleme für einen Satz Geschäftslogik, und jedes davon ist eine Stelle, an der sich ein Bug verstecken kann.

Die meisten Teams unterschätzen das, weil die Infrastruktur erst als Kostenpunkt auftaucht, wenn sie kaputtgeht. Es geht leise kaputt, und zwar auf drei konkrete, teure Arten.

Die drei Fehlermodi, die das teuer machen

Stiller Teilausfall. Ein Workflow erledigt Schritt eins und zwei, dann wirft Schritt drei einen Fehler, der protokolliert, aber nirgends sichtbar gemacht wird, wo ihn ein Mensch sehen würde. Das System glaubt nun, die Aufgabe sei erledigt, oder es prüft nie wieder nach. Niemand bemerkt es, bis sich ein Kunde über etwas beschwert, das seit Wochen automatisch hätte laufen sollen.

Doppelte Nebenwirkungen. Ein Retry löst aus, weil eine Antwort langsam war, nicht weil der erste Versuch tatsächlich fehlgeschlagen ist, und nun wird die Belastung, die E-Mail oder das Ticket doppelt erstellt. Idempotenz, also sicherzustellen, dass eine Operation denselben Effekt hat, egal ob sie einmal oder fünfmal läuft, klingt nach einer Kleinigkeit, bis eine Zahlung oder eine kundenseitige Benachrichtigung doppelt auslöst und jemand erklären muss, warum.

Verlorener Zustand nach Neustart. Ein lang laufender Prozess wird durch ein Deployment, einen Absturz oder ein Skalierungsereignis unterbrochen, und der im Arbeitsspeicher gehaltene Fortschritt einer mehrstufigen Sequenz ist weg. Der Workflow startet entweder bei null neu, wiederholt Arbeit und riskiert doppelte Nebenwirkungen, oder er stoppt still, und niemand merkt es, bis ein nachgelagerter Bericht falsch aussieht.

Jedes dieser Probleme ist lösbar. Keines davon ist trivial, und alle drei tauchen bei jedem Workflow, den ein Team baut, erneut auf, was bedeutet, dass sich die Kosten, sie einmal schlecht zu bauen, bei jeder neuen Automatisierung wiederholen.

Delegieren Sie es an Infrastruktur

Das Argument hier lautet nicht »schreiben Sie nie Orchestrierungscode«. Es lautet, dass Retries, Scheduling, Zustandsnachverfolgung und Idempotenz gelöste Probleme mit ausgereifter Infrastruktur dahinter sind, und sie pro Projekt neu zu lösen ist eine schlechte Nutzung von Engineering-Zeit, die stattdessen in die eigentlichen Domänenregeln fließen sollte: Was gilt als festhängende Bestellung, wo liegt die richtige Eskalationsschwelle, was bedeutet »erledigt« für dieses konkrete Geschäft. Das ist die Logik, die nur Ihr Team versteht, und sie ist es wert, Engineering-Zeit dafür zu schützen.

Ein Team, das seinen eigenen Code auf »was soll passieren« beschränkt und sich bei »stellen Sie sicher, dass es zuverlässig passiert« auf Infrastruktur verlässt, liefert schneller und debuggt weniger, weil die harten, allgemeingültigen Fehlermodi von etwas Erprobtem übernommen werden, statt von etwas, das einmal unter Zeitdruck gebaut und nie wieder überarbeitet wurde.

Wann Sie es selbst bauen sollten

Das ist kein pauschales Argument gegen eigene Orchestrierung. Wenn Ihr Prozess wirklich keine Retries braucht, weil jeder Schritt sofort abläuft und von Natur aus idempotent ist, ist die Infrastruktur kein echter Kostenfaktor, und sie selbst zu bauen ist völlig in Ordnung. Wenn Ihre Zuverlässigkeitsanforderungen ungewöhnlich spezifisch sind, etwa strikte Reihenfolge-Garantien über Schritte hinweg, die ein generisches Tool schlecht abbildet, kann eine maßgeschneiderte Eigenlösung ein generisches Tool übertreffen. Und ein kleines, einzweckiges Skript, das einmal täglich läuft und dessen Ausgabe ein Mensch prüft, braucht nicht dieselbe Sorgfalt wie ein unbeaufsichtigter, kundenseitiger Prozess; dort Infrastruktur hinzuzufügen ist Überengineering, keine Sorgfalt.

Die Entscheidung hängt an Volumen und Konsequenz: Je häufiger ein Workflow unbeaufsichtigt läuft und je mehr er Dinge berührt, die Kunden oder Geld sichtbar betreffen, desto stärker wiegt die Infrastruktur-Steuer, und desto stärker spricht das dafür, sie an etwas zu delegieren, das für den Umgang mit Fehlern entworfen wurde, nicht an etwas, das zusammengebaut wurde, damit eine Demo funktioniert.

Geschäftslogik ist der einzige Teil eines Automatisierungsprojekts, den ein Wettbewerber nicht einfach kopieren kann. Alles andere lässt sich als Commodity behandeln, weil es bereits eine ist.