Unverzichtbare Komplexität

Nach dem Sturm der ersten Monate Geschäftstätigkeit der Silberrücken AG, kann ich diese Woche für Einkehr und Reflexion nutzen. Ein Thema, dass meine Überlegungen in letzter Zeit immer wieder bestimmt hat, ist dass der Komplexität in der Systementwicklung. Grund genug, darüber mal einen Blog zu schreiben.

Die Konnotation der Komplexität hat sich in der Informatik weg vom Ressourcenverbrauch eines Algorithmus, hin zu Überlegungen rund um das betriebene Geschäft entwickelt. Algorithmische Komplexität kommt bei der Analyse von Daten oder der Bildverarbeitung immer noch zum Zuge, aber in der Architektur von Geschäftssystemen meinen wir heute stattdessen die Vielzahl und Vielschichtigkeit der Interaktionen zwischen Akteuren in einem System. Weil mich das Thema nunmal sehr interessiert, und ich im Rahmen meines aktuellen Buchprojekts auch gerne darüber schreiben wollte, habe ich die Klammer aufgetan, um ein breiteres Meinungsbild zu entwickeln.

Sehr überrascht war ich, dass die treffendste Aussage zum Thema aus dem Jahre 1975 stammt, und zwar von Frederick Brooks. Brooks hat damals sein Werk „Vom Mythos des Mann-Monats“ veröffentlicht, in dem es vor allem um die menschlichen Faktoren der Softwareentwicklung geht. Brooks erkannte, dass ein System eine inhärente Komplexität hat, die sich nicht reduzieren lässt. Ich nenne diese die unverzichtbare Komplexität, welche das Geschäft repräsentiert, dass ein System unterstützen soll.

Diese Komplexität lässt sich nicht reduzieren, ohne das darunter liegende Geschäft ebenfalls zu reduzieren. Nun ist eine Organisation aber auf dieses Geschäft angewiesen, um operieren zu können. Die einfache Formel lautet, dass bei Reduktion ein Unternehmen Marktvorteile verliert, weil beispielsweise nicht mehr auf die Bedürfnisse von Kunden eingegangen werden kann.

Erst letztens habe ich in einem B2B Shop eine Workflowimplementierung mit konfigurierbarer Autorisierung für Bestellungen von Mitarbeitern gesehen. In der Entwicklung aufwändig und kostenintensiv, bietet die Funktion dem Unternehmen dennoch einen Marktvorteil, weil es ein Bedürfnis der B2B Kunden ist, und nicht alle Konkurrenten dieses leisten können.

Vereinfachungen sind riskant

Komplexität ist anstrengend. Wir können nur mit einem bestimmtes Mass an Komplexität umgehen, bevor wir den Faden verlieren und das vorliegende Problem nicht mehr vollumfassend begreifen können. Häufig müssen komplexe Problemstellungen auch unter Zeitdruck verstanden und gelöst werden, beispielsweise im Rahmen einer Management Sitzung. In diesem Fall arbeiten wir dann mit Vereinfachungen, die es uns erlauben eine Entscheidung zu treffen. Das ist aber gefährlich, denn es besteht das Risiko, dass bei der Simplifizierung wesentliche Aspekte des Problems ignoriert werden. Eine einfache und funktionierende Lösung für komplexe Problemstellungen zu finden, ist sehr schwierig.

 

Komplexität fassbar machen

Die Gretchenfrage lautet also, ob es Methoden und Techniken gibt, die es erlauben die unverzichtbare Komplexität zu beherrschen, um bessere Entscheidungen treffen zu können? Die Antwortet lautet ja, die gibt es. Diese Methoden und Techniken wurden aber nicht unbedingt im Hinblick auf diese Fragestellung entwickelt. Nehmen wir als Beispiel das Anforderungsmanagement: Wenn man ein Verständnis von einem System entwickeln möchte, dann ist der Anforderungskatalog ein wichtiges Werkzeug um die Prozesse, Daten und Regeln zu verstehen, die es treiben.

Eine andere Technik kommt aus dem domänengetriebenen Entwurf. Hier etabliert man im System eine gemeinsame Sprache, die vom Team verstanden wird. Die Idee dabei ist, dass man seine natürlichen, linguistischen Fähigkeiten nutzen kann, um Probleme zu lösen. Das funktioniert aber nur, wenn alle dieselbe Sprache sprechen und Nomen und Verben im Kontext vom Team identisch interpretiert werden. Erst wenn das der Fall ist, kann ein Problem zufriedenstellend gelöst werden. Interessanterweise bietet der domänengetriebene Entwurf auch Techniken zur Dekomposition des Geschäfts in Subdomänen, eine weitere Technik zur Beherrschung von Komplexität.

Jetzt gerade erschienen ist eine Übersetzung eines amerikanischen Titels zu diesem Thema. „Domain-Driven Design kompakt“ von Frau Dr. Lilienthal und Herrn Schwentner erscheint diesen Monat im dpunkt Verlag. Da ich selber auch über das Thema schreibe, aber nicht in jedem Fall ein Freund von Anglizismen bin, hatte ich mich unlängst mit den beiden zu möglichen Übersetzungen ausgetauscht.  Das Buch ist sehr gut und ich kann es den Software Architekten empfehlen, und das englische Original ebenfalls.

Conway, immer Conway

Ein wesentlicher Teil der Komplexität entstammt den Interaktionen zwischen den Akteuren im System. Eine genaue Kenntnis der involvierten Stakeholder und ihre Organisationen und Beziehungen untereinander, sind ein Erfolgskriterium für den Entwurf. Melvin Conway hat dies bereits 1968 erkannt, als er herausfand, dass eine Organisation stets ein System entwickelt, dass ihren Kommunikationsstrukturen entspricht. Das Organigramm einer Organisation ist dem Architekten also ein wichtiges Werkzeug, um das Geschäft verstehen zu können. Im Umkehrschluss bedeutet dies, dass zum Entwurf auch der Umbau einer Organisation gehören darf, wenn dies die bessere Lösung darstellt.

Fazit

Wer ein Geschäftssystem einführen oder verändern möchte, ist gut beraten einen ganzheitlichen Ansatz zu wählen. Neben den funktionalen Aspekten, der Organisationsform sowie den Geschäftsstrukturen, gibt es eine Reihe weiterer Aspekte, die so aufbereitet werden sollten, dass die unverzichtbare Komplexität nicht reduziert wird, aber auch keine überflüssigen Informationen präsentiert werden. Durch dieses Vorgehen lässt sich die Komplexität beherrschen und gute, nachhaltige Entscheidungen werden möglich.

 

Kommentar verfassen