Die Anatomie des Overheads
Kürzlich saß ich in einem Meeting, das sinnbildlich für das größte Problem der modernen Software-Entwicklung steht. Es ging um eine technische Anpassung, die in JavaScript genau fünf Zeilen Code umfasst. Ein einfacher Regex, ein Mapping, ein .toLowerCase(). Zeitaufwand für die Implementierung: Ungefähr so lang, wie man braucht, um einen Espresso zu ziehen.
Doch statt diesen Espresso zu trinken und das Problem zu lösen, erlebte ich die Geburt einer bürokratischen Kaskade. In vielen gewachsenen Agentur- und Enterprise-Strukturen sieht der Weg dieser fünf Zeilen Code heute so aus:
- Der Gatekeeper (Project Management): Erkennt ein Problem, darf aber keine technische Entscheidung treffen. Er schreibt eine User Story.
- Die Schätzrunde: Mehrere Personen diskutieren über „Story Points“ und „Aufwand“. Ein 5-Minuten-Fix wird zur 4-Stunden-Task, um „Puffer“ für den Prozess zu haben.
- Der Theoretiker (Technical Architect): Sucht nach einem universellen Standard (RFC), der für das spezifische Problem völlig irrelevant ist, weil das Ziel-System eine ganz eigene, proprietäre Logik erzwingt.
- Die Stille Post: Die Logik wird vom Architekten an einen Manager und von dort an einen Developer delegiert, der das ursprüngliche Problem – den Schmerz des Kunden – nie selbst gesehen hat.
Das Ergebnis ist immer gleich: Am Ende wird eine technisch „korrekte“ Lösung gebaut, die in der Realität trotzdem scheitert, weil der Kontext auf dem Weg durch die Hierarchien verloren ging. Ich nenne das den „Context Collapse“. Wenn die Kommunikation wichtiger wird als die Execution, ist das Projekt bereits gescheitert.
Das Process Debt Paradoxon
Wir reden in der IT ständig von Technical Debt. Aber was wir völlig ignorieren, ist das Process Debt. Jedes Mal, wenn ich eine Entscheidung, die ein erfahrener Engineer in 60 Sekunden treffen könnte, in einen Prozess aus Tickets, Meetings und Schätzungen zwinge, verbrenne ich Kapital. Nicht nur Geld, sondern auch kognitive Energie.
Während ein einziger Product Engineer mit einem modernen Tech-Stack (Next.js, Supabase) und LLM-Support heute ganze Plattformen am Wochenende hochzieht, braucht ein klassisches Team drei Tage, um einen String zu formatieren.
Wöchentliche Insights zu AI-Architektur. Kein Spam.
Das Problem in der deutschen IT-Landschaft ist die Angst vor der Autonomie. Strukturen werden so gebaut, dass niemand „schuld“ ist, wenn etwas bricht. Wenn ein Ticket existiert, eine Schätzung vorliegt und ein Architekt sein Okay gegeben hat, ist das Versagen systemisch gedeckt. Aber: Der Kunde bezahlt nicht für gedecktes Versagen. Er bezahlt für funktionierende Software.
Ich setze Logik konsequent in die Middleware (Edge/Node). Dort ist sie sicher, schnell und entkoppelt von schwerfälligen Legacy-Backends. Wenn ich eine Transformation brauche, baue ich sie dort – direkt, ohne Umwege über fünf Jira-Tickets. Wer die Komplexität im Prozess lässt, statt sie im Code zu abstrahieren, hat das Prinzip der Lean Architecture nicht verstanden.
Das Urteil: Radikaler Pragmatismus
Wenn die Kosten für das Besprechen einer Lösung die Kosten für die Umsetzung um den Faktor 100 übersteigen, ist das System kaputt. Meine Strategie in solchen Situationen ist radikaler Pragmatismus: Code over Documentation.
Oft ist es effizienter, den fertigen Prototypen direkt in den Raum zu werfen, als drei Runden über die Theorie dahinter zu drehen. In meiner Arbeit als Architect fokussiere ich mich darauf, Barrieren abzubauen. Ich nutze Agentic Workflows und Middleware-Orchestration, um Legacy-Systeme zu umgehen, statt sie in endlose Meetings zu integrieren.
Mein Ansatz:
- Build fast: Ein funktionierendes Stück Code in der Middleware schlägt jedes Architektur-Diagramm.
- Lean Thinking: Jedes Meeting ohne Code-Output ist eine potenzielle Verschwendung.
- Ownership: Ich übernehme Verantwortung für das Ergebnis, nicht für das Befolgen eines Prozesses.
Wer baut, gewinnt. Wer verwaltet, verliert Zeit. Wir müssen uns entscheiden: Wollen wir Software-Verwalter sein oder Software-Builder? Ich habe mich für Letzteres entschieden. Meine R&D-Projekte zum Thema Agentic Orchestration zeigen, wie man diese Geschwindigkeit technisch ermöglicht (Source).
Das Urteil: Hört auf, über 5 Zeilen Code zu debattieren. Schreibt sie. Testet sie. Schippt sie. Der Markt wartet nicht auf euer nächstes Sprint-Review.