Über unsMediaKontaktImpressum
Martin Lehmann & Dr. Renato Vinga-Martins 11. September 2018

Microservices nur bei ausreichender "Komplexität"

Martin Fowler setzt Produktivität und Komplexität in Zusammenhang (s. Abb. 1) und formuliert als Ratschlag: "Don't even consider microservices unless you have a system that's too complex to manage as a monolith." Fowler empfiehlt also, Microservices nur bei "ausreichender Komplexität" einzusetzen. Doch was bedeutet hier eigentlich Komplexität?

Komplex und kompliziert: zwei vollkommen unterschiedliche Dinge

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.

Alternativen finden – Schadensbegrenzung statt Schadensvermeidung

In einem komplexen System ist jede erfolgreiche Praktik weitgehend systemspezifisch und nicht verlässlich auf andere Systeme übertragbar. Das Zusammenspiel der einzelnen Systemteile sorgt für die Komplexität (Stichwort: Emergenz).

Das Cynefin-Modell weist folglich auch keine wirklichen Best Practices aus. Nur "Ausprobieren" (probe) wird empfohlen: Und zwar Ausprobieren im Sinne von echten, neuen Alternativen, nicht im Sinne nur kleinerer Abweichungen eines altbekannten Ansatzes. Der Schlüssel liegt also im Loslassen von Kontrolle – so wie ein komplexes System unkontrollierbar ist, so ist auch eine gute Lösungsfindung nicht kontrollierbar und nicht vorhersehbar. Die Denkweise soll statt Schadensvermeidung (Fail-Safe) besser Schadensbegrenzung (Safe-Fail) im Blick haben [6]. Wenn wir das beste Produkt, die beste Lösung, die beste Antwort nicht kennen, ja gar nicht kennen können, dann bleibt nur, Vielfalt zu unterstützen und erfolglose Ansätze bewusst mit einzuplanen, um insgesamt flexibel zu bleiben. Ein erfolgloser Ansatz ist dabei nicht notwendigerweise falsch, da emergente Praktiken a priori nur situationsbedingt erfolgreich oder erfolglos sind. Konkrete Erfahrungen sind also kaum übertragbar, da sie nur unter sehr spezifischen Bedingungen gelten.

Was hat das mit unserem IT-Geschäft zu tun?

In den obigen Ausführungen haben wir etwas unscharf von "System", ihren "Elementen" und deren "Vernetzung" gesprochen. Die angegebenen Quellen und Beispiele zielten v. a. auf die Psychologie in Entscheidungssituationen ab. Auf das IT-Geschäft übertragen ist das IT-Projekt das "System", die Projektakteure wie z. B. Stakeholder und Mitarbeiter sind die "Elemente" und deren Zusammenarbeit stellt die "Vernetzung" dar. In diesem Sinne kann Psychologie auch Architektur-relevant sein!

Wenig oder keine Auswirkungen werden bei Umsetzung des einzelnen kleineren IT-Projektauftrags zu sehen sein: Ein solches kleines IT-Projekt ist i. d. R. zeitlich eingegrenzt, viele Entscheidungen sind bereits gefallen, viele Einflussgrößen sind festgelegt. Doch je langfristiger die Planung von IT-Systemen und IT-Anwendungslandschaften zu leisten ist, desto mehr spielt die damit einhergehende inhärente Komplexität eine Rolle – z. B. wenn zu entscheiden ist, wie flexibel die Architektur sein muss oder werden soll. Denn IT-Systeme müssen an die geschäftlichen Rahmenbedingungen angepasst sein. Dabei ist es ein Unterschied, ob 200 oder nur 20 "Ansprechpartner" mitreden und ob 50 oder nur 5 Personen zusammenarbeiten. Auch die Art, wie Softwareentwicklungsteams sich selbst weiterentwickeln wollen, spielt eine wichtige Rolle – wie sie beispielsweise mit dem fortwährenden Betreten von fachlichem oder technischem Neuland ihr Wissen und Können erweitern müssen.

