Softwarearchitektur: Auf schockverliebt folgt der Schock

Als ich 2014 als Professional Developer bei einem Gaming-Unternehmen mit rund 25 Entwicklern arbeitete, hörte ich auf einer Konferenz zum ersten Mal von Microservices – und war sofort begeistert. Wir entwickelten ein Rollenspiel, in dem Spieler ihren Charakter durch verschiedene Welten steuerten, Loot sammelten und ihr Inventar verwalteten. Meine Idee lag auf der Hand: ein eigenständiger Inventory Service, der die Ausrüstung verwaltet, sauber getrennt vom Rest der Anwendung. Verschiedene Spielmodi sollten sich diesen Service teilen, wiederverwendbar und modern.

Also stellte ich das Konzept dem CEO vor. Seine Antwort kam schnell: “Zu komplex für das, was wir vorhaben. Nicht pragmatisch genug.” Ich war frustriert und dachte: Er hat keine Vision – er versteht nicht, wohin die Branche geht. Was soll man auch erwarten von jemandem, der auf Konferenzen nicht über den Tellerrand hinausschaut? Heute, mehr als zehn Jahre später, bin ich ihm dankbar. Denn Pragmatismus rechnet sich meist mehr als Euphorie. Wie Entwickler sich dagegen wappnen können.

Was stattdessen passierte: Monolith, pünktlich, gescheitert

Also bauten wir einen Monolithen. Das Spiel wurde pünktlich fertig – und scheiterte trotzdem, weil es keinen Markt fand. Kein Product-Market-Fit. Wir stellten die Entwicklung ein.

Aber: Genau deshalb war der Monolith die richtige Entscheidung. Hätten wir Microservices gebaut, wären wir Monate später zu derselben Erkenntnis gekommen, nur mit deutlich höherer Rechnung. Die verteilte Architektur hätte das Spiel nicht besser gemacht – sie hätte uns nur langsamer gemacht.

Und wenn das Spiel funktioniert hätte? Dann hätten wir die Architektur später aufteilen können, mit einem bewiesenen Geschäftsmodell und echtem Skalierungsbedarf im Rücken. Niemand sollte unterschätzen, wie weit vertikale Skalierung trägt. Microservices werden erst ab einer Größenordnung notwendig, die die wenigsten Unternehmen jemals erreichen. Netflix hat 2.500 Entwickler an einem Produkt, an vielen anderen arbeiten vermutlich weniger als 15.

Das Muster erkennen: Technologieverliebtheit

Was mir 2014 passiert ist, sehe ich heute regelmäßig bei Kunden. Sie entdecken eine Technologie auf einer Konferenz oder in einem Blogartikel, sind begeistert und die Begeisterung wächst zur Überzeugung. Und dann passiert etwas Gefährliches: Die Lösung beginnt, nach ihrem Problem zu suchen.

Die Technologie wechselt – Ende der 90er Jahre waren es Enterprise Javabeans, 2005 SOA mit dem Enterprise Service Bus, 2012 NoSQL, 2015 Microservices, 2018 Kubernetes, 2022 Event Sourcing – doch das Verhalten bleibt das gleiche.

Ein Kunde diskutiert seit Jahren über Kubernetes, obwohl seine Anwendung zustandsbehaftet ist und kein Bedarf an horizontaler Skalierung besteht. Ein anderer hat sich in Event Sourcing verliebt, ohne je ein konkretes Problem damit lösen zu müssen. Die Begeisterung ist stetig – der passende Kontext oft nicht.

Wenn Event Sourcing, Kafka und Microservices das Feature ersetzen

Besonders deutlich wurde mir das bei einem anderen Unternehmen, das sein bestehendes Produkt neu entwickeln wollte. Die alte Software war zu unflexibel, die Entwicklungszyklen zu lang. Ein kleines Team von fünf Fullstack-Entwicklern begann mit der Neuentwicklung – und griff zum großen Werkzeugkasten: Event Sourcing, Kafka als Message Broker, Kubernetes für die Infrastruktur und dazu eine Microservice-Architektur.

