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.
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.
Das Modell stammt von Gene Kim und ist in The Phoenix Project sowie im DevOps Handbook ausgeführt. Es beschreibt drei aufeinander aufbauende Prinzipien.
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:
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.
Information fließt von rechts nach links — und zwar möglichst schnell und in möglichst vielen Schleifen.
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.
Eine Kultur, in der Experimente erwünscht sind und Fehler als Erkenntnisquelle gelten.
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.
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.
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.
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.
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.
| 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 |
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