Holger: Als Berater habe ich in der jüngsten Vergangenheit einige bemerkenswerte Ausprägungen mitbekommen: Der Hype nach der Umsetzung von Microservice-Architekturen setzte sich ungebremst in den Unternehmen durch – und das zu großen Teilen, ohne diesen Trend wirklich zu reflektieren.
Notwendige Fragestellungen wie: „Warum machen wir Microservice-Architekturen?“, „Was sind die Argumente für deren Einführung?“ wurden manchmal nicht gestellt oder beantwortet. Oftmals fußt die Entscheidung für Microservice-Architekturen auf bunten Marketing-Foliensätzen eines/einer bekannten Architekt:in, die den Trend auf einer Konferenz oder in einem Zeitungsartikel als die Lösung vieler offensichtlicher Probleme postuliert hat.

Mit dieser Herangehensweise an die Umsetzung von Microservice-Architekturen nehmen wir etwas in Kauf: Eine verborgene Komplexität, denn wir wissen zu Teilen gar nicht, was sich dahinter tatsächlich verbirgt. Und hierin besteht eine ungemeine Gefahr des Scheiterns eines solchen Vorhabens, denn die explizite Inkaufnahme von etwas Verborgenem äußert sich in Softwareprojekten und ihren Umfeldern in genau dem Moment, wenn Eskalationen zunehmen, Themen zu langsam umgesetzt werden oder Digitalisierung, Modernisierung und neue Anforderungen nur schwer einzubringen sind. In einer extremen oder auch verzweifelten Form fällt u.a. eine Aussage wie: „das wird nicht funktionieren“ oder „das ist nicht umsetzbar“. In der Konsequenz nimmt die eigene Unzufriedenheit oder diejenige von Kunden oder Auftraggebern zu. Der daraus resultierende Aktionismus führt im weiteren Verlauf dazu, dass in einem Projektrahmen nicht mehr pro-aktiv agiert, sondern schlimmstenfalls nur noch reagiert oder das Projekt als gescheitert verurteilt wird.

Es kann potenziell eine Unübersichtlichkeit oder auch ein Chaos, das nicht mehr beherrschbar erscheint – oder schlimmstenfalls sogar ist -, entstehen.

Nehmen wir dieses Chaos also als etwas schicksalhaftes an? Oder möchten wir lieber die Komplexitäten – die aus der Wahl eines geeigneten Architekturstils resultieren – aktiv angehen und beherrschbar halten und die Kontrolle über das Vorgehen der Umsetzung von Softwaresystemen behalten? Was bedeutet dann ein geeigneter Architekturstil?

Und genau diesen Fragestellungen sehe ich mich sowohl in meinen Projekten als auch in meinen Trainings zu flexiblen Architekturmodellen und Cloudinfra gegenübergestellt. Die Teilnehmer:innen dieser Schulungen bitten häufig um Hilfestellungen aus genau den gerade erwähnten Aspekten heraus. Die Lösungsräume erarbeiten wir dann gemeinsam.

Holger: Laut C.G. Jung fassen wir das Unbewusste bis zum Zeitpunkt des Bewusstmachens als Schicksal auf. D.h. das, was uns nicht bewusst ist, kann als etwas, das evtl. nicht im Detail verstanden oder bewusst wahrgenommen wird aufgefasst- und weiter: als ein Verhängnis einer höheren Macht, die das Leben bestimmt und lenkt, angesehen werden. Es wird somit hingenommen und akzeptiert.

Bezogen auf unsere Softwaresysteme und -architekturen wäre die Frage: Gibt es evtl. Themen, die wir in einer Entscheidungsfindung nicht sehen, die sozusagen im Verborgenen, Unbewussten liegen?

Eine Entscheidung für oder gegen eine Realisierung/Umsetzung oder einen Architekturstil würde evtl. ganz anders gefällt werden, wenn wir uns gewisse Aspekte bewusst machen.

Fundamentaler Ausgangspunkt ist das CAP-Theorem, welches zwar oftmals bekannt ist, doch dessen Auswirkungen auf unsere Entscheidungsfindung gerade im Kontext von Softwarearchitekturen kaum oder gar nicht beachtet wird.

Es geht daher nicht um das Beherrschen des Unbewussten oder der Komplexität, sondern um das Bewusstwerden darüber – über blinde Flecken und Bereiche, die uns in der Entscheidung massiv beeinflussen und die Komplexität reduzieren können – resultierend aus den Ergebnissen, die uns das CAP-Theorem liefert.

