Constraints and Bottlenecks

Definition

Constraints (Beschränkungen) und Bottlenecks (Engpässe) sind die limitierenden Faktoren eines Systems. Jedes System hat mindestens einen Engpass, der seinen maximalen Gesamtdurchsatz oder seine Leistungsfähigkeit bestimmt. Die Theory of Constraints besagt: Jede Optimierung an einer Stelle, die *kein* Engpass ist, ist eine reine Illusion. Sie erhöht den Durchsatz des Gesamtsystems nicht, sondern baut oft nur Zwischenlager (Queues, Work-in-Progress) auf.

Systemmechanismus

Der Durchfluss (Fluss, Flow) von Arbeit oder Datenblöcken durch ein System wird durch die langsamste Station (den Bottleneck) vorgegeben. Wenn du die Stationen davor schneller machst, stauen sich die Pakete vor dem Engpass. Machst du die Stationen danach schneller, drehen sie Leerlauf. Verbesserungen zeigen also nur dann im globalen Maßstab Wirkung, wenn sie exakt am aktuellen Bottleneck ansetzen.

Architekturbeispiel

Eine API-Landschaft liefert Latenzzeiten von 500ms pro Request. Die Entwickler optimieren den featurereichen Service A von 100ms auf 10ms (riesiger prozentualer Gewinn). Die Gesamt-Latenz sinkt jedoch nur unmerklich. Warum? Der eigentliche Architekturnadelöhr ist ein veralteter Authentifizierungs-Service B, auf den Service A zwingend warten muss. Dieser hat weiterhin 400ms Latenzzeit. Die Investition am Falschen Ort war verschwendet, die Gesamtarchitektur hat nichts gewonnen.

Organisationsbeispiel

Ein Unternehmen stellt zehn neue Frontend-Entwickler ein, um die Feature-Lieferung zu beschleunigen. Es gibt jedoch weiterhin nur einen DevOps-Ingenieur, der Deployments auf Produktion durchführen kann (der Engpass). Das Resultat: Die Entwicklungsgeschwindigkeit vor dem Bottleneck steigt massiv an, was zu enormen Rückstaus in Git und ungetesteten Integrationszweigen führt. Das Delivery an den Kunden bleibt exakt so langsam wie vorher, nur sind jetzt alle deutlich gestresster.

Diagnosefragen

1.Wo staut sich die Arbeit (Tickets, Pull Requests) oder die Datenlast (Queues) im System auf?

2.Wo gibt es Stationen oder Mitarbeiter, die extrem ausgelastet sind, während abhängige Stationen oft auf Zuarbeit warten?

3.Optimieren wir gerade wirklich den primären Engpass, oder machen wir nur eine bequeme lokale Komponente noch schneller?

Diagramm

Warum dieses Konzept in Architektur hilft

Sobald ein Engpass im System identifiziert wurde (z.B. eine langsame Altsystem-Komponente), sollte die gesamte Architektur und Organisation danach ausgerichtet werden, ihn nicht zu überlasten (Flow reduzieren). Erst wenn diese "Unterwerfung" funktioniert hat, folgt die Ausweitung des Engpasses (Elevation), etwa durch massives Refactoring oder Caching. Wird der Engpass behoben, wandert er an eine andere Stelle im System.

Woran du das Konzept von ähnlichen Themen unterscheidest

Im Gegensatz zu *Feedback Loops*, die das zyklische Verhalten von Systemen beschreiben, fokussiert sich die Engpass-Theorie rein auf den Fluss (Flow) und die Durchsatzbegrenzung linearer oder schwach verzweigter Systemketten.

Wie du das Konzept praktisch nutzt

Die fünf Schritte der Fokussierung nach Goldratt: 1) Finde den Engpass. 2) Laste den Engpass aus, ziehe maximalen Nutzen daraus. 3) Unterwerfe alles andere dem Takt des Engpasses (Work-in-Progress Limits vorschalten). 4) Erweitere den Engpass (z.B. Hardware dazukaufen, Team vergrößern, Code refaktorisieren). 5) Wenn der Engpass behoben wurde, gehe zurück zu Schritt 1.

Erste Umsetzungsschritte

Verwende Flow-Metriken aus Kanban oder Continuous Delivery (z.B. Lead Time, Cycle Time), um Engpässe unbestechlich sichtbar zu machen. Lass dich nicht von lokaler Ressourcenauslastung in die Irre führen. Lokales Heldentum an der falschen Stelle schadet dem Gesamtfluss.

Woran du Wirkung erkennst

Wissen wir, wo unser Engpass *heute* liegt? Werden Performance-Budgets explizit in die Behebung dieses spezifischen Engpasses investiert?

Quellen

Eliyahu Goldratt — The Goal (North River Press, 1984)

Wikipedia: Theory of Constraints

Gene Kim et al. — The Phoenix Project (IT Revolution, 2013)