02 — Kultur und Prinzipien
Teil A — Warum überhaupt. Zurück zur Übersicht.
Lernziel
Nach diesem Kapitel kennst du die fünf CALMS-Dimensionen und die Drei Wege und kannst sie an konkreten Beispielen erläutern. Du kannst außerdem erklären, warum die Organisationsstruktur die Softwarearchitektur bestimmt, und weißt, was das DIKW-Modell für die Fehlersuche taugt.
2.1 CALMS
CALMS ist ein Ordnungsrahmen, mit dem sich beurteilen lässt, wo eine Organisation steht. Er entstand um 2010 als CAMS bei Damon Edwards und John Willis; das L für Lean kam später durch Jez Humble hinzu.
| Buchstabe | Bedeutung | Prüffrage |
|---|---|---|
| Culture | Zusammenarbeit, geteilte Verantwortung, Umgang mit Fehlern | Was passiert bei uns nach einer Störung — Ursachenanalyse oder Schuldsuche? |
| Automation | Alles, was wiederholt und fehleranfällig ist, wird automatisiert | Welchen Handgriff machen wir mehr als zwölfmal im Jahr von Hand? |
| Lean | Verschwendung reduzieren, kleine Arbeitspakete, Fluss statt Stapel | Wie groß ist unser durchschnittliches Release? |
| Measurement | Entscheidungen auf Daten stützen | Woher wissen wir, ob die letzte Änderung etwas verbessert hat? |
| Sharing | Wissen und Erkenntnisse teilen, nicht nur Ergebnisse | Wo steht, was wir bei der letzten Störung gelernt haben? |
Der praktische Wert liegt in den Prüffragen. Wer sie ehrlich beantwortet, hat binnen einer halben Stunde eine belastbare Standortbestimmung.
Culture steht nicht zufällig vorn. Automatisierung in einer Organisation, in der nach jeder Störung ein Schuldiger gesucht wird, führt zu einem vorhersagbaren Ergebnis: Niemand traut sich mehr, etwas auszurollen. Die Werkzeuge sind dann installiert, aber ungenutzt.
Kultur lässt sich allerdings nicht anordnen. Sie folgt den Anreizen. Wenn Beförderungen an Störungsfreiheit hängen, wird niemand Risiken eingehen — unabhängig davon, was im Leitbild steht.
2.2 Die Drei Wege
Das Modell stammt von Gene Kim und ist in The Phoenix Project sowie im DevOps Handbook ausgeführt. Es beschreibt drei aufeinander aufbauende Prinzipien.
Der Erste Weg: Fluss
Arbeit fließt von links nach rechts — von der Idee über die Entwicklung und den Betrieb bis zum Kunden. Ziel ist, diesen Fluss zu beschleunigen.
Konkret heißt das:
- Arbeit sichtbar machen (Kanban-Board, Ticketsystem)
- Arbeitspakete klein halten — kleine Änderungen fließen schneller und brechen seltener
- angefangene Arbeit begrenzen (Work in Progress)
- Engpässe finden und dort ansetzen, nicht anderswo
- niemals einen bekannten Fehler nach rechts weitergeben
Der Merksatz für den Ersten Weg: Eine kleine Änderung, die schiefgeht, ist ein Ärgernis. Eine große Änderung, die schiefgeht, ist ein Vorfall. Bei einer Auslieferung mit zweihundert Änderungen weiß niemand, welche davon das Problem verursacht hat — und die Fehlersuche dauert länger als die Entwicklung.
Der Zweite Weg: Rückmeldung
Information fließt von rechts nach links — und zwar möglichst schnell und in möglichst vielen Schleifen.
- automatisierte Tests melden Fehler in Minuten statt in Wochen
- Überwachung meldet Probleme, bevor Anwender anrufen
- Entwickler sehen, wie sich ihr Code in Produktion verhält
- der Betrieb ist früh eingebunden, nicht erst beim Ausrollen
Der Wert einer Rückmeldung sinkt mit ihrem Alter. Ein Fehler, der beim Commit auffällt, kostet Minuten. Derselbe Fehler in Produktion kostet je nach Quelle das Zehn- bis Hundertfache — und das liegt weniger am Aufwand der Korrektur als am verlorenen Kontext: Nach sechs Wochen weiß niemand mehr, warum diese Zeile so geschrieben wurde.
Der Dritte Weg: Lernen und Experimentieren
Eine Kultur, in der Experimente erwünscht sind und Fehler als Erkenntnisquelle gelten.
- Zeit für Verbesserung ist eingeplant, nicht „wenn mal Luft ist„
- Störungen werden ohne Schuldzuweisung aufgearbeitet
- Erkenntnisse werden geteilt, nicht in Teams eingeschlossen
- bewusst wird Belastung erzeugt, um Widerstandsfähigkeit zu prüfen
Der dritte Weg ist der, der am häufigsten übersprungen wird. Er lässt sich nicht kaufen und zeigt keine schnellen Ergebnisse — er ist aber der einzige, der die ersten beiden dauerhaft trägt.
2.3 Conways Gesetz
1967 formulierte Melvin Conway eine Beobachtung, die seither erstaunlich zuverlässig zutrifft: Organisationen entwerfen Systeme, die ihre eigenen Kommunikationsstrukturen abbilden.
Praktische Folgen:
| Organisation | Erwartbare Architektur |
|---|---|
| Vier Abteilungen, die selten miteinander sprechen | Vier Module mit umständlichen Schnittstellen |
| Eine getrennte Datenbankabteilung | Alle Anwendungen teilen sich eine zentrale Datenbank |
| Ein zentrales Betriebsteam als Nadelöhr | Alles muss durch dieses Team, egal wie klein |
| Kleine, eigenständige Produktteams | Kleine, eigenständige Dienste |
Das erklärt, warum Architekturprojekte scheitern, die die Organisation unangetastet lassen. Wer Microservices will, aber die Freigabe jeder Änderung zentral bündelt, bekommt einen verteilten Monolithen — also alle Nachteile beider Ansätze.
Die praktische Anwendung heißt umgekehrtes Conway-Manöver: Man verändert die Teamstruktur so, dass sie der gewünschten Architektur entspricht — und lässt die Architektur folgen.
2.4 Das DIKW-Modell
DIKW unterscheidet vier Stufen, auf denen Erkenntnis entsteht.
| Stufe | Bedeutung | Beispiel aus dem Betrieb |
|---|---|---|
| Data | Rohdaten ohne Zusammenhang | HTTP 500 um 14:32:07 |
| Information | verknüpfte Daten: wer, was, wann, wo | 340 Fehler in fünf Minuten, alle im Prämienrechner |
| Knowledge | daraus abgeleitete Erkenntnis | Der Fehler trat nach dem Ausrollen von Version 2.4 auf |
| Wisdom | Erfahrung, Werte, Urteilsvermögen | Wir rollen zurück und untersuchen morgen — nicht umgekehrt |
Der Nutzen für die Praxis liegt in der Diagnose: Bei einer Störung lässt sich fragen, auf welcher Stufe es hakt.
- Fehlen Daten? Dann fehlt Instrumentierung — siehe Kapitel 12.
- Fehlt Information? Dann sind die Daten da, aber nicht auswertbar. Logs ohne Zeitstempel, Metriken ohne Bezeichner.
- Fehlt Wissen? Dann fehlt Erfahrung oder Dokumentation. Runbooks helfen.
- Fehlt Weisheit? Dann fehlt Entscheidungsspielraum — meist ein Führungsthema.
Die meisten Organisationen ertrinken übrigens in Daten und verhungern an Information. Ein Dashboard mit vierzig Diagrammen, das niemand liest, ist der Regelfall, nicht die Ausnahme.
2.5 Lab: CALMS-Selbsteinschätzung
Bewerte deinen Betrieb — oder deine Ausbildungsabteilung — in jeder Dimension von 1 bis 5.
Culture 1 ── 2 ── 3 ── 4 ── 5 1 = Störungen enden mit der Frage "wer war das?" 5 = Störungen enden mit einer dokumentierten Ursachenanalyse Automation 1 ── 2 ── 3 ── 4 ── 5 1 = Auslieferung ist eine Anleitung mit 30 Handgriffen 5 = Auslieferung ist ein Knopfdruck Lean 1 ── 2 ── 3 ── 4 ── 5 1 = zwei große Releases im Jahr 5 = viele kleine Änderungen, laufend Measurement 1 ── 2 ── 3 ── 4 ── 5 1 = wir merken Störungen, wenn Anwender anrufen 5 = wir sehen Abweichungen, bevor sie wirken Sharing 1 ── 2 ── 3 ── 4 ── 5 1 = Wissen steckt in Köpfen 5 = Wissen steht dokumentiert und wird gepflegt
Anschließend die entscheidende Frage: Welche Dimension hat den niedrigsten Wert — und was wäre der kleinste sinnvolle Schritt, um von 2 auf 3 zu kommen?
Nicht auf 5. Auf 3. Wer Verbesserungen zu groß plant, setzt sie nicht um.
2.6 Anti-Pattern
| Anti-Pattern | Woran man es erkennt | Was stattdessen hilft |
|---|---|---|
| Kultur per Dekret | Werteplakate im Flur, unveränderte Zielvorgaben | Anreize ändern, nicht Poster aufhängen |
| Automatisierung ohne Kultur | Pipeline vorhanden, aber niemand traut sich auszuliefern | Erst Vertrauen und Rückrollbarkeit, dann Tempo |
| Sharing als Einbahnstraße | Nur Erfolge werden geteilt | Auch Fehlschläge dokumentieren — die lehren mehr |
| Kennzahlen als Druckmittel | Teams werden anhand der Deployment-Frequenz verglichen | Kennzahlen zur Selbststeuerung, nicht zur Bewertung |
| Architektur ohne Organisation | Microservices im Entwurf, zentrale Freigabe im Alltag | Conway ernst nehmen |
2.7 Reflexionsfrage
Wenn morgen ein Produktivsystem drei Stunden ausfällt — wie läuft die Aufarbeitung bei euch ab? Wer sitzt im Raum, welche Frage wird zuerst gestellt, und was ist das schriftliche Ergebnis?
Die Antwort auf diese eine Frage sagt mehr über den Reifegrad einer Organisation aus als jede Werkzeugliste.
Weiter mit Kapitel 03 — Versionskontrolle und Branching