Inhalte
Das Thema Komplexität ist in aller Munde. Die Welt wird immer komplexer. Die Vielfalt der Möglichkeiten, die Vernetzung und damit die Unsicherheit steigt. Dazu gibt es sogar ein Modell, welches die heutige Welt beschreiben soll: «VUCA». Dieses Akronym steht für volatility (Volatilität), uncertainty (Ungewissheit), complexity (Komplexität) und ambiguity (Ambiguität).
In diesem Zusammenhang möchte ich hier die Frage beantworten, ob sich denn Komplexität überhaupt reduzieren lässt. Zudem werde ich das Thema Komplexität im Bereich Software- und Systementwicklung etwas genauer beleuchten.
Was bedeutet der Begriff komplex – und was ist der Unterschied zu kompliziert?
Zu diesen Begriffen gibt es viele verschiedene Definitionen. Ich möchte aber auf den aus meiner Sicht wesentlichen Unterschied eingehen: Kompliziert ist, wenn eine Reaktion basierend auf einer oder mehreren Ursachen erklärbar ist (d.h. deterministisch). Das ist nicht immer offensichtlich und die Möglichkeiten der Ursache(n) ist manchmal sehr gross. Im Unterschied dazu ist etwas komplex, wenn es keine vollständige Ursache-Wirkungs-Zuordnung gibt. Das ist immer bei «lebenden» Systemen der Fall. D.h. wenn Menschen (oder auch Tiere und Pflanzen) in einem System involviert sind. Auf der anderen Seite sind technische Systeme per Definition «nur» kompliziert. Auch wenn eine grosse Maschine kaum mehr vollends verstehbar ist, sind doch die Reaktionen immer einer oder mehrere Ursachen zuzuordnen – und deshalb kompliziert.
Ich weiss umgangssprachlich wird dieser Unterschied nicht immer gemacht. Es ist allerdings wichtig diese Unterscheidung zu kennen, denn Komplexität braucht andere Methoden als Kompliziertheit – aber dazu weiter unten mehr.
Kann man Komplexität reduzieren?
Ein typisches komplexes System in unserem Umfeld ist ein Software-Entwicklungs-Projekt. Wichtig hier, das Entwicklungs-Projekt – nicht das Software-Produkt! Wie nachfolgende Visualisierung zeigt, sind darin neben den technischen Dingen, eben auch Menschen involviert.
Es gibt Interaktionen von Mensch zu Mensch (z.B. Kommunikationskanäle, Meetings, Workshops…) oder von Menschen zu technischen Artefakten (das sind dann Prozesse, Tools oder Methoden).
Damit ist auch einfach ersichtlich, dass es offensichtlich eine dem System zugeordnete Komplexität gibt. Diese ist abhängig von der Grösse des Systems, d.h. der Anzahl der Elemente wie Menschen oder technischen Artefakten. Die Komplexität zu reduzieren würde bedeuten, Elemente aus dem System zu entfernen. Das ist auch in einigen Fällen möglich und notwendig. Insofern lässt sich Komplexität dann reduzieren, wenn die Freiheit besteht, das System als solches zu verändern.
In vielen Fällen ist, kann jedoch die Grundkomplexität, auch inhärente Komplexität genannt, nicht reduziert werden.
Aber…
In vielen Fällen hat man es ja nicht nur mit der Grundkomplexität zu tun. Aus welchen Gründen auch immer, sind in solchen Systemen oft weitere Elemente enthalten, welche zusätzliche Komplexität reinbringen. Diese Elemente waren sicher ursprünglich dazu gedacht, das System zu beherrschen. Aber aufgrund der stetigen Veränderung des Umfeldes und damit des Systems sind diese vielleicht nicht mehr notwendig oder müssten geändert werden. Ein typisches Beispiel dazu sind Software-Werkzeuge (Tools). Diese Tools sind entweder nicht mehr adäquat, vielleicht nicht geeignet aufgesetzt und eingerichtet oder vielleicht sind auch die Benutzer nicht richtig geschult. Alle diese Möglichkeiten bringen zusätzliche und damit unnötige Komplexität (accidental complexity) in ein System rein. Diese unnötige Komplexität lässt sich und sollte reduziert oder noch besser eliminiert werden!
Ich spreche in dem Zusammenhang auch gerne vom Komplexitätsmonster:
Was sind Quellen unnötiger Komplexität im Software- und Systementwicklungsumfeld?
Die folgende Auflistung sind typische Quellen unnötiger Komplexität:
- Rollen, Aufgaben und Verantwortlichkeiten der Mitarbeiter sind nicht klar definiert
- Entwicklungs-Prozesse sind nicht definiert oder nicht geeignet
- Es werden falsche Methoden eingesetzt
- Einsatz nicht geeigneter Entwicklungs-Tools
- Falsch aufgesetzte Entwicklungs-Tools
- Einsatz ungeeigneter Technologien
- Einsatz ungeeigneter Lösungskonzepte (System- oder Software-Architekturen)
- Ungenügende Dokumentation von Anforderungen oder Lösungen
- …
Wichtig:
Nicht nur das Vorhandensein von ungeeigneten Prozessen, Technologien oder Tools, sondern auch das Fehlen von Definitionen, Dokumentationen oder Strukturen kann zu unnötiger Komplexität führen!
Vielleicht kennst Du diese Situation:
Du möchtest Deine eigene Software-Entwicklung hochskalieren. Dazu hast Du sicher gute Gründe. Weil es aktuell nicht so einfach ist Fachleute zu finden, hast Du einen Software-Partner gesucht, mit dem Du Dein Team verstärkt hast.
Eine nachvollziehbare Idee!
Nachdem das Ganze gestartet hat, stellst Du eine zunehmende Unruhe im Software-Team fest:
Lange Diskussionen über Lösungsansätze mehren sich
- Externe Entwickler bringen gut gemeinte Ratschläge und Vorschläge zum
- Entwicklungsprozess mit ein, was zu zusätzlichen Diskussionen und Unruhe führt
- Zunehmend beklagen sich die internen Entwickler, über den grossen Betreuungsaufwand
Das alles führt dazu, dass nach einer gewissen Zeit die Entwicklungsgeschwindigkeit merklich sinkt.
Was ist da passiert? Die Idee war doch nicht schlecht… Warum skaliert das nicht?
Ja, genau – hier hat das Komplexitätsmonster zugeschlagen. Die fehlenden oder lückenhaften Dokumentationen, Strukturen und Prozesse führen zu unnötiger Komplexität. Was mit einem eingespielten internen Team noch funktioniert hat, geht plötzlich nicht mehr.
Essenziell wäre in einem solchen Fall:
- Genügende und dokumentierte Anforderungsbeschreibungen
- Coding- und Development-Guidelines
- Architektur-Definitionen und Dokumentationen
- Guidelines & Checklisten für das Aufsetzen der Tools und Entwicklungsinfrastruktur
Wie kann systematisch ein komplexes System beherrscht werden?
Wie bereits erwähnt braucht es andere Ansätze, um ein komplexes System zu beherrschen, als dies bei rein technischen Systemen der Fall ist. Nachfolgend ein Modell, welches ich oft benutze, um die Dimensionen zur Beherrschung eines komplexen Systems aufzuzeigen:
Idealerweise werden alle diese 3 Dimensionen betrachtet und entsprechende Lücken identifiziert und geschlossen. Alle 3 Dimensionen haben auch Abhängigkeiten. Zum Beispiel kann erst nachdem ein genügendes Systemverständnis aufgebaut ist die relevanten Interaktionen betrachtet und allenfalls optimiert werden.
In dem Zusammenhang höre ich von Managern und Führungskräften oft die Aussage, dass Ihnen das Gesamtsystem schon klar ist. Soll aber ein effektives und effizientes Arbeiten in einem System ermöglicht werden, dann müssen auch alle Beteiligten ein gemeinsames Systemverständnis besitzen.
Wie weiter?
Falls Du Fragen zu dem Beitrag hast, dann schreib mir einfach – gerne helfe ich dir weiter.
Weiteres zum Thema:
- Komplexität beherrschen lernen – die visuellklar Trainings
- Software Architektur ist nicht komplex – in 5 Schritten zur geeigneten Software Architektur
- SYSTEMArt
Viel Erfolg bei Deinen komplexen-Projekten
Matthias
