Behaviour over Time Charts

Zweck

"Verhalten über die Zeit" (Behaviour over Time, BOT) Graphen sind das absolute Fundament der System-Diagnose. In der Softwareentwicklung neigen wir dazu, Systeme in isolierten "Ereignissen" (Incidents, Sprints, Spikes) zu betrachten. Ein BOT Chart zwingt uns, aus dem operativen Tagesgeschäft herauszuzoomen und zu erkennen, dass das heutige Ereignis nur ein Datenpunkt in einer viel größeren, jahrelangen System-Kurve ist. Es deckt auf, ob ein Problem wächst, verfällt, oszilliert oder an einem harten physikalischen Limit zerschellt (z.B. S-Kurve).

Einsatzkontext

BOT Charts werden als der allererste Schritt in fast jeder Ursachenanalyse (Root Cause Analysis) im System-Design genutzt. Bevor du versuchst, zu verstehen, *warum* der Jenkins-Server heute brennt, musst du aufmalen, *wie* sich die Build-Queue in den letzten 24 Monaten verhalten hat. Ohne diese historische Timeline rätst du blind.

Schritt für Schritt

1.Das Problem definieren: Lege die kritische Variable fest, die du untersuchen willst (z.B. Defekt-Rate, Fluktuation der Entwickler, Technische Schulden).

2.Die Zeitachse spannen (X-Achse): Gehe weit genug zurück, um echte Muster zu sehen (Monate oder Jahre, nicht Tage).

3.Den Graph zeichnen (Y-Achse): Zeichne grob (ohne perfekte Zahlen, es geht um die Kurvenform) den Verlauf ein. Geht es stetig nach oben? Gibt es wilde Schwankungen (Oszillation)?

4.Verwandte Graphen übereinanderlegen: Der Magie-Moment entsteht hier. Mache denselben Graphen für *externe* treibende Kräfte (z.B. "Anzahl neuer Features pro Sprint") und lege ihn über den ersten Graphen, um verzögerte (Delayed) Korrelationen zu sehen.

Beispiel

Ein Engineering-Team klagt über sinkende Release-Frequenz (Graph 1: "Deployments pro Woche" - Linie geht nach unten). Sie beschuldigen die QA. Ein Architekt holt ein BOT Chart hervor und zeichnet darüber Graph 2 ("Anzahl der Microservices im System", Linie geht rasant nach oben) und Graph 3 ("Anzahl der DevOps Ingenieure", Linie bleibt komplett flach). Das Verhalten über Zeit zeigt gnadenlos: Die sinkende Release-Frequenz ist keine Faulheit der QA, sondern das mathematische Zusammentreffen von explodierender Architektur-Komplexität bei stagnierender Deployment-Kapazität.

Diagramm

Wie aus Diagnose Handlung wird

Der wertvollste Aspekt von BOT Charts in der Architektur ist das Sichtbarmachen von *Delays* (Verzögerungen). Wenn das Management harten Druck ausübt (Graph A steigt abrupt), steigt die Ticket-Velocity kurzfristig mit an (Graph B steigt). Sechs Monate später jedoch explodieren plötzlich die Bug-Raten (Graph C steigt), während die Velocity extrem kollabiert. Hättest du nur Snapshot-Metriken im Q3 angesehen, hättest du das Problem nicht verstanden. Das BOT-Diagramm beweist das "Fixes That Fail" Muster: Der kurzfristige Tempo-Hack im Q1 hat zeitverzögert im Q3 das System getötet.

Wann diese Methode die richtige ist

Im Gegensatz zum komplexen *Stock and Flow Mapping*, welches harte physikalische Gleichungen formuliert, leben BOT-Graphen oft sehr stark von qualitativen Einschätzungen. Es ist völlig legitim, weiche Faktoren wie "Moral der Entwickler" oder "Architektonische Übersicht" als handgezeichneten Linien-Verlauf (Puls) in die Zeit-Achse aufzunehmen.

Wie du die Diagnose im Alltag einsetzt

Zwinge dein Team dazu, keine Architektur-Diskussion über ein "akutes Problem" ohne BOT Chart zu führen. Wenn jemand sagt: "Wir müssen den Cache vergrößern, wir sind am Limit", lass ihn an das Whiteboard gehen und die Cache-Hit-Ratio, die Latenz und die User-Anmeldungen der letzten 2 Jahre als drei Kurven aufmalen. Oft erkennt das Team beim physikalischen Malen der Lücken, dass das Problem ganz woanders entstanden ist.

Erste Analyse-Schritte

Es geht in den Workshops bei BOT Charts nicht um datengenaue Excel-Generierung! Ein BOT-Chart ist ein *Gesprächs-Tool*. Lasse den Principal Dev eine Kurve malen, und lass den Product Owner eine konkurrierende Kurve in rot darüber zeichnen, wenn er die Historie des Softwareverfalls völlig anders wahrgenommen hat.

Woran du eine brauchbare Diagnose erkennst

Enthält euer DORA-Metriken Dashboard (Lead Time, Deployment Freq., MTTR) nicht nur aktuelle Tachometer-Geweih (Gauges), sondern gnadenlose Liniengraphen, die den Verfall oder Aufstieg über die letzten 24 Monate visualisieren?

Quellen

John Sterman — Business Dynamics, Kap. 5: BOT Graphs (McGraw-Hill, 2000)

The Systems Thinker: Behaviour Over Time Diagrams

Peter Senge — The Fifth Discipline Fieldbook (Doubleday, 1994)