Kommunikationskosten
Softwareentwicklung ist keine reine Implementierungsarbeit.
Sie ist Koordinationsarbeit.
Mit wachsender Teamgröße und Systemkomplexität steigen nicht nur Codezeilen – sondern Kommunikationsbeziehungen.
Architektur skaliert nur so gut wie Kommunikation beherrschbar bleibt.
1. Das mathematische Grundproblem
In einem Team mit n Personen entstehen:
n(n−1) / 2 Kommunikationsbeziehungen
Beispiele:
- 3 Personen → 3 Verbindungen
- 5 Personen → 10 Verbindungen
- 8 Personen → 28 Verbindungen
- 12 Personen → 66 Verbindungen
Kommunikation wächst quadratisch.
Ab einer gewissen Größe dominiert Koordination die Wertschöpfung.
2. Brooks’ Law
Fred Brooks formulierte:
„Adding manpower to a late software project makes it later.“
Warum?
Neue Personen erzeugen:
- Einarbeitungsaufwand
- Abstimmungsbedarf
- Integrationskosten
- zusätzliche Kommunikationskanten
Mehr Menschen erhöhen zunächst Komplexität – nicht Geschwindigkeit.
3. Kommunikationskosten im Systemdesign
Kommunikation existiert nicht nur zwischen Menschen.
Sie existiert auch zwischen:
- Services
- Modulen
- APIs
- Teams
- Domänen
Wenn zwei Komponenten ständig synchronisiert werden müssen, ist die Grenze falsch geschnitten.
Wenn zwei Teams permanent Meetings brauchen, ist die Architektur zu stark gekoppelt.
4. Microservices und Kommunikationskosten
Microservices versprechen Unabhängigkeit.
Aber jeder Service erzeugt:
- API-Abstimmung
- Versionierungsfragen
- Contract-Governance
- Incident-Koordination
- Monitoring-Abstimmung
Zu viele Services erhöhen:
- Organisationslast
- Fehlerquellen
- Koordinationsaufwand
Microservices multiplizieren Kommunikationskosten.
5. Gute Architektur reduziert Kommunikation
Ziel ist nicht „mehr Abstimmung“.
Ziel ist:
Kommunikation auf das notwendige Minimum reduzieren.
Das gelingt durch:
- klare Abstraktionsgrenzen
- stabile Contracts
- klare Ownership
- entkoppelte Deployments
- modulare Domänen
Je besser die Grenze, desto weniger Abstimmung.
6. Kommunikationskosten vs. Qualität
Hohe Kommunikationskosten führen zu:
- impliziten Entscheidungen
- informellen Absprachen
- „quick fixes“
- sinkender Dokumentation
- Architektur-Erosion
Wenn Koordination zu teuer wird, werden Standards umgangen.
7. Organisationsdesign als Gegenmittel
Kommunikationskosten lassen sich steuern durch:
- kleine, fokussierte Teams
- klare Verantwortlichkeiten
- definierte Entscheidungsrechte
- stabile Schnittstellen
- Platform-Enablement
Teamgröße unter 7–9 Personen ist kein Zufall.
Kleine Teams reduzieren Quadratik.
8. Symptome zu hoher Kommunikationskosten
- Viele Meetings mit wenig Output
- Entscheidungen dauern lange
- Ständige API-Änderungen
- Feature-Entwicklung blockiert durch andere Teams
- Unklare Ownership
- Incident-War-Rooms mit 20 Personen
Wenn Koordination teurer wird als Implementierung, ist das System überkomplex.
9. Leitfragen
- Wie viele Teams sind an einem Feature beteiligt?
- Wie viele Services sind für einen Flow notwendig?
- Wie oft müssen Teams synchronisieren?
- Wie viele Personen sitzen regelmäßig in Architektur-Meetings?
- Können Teams unabhängig deployen?
Wenn Antworten „viele“ lauten, steigen Kommunikationskosten.
10. Kerngedanke
Komplexität entsteht nicht nur im Code.
Sie entsteht in Kommunikationsbeziehungen.
Gute Architektur reduziert:
- technische Kopplung
- organisatorische Abhängigkeiten
- unnötige Abstimmung
Schlechte Architektur skaliert Kommunikation.
Und Kommunikation skaliert schneller als Features.