REA.02: Architektonische Irrungen

Effizienz – Fluch und Segen

In jedem Management Bericht und in jeder Strategie steht das Streben nach Effizienz. Effizienz an der richtigen Stelle gefördert, ist etwas Anstrebenswertes. Effizienz ist jedoch eine gefährliche Waffe. Lokale Effizienz oder zeitlich begrenzte Effizienz kann zu einem dysfunktionalen Gesamtsystem führen.

Der Aussage, dass lokale Effizienz schädlich für ein Gesamtsystem ist, stimmt wahrscheinlich mittlerweile die Mehrheit zu. Dass zeitliche Effizienz ebenso schädlich ist, da sind wir uns erstaunlicherweise weniger einig. Wobei wir hier fantastische gute Beispiele haben, wie etwas das Totsparen der Deutschen Bahn oder des britischen Gesundheitssystems.

Diesen Blog widme ich Aussagen und Schlussfolgerungen, die aus meiner persönlichen Sicht schlichtweg falsch sind und aus einem falsch verstandenen Effizienzstreben resultieren.

Falschaussage eins: Das gesamte System muss konsistent sein

Ein weit verbreitetes Missverständnis ist, dass alle Systeme vollständig konsistent sein müssen. Dieser intuitive Wunsch nach Einheitlichkeit führt oft zu Over-Engineering und der Abneigung, sinnvolle Inkonsistenzen zu akzeptieren. Diese Aussage „unsere Systeme müssen vollständig konsistent sein“ ist schlichtweg falsch.

Das gesamte System muss nicht konsistent sein. Ein Gesamtsystem besteht aus einzelnen Kontexten. Ein gut identifizierter Kontext umfasst einen in sich geschlossenen fachlichen Aspekt von beschränktem Funktionsumfang. Dieser Kontext fügt sich in das Gesamtsystem über klar definierte Schnittstellen ein, nach dem Prinzip der losen Kopplung. Die Forderung ist, dass ein fachlicher Kontext in sich konsistent sein muss. Konsistenz der Kontexte untereinander muss nicht zwingend vorhanden sein.

Ein Beispiel: Ein Online-Shop beliefert Kunden mit Produkten. Damit die Lieferadresse schnell bestimmt werden kann, hält sich die Logistik die Lieferadresse zu einer Kunden-ID. Das sind redundante Daten zum CRM. Es ist vollkommen in Ordnung, wenn die Lieferadresse für eine Kunden-ID in der Logistik vom korrekten Wert im CRM abweicht, solange keine Lieferung für die Kunden-ID ansteht. Um zu vermeiden Lieferungen an die falsche Adresse zu senden, könnte das folgende Vorgehen gewählt werden: Das CRM sendet eine Notifikation zu einer Kunden-ID an die Logistik, wenn sich die Lieferadresse geändert hat. Die Notifikation interessiert die Logistik nicht, solange nichts an die Kunden-ID zu versenden ist. Wenn jedoch eine Lieferung an diese Kunden-ID stattfinden soll, so prüft die Logistik, ob eine Notifikation vorhanden ist. Wenn ja, dann pullt sich die Logistik die aktuelle Lieferadresse vom CRM-System. Das ist ein Ansatz fachliche Kontexte zu entkoppeln, der sinnvolle Inkonsistenzen zwischen den Kontexten zulässt. Konsistenz ist für einen fachlichen Kontext für den Zeitpunkt der Ausführung einer fachlichen Funktion notwendig. Dieses Design Prinzip ermöglicht eine lose Kopplung von Komponenten. So würden etwa Batch Läufe überflüssig, typisch zu einem Zeitpunkt geringer Systemaktivität, um alle Geschäftsobjekte vom Typ X von einem System zum nächsten zu schaufeln. Irgendwann ist die Nacht zu kurz für den Batch oder die Kette der Batch Läufe.

Falschaussage zwei: Wir vermindern Komplexität

