Microservices nur bei ausreichender "Komplexität"

Leider werden die Begriffe "komplex" und "kompliziert" oft vermischt oder verwechselt: Oft ist kompliziert gemeint, wenn in technologischen Zusammenhängen von komplex die Rede ist.

• Kenntnislücken in komplizierten Systemen lassen sich oft durch präzisere Vorbereitung und mehr Expertise schließen. In komplizierten Situationen sind oft klassische, lineare Vorgehensweisen sowie monolithisch organisierte Systeme von Vorteil und angemessen.
• Dagegen lassen sich komplexe Systeme nicht kontrollieren, nur analysieren und nur teilweise steuern. Analog zur agilen Vorgehensmethodik eignen sich Microservices mit ihrer Reaktionsfähigkeit für ein komplexes, fachlich-innovatives Umfeld mit häufigen Änderungen – also mit viel Dynamik.

Komplexität steht daher für unplanbare Dynamik (eines IT-Projektes), die aus der Vernetzung von interagierenden Elementen (Stakeholder, Projektmitarbeiter) entsteht.

Es gibt verschiedene Klassifikationen des Begriffs "komplex" – insbesondere in der Abgrenzung zu "kompliziert". Wir stellen zwei mögliche Begriffsklärungen vor, die aus dem Umfeld agiler Vorgehensweisen stammen. Die sogenannte Stacey-Matrix [2] dient als Orientierung zum Einsatz von Vorgehensweisen und kann als Entscheidungsgrundlage herangezogen werden, ob und wie agile Vorgehensweisen einzusetzen sind. Sie teilt Problemstellungen in vier Bereiche ein (vgl. auch Abb. 2):

• Bereich "Einfach": Das Ziel, die Anforderungen und auch der einzuschlagende Weg sind klar – in der Regel werden hiermit erprobte Routine-Aufgaben adressiert.
• Bereich "Kompliziert": Das Was und/oder das Wie sind teilweise unklar. Man kann sich diesem Problem durch das Vorgehen "Anschauen, analysieren, reagieren" nähern.
• Bereich "Komplex": Ziele, Anforderungen und auch der Weg sind sehr unklar. Dabei hilft iteratives Vorgehen: "Probieren, anschauen, reagieren, erneut probieren, anschauen, reagieren …".
• Bereich "Chaotisch": In diesen Situationen ist alles nebulös, so dass die einzige Option ein aktives "Auf-Sicht-Fahren" ist.

Die Stacey-Matrix verdeutlicht, dass wir bei unklaren Situationen und Problemstellungen einer flexiblen Organisation den Vorzug gegenüber einer gut durchgeplanten Vorgehensweise geben sollten. Abb. 2 zeigt eine Version der Matrix, die für Agilität optimiert ist [3]. Dabei wurden die beiden ursprünglichen Achsenbeschriftungen auf die Verwendung in IT-Projekten angepasst und durch "Requirements" und "Technology" ersetzt. Auf den ersten Blick überzeugt diese Darstellung. Sie gibt Orientierung und ein IT'ler findet darin sich und sein Tätigkeitsfeld im Berufs- und Projektalltag wieder.

Bei genauerer Betrachtung erscheint uns diese Matrixversion jedoch aufgrund der neuen Achsenbeschriftungen problematisch oder doch zumindest missverständlich. Sie suggeriert, dass man Komplexität in den Griff bekommt, indem man sich bezüglich Anforderungen einigt (Achsenbeschriftung Agreement -> Requirements) und indem man Sicherheit bezüglich Technologien schafft (Certainty -> Technology). Doch das trifft nicht den Punkt, denn die genannten Unklarheiten sind eher Indizien für komplexe Situationen. Als Folge besteht die Gefahr, ausgesuchte Indizien mit den treffenderen Ursachen zu verwechseln und so das Wesen von Komplexität falsch zu verstehen: In komplizierten Situationen kann man entlang eines Top-Down-Entwurfs den geeigneten Zeitpunkt abwarten, um ein Thema auszuarbeiten und weiter zu detaillieren. Komplexe Situationen werden demgegenüber unerwartete Entwicklungen hervorbringen oder sogar disruptiv sein. Es reicht in komplexen Situationen in der Regel schlicht nicht aus, einfach nur mehr Zeit oder Aufwand in die Klärung zu stecken.

