Das Cynefin-Framework und Microservices

Wir brauchen doch gar keine Microservices, oder…?

Im letzten Beitrag dieser Reihe zu Komplexität und Microservices konnten wir festhalten, dass der Microservice-Vorteil durch die niedrige Kopplung erreicht wird. Doch warum?

Hier hilft das Cynefin-Framework von Dave Snowden in Abbildung 7 weiter, das aus Wissensmanagement und aus agiler Software-Entwicklung bekannt ist. Dieses Framework charakterisiert Situationen durch fünf Teilbereiche, von denen uns diese drei speziell interessieren:

• In einfachen Situationen (Obvious) helfen die Best Practices; es gibt genau eine Lösung.
• In komplizierten Situationen gibt es mehrere mögliche Lösungen; und die Aufgabe besteht darin, eine passende Lösung zu finden. Dabei helfen die Good Practices. Mit genügend Zeit, Aufwand und Expertise lassen sich komplizierte Probleme lösen.
• Ganz anders ist das in komplexen Situationen. Im Gegensatz zu komplizierten Situationen gibt es nicht a priori eine beste Lösung. Im Nachhinein findet sich evtl. eine ganz einfache Lösung. Es wäre ein Fehler, diese Lösung dann zukünftig einfach auf ähnliche Fragestellungen anzuwenden. Denn in komplexen Situationen muss man sich erst an eine passende Lösung herantasten. Und dabei helfen die Emergent Practices. Das sind Praktiken, die wir kontextbezogen selbst entwickeln müssen.

Der Produktivitätsverlauf von Martin Fowler und das Cynefin-Framework von Dave Snowden drücken beide auf ihre Weise aus, dass Komplexität ein Problem darstellt, für das wir eine eigene Lösungsstrategie benötigen. Einfach ausgedrückt: Menschen machen Projekte. Und je mehr Menschen beteiligt sind, desto komplexer wird ein Vorhaben, und desto eher brauchen wir ein passendes Vorgehen und eine passende Architektur, weil die Produktivität sinkt.

In komplexen Situationen brauchen wir also komplexe Antworten, denn wegen der Dynamik gibt es nicht DIE Lösung. Stattdessen geht es um eine Vielzahl kleiner Lösungsschritte. Und so besteht das passende Vorgehen aus vielen Iterationen, in denen wir unsere Ideen als Experimente durchführen. Hier hilft der Demingkreis aus Abbildung 8: Wir überlegen uns zunächst zu einer konkreten Aufgabe eine Lösung. Die setzen wir als Nächstes im kleinen Maßstab um und prüfen anschließend, wie erfolgreich die Maßnahme war. Wenn wir zufrieden sind, dann übernehmen wir das Ergebnis in größerem Maßstab. Anderenfalls lassen wir sie fallen und denken uns in der nächsten Iteration etwas Neues aus.

Übertragen auf eine Microservice-Architektur kann man so beispielsweise die Akzeptanz für neue Features erst im Kleinen (z. B. für wenige Nutzer) testen und die Lösung im Erfolgsfall übernehmen. Dabei sollte die fachliche Neuerung oder der neue Microservice möglichst unabhängig vom restlichen System sein, denn das bedeutet wenig Abstimmungen und kurze Releasezyklen. Dabei geht es NICHT primär um Kostenreduktion. Der Demingkreis macht mit seinem „inspect and adapt“ aus der Microservice-Architektur ein adaptives System. Und darin liegt der wesentliche Unterschied zu einem komplizierten System: wir wollen nicht optimieren, wir wollen uns anpassen.

Professor Kruse zeigt in seinem Kurzbeitrag über den menschlichen Umgang mit Komplexität, wieso nur Erfahrungswissen jenseits des rationalen Verstehens eine erfolgversprechende Strategie ist.

Hier kommt Conway ins Spiel: Der Demingkreis hilft, in komplexen Situationen angemessen zu reagieren. Aber es bleibt offen, wie man das umsetzen kann. Melvin Conway hat schon in den 60er Jahren beobachtet, wie sich Spezialistenteams auswirken. Er hat die Organisationsstruktur in der Architektur wiedergefunden (s. Abbildung 9): Die Spezialistenteams haben zu einer großen Schichtenarchitektur geführt, dem Monolithen mit seinen Abstimmungen und dem Planungsvorlauf, kurz: mit den zu langen Zyklen.  

Agile Unternehmen machen sich Conways Beobachtung wie in Abbildung 10 dadurch zunutze, dass sie sie einfach umdrehen („Inverse Conway Maneuver“). Sie arbeiten mit kleinen, cross-funktionalen Teams, und jedes dieser autonomen Teams ist für fachlich eigenständige Aufgaben verantwortlich. Dazu erhält jedes Team alle notwendigen Kompetenzen und insbesondere auch Entscheidungsbefugnisse. So zerlegen wir den Monolithen organisatorisch, fachlich und technisch in einzelne Microservices.

