Niemand hat die Architektur Ihrer Software gewählt. Das wird teuer.

Niemand hat die Architektur Ihrer Software wirklich gewählt. Sie ist entstanden—eine überstürzte Entscheidung nach der anderen. Und dieser stille Unfall ist meist der teuerste Posten in Ihrem Stack.

Der unbequeme Teil: Architektur ist kein technisches Detail, das Ihre Entwickler regeln, nachdem die wichtigen Entscheidungen gefallen sind. Sie ist die wichtige Entscheidung. Sie legt fest, was Ihr Produkt nächstes Jahr kann, was eine neue Funktion kostet und wie schnell Sie jemanden einstellen, der den Code wirklich versteht.

Ich habe einmal ein sechsmonatiges Rewrite erlebt, aus einem einzigen Grund: Niemand benannte am Anfang einen Architekturstil. Das Team schrieb Code, bis der Code es in die Ecke schrieb. Da berührte jede neue Funktion alles, und „etwas Kleines hinzufügen“ hieß „das ganze System anfassen“.

Architekturstile gibt es, weil Software immer wieder zusammenbrach

Architekturstile sind keine akademische Deko. Sie entstanden Ende der 1960er, um die wörtlich so genannte „Software-Krise“ zu bekämpfen—Projekte, die zu komplex waren, um sie zu beenden. Strukturierte Programmierung brachte Disziplin in Spaghetti-Code. Objektorientierung ließ Teams reale Dinge modellieren statt roher Anweisungen. Spätere Stile machten verteilte Systeme und Microservices möglich.

Nimmt man den Jargon weg, ist ein Stil nur ein Bauplan: wie die Teile angeordnet sind und wie sie miteinander reden. Wählen Sie gut, bekommen Sie Software, die skaliert, Veränderung übersteht und günstig wartbar bleibt. Wählen Sie zufällig, fühlt sich jede neue Funktion wie eine Operation an.

Vier Stile, die man bewusst wählen sollte

Sie müssen keinen Katalog auswendig lernen. Sie müssen die Handvoll erkennen, die die meisten realen Probleme löst—und wissen, was jeder Ihnen einkauft.

• **Schichten** — Präsentation, Geschäftslogik und Datenzugriff der Reihe nach gestapelt. Langweilig, vorhersehbar und immer noch der richtige Default für die meisten Business-Apps. Greifen Sie erst zu Schickerem, wenn Schichten wirklich anfangen zu schmerzen.
• **Event-driven** — Komponenten veröffentlichen Events und reagieren asynchron darauf. Stark, wenn Teile unabhängig skalieren oder in Echtzeit reagieren müssen: Bestellung erstellt, E-Mail versendet, Lager aktualisiert—ohne eine Riesenfunktion, die die nächste ruft.
• **Microkernel (Plugin)** — Ein kleiner, stabiler Kern plus Funktionen als externe Module. Lebt Ihr Produkt von Erweiterungen und Anpassung, hält das den Kern gesund.
• **Space-based / Actor-Modell** — Unabhängige Actors, die nur über asynchrone Nachrichten kommunizieren. Gebaut für hohe Nebenläufigkeit und Verteilung—Systeme, die unter unvorhersehbarer Last stehen bleiben müssen.

Beachten Sie das Muster: Jeder Stil ist die Antwort auf einen konkreten Druck—Veränderung, Skalierung, Anpassung oder Nebenläufigkeit. Wählen Sie zuerst den Druck. Der Stil folgt.

Was 2026 wirklich geändert hat

Die neuen Trends werden als „die Zukunft“ verkauft. Eigentlich sind es schärfere Werkzeuge für Skalierung, Resilienz und Flexibilität—nützlich, wenn das passende Problem da ist, teuer, wenn nicht.

• **Serverless** — Funktionen auf AWS Lambda und ähnlichen skalieren auf null und zurück, ohne dass Sie Server bereitstellen. Sie zahlen für Nutzung, nicht für Leerlauf.
• **Mesh-App + verteilte Daten** — Eine geteilte Datenschicht, damit Teams Funktionen hinzufügen, ohne jedes Quartal ein monolithisches Rewrite.
• **Event Streaming + CEP** — Kafka-artige Streams plus Complex Event Processing lassen Sie auf Muster über viele Events in Echtzeit reagieren, statt auf einen Nacht-Batch zu warten.
• **Reaktiv, nicht blockierend** — Systeme, die unter Ausfall reaktionsfähig und elastisch bleiben, statt zu kippen, wenn eine langsame Abhängigkeit alles mitzieht.

Nichts davon ist automatisch „besser“. Es ist ein Trade. Sie kaufen Skalierbarkeit und Flexibilität mit mehr beweglichen Teilen und härterem Debugging. Der Trade ist brillant, wenn das Problem real ist, und leichtsinnig, wenn es eingebildet ist.

Wie man ohne sechsmonatige Debatte wählt

Fangen Sie langweilig an. Nehmen Sie Schichten oder einen modularen Monolithen. Die meisten Produkte wachsen nie darüber hinaus, und die, die es tun, sagen Ihnen genau wo—mit echtem Traffic und echtem Schmerz, nicht mit einer Whiteboard-Vermutung.

Dann stellen Sie drei Fragen, bevor Sie zu etwas Verteiltem greifen: Welcher Teil muss wirklich allein skalieren? Welche Änderung erwarten wir am häufigsten? Wer wartet das, wenn der ursprüngliche Autor geht? Ihre ehrlichen Antworten zeigen auf den Stil—nicht ein Konferenztalk vom letzten Monat.

Das Fazit gegen den Strom

Serverless, Event Streaming, Microservices—keines davon ist eine Persönlichkeit. Es sind Wetten. Können Sie das konkrete Problem nicht benennen, für das Sie diese Komplexität kaufen, sind Sie nicht modern. Sie sind teuer.

Architektur ist eine Business-Entscheidung im Hoodie. Die Teams, die gewinnen, haben nicht den angesagtesten Stack. Sie haben bewusst gewählt. Planen Sie einen Build oder blicken Sie auf ein Rewrite, schicken Sie uns die eine Funktion, die Sie sich am meisten fürchten, nächstes Jahr hinzuzufügen—diese eine Frage verrät meist die Architektur, die Sie wirklich brauchen.