The #1 Problem in SMEs
Find the English version below
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
Hi ,
As written on Monday: Small and medium-sized enterprises (SMEs) have no problem with performance.
However, that's not entirely true. Over the past few years, I've worked on many products that were slow. Improving performance would have been positive for the business. In certain areas, like the gaming industry, it was inevitable to be performant. Retention is one of the most important metrics in the industry. But that's the exception, not the rule.
Performance issues are just the tip of the iceberg in software development for SMEs.
Poor performance is just a symptom. It's rarely so bad that it's the problem in the application.
SMEs Suffer from Overengineering
In 2022, I already vented on my blog about how every applicant tells me about microservices. The blog hit a nerve back then. It even got a feature on Hackernews.
And what do I see in the market today? My clients are suffering from microservices again (but not exclusively 😉).
In all my projects, the architecture is too complex. It has been overengineered.
As a result: High maintenance effort, low velocity, and all the typical problems in a distributed system like deadlocks, inconsistencies, or duplications.
And also performance issues because synchronous calls have to be made (must be made) over the network.
But that's the symptom. Not the cause.
Why we see the same pattern over and over again is hard to say. Probably a mix of Survivorship Bias, hype, and the mentorship crisis.
Most Teams Overdo It
All the SMEs I look after don't need complex architecture. Products in the SME sector usually cover only one domain.
For one domain, you want to have only one single service. If you don't do that, you're designing a distributed monolith. All services are interdependent. You have to make synchronous calls among them.
As a result, you combine all the disadvantages of a monolith and a distributed system. Lose-lose.
Moreover, many products still have to prove themselves in the market. In such a phase of your business, you want to be flexible. You want to try things out, discard them, and rebuild. And quickly. A distributed system doesn't allow you to do that. The non-functional requirements are exponentially higher than in a monolith.
The Pragmatic Programmer (2022 Edition) p. 448
The paradox in my business last year: All my clients had this problem. And in all cases, I started here. The architecture was overengineered, and I simplified it with them. Because that's the only sustainable way.
That's why I'm going to change my positioning.
An External Expert is More Effective in Rebuilding the Architecture
What has surprised me in my work is how quickly I produce results as an outsider. As an outsider, I have the opportunity to point out the sore spots. With my three-day Architecture Discovery Workshop (you know, the one I never advertised, but unlike the Performance Workshop, sold four times) I always brought about fundamental changes.
And in retrospect, that makes sense. Your current team was the one that designed the complex architecture. Recognizing and admitting to oneself that a fundamentally wrong decision was made is difficult. Every one of our human instincts wants to prevent this realization. As an outsider, I can overcome this point. I can provide the arguments for the management and for the team to recognize the problem and finally address it.
In the coming weeks, I will report more on this. What the strategies are. How to work iteratively on the architecture. What to consider with the employees in such a phase. And much more.
What are your observations in projects? Do you experience architectural overengineering in SMEs? I look forward to hearing about your experience!
Rule the Backend,
~ Marcus