Die Teams sind selbständig und können stark entkoppelt arbeiten, weil wir ihren Vernetzungsgrad minimieren: sie arbeiten autonom.

Zusammengefasst sind die beiden Erfolgsfaktoren:

• Die Verantwortungsbereiche müssen fachlich ausreichend eigenständig sein, sonst sind die Teams faktisch doch wieder eng aneinander gebunden.
• Jedes Team muss organisatorisch so aufgestellt sein, dass es seine Aufgaben wirklich eigenständig erledigen kann.

Zwei Beispiele aus einem Vortrag über die Microservice-Architektur der REWE Digital beschreiben sehr gut die beiden Erfolgsfaktoren:

1. „Buttons müssen peu-à-peu grün werden dürfen. Es darf niemals heißen: Wir müssen alles gemeinsam deployen, damit alle Buttons gleichzeitig grün werden.“
2. „Seht zu, dass ihr jederzeit unabhängig voneinander deployen könnt. Auch ohne Absprachen. Es darf niemals heißen: Wir können nicht deployen, weil die anderen doch erst noch das und das tun müssen.“

Mit einem Wort: das Management setzt den Rahmen. Die Teams sind innerhalb dieses Rahmens für die Lösungen verantwortlich. Dadurch erhalten Mitarbeiter viel mehr Kompetenzen als in klassischen, arbeitsteiligen Strukturen und es entsteht eine neue Verantwortungsaufteilung: das Management regelt, anstatt zu steuern, die Teams arbeiten autonom. Eine solche Veränderung ist erfahrungsgemäß langwierig und aufwendig, da damit v. a. ein kultureller Wandel eingehen muss.

Abbildung 11 bringt zum Ausdruck, dass Projekte in diesen Umgebungen keine Lösung sind. Denn dann sind Inhalt, Termin und Budget schon fixiert und der mit Microservices adressierte Problempart ist schon erledigt. Mit und in Projekten behandeln wir Aufgaben wie in komplizierten Situationen, selbst wenn wir uns in einer komplexen Situation befinden. Das Wichtige für uns ist aber: Wie wollen wir aus dieser Perspektive heraus die richtige Architekturentscheidung treffen? Wir müssen also eine längerfristige Produktperspektive einnehmen, wenn wir feststellen wollen, ob Microservices die richtige Wahl sind. Dann haben Teams auch die Chance, aus den schwierigen Phasen zu lernen und zu echten Teams zusammenzuwachsen. Die Teams brauchen Zeit, damit Vertrauen entstehen kann: das Vertrauen des Managements gegenüber den Teams und das Vertrauen im Team und zwischen Teams.

Die abschließende Abbildung 12 bringt die beiden Aspekte Komplexität und Autonomie zusammen. Mit dem Diagramm kann man sich bzw. sein IT-Vorhaben verorten. Es zeigt, dass man mit Monolithen genauso wie mit Microservices gute Architekturen baut. Es zeigt auch den Kontext, von dem es maßgeblich abhängt, welche Architektur sinnvoll ist. Eine monolithisch geprägte Architektur (links unten) unterstützt gut planbare Vorhaben. Eine Microservice-Architektur (rechts oben) ermöglicht flexible Reaktionen. Der Komplexität innovativer oder wachstumsstarker Produkte müssen wir mit einem Architekturstil begegnen, dessen Hauptziel Flexibilität ist. Microservice-Architekturen haben genau dieses Potential.

Die roten Zonen im Diagramm zeigen die ungünstigen Konstellationen, die es zu vermeiden gilt: In einem überschaubaren Geschäftsfeld verursachen lose kooperierende autonome Teams unnötig hohe Kosten (links oben). In einem komplexen Geschäftsfeld dauert eine durchgeplante Lösungsfindung zu lange – falls überhaupt tragfähige Lösungen entstehen (rechts unten). Eine Warnung: Das Diagramm suggeriert, es wäre ein fließender Übergang zwischen einer monolithischen und einer Microservice-Architektur möglich. Im technischen Sinn kann man sich das vorstellen, denn man kann die benötigten Praktiken und den Betrieb einer passenden Infrastruktur üben, indem man einzelne Teile aus dem Monolith herauslöst (als inkrementelle Migration). Es ist allerdings mehr als fraglich, ob ein Technologie-fokussiertes Vorgehen die erhofften Resultate liefert.

Zusammenfassend lässt sich feststellen: Microservices bringen umfassende Veränderungen, die weit über Technologie hinausgehen. Sie bestehen darin, „zu regeln, statt zu steuern“, „zu vertrauen statt zu kontrollieren“. Sie fördern Autonomie und Kooperation statt Arbeitsteilung und Konkurrenz. Lieber schnelle Reaktion als Optimierung.

Hier geht es zum ersten Teil des Blogbeitrags