Publiziert: Zuletzt aktualisiert:

Systemarchitektur

Die gewählte Systemarchitektur determiniert massgeblich die langfristige Wartbarkeit, Skalierbarkeit und die ökonomische Effizienz einer Software-Landschaft. Eine fehlerhafte Architektur-Entscheidung in frühen Phasen generiert technische Schulden (Technical Debt), die in späteren Wachstumsphasen exponentielle Kosten verursachen.

Wir forcieren pragmatische Architekturen, die mit der Organisation wachsen können — vom gut strukturierten Monolithen (Modulith) bis hin zu dezentralen Microservices, wenn die Komplexität es rechtfertigt.

Anti-Patterns: Die Big Ball of Mud

Viele gewachsene IT-Systeme enden als unstrukturierte Monolithen, in denen jede Änderung an einer Stelle unvorhersehbare Seiteneffekte an anderer Stelle auslöst. Diese Big Ball of Mud Architekturen ersticken jegliche Innovationskraft, da das Team mehr Zeit mit Fehlerbehebung als mit der Entwicklung neuer Features verbringt. Ein unüberlegter Wechsel zu Microservices ohne die nötige operative Reife führt oft nur zu einem verteilten Monolithen, der die Komplexität erhöht, ohne die Probleme zu lösen.

Evolutionäres Design

  1. Modulith First: Start mit einer monolithischen Anwendung, die intern jedoch strikt in fachliche Module getrennt ist. Dies erlaubt eine einfache Entwicklung bei gleichzeitigem Pfad für spätere Auslagerungen.
  2. Microservices bei Bedarf: Zerlegung des Systems erst dann, wenn unterschiedliche Skalierungsanforderungen, Teamgrössen oder Technologie-Anforderungen dies zwingend erfordern.
  3. API-First & Entkopplung: Kommunikation zwischen Modulen oder Services erfolgt ausschliesslich über definierte Schnittstellen (APIs), um Seiteneffekte zu minimieren.
  4. Strangler Fig Pattern: Schrittweise Ablösung veralteter Legacy-Systeme, indem neue Funktionalitäten in neuen Services gebaut werden, die das alte System sukzessive "umwuchern" und ersetzen.
  5. Architectural Decision Records (ADRs): Dokumentation aller wichtigen Architektur-Entscheidungen inklusive Kontext und Abwägungen, um die Historie für zukünftige Teams nachvollziehbar zu machen.

Praxis-Beispiel: Der Strangler Fig Ansatz

Statt eines riskanten Big Bang Re-Platformings eines alten ERP-Systems wird zuerst die Rechnungsstellung in einen neuen, modernen Service ausgelagert. Das alte System bleibt bestehen, verliert aber nach und nach seine Aufgaben an die neue Architektur, bis es am Ende abgeschaltet werden kann.

FAQ

Sollten wir nicht direkt auf Microservices setzen, um wie Netflix oder Amazon zu sein?

Nur wenn ihr auch die gleiche Anzahl an Ingenieuren und die gleiche operative Komplexität managen wollt. Für die meisten Schweizer Unternehmen ist ein gut strukturierter Modulith die ökonomisch sinnvollere und schnellere Wahl.

Wie verhindern wir, dass unsere neue Architektur in 5 Jahren wieder veraltet ist?

Durch evolutionäres Design. Wir bauen Systeme so, dass sie austauschbar bleiben. Die Modularisierung ist wichtiger als die initiale Wahl des Frameworks.

Reference Guide

  • Building Evolutionary Architectures: Neal Ford et al. über Systeme, die sich mit der Zeit verändern können. O'Reilly
  • The Strangler Fig Application: Martin Fowler über das Pattern zur Legacy-Migration. martinfowler.com
  • Clean Architecture: Robert C. Martin über die Prinzipien der Softwarestrukturierung. Prentice Hall

Verwandte Themen

Offene Punkte