Das Ergebnis nach 18 Monaten: kaum produktive Features. Das Team hatte die Komplexität massiv unterschätzt. Event Sourcing – die Idee, alle Zustandsänderungen als Ereignisse zu speichern statt nur den aktuellen Zustand – klingt in Konferenzvorträgen elegant. In der Umsetzung mit einem Fünf-Personen-Team multipliziert sich der Aufwand allerdings mit jeder Iteration: Projektionen müssen gebaut und gewartet werden, Event-Migrationen sind aufwendig, und Debugging wird zur Archäologie durch Schichten vergangener Zustandswechsel.

Die technische Begeisterung im Team war trotzdem hoch. Die Technologie war spannend, das Lernen machte Spaß. Was fehlte, war die Reflexion: Bringt uns das dem Ziel näher? Am Ende stellte das Unternehmen das Projekt ein. Nicht allein wegen der Technologiewahl, aber die technische Sackgasse beschleunigte die Entscheidung erheblich.

Was wäre die Alternative gewesen? Mit einer einfacheren Architektur – einem Modulithen, einer relationalen Datenbank, einer simplen Deployment-Pipeline – hätte das Team nach drei bis vier Monaten etwas Vorzeigbares gehabt. Die Erkenntnis, dass das Produkt nicht zur Unternehmensstrategie passt, wäre viel früher gekommen, und die Entscheidung, das Projekt einzustellen, hätte nur einen Bruchteil der Kosten verursacht.

Was 18 Monate Overengineering kosten

Rechnen wir es durch. Fünf Entwickler, 18 Monate Entwicklungszeit. Pro Jahr gibt es rund 220 Arbeitstage, für 18 Monate also etwa 330 Arbeitstage pro Person. Bei einem realistischen Kostensatz von 700 Euro pro Entwicklertag ergibt sich:

5 Entwickler x 330 Tage x 700 Euro = 1.155.000 Euro.

Mehr als eine Million Euro. Für ein Projekt, das kaum nutzbare Features produziert hat.

Was hätte ein pragmatischer Ansatz in derselben Zeit geliefert? Ein funktionierendes Produkt nach wenigen Monaten, echtes Nutzer-Feedback, datenbasierte Entscheidungen statt Annahmen – und vor allem die Möglichkeit, frühzeitig zu erkennen, ob das Produkt eine Zukunft hat.

Die sichtbaren Kosten sind das eine, die unsichtbaren wiegen schwerer: verzögertes Markt-Feedback, aufgeschobene strategische Entscheidungen, verpasste Gelegenheiten. Diese Accidental Complexity entsteht nicht durch böse Absicht, sondern durch eine Technologieentscheidung, die den Blick auf das Produkt verstellt hat.

Warum selbst kluge Entwickler in die Falle tappen

Technologieverliebtheit ist kein Zeichen von Inkompetenz – im Gegenteil. Es sind oft die besten Entwickler, die auf Konferenzen gehen, Blogartikel lesen und neue Technologien ausprobieren wollen. Das Problem liegt nicht in der Neugier, sondern in fehlenden Korrektiven.

Der Konferenzeffekt

Vorträge auf Konferenzen zeigen Erfolgsgeschichten. Sie zeigen, wie eine Technologie ein bestimmtes Problem gelöst hat. Was sie selten zeigen, sind die Rahmenbedingungen: die Teamgröße, das Budget, die Jahre an Vorarbeit. Ein 45-Minuten-Vortrag kann diesen Kontext nicht transportieren. Was bleibt, ist die Begeisterung ohne die Einordnung.

Resume-Driven Development

Neue Technologien machen Lebensläufe attraktiver. Wer Kafka und Kubernetes im Profil vorweisen kann, bekommt mehr Anfragen von Recruitern. Das ist kein böser Wille, sondern ein rationaler Anreiz – der allerdings gegen die Interessen des Unternehmens arbeitet, wenn die Technologie nicht zum Problem passt.

