Software Architect
Architektur entsteht immer.
Die Frage ist nur: bewusst – oder zufällig.
Der Software Architect verantwortet, dass sie bewusst entsteht.
1. Kurzdefinition
Ein Software Architect verantwortet die konzeptionelle Integrität eines Systems.
Nach Frederick P. Brooks bedeutet das:
Eine kohärente, verständliche Gesamtidee, die sich durch alle wesentlichen Entscheidungen zieht.
Architektur ist kein Diagramm. Architektur ist die Summe schwer reversibler Entscheidungen.
2. Kernverantwortung
Der Architect entscheidet über:
- Systemstruktur
- Modularisierung
- Schnittstellen
- Integrationsmuster
- Datenflüsse
- nicht-funktionale Prioritäten
- technische Leitplanken
Er schützt die strukturelle Integrität.
3. Was Architektur wirklich ist
Architektur betrifft Entscheidungen:
- mit hoher Tragweite
- mit hoher Änderungskosten
- mit systemweiter Wirkung
Beispiele:
- Monolith vs. Microservices
- Event-driven vs. synchron
- Datenmodell-Strategie
- Authentifizierungsmechanismus
- API-Kontrakte
- Deployment-Topologie
Nicht jede Entscheidung ist Architektur. Nur die schwer rückbaubaren.
4. Architektur = Trade-off-Arbeit
Architektur ist nie optimal. Sie ist:
- Performance vs. Flexibilität
- Sicherheit vs. Usability
- Geschwindigkeit vs. Wartbarkeit
- Kosten vs. Resilienz
Der Architect macht diese Konflikte sichtbar – und entscheidet bewusst.
5. Architektur und Organisation
Conway’s Law:
Systeme spiegeln Kommunikationsstrukturen wider.
Ein Architect muss:
- Teamzuschnitt verstehen
- Verantwortlichkeiten klären
- Schnittstellen minimieren
- Integrationsrisiken erkennen
Architektur ohne Organisationsbewusstsein ist naiv.
6. Was ein Software Architect nicht ist
❌ Kein Feature-Implementierer mit Titel
❌ Kein Projektmanager
❌ Kein „Chief Developer“
❌ Kein Diagramm-Produzent
❌ Kein Gatekeeper ohne Umsetzung
Architektur ohne Team ist Papier. Team ohne Architektur ist Chaos.
7. Abgrenzung: Architect vs. Tech Lead
| Software Architect | Tech Lead |
|---|---|
| Systemweite Struktur | Teamweite Delivery |
| Langfristige Integrität | Operative Umsetzung |
| Architektur-Constraints | Umsetzung innerhalb Constraints |
| Domänen- und Systemgrenzen | Feature-Design |
| Governance & Leitplanken | Code-Qualität & Reviews |
Ein Tech Lead schützt das Team. Ein Architect schützt das System.
In kleinen Teams können beide Rollen identisch sein. In komplexen Systemen nicht.
8. Architektur im Qualitätsstufen-Modell
Stufe 1:
- implizite Architektur
Stufe 2:
- dokumentierte Struktur
- erste ADRs
Stufe 3:
- klare Systemgrenzen
- bewusste NFR-Strategien
- Observability-Architektur
Stufe 4:
- Traceability
- Sicherheitsarchitektur
- formale Architektur-Reviews
Stufe 5:
- auditierbare Architekturentscheidungen
- formalisierte Constraints
- unabhängige Verifikation
Hohe Qualitätsstufen ohne Architekturverantwortung sind instabil.
9. Mythos-Check
Mythos: Architektur ist Big Design Up Front.
Falsch. Architektur ist iterativ – aber nicht beliebig.
Mythos: Gute Entwickler brauchen keinen Architect.
Falsch. Gute Entwickler brauchen klare Leitplanken.
Mythos: Architektur entsteht durch Refactoring.
Nur teilweise.
Struktur ohne Entscheidung bleibt emergent – nicht intentional.
10. Wirksame Architektur-Artefakte
- C4-Diagramme
- ADRs
- Schnittstellen-Verträge
- Qualitätsziele (NFRs)
- Architektur-Prinzipien
- Tech-Radar
Nicht die Artefakte sind wichtig. Sondern die Klarheit dahinter.
11. Kurzcheck: Bin ich Architect?
- Treffe ich schwer reversierbare Entscheidungen?
- Schaffe ich klare Systemgrenzen?
- Dokumentiere ich Trade-offs?
- Denke ich in Lebensdauer und Skalierung?
- Erkenne ich Organisationsrisiken?
- Schütze ich konzeptionelle Integrität?
Wenn ja, erfüllst du die Rolle.
Kernaussage
Architektur ist Verantwortung für Systemintegrität.
Nicht für Code. Nicht für Tickets. Nicht für Termine.
Für Struktur.
Und ohne bewusste Struktur entsteht der Big Ball of Mud.