Wer in solchen komplexen IT-Situationen ingenieursmäßige Lösungen nach dem Muster für komplizierte Bedingungen baut, der wird scheitern: Die vielen, dynamischen, unerwarteten Änderungen der komplexen Projektsituation werden ihn "überrollen". Sehr anschaulich und empfehlenswert ist der kurze YouTube-Beitrag von Professor Peter Kruse zur Komplexität [7]. Er verdeutlicht, dass wir zur Komplexitätsbewältigung von Kontrolle ablassen und auf "Erfahrungswissen" zurückgreifen müssen.

Zusammenfassung

So wie einfache, komplizierte und komplexe Situationen sich grundlegend voneinander unterscheiden, so gilt das auch für die zu ihnen passenden Vorgehensweisen. So fokussiert sich beispielsweise Scrum auf die nahe Zukunft mit kurzen Auslieferungszyklen – in der Regel aber zu Lasten einer längerfristigen Planbarkeit und Optimierung. Automatisierung auf allen Ebenen wird damit nötig – der Preis für die gewonnene Flexibilität. Deshalb stellen wir uns vor dem Einsatz agiler Ansätze in der Regel die Frage, in welchem Problembereich wir uns befinden und wählen agile oder andere Vorgehensmethoden gezielt und passend aus.

Und genau das müssen wir auch bei der Entscheidung "Monolith vs. Microservices" tun: Wieviel Flexibilität wird benötigt, wieviel Dynamik wird erwartet? Ist das Problem kompliziert oder komplex? Deshalb sind Aspekte aus der Agilität wie z. B. kurze Releasezyklen, kleine Teamgröße und Produktverantwortung auf ein Umfeld mit Microservice-Einsatz übertragbar. Microservices adressieren also mit ihrer Reaktionsfähigkeit ein durch hohe Dynamik geprägtes, innovatives Umfeld mit häufigen Änderungen.

Lesen Sie jetzt Teil 2 der Artikelserie:

Wie groß darf ein Microservice sein? Und ist das überhaupt wichtig?

Komplexe Situationen erfordern flexible Reaktionen. Die geringe Größe eines Microservice ist letztlich sekundär. Wichtiger sind vielmehr Übersichtlichkeit von Microservices und ihrer Abhängigkeiten.
>> Weiterlesen
Quellen
  1. Martin Fowler; 2015: MicroservicePremium 
  2. Ralph D. Stacey; 2007 (1993): Strategic management and organisational dynamics - The challenge of complexity to ways of thinking about organisations;
    Brenda Zimmermann: The Stacey Matrix 
  3. Bernie Maloney; 2012: Agile Frameworks - A Brief Orientation
  4. Dietrich Dörner; 1989: Die Logik des Mißlingens. Strategisches Denken in komplexen Situationen
  5. Youtube: Dave Snowden; 2010: The Cynefin Framework
    Wikipedia: Cynefin framework
  6. Stephanie Borgert; 2016: Fehler machen – gewusst wie!
  7. Youtube: Professor Peter Kruse; 2016: Wie reagieren Menschen auf wachsende Komplexität?

Martin Lehmann auf den IT-Tagen 2018

Martin Lehmann hält zwei Vorträge auf den diesjährigen IT-Tagen – der Jahreskonferenz der Informatik Aktuell.

Alle (halbe) Jahre wieder kommt das neue Java-Release!
(11.12.2018, 09:00 Uhr)

Modularity-Patterns mit dem Java-Modulsystem Jigsaw
(12.12.2018, 11:30 Uhr)

Autor

Martin Lehmann

Seit Ende der 90er Jahre wirkt Martin Lehmann als Softwareentwickler und -architekt in der Softwareentwicklung in diversen Projekten der Individualentwicklung für Kunden verschiedener Branchen.
>> Weiterlesen

Dr. Renato Vinga-Martins

Dr. Renato Vinga-Martins arbeitet bei der Accso – Accelerated Solutions GmbH mit technologischem Schwerpunkt als Architekt, Berater und Projektleiter in allen Phasen der Individualsoftware-Entwicklung.
>> Weiterlesen
Das könnte Sie auch interessieren
botMessage_toctoc_comments_9210