Softwarearchitektur für den Mittelstand: skalierbar planen, ohne zu überbauen
Microservices für 50 Nutzer sind kein Weitblick, sondern teurer Ballast. Wie man Architektur so plant, dass sie mit dem Geschäft wächst — nicht mit dem Hype.
Zwei Fehler kosten im Mittelstand gleich viel — nur zu unterschiedlichen Zeitpunkten. Der erste: alles als schnelles Skript bauen, das nach zwei Jahren niemand mehr ändern kann. Der zweite: am ersten Tag eine Architektur für Millionen Nutzer entwerfen, die man nie haben wird.
Gute Architektur ist nicht die komplizierteste. Sie ist die, die die richtigen Entscheidungen früh trifft und die teuren Entscheidungen so lange offen hält, wie es verantwortbar ist.
Die falsche Skalierungsachse
Architektur-Diskussionen drehen sich fast immer um Last: „Was, wenn wir Millionen Anfragen pro Sekunde haben?" Im Mittelstand ist das selten das echte Problem. Die Achse, an der es wirklich knirscht, heißt Änderbarkeit: Wie teuer ist die nächste Anpassung, wenn das Geschäft sich ändert?
Der Accelerate State of DevOps Report 2024 von DORA misst genau das — wie schnell und stabil ein Team Änderungen liefert. Nicht Spitzenlast entscheidet über Erfolg, sondern wie billig die nächste Änderung ist.
Microservices sind selten die Antwort
Microservices lösen ein Organisationsproblem großer Unternehmen: viele Teams, die unabhängig liefern müssen. Ein Mittelständler mit einem kleinen Team hat dieses Problem nicht — aber bekommt alle Kosten: verteilte Fehler, Netzwerkgrenzen, Betriebskomplexität.
Der Thoughtworks Technology Radar warnt seit Jahren vor genau dieser Reflex-Adoption. Für die meisten Mittelstandssysteme ist ein gut strukturierter, modularer Monolith die schnellere, stabilere und billigere Wahl.
Vier Prinzipien, die mit dem Geschäft skalieren
1. Klare Grenzen statt vieler Dienste
Was zählt, sind saubere innere Grenzen — Module, die man unabhängig verstehen und ändern kann. Ob daraus später Dienste werden, ist eine spätere, billige Entscheidung — wenn die Grenzen stimmen.
2. Daten von Logik trennen
Die Datenstruktur überlebt fast jede Oberfläche und jeden Framework-Wechsel. Wer die Daten sauber modelliert, kann oben fast alles austauschen. Wer Logik in die Datenbank verstreut, friert das System ein.
3. Entscheidungen aufschieben, nicht vermeiden
Gute Architektur hält teure Wahlmöglichkeiten offen: Welcher Zahlungsanbieter, welche Suche, welche Queue — das entscheidet man spät, hinter einer Schnittstelle, nicht am ersten Tag fest verdrahtet.
4. Eine Schnittstelle nach außen
Eine API-Schicht trennt das System von allem, was außen hängt — Webshop, ERP, Excel-Realität. Sie ist dieselbe Schicht, die später Modernisierung und Integration trägt (siehe API-Integration für Unternehmen).
„Boring Technology" ist eine Architektur-Entscheidung
Die spannendste Technologie ist selten die richtige für ein System, das fünf Jahre laufen und von wechselnden Leuten gewartet werden muss. Bewährte, langweilige Bausteine senken Risiko, Einarbeitungszeit und Betriebskosten. Neuheit gehört dorthin, wo sie echten Wettbewerbsvorteil bringt — nicht in die Standardteile.
Architektur ist auch eine Build-or-Buy-Frage
Die beste Architektur für einen Standardprozess ist oft kein eigener Code, sondern ein eingekauftes Produkt mit sauberer Anbindung. Was man selbst baut, sollte das sein, was einen unterscheidet — der Rest wird angebunden, nicht nachgebaut. Wo Eigenbau sinnvoll ist, zeigt sich oft an konkreten Web-Anwendungen wie einem B2B-Portal mit Next.js.
Checkliste vor der Architekturentscheidung
- Skalieren wir entlang Änderbarkeit, nicht nur Last?
- Haben wir klare innere Grenzen statt vieler verteilter Dienste?
- Sind Daten und Logik sauber getrennt?
- Halten wir teure Entscheidungen hinter Schnittstellen offen?
- Gibt es eine API-Schicht nach außen?
- Nutzen wir bewährte Technik für die Standardteile?
- Bauen wir nur, was uns unterscheidet — und kaufen den Rest?
Häufige Fragen
Brauchen wir keine Microservices, um skalierbar zu sein? Meist nicht. Skalierbarkeit kommt aus klaren Grenzen und sauberen Daten — nicht aus der Anzahl der Dienste. Microservices lösen ein Teamproblem, kein Lastproblem.
Ist ein Monolith nicht veraltet? Ein unstrukturierter Monolith ja. Ein modularer Monolith mit klaren Grenzen ist für die meisten Mittelstandssysteme die robusteste Wahl.
Wann lohnt sich eine aufwendigere Architektur? Wenn mehrere Teams unabhängig liefern müssen oder einzelne Teile echt unterschiedlich skalieren. Beides ist im Mittelstand seltener als gedacht.
Wie verhindern wir, dass die Architektur uns einsperrt? Entscheidungen hinter Schnittstellen aufschieben und Daten sauber modellieren. Dann bleibt fast alles austauschbar.
Fazit
Skalierbare Architektur im Mittelstand heißt nicht „bereit für Millionen Nutzer", sondern „billig änderbar, wenn sich das Geschäft ändert". Klare Grenzen, saubere Daten, aufgeschobene teure Entscheidungen, eine API nach außen und bewährte Technik schlagen jeden Microservice-Reflex — und kosten weniger.
Weiterlesen
- Web-App mit Next.js: B2B-Portal entwickeln — Architektur an einem konkreten System.
- API-Integration für Unternehmen: ERP, CRM, Webshop und Excel verbinden — die Schicht nach außen.
Nächster Schritt
Sie wollen ein System planen, das mit dem Geschäft wächst statt mit dem Hype? Beginnen Sie mit einer kurzen Einschätzung Ihrer Anforderungen. Wir entwerfen eine Architektur, die heute trägt und morgen änderbar bleibt.
Quellen
- DORA, Accelerate State of DevOps Report 2024 — dora.dev
- Thoughtworks, Technology Radar — thoughtworks.com
- Atlassian, Agiles Projektmanagement — atlassian.com