Wer sich ein klein wenig mit Systemtheorie beschäftigt hat, der weiss, dass die (Anmerkung: fachliche) Komplexität eines Systems eine immanente Eigenschaft des Systems ist. Die Komplexität des soziotechnischen Ökosystems des Unternehmens kann nicht durch Änderungen innerhalb (!) der Systemgrenze vermindert werden. Zudem gilt die Aussage, dass 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. Es ist vollkommen gleichgültig welche Technologie oder welche Prinzipien in der Architektur angewendet werden, die Komplexität des Gesamtsystems bleibt immer gleich hoch – eben, weil dies eine immanente Eigenschaft des gewählten Business Modells des Systems ist. Hier verbleiben nur grundlegende zwei Ansätze. Der erste Ansatz ist ein weniger komplexes Business Modell zu wählen, was übrigens das Erfolgsrezept vieler Tech Giganten des New Business ist. Der zweite Ansatz ist die Komplexität besser beherrschbar zu machen, sie also geschickt zu verteilen. Diese Verteilung der Komplexität ist der Schlüssel zum Erfolg, nicht die Wiederverwendung einzelner Komponenten.

Ausflug: Standardisierung, Plattform und Wiederverwendung

Ich wage die plakative Aussage: Standardisierung ist hilfreich, Wiederverwendung (aus Effizienzgründen) ist kontraproduktiv, Plattformen sind ein Zwitter und ein guter Vermittler. Was sind die Charakteristiken und Unterschied zwischen Standardisierung, Plattform und Wiederverwendung?

Standardisierung und Plattform implementieren beide allgemeingültige Prinzipien, die in einem Kontext eingesetzt werden. Die Unterscheidung zwischen Standardisierung und Plattform liegt in der Fachlichkeit. Ein Mechanismus zur Standardisierung beinhaltet keine Fachlichkeit, d.h. das Prinzip oder dessen Implementierung kann in vollkommen unterschiedlichen fachlichen Kontexten eingesetzt werden. Eine Plattform hingegen implementiert die allgemeingültigen fachlichen Aspekte einer Domäne, die sich über die Zeit gar nicht oder nur sehr träge ändern.

Wiederverwendung ist der Versuch eine fachliche Komponente in mehreren ähnlichen Kontexten einzusetzen. Wiederverwendung ist positiv, wenn die Veränderung der betroffenen Kontexte träge sind (=> Plattform), sie ist kontraproduktiv, wenn die Veränderungsgeschwindigkeit in den Kontexten hoch ist. Das klingt sehr abstrakt. Sehen wir uns Beispiele an.

Eines der markanten Beispiele für Standardisierung ist, oder war, die A/B Schaltung in der analogen Telefonie. Sie war Garant über hundert Jahre für die beständige Weiterentwicklung im Bereich der Telekommunikation, in allen Ländern und mit beliebig vielen Anwendungen, die auf Datentransport aufbauten.

Moderne Beispiele von Standardisierung sind TCP/IP, der Austausch von Daten mittels Jason, die Virtualisierung von Infrastruktur, das metrische System, die Einigung über Zeitzonen (auch wenn hier über Sommer- und Winterzeit diskutiert wird), die Standardprotokolle im Zahlungsverkehr, die Einigung auf einen Stecker zum Laden von Mobilgeräten. Standardisierung erlaubt die Anwendung eines Prinzips unabhängig vom fachlichen Kontext des Prinzips.

Ein gutes Beispiel für Plattform ist eine Typenplattform im Automobilbau, die es erlaubt mehrere unterschiedliche Modelle mit vollkommen unterschiedlichem Aufbau auf der identischen Plattform aufzubauen. So basierten zum Beispiel von VW Golf IV, Bora, New Beetle, Skoda Oktavia, Seat Leon, Audi A3 und Audi TT auf der identischen Plattform. Wiederverwendung hingegen ist die Nutzung einer fachlichen Komponente in mehr als einem Kontext. Also beispielsweise die Nutzung einer Preis- und Rabatt-Implementierung für dezentrale und länderspezifische Services. Die Komplexität der Komponente steigt, da jeder Kontext zu berücksichtigende spezifische Eigenschaften besitzt. Die Allgemeingültigkeit ist nicht gegeben. Ob Wiederverwendung Fluch oder Segen ist, bestimmt die Komplexität der Fachlichkeit und die Veränderungsgeschwindigkeit des fachlichen Kontext.

• Blog 1: Ein Essay über resiliente Enterprise Architecture

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.

Resilince in Enterprise Architecture © 2024 by Rainer Grau is licensed under CC BY-SA 4.0