REA.03: Das Spiel mit der Komplexität

Das Effizienzstreben als Stolperstein

Im Blog zwei dieser Serie haben wir festgestellt, dass die Komplexität eines Systems eine immanente Eigenschaft des Systems ist und ein System zur Regelung und Steuerung eines komplexen Systems die gleiche Komplexität aufweisen muss, wie das System selbst. Wenn das Business Modell eines Unternehmens als das zu betreibende System angesehen wird, so ist damit klar, dass dieses Business Modell auch die Komplexität der Software bestimmt, welche das Business Modell betreibt.

Dieser Aussage stimmt ein Management oft noch zu «Unser Geschäft ist eben komplex…». Nun ist das Management bestrebt das Business Modell zu kostengünstig wie möglich zu betreiben. Hier kommt dann typisch der Ruf nach Effizienz und Standardisierung auf. Das Thema Standardisierung haben wir im Blog zwei diskutiert als ein möglicher Weg, um gewisse – aber eben nur gewisse – Aspekte im Unternehmen zu adressieren.

Verbleibt das Thema des Effizienzstrebens. Effizienz ist ein zweischneidiges Schwert oder – besser ausgedrückt – falsch eingesetzt ein schleichend wirkendes Gift. Die berechtigte Frage des Managements wird sein: Warum sollen wir auf Effizienz verzichten?

Meine persönliche Argumentation ist

Wir verzichten nicht grundsätzlich auf Effizienz, wir gewichten Resilienz gegenüber Veränderung höher als maximale Effizienz.
Jedes Vorgehen im Unternehmen wollen wir so effizient wie möglich gestalten – unter der Rahmenbedingung auch langfristig die Fähigkeit zur schnellen Adaption des Business Modell zu ermöglichen.
Mit dem Verzicht auf maximale Effizienz zu Gunsten der Resilienz senken wir mittel- und langfristig ökonomische Risiken deutlich.
Mit dem Verzicht auf maximale Effizienz zu Gunsten der Resilienz steigern wir mittel- und langfristig die Innovationsgeschwindigkeit des Unternehmens erheblich

Leider wird im Management dem kurzfristigen Senken von Kosten über das Einfordern der maximalen Effizienz die Fähigkeit der Resilienz nur zu häufig geopfert.

Ökonomische Risiken des Effizienzstrebens

Widmen wir uns dem Aspekt ökonomisches Risiko. Die meisten Unternehmen befinden sich in einer Situation ein «Altsystem» oder eine «Technologie» abzulösen. Diese Ablösung benötigt einen erheblichen Teil des Investitionskapitals des Unternehmens und geht zumeist über mehrere Jahre. Das ist aus zwei Gründen ökonomisch tragisch. Zum einen sind zwei Systeme, das Alte und das Neue, parallel zu pflegen, zum anderen steht für neue Produkte oder Services ein erheblich vermindertes Investitionskapital zu Verfügung. Auch wenn die «neue» Plattform neue Features ermöglicht, so sind die Mittel für Investition in neue Features beschränkt, da Betrieb und Wartung der «alten» Plattform erhebliche Mittel bindet. Zudem besitzt die «neue» Plattform über eine Anfangszeit der Implementierung noch nicht den notwendigen Set an Features, um die vorhergehende Plattform abschalten zu können.

Um hier die Analogie eines Appenzeller Hauses zu bemühen. Diese Verfahren bedeutet neben dem alten Haus ein neues Haus zu bauen, während beide Häuser gleichzeitig bewohnt werden. In einem Haus ist die Küche, das Badezimmer ist im zweiten Haus. Wasserleitungen und Strom sind hingegen in beiden Häusern zu installieren und zu bezahlen. Hausbesitzer mit beschränkten wirtschaftlichen Mitteln würde nie so handeln. Nur Millionäre leisten sich dieses Vorgehen – vielleicht ist das auch schon eine Analogie in die Unternehmenswelt. Die «Millionäre» unserer Unternehmen können sich solch unvernünftiges Handeln erlauben.

Wir müssen zum Appenzeller Ansatz zurück – jedes Element unserer Systemlandschaft für sich muss schnell, einfach und ökonomisch tragbar auswechselbar sein.

Ein Unternehmen sollte sich NIE in der Situation befinden parallel ein Altsystem und eine Neuentwicklung betreiben zu müssen, die erheblich Arbeitskraft und Geld zur Pflege und Weiterentwicklung binden.

Ein alternativer Ansatz: Komplexität verteilen

Wie aus der Systemtheorie hervorgeht (siehe Blog zwei der Serie), kann die Komplexität eines Systems nicht vermindert werden, ohne den Kontext des Systems zu verändern. Das Business Modell eines Unternehmens definiert die Komplexität des Systems, welches das Business Modell treibt. Dies kann nur vermindert werden, wenn ein einfacheres Business Modell gewählt wird – was übrigens der Ansatz asiatischer Autobauer, oder auch von Tesla, im Gegensatz zu europäischen Autobauern ist. Wenn ein Unternehmen wirklich Effizienz gewinnen will, dann sollte es überlegen ein einfacheres Business Modell zu wählen. Europäische Autobauer könnten den Wahnsinn des Konfigurators abstellen und – wie zum Beispiel Tesla oder asiatische Autobauer – einen festen Set an Varianten zur Verfügung stellen. Hier ist die Balance zwischen EInfachheit des Business Modells und der Personalisierung des Angebotes abzuwägen. Das wäre ein Thema eine eigenen Blog.

Was wir jedoch können, ist die Komplexität so im System zu verteilen, dass wir sie besser beherrschen können. Hier greift ein weiteres wichtiges Prinzip. Die Komplexität geeignet verteilen.

Bild 1: Die Komplexität eines modularen Systems bestimmt sich aus der Komplexität der einzelnen Knoten und der Komplexität des Netzwerkes an Verbindungen zwischen den Knoten

Wenn wir die Anwendungslandschaft betrachten, die ein beliebiges Business Modell treibt, so besteht diese aus Komponenten und den Schnittstellen zwischen den Komponenten. Die Komplexität verteilt sich somit auf die Komponenten zum einen, zum anderen auf das Netzwerk der Schnittstellen zwischen den Komponenten.

Aber wie verteilen wir Komplexität effektiv?

Wenn wir alle Funktionen in einer einzigen, massiven Komponente bündeln würden, so führt das zu einem monolithischen System, das schwer zu verstehen, schwierig zu warten, riskant zu ändern ist und nicht skaliert.

Brechen wir den Monolithen in eine zu grosse Vielzahl an winzig kleinen Komponenten auf, die jeweils für eine bestimmte Funktion verantwortlich sind, so riskieren wir, eine unüberschaubare Anzahl von Schnittstellen zu schaffen mit ungewollten Kopplungen zwischen den Einzelteilen.

Die Herausforderung besteht darin, den „Sweet Spot“ zu finden, die Balance zwischen Grösse und Anzahl an Komponenten und der Komplexität des Schnittstellen Netzwerkes. Dem widme ich mich im nächsten Blog.

Blog 1: Ein Essay über resiliente Enterprise Architecture
Blog 2: Architektonische Irrungen

P.S.: Alle Bilder sind frei lizenzierbaren Quellen entnommen, eventuell mit der entsprechenden Attribution – oder meine eigenen. Daher können alle Bilder aus dieser Blogserie entsprechend Attribution weiter verwendet werden.