Software Architektur
Konzeptuelle Beschreibung von Struktur, Komponenten und Schnittstellen eines Softwaresystems zur Erfüllung nicht-funktionaler und funktionaler Anforderungen.
Klassifikation
- KomplexitätHoch
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Fehlende Abstimmung führt zu Silos und Inkonsistenzen
- Falsche Annahmen bei Anforderungen können teure Nacharbeiten verursachen
- Unzureichende Operationalisierung der Architektur behindert Laufzeitstabilität
- Frühe und iterative Architekturvalidierung mit Prototypen
- Dokumentation von Entscheidungsgründen, nicht nur von Ergebnissen
- Enge Zusammenarbeit von Architektur- und Produktteams
I/O & Ressourcen
- Geschäfts- und Produktziele
- Nicht-funktionale Anforderungen
- Bestehende Systemarchitektur und Technik-Stack
- Architekturdiagramme und Komponentenbeschreibungen
- Dokumentierte Architekturentscheidungen (ADRs)
- Qualitäts- und Betriebsanforderungen
Beschreibung
Softwarearchitektur beschreibt Struktur, Komponenten, Schnittstellen und Leitprinzipien zur Gestaltung komplexer Softwaresysteme. Sie schafft Abstraktionen zur Erreichung von Skalierbarkeit, Wartbarkeit und Wiederverwendung und macht Qualitätsanforderungen explizit. Architekturentscheidungen prägen Technologie-, Betriebs- und Organisationsaspekte auf Enterprise-, Domain- und Team-Ebene.
✔Vorteile
- Verbesserte Skalierbarkeit und Performance durch klaren Systemaufbau
- Erhöhte Wartbarkeit und geringere Änderungsrisiken
- Bessere Kommunikationsgrundlage zwischen Technik und Business
✖Limitationen
- Hoher initialer Aufwand für Analyse und Dokumentation
- Überarchitektur kann Time-to-Market verlangsamen
- Nicht alle Qualitätsanforderungen lassen sich gleichzeitig optimieren
Trade-offs
Metriken
- Mean Time To Recovery (MTTR)
Durchschnittliche Zeit zur Wiederherstellung nach einem Ausfall.
- Deployment-Frequenz
Wie häufig Releases oder Deployments durchgeführt werden.
- Latenz und Antwortzeit
Metriken zur Laufzeitleistung von Endpunkten und Prozessen.
Beispiele & Implementierungen
Microservice-Einführung bei E-Commerce
Aufteilung eines Bestellsystems in autonome Services zur Verbesserung der Skalierbarkeit und Release-Frequenz.
Event-Driven-Architektur in Finanzen
Einsatz von Ereignisströmen zur Entkopplung von Komponenten und zur Gewährleistung von Nachvollziehbarkeit.
Monolithische Konsolidierung für Performance
Gezielte Zusammenführung verteilter Komponenten zur Reduktion von Latenz und Betriebsaufwand.
Implementierungsschritte
Ziele und Qualitätsanforderungen erheben
Domänen und Bounded Contexts analysieren
Architekturmuster und -stile bewerten
Architekturentscheidungen dokumentieren (ADRs)
Operationalisierung: Monitoring, Deployments und SLAs einführen
⚠️ Technische Schulden & Engpässe
Tech Debt
- Nicht refaktorierte Monolith-Teile nach Aufteilung
- Veraltete Schnittstellen ohne Versionierung
- Fehlendes automatisiertes Testen für kritische Integrationen
Bekannte Engpässe
Beispiele für Missbrauch
- Einführen von Microservices für kleine, unkritische Funktionen ohne Betriebskonzept
- Ignorieren nicht-funktionaler Anforderungen während Designphase
- Dokumentationsverfall: Architektur ist nicht mehr aktuell
Typische Fallen
- Verwechseln von Architekturprinzipien mit Implementierungsdetails
- Vernachlässigung von Betrieb und Observability
- Zu späte Einbindung relevanter Stakeholder
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Budget- und Zeitlimits
- • Regulatorische Anforderungen
- • Vorhandene Legacy-Systeme