REA.05: Die Komplexität des Schnittstellen Netzwerkes

Die Komplexität des Netzwerkes an Schnittstellen bewerten

Die Komplexität des Netzwerks der Schnittstellen zu bewerten, welches die Komponenten lose koppelt, ist herausfordernd. Allerdings existieren in der Enterprise Architecture bewährte Prinzipien, die den meisten bekannt sind und – leider – nur wenig genutzt werden.

Die folgenden fachlichen (!!) Eigenschaften einer Schnittstelle sind hierbei relevant

Zeitkritikalität

Die Aussage wie zeitkritisch der Transport eines Geschäftsobjektes oder einer Steuerinformation von einer Provider-Komponente zu einer Consumer-Komponente im Sinne des Geschäftsprozesses ist.
Ein Beispiel aus der Logistik: wenn ein Paket auf einer Fördertechnik auf eine Weiche zusteuert, dann ist es zeitkritisch zu entscheiden, ob das Paket nach rechts oder nach links fährt.

Leistung

Leistung ist physikalisch Arbeit pro Zeit. Wenn wir als Arbeit das Verarbeiten einer fachlichen Aufgabe als Folge des Ansprechens einer Schnittstelle einer Komponente ansehen, dann ist die Leistung die Anzahl der Verarbeitungen pro Zeit. Für eine moderne skalierende Umgebung bedeutet dies, dass Leistung und Kosten sich maximal linear entwickeln. Oder einfach gesagt: n-mal so viel Verarbeitungen kosten maximal n-mal so viel bei gleichem Verhalten einer einzelnen Verarbeitung.

Volumen

Das Volumen einer fachlichen Eigenschaft, die mit einem Verwenden der Schnittstelle transportiert wird. Auch wenn es uns bewusst ist, dass in vielen Fällen die Nutzinformation bei einem Schnittstellenaufruf heutzutage oft nur einen Bruchteil der Brutto transportierten Datenmenge entspricht, so kann das schnell kippen, wenn Listen oder Bilder übertragen werden. Ein für mich prägendes Beispiel war eine Briefsortieranlage, in welcher pro Minute bis zu 500 Briefe (Quelle: https://www.post.ch/de/jobs/blog/2015/a-briefe) nach Postleitzahlen sortiert wurden – einschliesslich Scan der Adresse. Hier multiplizieren sich Leistung (500 pro Minute) und Volumen (im Schnitt 1.5 Mbyte Nutzdaten pro Scan) zu einer respektablen Anforderung, die ein System erst einmal bewältigen muss.

Masterverhalten und pass-through von Daten

Wie in einem früheren Blog bereits diskutiert, die Daten der Komponenten des Gesamtsystems müssen nicht über das Gesamtsystem konsistent sein. Ein fachlicher Kontext (nach Marc Fowler ein «boundeed context») muss über konsistente Daten verfügen. In einem modularen System verfügt eine Komponente über die Daten, die diese zur fachlichen Verarbeitung benötigt. Allerdings ist jede Komponente nur zu einem Teil der Master, also der Besitzer, die «single source of truth» der Daten. Viele Daten, die eine Komponente zur fachlichen Verarbeitung benötigt sind eine Kopie der Daten des Masters. Eine Logistik Komponente, welche den Druck eines Adresslabel für ein Paket druckt, muss über die Adresse verfügen. Master der Adressinformation ist die CRM-Komponente. Die Logistik-Komponente holt sich entweder jedes Mal die Adressinformation von der CRM-Komponente, oder sie hält sich eine «Kopie». Ein wichtiges Prinzip ist: eine Komponente holt eine Kopie der Daten immer direkt vom Master. In vielen Implementierungen werden Daten jedoch von Komponente zu Komponente weitergereicht. Das CRM gibt die Adressdaten an Komponente A, diese reicht sie weiter an B und diese weiter an C. Nun sind die Systeme CRM, A, B und C gekoppelt. Die Komplexität des Schnittstellensystem ist damit künstlich erhöht aufgrund einer fehlerhaften Architektur. Eine technische Implementierung zur Entkoppelung ist der Einsatz eines Queueing System oder «Enterprise Bus» Systems. Allerdings ist es ein Trugschluss, dass hiermit die Schnittstellen Komplexität positiv adressiert wird. Diese verbleibt identisch, sie wird lediglich auf das Queueing System verschoben. Das Queueing System optimiert die Entkopplung durch Asynchronität statt Synchronität – was immerhin ein wichtiges Element der Entkopplung von Systemteilen ist.

Schnittstellen und Technologie

Schnittstellen benutzen Infrastruktur, siehe der Einwurf im Blog 2 dieser Serie. Infrastruktur ist eine hoch standardisierte Laufzeitumgebung, welche dem Konsumenten austauschbare Ressourcen zur Verfügung stellt. Wichtig sind die Worte «austauschbar» und «standardisiert». Austauschbar bedeutet die Infrastruktur zu vertretbaren Kosten von einem anderen Anbieter beziehen zu können. Standardisiert bedeutet, dass die entsprechende Technologie von einer grossen Menge an Anbietern angeboten wird und dies über einen längeren Zeitraum, eventuell in beständig neuen Versionen. Ich persönlich würde fünf Jahre Existenz als untere Grenze einer Infrastruktur Technologie ansehen, die als Standard angesehen werden kann. Der WLAN-Standard ist ein gutes Beispiel. Der erste 802.11 Standard übertrug 2 Mbps per Radiowellen. Der neuste Standard 802.11be überträgt bis zu 2900 Mbps, also fast das 1500 fache. Für eine Anwendung ist es nur bedingt interessant, ob das Netzwerk nun über 802.11 oder über 802.11eb verfügt.

Das Geflecht der logischen Schnittstellen ist oft ein gordischer Knoten

Auf moderne Cloud Umgebungen bezogen bedeutet dies auf eine standardisierte Container Technologie zurückzugreifen wie Kubernetes oder OpenShift. Die Container Technologie Kubernetes steht auf den Cloud Plattformen von AWS, Microsoft oder Google zur Verfügung. Ein Wechsel ist (technologisch) mit vertretbaren Mitteln möglich – solange man keine Cloud Anbieter spezifischen Erweiterungen verwendet. Eine ganz andere Frage ist in diesem Fall die ökonomische und die rechtliche Seite eines Wechsels des Cloud Anbieters, welche oft die höhere Hürde darstellt als der technologische Shift.

Schnittstellen nutzen also Infrastruktur. Allein aus dieser kleinen Diskussion wird klar: Ein Unternehmen tut gut daran die Anzahl an Schnittstellentechnologien gering und strikt standardisiert zu halten und auf Anbieter spezifische Erweiterungen zu Gunsten einer mittelfristig stabilen Infrastruktur zu verzichten. Das ist möglich – auch wenn es in der Entwicklung bei progressiven Protagonisten nicht unbedingt auf Gegenliebe stösst.

Blog 1: Ein Essay über resiliente Enterprise Architecture
Blog 2: Architektonische Irrungen
Blog 3: Das Spiel mit der Komplexität
Blog 4: Komplexität verteilen – Die Grössen einer Komponente

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.