Hi,

Wie am Montag geschrieben : Kleine und mittlere Unternehmen (KMU) haben kein Problem mit Performance.

Wobei - so stimmt das nicht. Ich habe in den letzten Jahren an vielen Produkten gearbeitet, die langsam waren. Und die Performance zu verbessern wäre positiv für das Geschäft gewesen. In manchen Bereichen, wie der Gaming Branche, war es unvermeidbar performant zu sein. Die Retention ist einer der wichtigsten Metriken in der Branche.

Das ist aber die Ausnahme und nicht die Regel.

Performanceprobleme sind nur die Spitze des Eisbergs in der Softwareentwicklung im Mittelstand.

Die schlechte Performance ist nur ein Symptom.

Sie ist selten so schlecht, dass sie das Problem in der Anwendung ist.

KMUs leiden an Overengineering

2022 habe ich mich in meinem Blog schon darüber ausgelassen, wie jeder Bewerber mir von Microservices erzählt . Der Blog traf damals einen Nerv. Er bekam sogar ein Feature auf Hackernews .

Und was stelle ich heute auf dem Markt fest? Meine Kunden leiden wieder (aber nicht exklusiv 😉) an Microservices.

In all meinen Projekten ist die Architektur zu komplex. Sie wurde overengineered.

Als Resultat: Hoher Wartungsaufwand, niedrige Velocity und alle typischen Probleme in einem verteilten System wie Deadlocks, Inkonsistenzen oder Duplizierungen.

Und eben auch Performanceprobleme, weil synchrone Calls über das Netzwerk gemacht werden (müssen).

Aber das ist das Symptom. Nicht die Ursache.

Warum wir das gleiche Muster wieder und wieder sehen, ist schwer zu sagen. Vermutlich eine Mischung aus Survivorship Bias , Hype und der Mentorship Crisis .

Die meisten Teams schießen über das Ziel hinaus

Alle KMUs, die ich betreue, brauchen keine komplexe Architektur. Die Produkte im Mittelstand decken in der Regel nur eine Domäne ab.

Für eine Domäne möchtest du nur einen einzigen Service haben. Wenn du das nicht machst, dann entwirfst du einen verteilten Monolithen. Alle Services sind untereinander abhängig. Du musst synchrone Calls unter ihnen machen.

Als Resultat hast du alle Nachteile eines Monolithen und eines verteilten Systems kombiniert. Lose-Lose.

Außerdem müssen sich viele Produkte erst noch auf dem Markt beweisen. In einer solchen Phase deines Geschäfts möchtest du flexibel sein. Du willst Dinge ausprobieren, wieder wegwerfen und neubauen. Und das schnell. Ein verteiltes System erlaubt dir das nicht. Die nicht-funktionalen Anforderungen sind exponentiell höher als im Monolithen.

The Pragmatic Programmer (2022 Edition) p. 448

Das Paradoxe an meinem Geschäft im letzten Jahr: All meine Kunden hatten dieses Problem. Und bei allen habe ich an dieser Stelle angesetzt. Die Architektur ist overengineered und ich habe sie mit ihnen vereinfacht. Denn nur das ist nachhaltig.

Darum werde ich meine Positionierung ändern.

Ein Externer Experte ist effektiver im Umbau der Architektur

Was mich in meiner Arbeit überrascht hat, ist, wie schnell ich als Externer Ergebnisse produziere. Als Externer habe ich die Möglichkeit, den Finger in die Wunde zu stecken. Mit meinem dreitägigen Architecture Discovery Workshop (du weißt schon, den, den ich nie beworben habe, aber im Gegensatz zum Performance Workshop viermal verkauft habe ) habe ich immer fundamentale Änderungen herbeigeführt.

Und retrospektiv ergibt das auch Sinn. Dein aktuelles Team war es ja, die die komplexe Architektur entworfen haben. Selbst zu erkennen und sich einzugestehen, dass man sich fundamental falsch entschieden hat, ist schwer.

Jeder unserer menschlichen Instinkte will diese Erkenntnis verhindern. Als Externer kann ich diesen Punkt überwinden. Ich kann die Argumente für die Geschäftsführung und für das Team liefern, das Problem zu erkennen und endlich anzugehen.

In den kommenden Wochen werde ich mehr darüber berichten. Was die Strategien sind. Wie man iterativ an der Architektur arbeitet. Was bei den Mitarbeitern in so einer Phase zu beachten ist. Und vieles mehr.

Was sind deine Beobachtungen in Projekten? Erlebst du ein Architektur-Overengineering im Mittelstand? Ich freue mich über deine Erfahrung!

Rule the Backend,

~ Marcus