Social Proof

“Netflix macht das auch.” Ja, mit Tausenden Entwicklern, Millionen Nutzern und einem Infrastrukturbudget, das größer ist als der Umsatz der meisten Unternehmen. Der Verweis auf die Großen klingt überzeugend, ignoriert aber den Kontext vollständig.

Unterschätzte vertikale Skalierung

Wie weit trägt ein gut gebauter Monolith? Eine einzelne Anwendung auf moderner Hardware bedient problemlos Zehntausende gleichzeitige Nutzer. Aber: Die Skalierungsprobleme, für die Microservices eine Lösung sind, treten bei den allermeisten Unternehmen nie auf.

Wer führt, sollte dieses Muster kennen – nicht um Entwicklern Vorwürfe zu machen, sondern um das richtige Gegengewicht zu schaffen. Jeder, der entwickelt, sollte sich ehrlich fragen: Löse ich gerade ein Problem meines Arbeitgebers oder eines meines Lebenslaufs?

Was stattdessen hilft: pragmatische Entscheidungskultur

Technologiebegeisterung ist nicht das Problem. Es sind fehlende Reflexion und fehlende Entscheidungskultur.

Mir hilft eine einfache Frage, bevor ich eine Technologie vorschlage: Löse ich damit ein reales Problem oder suche ich ein Problem für meine Lösung? Wenn ich das Problem nicht in zwei Sätzen beschreiben kann, ist die Technologie wahrscheinlich nicht die Antwort. Das klingt banal, aber es hätte mich 2014 vor der Microservice-Idee bewahrt.

Genauso wichtig ist die Rolle der Führung. Mein CEO traf und begründete damals eine klare Entscheidung. Das war frustrierend, aber es hat funktioniert – denn auch ein Nein gibt dem Team Klarheit. Ein klares “Wir machen das nicht, weil unsere Priorität auf Feature-Delivery liegt”, ist besser als monatelange Diskussionen ohne Ergebnis. Endlose Technologiedebatten kosten mehr als die vermeintlich falsche Entscheidung.

Was ich bei Kunden außerdem immer wieder sehe: Neue Technologie wird diskutiert, bevor die Grundlagen stehen. Automatisierte Tests fehlen, die Deployment-Pipeline ist fragil, Monitoring liefert kaum Erkenntnisse, Release-Zyklen ziehen sich wochenlang hin. Neue Technologie auf einem wackeligen Fundament macht das Fundament nicht stabiler – sie macht es teurer.

Eine pragmatische Reihenfolge sieht anders aus:

1. Problem benennen. Welches konkrete Geschäfts- oder Lieferproblem soll die Technologie lösen?
2. Einfachste tragfähige Lösung prüfen. Reicht ein Modulith, eine relationale Datenbank oder eine bessere Deployment-Pipeline?
3. Betriebskosten ehrlich bewerten. Kann das vorhandene Team die Lösung dauerhaft betreiben?
4. Entscheidung begründen. Ein klares Nein ist besser als eine monatelange Technologiedebatte.

Technologie darf kommen. Aber erst, wenn der Bedarf bewiesen ist, und nicht, weil es auf einer Konferenz gut klang.

Warum der CEO recht hatte

Der CEO meines Gaming-Unternehmens traf 2014 keine Technologieentscheidung. Er traf eine Geschäftsentscheidung: Wir wissen noch nicht, ob dieses Spiel funktioniert, also bauen wir es so, dass wir das schnell herausfinden. Er hatte recht.

Technologieentscheidungen sind Geschäftsentscheidungen. Wer das vergisst, baut Architektur für den Lebenslauf statt für das Produkt. Ein Team, das eine klare Entscheidung bekommt, kann sich auf das konzentrieren, was dem Produkt hilft. Ein Team, das monatelang über Technologie diskutiert, kann das nicht.

Die beste Architektur ist die, die du heute nicht brauchst und morgen trotzdem bauen kannst.