Zwei Punkte verursachen das Problem mit dieser Matrixversion aus Abb. 3:

• Unterdrückte Dynamik: Die ursprüngliche Stacey-Matrix nennt "Agreement" und "Certainty", die ein Betrachter intuitiv auf aktive Systemelemente bezieht – wie auf Personen als Verursacher der Dynamik. Die Änderung der beiden Achsenbeschriftungen in "Technology" und "Requirements" nimmt automatisch die Dynamik aus der Matrix heraus.
• Sind agile Projekte denn immer (zu) komplex? Die ursprüngliche Stacey-Matrix adressiert eigentlich das Thema "Strategisches Management in Organisationen". Komplexität begreift sie als unplanbare Dynamik, analog zu naturwissenschaftlichen Prozessen mit inhärenter Unsicherheit und Unvorhersagbarkeit von Veränderungen. Unter diesem Blickwinkel stellt sich uns die Frage, wie komplex IT-Vorhaben mit einer Teamgröße von beispielsweise 20 Projektmitarbeitern denn eigentlich sein können. Hinzu kommt, dass die IT-Projekte i. d. R. zeitlich begrenzt sind. Wir reden hier also nicht von langen Produktentwicklungen oder langwierigen Unternehmensveränderungen. "Normale" IT-Projekte verlassen (hoffentlich) mit voranschreitender Projektdauer den Komplexitätsbereich und enden im einfachen Bereich.

Merkmale komplexer Systeme

Das soziologische Lohhausen-Experiment aus den 70ern [4] verdeutlicht gut die Anforderungen, die komplexe Situationen an uns stellen. In diesem Experiment mussten Probanden als Bürgermeister für 10 Jahre die Geschicke einer fiktiven Stadt bestimmen und mit etwa 2000 hochgradig vernetzten Variablen umgehen. Erfolgreiche Bürgermeister trugen zum Florieren ihrer Stadt bei und zeichneten sich insbesondere durch Vielfalt (mehr Entscheidungen, mehrere Absichten) und Lernfähigkeit (Selbstreflexion, Nachfragen, Hypothesenbildung und -überprüfung) aus. Diese Erkenntnisse mit diesem fiktiven komplexen System lassen sich auf komplexe IT-Projekte übertragen.

Gegenüber der oben dargestellten Stacey-Matrix verwendet das Cynefin-Modell [5] gar keine Skalen, s. Abb. 3. Das Cynefin-Modell benennt vier Kontextklassifizierungen mit Übergängen aufgrund von Situationsveränderungen: Beispielsweise führt wachsende Expertise von Complicated nach Obvious. Die vier Kontexte repräsentieren Eigenschaften des Lösungsraums (z. B. genau eine beste Lösung in Obvious). Dieses Modell überzeugt auch deshalb, da dadurch bereits Dynamik als Einschätzungskriterium mitkommt. Gleichzeitig besitzt jeder der vier Kontexte ein angemessenes Handlungsmuster, z. B. "probe-analyse-respond" in Complex (in der Abb. in blau).

Die wesentlichen Merkmale komplexer Systeme sind demnach:

• Es entsteht Dynamik durch Wechselwirkungen einer großen Zahl der interagierenden Elemente über deren Vernetzung. Die Dynamik wächst, wenn die Zahl der Elemente bzw. ihr Vernetzungsgrad wachsen.
• Kausale Ursache-Wirkung-Beziehungen greifen nicht, die Wechselwirkungsketten sind also nicht-linear. Voraussagen über die Systementwicklung sind kaum bis gar nicht möglich, Ursachen und Gesetzmäßigkeiten finden sich oft erst in Rückschau-Analysen.
• Intransparenz verhindert Voraussagen, sie macht also Elemente mit ihren Wechselwirkungen unkalkulierbar.

Solche komplexen Systeme können wir kaum oder gar nicht planen und kontrollieren. Uns bleibt nur, ihnen mit einem Regelsystem aus ständigem Ausprobieren, Erkennen und Reagieren (probe-sense-respond) zu begegnen.