Systemzustände von Softwareprojekten
Softwareprodukte entwickeln sich über Zeit nicht nur technisch, sondern auch organisatorisch.
Architektur, Teamverhalten, Lieferfähigkeit und Erwartungsmanagement bilden gemeinsam ein System.
Dieses System kann unterschiedliche Zustände annehmen.
Viele langlebige Softwareprodukte durchlaufen ähnliche Phasen.
Das folgende Modell beschreibt vier typische Systemzustände:
| Zustand | Beschreibung |
|---|---|
| Healthy System | Das System verbessert sich aktiv und bleibt gut veränderbar |
| Strained System | Komplexität wächst, Änderungen werden langsamer |
| Dysfunctional System | Lieferung wird schwierig, Fehler und Workarounds nehmen zu |
| Stable Failure | Das System wird organisatorisch stabil betrieben, obwohl strukturelle Probleme bestehen |
Diese Zustände sind keine festen Kategorien.
Sie beschreiben typische Dynamiken, die in vielen Softwareorganisationen beobachtet werden können.
Die Systemzustandskurve
Mit zunehmender Systemkomplexität sinkt typischerweise die Änderbarkeit eines Systems.
Wenn keine aktive Architekturpflege stattfindet, driftet ein System häufig durch mehrere Zustände.
Der kritische Punkt liegt meist zwischen Dysfunctional System und Stable Failure.
In dieser Phase hört das System häufig auf, sich selbst zu korrigieren.
Healthy System
Ein gesundes System zeichnet sich durch hohe Änderbarkeit und aktive Verbesserung aus.
Typische Merkmale:
- Features werden regelmäßig fertiggestellt
- Architektur wird aktiv gepflegt
- Refactoring ist Teil der normalen Entwicklung
- Entwickler können die meisten Bereiche des Systems sicher ändern
Komplexität wächst zwar auch in gesunden Systemen, wird jedoch kontinuierlich kontrolliert.
Strained System
Mit zunehmender Systemgröße steigt die Komplexität.
In dieser Phase beginnen erste Reibungen sichtbar zu werden.
Typische Merkmale:
- Änderungen dauern länger
- bestimmte Module gelten als schwierig
- Architekturprobleme werden teilweise verschoben
- technisches Refactoring konkurriert stärker mit Featureentwicklung
Das System funktioniert weiterhin gut, benötigt jedoch mehr Aufmerksamkeit.
Dysfunctional System
Wenn strukturelle Probleme länger bestehen bleiben, kann ein System zunehmend schwer veränderbar werden.
Typische Merkmale:
- Sprintziele werden regelmäßig verfehlt
- Bugfixes dominieren die Entwicklung
- Änderungen erzeugen unerwartete Nebeneffekte
- Workarounds ersetzen strukturelle Verbesserungen
In dieser Phase wird die Entwicklung deutlich langsamer.
Stable Failure
Stable Failure beschreibt einen Zustand, in dem das System organisatorisch stabil betrieben wird, obwohl strukturelle Probleme bekannt sind.
Typische Merkmale:
- bekannte Architekturprobleme werden dauerhaft akzeptiert
- Erwartungen an Geschwindigkeit oder Qualität sinken
- schwierige Systembereiche werden gemieden
- Teams konzentrieren sich auf Stabilität statt Verbesserung
Das System funktioniert weiterhin, verliert jedoch zunehmend seine Änderbarkeit.
Der kritische Wendepunkt
Der entscheidende Übergang geschieht meist nicht zwischen zwei technischen Zuständen, sondern in der Organisation.
Solange ein Team versucht, strukturelle Probleme zu lösen, kann sich ein System erholen.
Wenn jedoch Verbesserungsversuche ausbleiben oder dauerhaft scheitern, stabilisiert sich das System um seine bestehenden Einschränkungen.
Dieser Zustand wird in den folgenden Artikeln genauer beschrieben.