Holger: Das CAP-Theorem liefert uns eine wesentliche Erkenntnis, die uns in der Entscheidungsfindung für gewisse Eigenschaften in verteilten Systemen, ermöglicht: Wir müssen uns für zwei der drei Eigenschaften: Konsistenz, Verfügbarkeit und Partitionstoleranz, entscheiden.

Diese Entscheidung hat einen fundamentalen Einfluss auf die Ausgestaltung und weitergehenden Möglichkeiten eines Systems. Benötigen wir beispielsweise eine ad-hoc-Konsistenz unserer zugrundeliegenden Daten, die den ACID-Prinzipien unterliegt oder nicht?

Wenn ich nun von „oder nicht“ spreche, ist dann schon jedem klar, wovon ich in der Alternative spreche? Dieses ist ein schönes Beispiel für das Bewusstmachen des Unbewussten. Was verbirgt sich denn hinter der Alternative zu ACID?

Wir sprechen von BASE (Base vs. Säure – scherzhaft). Dabei steht BASE für Basically available, soft-state und Eventual Consistency.
Dieses bedeutet, dass wenn ich die ACID-ad-hoc-Konsistenz verlasse und mich dagegen entscheide, kann ich mit den Mittlen der Eventual Consistency arbeiten. Ist diese Tatsache bewusst? Wir werden es in meinem Vortrag klären.

Holger: Ein zentrales Thema in der Architekturarbeit – insbesondere in Microservice-basierten Systemen – ist die Verteilung von Verantwortlichkeiten (Separation of Concerns).

Wo liegen denn meine Verantwortlichkeiten – fachliche und technische? In einem Service oder über mehrere Services verteilt? Kann ich die Verantwortlichkeiten trennen – und wenn ja, dann wie?

Die Trennung von Verantwortlichkeiten umfasst in der Umsetzung unterschiedliche Aspekte und Bereiche. Die Frage nach der Definition eines Verantwortungsbereichs muss gemeinsam mit allen beteiligten Stakeholdern geklärt werden. Wir müssen diese blinden Flecken aufdecken.

Ein moderner Trend ist es mit weitergehenden Aspekten zu arbeiten: Sidecars und daraus resultierend die Service-Meshes bieten uns ein enormes Potential bestimmte Komplexitäten und Verantwortlichkeiten in die Infrastruktur auszulagern. Auch hier kommt wieder die Frage nach dem Bewusstsein über diese Möglichkeiten zum Tragen. Ich hoffe dieses in meinem Vortrag aufzuklären.

Holger: Die Psychologie beschäftigt sich mit der Fragestellung der Problemlösung. Ein Problem wird dadurch gekennzeichnet, dass ich von einem Ausgangszustand in einen Zielzustand übergehen möchte, wobei zwischen diesen beiden Zuständen eine Barriere existiert, die es zu überwinden gilt.

Die Problemlösung besteht nun darin sog. Operatoren zu finden, mit deren Hilfe ich diese Barriere überwinden kann.

Der Erwerb dieser Operatoren erfolgt aufgrund von drei Arten:
I.) Entdecken

II.) Instruktion und

III.) Beobachtungslernen.

Aus diesen Möglichkeiten des Erwerbs müssen die Operatoren extrahiert werden und dieses passiert anhand der Analogiebildung. Dieses Konzept geht schon auf Platon zurück und ist essenziell. Wir erlernen die Themen anhand von Analogien.

Die Frage ist nun, wie uns dieser Prozess der Analogiebildung dabei helfen kann unbewusste Teile aufzudecken, um fundierte Entscheidungen für unsere Systemarchitekturen zu treffen, die uns die Kontrolle über diverse Ausprägungen ermöglichen?

Holger: Gegenfrage: Wodurch ist der Rahmen eines Softwaresystems definiert? Wo liegt seine Grenze? Wir klären dieses in Rahmen des Vortrags.

Holger: Die ISO-25010-Norm definiert Qualitätsmerkmale für Software. Diesen Qualitätsmerkmalen werden Qualitätsszenarien, die aus den Qualitätsanforderungen abgeleitet werden, zugeordnet und priorisiert.

Wichtig ist nun, dass jedes System in seinen Lösungsszenarien und -strategien in Bezug auf die in der Norm definierten Qualitätsmerkmalen optimiert werden kann.

Hier fängt unser Entscheidungsprozess als Softwarearchitekt an. Unter Einbezug der Erkenntnisse aus dem CAP-Theorem sowie der Aufklärung blinder Flecken in Bezug auf die Infrastruktur (oder auch Makroarchitektur) können unsere zu realisierenden Systeme exakt auf die umzusetzenden funktionalen sowie qualitativen Merkmalen optimiert und angepasst werden.
Wir werden dieses an einem durchgängigen Beispiel in meinem Vortrag entdecken.