Architektur
Grundlegendes Modell für Aufbau, Beziehungen und Prinzipien eines Systems zur Steuerung technischer und fachlicher Entscheidungen.
Klassifikation
- KomplexitätHoch
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeReif
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Überarchitektur (Overengineering) führt zu unnötiger Komplexität.
- Fehlende Anpassung an Betriebsrealitäten erzeugt technische Schulden.
- Unklare Verantwortlichkeiten verhindern schnelle Entscheidungen.
- Dokumentiere Entscheidungen kurz und nachvollziehbar als ADRs.
- Priorisiere Qualitätsattribute und messe sie mit SLOs.
- Führe regelmäßige Architektur-Reviews mit cross-funktionalen Teams durch.
I/O & Ressourcen
- Geschäftsziele und Use Cases
- Technische Randbedingungen und bestehende Systeme
- Teamkompetenzen und Betriebsmodell
- Architekturentscheidungsdokumente (ADR)
- Komponenten- und Schnittstellendiagramme
- Qualitätsziele mit Metriken und SLOs
Beschreibung
Architektur beschreibt die grundlegende Struktur, Komponenten und Beziehungen eines Systems sowie die Prinzipien, nach denen diese gestaltet werden. Sie verbindet fachliche Anforderungen mit technischen Entscheidungen, führt Qualitätsziele und Schnittstellen zusammen und bietet Entscheidungsrahmen für Skalierbarkeit, Sicherheit und Wartbarkeit in verschiedenen organisatorischen Kontexten.
✔Vorteile
- Bessere Skalierbarkeit und Vorhersehbarkeit von Systemverhalten.
- Klare Entscheidungsgrundlage für Technologie- und Organisationsfragen.
- Erleichterte Wartbarkeit und Teamkoordination durch Verantwortungsgrenzen.
✖Limitationen
- Kann übermäßig bürokratisch werden, wenn Governance fehlt.
- Nicht jede architektonische Empfehlung passt in alle Organisationskontexte.
- Hoher Initialaufwand für Dokumentation und Abstimmung.
Trade-offs
Metriken
- Ansprechzeit (P95)
Misst die 95. Perzentil-Antwortzeit relevanter Endpunkte.
- Verfügbarkeit (Uptime)
Prozentuale Zeit, in der das System für Nutzer erreichbar ist.
- Mean Time to Recovery (MTTR)
Durchschnittliche Zeit zur Wiederherstellung nach Ausfällen.
Beispiele & Implementierungen
E-Commerce-Plattform mit skalierbaren Services
Aufteilung in Checkout-, Katalog- und Zahlungsservices mit asynchroner Kommunikation und klaren SLAs.
Bankensystem mit strenger Sicherheitsarchitektur
Mehrschichtige Sicherheitskontrollen, Trennung sensibler Daten und Auditing auf Architektur-Ebene.
IoT-Plattform mit Edge- und Cloud-Komponenten
Verarbeitung sensitiver Daten am Edge, Aggregation in der Cloud und Resilienz durch lokale Caching-Strategien.
Implementierungsschritte
Stakeholder-Workshops zur Anforderungsaufnahme
Erstellung von Architekturentscheidungen und Diagrammen
Iterative Implementierung mit Reviews und Tests
⚠️ Technische Schulden & Engpässe
Tech Debt
- Kurzfristige Workarounds statt robuster Schnittstellen-Designs.
- Unklare Ownership führt zu nicht behobenen Architekturproblemen.
- Fehlende Automatisierung von Tests und Deployments
Bekannte Engpässe
Beispiele für Missbrauch
- Einführung komplexer Microservice-Architektur für triviale Anwendungen.
- Strikte Standardisierung ohne Berücksichtigung lokaler Anforderungen.
- Dokumentation, die veraltet ist und nicht dem Implementierungsstand entspricht.
Typische Fallen
- Zu frühe Festlegung auf eine Technologie vor Klärung der Anforderungen.
- Vernachlässigung nicht-funktionaler Anforderungen bei Designentscheidungen.
- Unzureichende Einbindung von Betrieb und Sicherheit in Architekturentscheidungen.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Budget- und Infrastrukturlimits
- • Regulatorische Anforderungen an Datenhaltung
- • Legacy-Systeme mit begrenzter Änderbarkeit