Die Doppelhelix - ein gutes Beispiel für die Verteilung von Komplexität

REA.04: Komplexität verteilen – die Grösse einer Komponente

Die Komplexität eines Systems geeignet verteilen

Das Fazit des Blog drei dieser Blog Serien hat sich mit der Verteilung von Komplexität über eine Applikationslandschaft beschäftigt.

Wir haben festgestellt, dass ein einziger Monolith für die gesamte Applikationslandschaft ebenso schädlich wäre wie eine zu grosse Vielzahl an winzig kleinen Komponenten. 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.

Was ist denn nun eine geeignete Grösse für eine Komponente?

Ist das etwa ein Microservice?

Die Diskussion, wie gross ein Microservice sein darf, soll oder kann, beschäftigt die System Architektur genau so intensiv wie die Menschheit die Frage nach dem Sinn des Lebens (die Antwort lautet: 42). Hier gibt es keine feste Regel. Es gibt jedoch good-practices, die situativ anzuwenden und zu adaptieren sind.

Mark Fowler Ansatz der Bounded Context

Mark Fowler bietet zum Beispiel mit seiner Terminologie der bounded context eine good-practice an. Seine Aussage ist zusammengefasst: Eine Komponente ist ein Set an IT-Elementen, die einen fachlichen Kontext digital unterstützen. Sie kommunizieren über klar definierte, versionierte und dokumentierte Schnittstellen mit der Komponente. Die Nutzer der Komponente haben keine Ahnung, wie das Innere der Komponente aussieht, sie kennen nur die Schnittstellen und Qualitätseigenschaften wie zum Beispiel Ressourcenverbrauch, Performance oder Preis. Eine Schnittstelle kann dabei eine technische Schnittstelle sein, aber auch eine HCI-Schnittstelle, also ein UI sein. Leider sagt der Ansatz der bounded context viel über den Sinn einer Komponente, aber wenig über die Grösse aus.

Ökonomie als Massstab für die Grösse einer Komponente?

Eine weitere good-practice ist die ökonomische Betrachtung. Der Tausch einer beliebigen Komponente der Anwendungslandschaft darf für ein Unternehmen kein ökonomisches Risiko darstellen. Diese Aussage kann aus meiner Erfahrung quantifiziert werden. Ein Unternehmen sollte fähig sein eine Komponente der Anwendungslandschaft innerhalb von => maximal zwei Jahren <= komplett gegen eine neue Komponente auszutauschen mit einer Investition von maximal zehn Prozent des Investitionskapitals des Unternehmens.

Komplett ausgetauscht bedeutet: Die bisherige Komponente ist out-of-service, benötigt keine Ressourcen, bedarf keiner Maintenance, ist «gelöscht». Die neue Komponente ist produktiv, eingebettet in das Netzwerk der Schnittstellen der umgebenden Komponenten.

Einwurf
Hier kann die Frage gestellt werden: Warum ausgerechnet zwei Jahre?
Die Frage beantworte ich aus meiner Erfahrung: nach zwei Jahren verliert das Management die Geduld etwas zu finanzieren. Das Budget wird gekürzt, da mittlerweile andere Dinge die Aufmerksamkeit auf sich ziehen und bisher kein Erfolg nachzuweisen war. Die angestrebte Lösung leidet somit unter Budget Aufmerksamkeitsmangel und Budgetentzug. Die eingeforderten Einsparungen führen zu Qualitätsverlusten und Abkürzungen und damit zur nächsten Legacy.

Die ökonomische Sicht ist eine spannende Sicht auf die Grösse einer Komponente. Eine Komponente der Anwendungslandschaft kann eine Standardsoftware sein oder eine eigenentwickelte Komponente. Eine eigenentwickelte Komponente kann aus einem Geflecht an Microservices bestehen, solange sie «nach aussen» zu den weiteren Komponenten als Blackbox über klar definierte Schnittstellen kommuniziert.

Nach der ökonomischen good-practice entspricht in einem kleinen Startup eine Komponente eventuell wirklich einem Microservice. In einem grossen Unternehmen ist eine Komponente wahrscheinlich deutlich grösser, also ein Set an Microservices vielleicht dann eher mit der Terminologie «Applikation» versehen, die mit hoher Kohäsion ein bestimmtes fachliches Problem lösen, zum Beispiel einen Angebotsprozess, eine Preisberechnung oder eine Schadensabwicklung.

Die Team Regel als good practice

Eine dritte good-practice für die Grösse einer Komponente ist die Team Regel. Ideal ein, maximal zwei Entwicklungsteams mit je maximal zehn Teammitgliedern entwickeln eine Komponente. Wenn zwanzig Mitarbeitende eine Komponente entwickeln, dann erreicht die Komplexität der Komponente eine gerade noch beherrschbare Grenze. Zwanzig Mitarbeitende sind auch in der Lage eine Unmenge fachliches UND technisches Knowhow zu beherrschen. Mit dieser good-practice sind auch grosse Systemlandschaften möglich. Ein Gedankenspiel in dieser Richtung: Wenn ein komplexes System aus 50 Komponenten besteht gemäss der maximalen Grösse einer einzelnen Komponente dann bedeutet dies eine potentielle Entwicklungskapazität von 1000 Mitarbeitenden. Das ist schon ein sehr mächtiges System.

Blog 1: Ein Essay über resiliente Enterprise Architecture
Blog 2: Architektonische Irrungen
Blog 3: Das Spiel mit der Komplexität

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