Benedikt Stemmildt 07. Dezember 2021

Responsible Architecture

Geschwindigkeit, Effektivität und Freude durch unternehmerische Verantwortung

Geschwindigkeit

Wir ITler sind nie schnell genug. Hier noch schnell ein Feature, da noch schnell ein Feature und – ach was, wer braucht schon Tests? Doch am Ende steht man da und wird immer langsamer, immer fehleranfälliger und vor allem immer frustrierter. Wer kennt es nicht? Dabei haben wir den großartigsten Beruf, den man sich nur vorstellen kann: Wir erschaffen Dinge aus dem Nichts!

Geschwindigkeit ist eine der absolut wichtigsten Eigenschaften eines jeden IT-Teams, doch wie kommt es, dass wir so schlecht darin sind? – Wir verwechseln Geschwindigkeit mit Effizienz! Unsere Organisationen und Architekturen sind zu oft auf Effizienz ausgerichtet: Backend-/Frontend-Teams, zentrale Datenbanken, gemeinsame, einheitliche Datenformate. Alles Vorgehensweisen, die uns effizienter machen aber ausbremsen.

Zu viele Unternehmen haben sich daraufhin zu sorglos in die vermeintlich alles lösenden Ansätze, wie den Microservice- und Single-Page-Application-Hype gestürzt und werden nun durch eine noch komplexere Organisation und Architektur noch weiter ausgebremst. Zu übereilt ist die mutmaßlich falsche Architektur als Ursache für die fehlende Geschwindigkeit eingestuft. Um diesen Trugschluss zu vermeiden lässt sich nach dem Vorgehen der "Responsible Architecture" eine Architektur finden, die kurzfristig und langfristig für Geschwindigkeit, Effektivität und Freude sorgt.

Unabhängigkeit

Das "Responsible" in "Responsible Architecture" steht nicht für Nachhaltigkeit, sondern für Verantwortung – vollumfängliche, unternehmerische, Ende-zu-Ende-, kundenorientierte, messbare Verantwortung. Denn nur dadurch lässt sich das Commitment erzeugen, das benötigt wird, um Geschwindigkeit zu gewinnen und auch zu halten.

"Responsible Architecture" beschreibt nicht die eine Architektur, die man definiert, dokumentiert und dann implementiert. Ganz im Gegenteil, sie beschreibt den Weg, um zu seiner eigenen, ganz persönlichen Architektur zu finden. Wenn man so will, einen Pilgerweg, den es zu beschreiten gilt, um zu sich selbst zu finden. Bei einigen – sehr wenigen – Unternehmen kann dies heißen, dass am Ende des Weges eine Microservice-Architektur steht. Und bei anderen wird ein Monolith die passende Wahl sein.

Doch diese Reise zur eigenen Architektur beginnt nicht mit der Technik, sie endet damit. Am Anfang des Weges steht die Frage nach dem Business Model und dem Value Stream der Unternehmung. Über diese Fachlichkeit gelangen wir zur Frage nach der Organisation, Kultur und Arbeitsweise der Firma. Und kommen dann erst, wie versprochen, zu Herangehensweisen der Technik.

Geführt wird diese Reise von Architekten, die uns an Gabelungen mit den richtigen Methoden, Werkzeugen und Fragestellungen ausstatten, damit wir uns selbst für den passenden Pfad entscheiden. Es sind nicht die Architekten, die für uns entscheiden, doch sie machen uns die Konsequenzen unserer Entscheidungen in allen genannten Bereichen bewusst. Ein Architekt muss somit mehr als nur die Technik betrachten, System Thinking ist gefragt. Mit der "Responsible Architecture" hat er einen Werkzeugkasten, um auf jegliche Hürden entlang des Weges reagieren zu können. Bevor wir uns aber mit dem ersten Bereich der Fachlichkeit beschäftigen, noch ein wichtiger Disclaimer.

Disclaimer

Meine langjährige Erfahrung zeigt: Ohne, dass das Management und manchmal gar der Inhaber, die Reise anführt, wird man nicht zu seiner "Responsible Architecture" finden. Die langfristigen Veränderungen sind auf Gesamtunternehmensebene einfach zu groß, als dass man diese allein bewältigen kann. Das soll nicht heißen, dass man den Ball nicht ins Rollen bringen kann, aber man wird auf dem Weg das Management nicht nur überzeugen, sondern als Treiber gewinnen müssen.

Die Art der Führung spielt nämlich eine absolut zentrale Rolle, die der Reise seine Leitplanken gibt und ohne die kein Erfolg eintritt. "Transformational Leadership" – Hier geht es vor allem darum, eine Vision zu vermitteln, das Team positiv zu motivieren und ein Umfeld zu schaffen, in dem kollaboriert wird. Wer dazu tiefer ins Detail gehen möchte, dem empfehle ich "Leadership Is Language" von L. David Marquet [1].

Wenn wir während der gesamten Reise an dieser Art der Führung arbeiten, können wir inhaltlich in die "Responsible Architecture" eintauchen und beginnen mit den Fragestellungen zur Fachlichkeit.

Fachlichkeit

Das zentrale Element der "Responsible Architecture" ist die Frage nach Unabhängigkeit. Über Unabhängigkeit lässt sich Verantwortung erzeugen. Nur wenn ich ein Thema selbständig, unabhängig bearbeiten kann, kann ich auch wirklich verantwortlich dafür sein. Auf der anderen Seite ist ein gesamtes Produkt mit allen seinen fachlichen Anforderungen und Funktionen viel zu groß, um es zu überblicken. Daher suchen wir Architekten immer wieder nach Möglichkeiten, ein Produkt zu zerschneiden.

Und genau hier wird es spannend, denn Schnitte zu wählen, die eine Unabhängigkeit der einzelnen Teile erzeugen, ist nicht einfach. Architekten neigen von Natur aus zu technischen Schnitten. Diese Schnitte sind aber nur in den seltensten Fällen unabhängig. Um diesen Fehler zu vermeiden, beginnt die "Responsible Architecture" mit der Fachlichkeit und endet mit der Technik. Denn nur, wenn die einzelnen Teile für sich genommen wieder ein Produkt darstellen, welches dem Kunden Mehrwert bietet, hat man einen Schnitt gefunden, der unabhängig ist. Wichtig: hier ist der Kunde des Unternehmens, nicht der interne Kunde gemeint. Ein sehr einfaches Negativbeispiel ist die Trennung seines Produkts in Anzeige von Datum X und Persistenz von Datum X. Keiner der beiden Teile kann ohne den anderen einen Kundenmehrwert bieten.

Im E-Commerce-Bereich ist es zum Beispiel üblich, dass man zwischen (1) Suche, Produktliste und (2) Produktdetailseite, Warenkorb und (3) Checkout schneidet. So entstehen drei unabhängige Teilbereiche, die auch ohne die anderen einen eigenständigen Mehrwert darstellen. Im Folgenden Erkunden, Entscheiden und Erfüllen genannt.

Abb. 1: Unabhängige Trennung einer E-Commerce Shop Customer Journey. © Benedikt Stemmildt

Es gibt eine Vielzahl an Methoden, die helfen, um einen Schnitt zu finden, der diesen Ansprüchen gerecht wird. Ich möchte hier nicht jede Methode im Detail besprechen, aber einen Überblick und Verweise auf Details geben:

Value Stream Mapping – Mit Hilfe von Value Stream Mapping lässt sich die Wertschöpfungskette der Unternehmung abbilden. Diese hilft dann, unabhängige Schnitte zu finden, da meist einzelne Teile des Value Stream unabhängig von vorherigen oder nachfolgenden Teilen agieren können. Diese Methode bildet meist den aktuellen Stand der Dinge ab. Sie reicht nicht aus, um einen vollständigen Blick auf den Schnitt zu werfen.
Business Model Canvas – Die Business-Model-Canvas-Methode ermöglicht einen Blick in die Zukunft zu werfen und neue Geschäftsfelder zu ergründen. Das Wissen um mögliche neue Geschäftsfelder kann ein wichtiger Impuls für den richtigen Schnitt sein. Dieses Vorgehen ist sehr aus der Unternehmenssicht geprägt und bedarf weiterer Methoden, um einen vollumfänglichen Blick zu erlangen.
Jobs to be done – Mit dieser Methode kann man herausfinden, welche Bedürfnisse die Unternehmung beim Kunden erfüllt, und ableiten, ob diese Bedürfnisse auch anders erfüllt werden könnten. Oft wird durch diese Methode auch klar, wer die eigentlichen Wettbewerber sind. Zum Beispiel ist der größte Konkurrent eines Buchhändlers nicht ein anderer Buchhändler, sondern ein Video-Streaming-Anbieter. Auch dieses Wissen hilft, den Schnitt in Richtung Zukunft und vor allem in Richtung Kunde auszurichten und damit nicht am aktuellen Stand hängen zu bleiben.
Three Horizon Model – Dieses Modell soll veranschaulichen, welcher Zeithorizont bzw. Reifegrad welchen Themen zugeordnet ist. Mit Hilfe dieses Wissens lässt sich entscheiden, ob man Funktionen schon in die zu erstellende Architektur aufnimmt oder außerhalb in eigenen Architekturen umsetzt. Durch diese Methode entsteht Fokus, was grundsätzlich für die Gesamtarchitektur einen enormen Vorteil bietet.
Wardley Mapping – Wardley Mapping ist eine weitere Methode, um neue Geschäftsfelder zu ergründen. Man könnte behaupten, sie wäre ein Ersatz für die in die Jahre gekommene Business-Model-Canvas-Methode.
Strategisches Domain-driven Design – Mit Domain-driven Design tauchen wir eine Flughöhe tiefer ein, als vorherig genannte Methoden und können so den Makro-Schnitt bestätigen und auch innerhalb der bereits gefundenen Schnitte auf Mikroebene erneut schneiden.

Wir wissen alle, nicht nur fachliche Anforderungen spielen eine wichtige Rolle, wenn es um den optimalen Schnitt geht. Sondern Qualitätsanforderungen bestimmen häufig, ob ein Schnitt überhaupt realisierbar ist. Erst über die Qualitätsanforderungen wird klar, ob ein Produkt betrieben werden kann. Daher muss schon in diesem Schritt berücksichtigt werden, welche fachlichen SLAs unsere Teilprodukte erfüllen sollen.

Abschließend ist zu berücksichtigen, dass die wenigsten Produkte heutzutage zunächst vollständig konzipiert und dann umgesetzt werden. Stattdessen wird vielmehr parallel konzipiert und umgesetzt. Man released iterativ kleine, minimale Funktionen und baut diese aus. Oft hört man in diesem Zusammenhang den Spruch "Wir müssen das Zielbild jetzt schon mal mitdenken, damit wir uns nichts verbauen". Ich halte diese Aussage für sehr gefährlich und irreführend. Daher schlage ich einen anderen Gedanken vor: "Wir müssen jetzt schon mal mitdenken, wie wir während des Weges zu unserem aktuell unbekannten Ziel immer mehr Klarheit gewinnen, damit wir uns nichts verbauen". Diese Alternative betont, dass unser Ziel zu Beginn nicht bekannt sein muss, es auch in der Realität nie ist, aber wie wir das Ziel während des Weges finden und dies in unserem Schnitt berücksichtigt werden sollte. Der Weg ist etwas, was nicht in der Zukunft, sondern in der Gegenwart liegt und sich damit viel einfacher in unsere Gedanken einbeziehen lässt.

Im Buch "Lean Startup", von Eric Ries, sind diverse Methoden beschrieben, wie ein solcher Weg zu beschreiten ist [2]. Die bekannteste unter ihnen ist das "A/B-Testing". Unser Produktschnitt sollte also zumindest darauf ausgelegt sein, möglichst schnell viele dieser Tests durchführen zu können. Nur wenn wir die Build-Measure-Learn-Kurve mit unserer Anwendung möglichst häufig und schnell durchlaufen können, werden wir langfristig erfolgreich sein.

Organisation

Nachdem die Fachlichkeit auf individuelle, unabhängige Bereiche aufgeteilt ist, stellt sich die Frage nach der Organisation: Also wer bearbeitet diese Bereiche und auf welche Art und Weise?

Zunächst muss, um die gewonnene Unabhängigkeit nicht zu gefährden und auch auf organisatorischer Ebene Verantwortung zu ermöglichen, jeder Bereich exklusiv mit Mitarbeiterstellen besetzt werden. Sobald ein Mitarbeiter in mehreren fachlichen Teilbereichen tätig ist, geht das Gewonnene verloren. Auch dynamische Teams zu bilden, die sich permanent neu zusammensetzen, verhindert Verantwortung. Was aber nicht dagegen spricht ist Kollegen isoliert, in längeren Abständen die Teams wechseln zu lassen.

An dieser Stelle ein Hinweis: Es gibt mittlerweile neue Bewegungen, die aufgrund der nicht Vermeidbarkeit von sich ändernden Teams einen Ansatz von "Embrace Change" fahren. Mehr dazu im Buch "Dynamic Reteaming" von Heidi Helfand [3]. Dazu habe ich allerdings bisher keine persönliche Erfahrung gemacht.

Damit wir jeden Bereich eigenständig besetzen können, müssen wir auf interdisziplinäre Teams setzen. Sprich, ein Team besteht aus verschiedenen Disziplinen oder Rollen. Beispielsweise aus einem Produkt Owner und einigen Full-Stack-Entwicklern. Andere Zusammensetzungen sind auch möglich, solange alle Aufgaben des Teams mit Rollen abgedeckt sind. Vorsicht: Hier geht es vor allem um Rollen, nicht um Stellen. Eine Stelle kann mehrere Rollen einnehmen. Im aufgeführten Beispiel sind die Entwickler ebenfalls für die Qualitätssicherung zuständig.

Im Buch "Team Topologies" von Matthew Skelton und Manuel Pais werden neben den eben erwähnten Stream-aligned Teams weitere Möglichkeiten der Teamzusammensetzung im Detail erörtert [4]. Meiner Erfahrung nach sollte das Ziel aber sein, den Großteil der Teams, wie beschrieben, anhand der fachlichen Teilbereiche zu strukturieren.

Abb. 2: Interdisziplinär besetzte Teams, die sich keine Stellen teilen. © Benedikt Stemmildt

Ist das Team besetzt, stellt sich die Frage, wie das Team arbeiten sollte. Hier gibt es diverse, bereits ausführlich diskutierte, Methoden aus dem agilen Umfeld. Ob Kanban oder Scrum ist im Grunde völlig egal. Wichtig ist nur, diese Arbeitsweise nicht nur im Entwicklungsbereich anzuwenden. Wenn wir wieder an System Thinking denken, können wir nicht effektiv Richtung Kunde agieren, wenn wir nur einen Teil der am Prozess beteiligten Personen in unsere Arbeitsweise einbeziehen. Hier wird klar, warum die Unterstützung der gesamten Geschäftsführung oder des Inhabers nötig ist, denn dieser Umstand führt uns automatisch dazu, dass wir unsere Teams auch mit Kollegen aus dem Stakeholder-Bereich besetzen sollten oder zumindest unsere Arbeitsweise übergreifend organisieren sollten. Wer sich in diesem Bereich tiefer informieren möchte, dem empfehle ich das Modern Agile Framework [5].

Eine meiner Erfahrung nach sehr erfolgreiche Methode unabhängig von Scrum oder Kanban ist das Mob Programming. Hier arbeitet nicht ein Entwickler allein an seinem Rechner oder – wie beim Pair Programming – zwei Kollegen gemeinsam, sondern das gesamte Team. Das mag im ersten Moment wenig effizient klingen, ist aber extrem effektiv und vor allem sehr schnell. Und die Effizienz leidet am Ende weniger als man denkt. Ich persönlich habe die Erfahrung gemacht, dass diese Arbeitsweise sogar langfristig deutlich effizienter ist als Einzel- oder Pair Programming, man denke hier an Urlaube, Krankheitstage oder spontane Hilfestellungen für andere Teams. Sozusagen eine Win-Win-Situation und bei größeren Teams lassen sich sogar einfach mehrere Mobs bilden. Eine gute Mobgröße liegt, nach vielen eigenen praktischen Versuchen, zwischen 3 und 5 Personen. Mehr dazu kann man im Buch "Remote Mob Programming" oder auf der Internetseite nachlesen [6].

Um den Bereich Organisation abzuschließen, schauen wir auf die Kultur unserer entstandenen Teams, denn nur, wenn wir unsere Arbeitsweise dauerhaft in der Kultur des Unternehmens verankern und eine performance-orientierte Kultur etablieren, können wir die angesprochenen Vorteile vollständig nutzen. Performance-orientierte Kultur nach Westrum bedeutet sehr knapp zusammengefasst:

Hohe Kollaboration
Überbringung kritischer Informationen wird gefördert
Risiken werden offen geteilt und intensiv besprochen
Fachbereichsübergreifende Arbeit wird ermutigt
Misserfolge werden untersucht und aufgeklärt (nicht um den Schuldigen zu finden!)
Neuerungen werden begrüßt und umgesetzt

Zuletzt ein erneuter Verweis auf den Disclaimer aus der Einleitung, dass Leadership den Rahmen um unseren Weg zur "Responsible Architecture" setzt. Denn Transformational Leadership ermöglicht uns erst die beschriebenen Arbeitsweisen anzuwenden und eine performance-orientierte Kultur zu etablieren.

Technik

Witzig, oder? Wer bis hierhin durchgehalten hat, muss feststellen, dass wir bisher absolut gar nicht über technische Fragestellungen gesprochen haben. Klar, das war angekündigt, aber ist es nicht wahnsinnig interessant, wie viel wir über Architektur gesprochen haben, ohne Technik zu erwähnen?

Ohne ganz über Technik zu sprechen, kommen wir dann natürlich nicht aus. Auch hier geht es wieder darum, die gewonnene Unabhängigkeit nicht zu verlieren. Und wie schon in der Einleitung erwähnt, tendieren wir schnell zu Microservices und Single Page Applications als Lösung für diese Herausforderung. Doch dabei vergessen wir, dass ein System nur durch die Summe seiner Teile funktioniert und auch nur als Ganzes, oder eben zerlegt in kleinere, unabhängige, wieder eigenständige, für sich selbst vollständige, funktionierende Systeme, optimiert bzw. weiterentwickelt werden kann. In der Praxis ist ein Microservice für sich betrachtet sehr selten vollständig funktionsfähig. Für echte Unabhängigkeit ist eine lose gekoppelte Architektur essenziell und um Microservices lose zu koppeln kauft man sich enormen Overhead ein.

Denn eine synchrone Schnittstelle zwischen zwei Services ist keine lose, sondern eine sehr harte Kopplung, die es also zu vermeiden gilt. Wenn es um Daten geht, bekommt man das hin, indem man die von der Schnittstelle benötigten Daten nicht synchron abfragt sondern repliziert. Also eine Kopie davon in beiden Services vorhält. Das Kopieren ist nicht synchron an die Anwendungsfälle des Services gebunden und so entsteht eine lose Kopplung. Dies kann über diverse Mechanismen geschehen, HTTP-Feed, Queue oder direkt per SQL, event-basiert oder per Cron. Eigentlich ist es fast schon egal, welchen dieser Mechanismen man verwendet, solange er die Qualitätsanforderungen erfüllt.

Von direkten technologischen Zugriffen würde ich allerdings abraten, da ohne Abstraktion doch eine gewisse Kopplung entsteht und auf geteilte Infrastruktur sollte ebenfalls verzichtet werden. Auch diese sollte aufgeteilt und jeweils in die Verantwortung eines Teams geben werden. Denn von wem würde die geteilte Infrastruktur betrieben werden? Wer fühlt sich verantwortlich? Wenn es nur eine reine Infrastruktur-Komponente ist, dann ist das Team darum nicht am Kunden orientiert und kann keine unternehmerische Verantwortung aufbauen und ist erst recht nicht unabhängig.

Wenn ich diese Replikation nun für meine diversen Microservices mache, dann werde ich weder besonders effizient, noch effektiv, geschweige denn schnell sein, da ich die meiste Zeit nicht an Funktionen für den Kunden, sondern an Funktionen für meine Architektur arbeite. Doch was ist dann ein guter Schnitt auf technischer Ebene?

Eine gute Faustregel ist, hier pro Team ein System zu bauen. So reduziert sich der Aufwand der Replikation auf wenige Systeme, die Systeme selbst werden nicht zu komplex und bieten für sich selbst, quasi unabhängig, einen Kundenvorteil. Es kann aber auch hilfreich sein, dieser Faustregel nicht strikt zu folgen, sondern über Methoden wie den taktischen Teil von Domain-driven Design (hier schließt sich ein Kreis) zu Bounded Contexts zu finden. Man könnte dann für jeden dieser Contexts ein eigenes System entwickeln. So oder so wären fachlich geschnittene Systeme als Macroservice oder Self-Contained-System zu bezeichnen [7]. Wo mehrere Systeme pro Team funktionieren, führt ein System, das von mehreren Teams entwickelt wird, zum absoluten Gegenteil von Verantwortung und sollte daher tunlichst vermieden werden.

Ein Beispiel dazu: Im Bereich "Fachlichkeit" haben wir die Schnitte Erkunden, Entscheiden und Erfüllen betrachtet. Nun könnten wir für jedes Team je ein System bauen. Oder wir stellen fest, dass Produktlisten und Produktdetailseiten für uns verschiedene Bounded Contexts sind. Dann würden wir in Erkunden zwei Systeme entwerfen und in Entscheiden und Erfüllen bei einem bleiben. Die Systeme könnten Finden und Informieren heißen und für sich selbst dem Kunden Mehrwert bieten. Beide teilen sich dieselben Basisdaten, nämlich Produkte, was nicht dramatisch ist. Wir machen eines der beiden zum Owner der Daten und das andere repliziert sich den Teil der Daten, den es benötigt.

Damit der angesprochene Kundenmehrwert erzeugt werden kann, muss so ein System natürlich aus mehr als nur Datenhaltung bestehen. Es bedarf auch eines Frontends und – nicht zu vergessen – das System muss auch irgendwo aktiv ausgeführt werden. Wir trennen hier also ähnlich wie bei der Fachlichkeit vertikal und nicht horizontal. Ein Self-Contained-System beinhaltet Frontend, Backend und Infrastruktur.

Abb. 3: Lose gekoppelte Self-Contained-Systems mit Frontend und Backend Integration. © Benedikt Stemmildt

Wie wir Daten lose austauschen, haben wir uns bereits angeschaut, aber wie funktioniert die lose Kopplung eines Frontends? Ist das nicht ein Widerspruch? Eine Single-Page-Applikation im klassischen Sinne, ohne weitere Strategien, führt sofort zu einer sehr, sehr harten Kopplung.

Was lose Kopplung im Frontend angeht, kann man auf eine Vielzahl an Möglichkeiten zurückgreifen, die wir hier alle gar nicht im Detail besprechen können. Michael Geers beschreibt in seinem Buch "Micro Frontends" Vor- und Nachteile sowie Strategien jeder der Möglichkeiten und bietet damit einen super Anknüpfungspunkt [8]. Auch Single-Page-Applikationen lassen sich, durch dort aufgeführte Methoden, wie z. B. Module-Federation, lose koppeln.

Hier möchte ich nur die klassischste Variante der Links und Server-Side-Includes erwähnen. Sprechen wir von einer Webapplikation, bieten Links einen wunderbaren Mechanismus, um zwei Systeme lose gekoppelt zu integrieren. Jedes System hat seine eigene URL, hinter einem Proxy vereint, auf eine Domain gemapped. So kann durch einen Link zwischen zwei Systemen gewechselt werden, ohne dass der Anwender dies merkt. Nur auf ein gemeinsames visuelles Design muss man sich verständigen.

Geht es darum, Teile einer Seite von einem anderen System zu beziehen, lässt sich der erwähnte Proxy um Server-Side-Includes erweitern und so durch ein Pseudo-HTML-Tag ein Template-Include aus einer anderen Quelle machen. Quasi wie ein Bild, nur dass eben kein Bild, sondern HTML zurückkommt und das Tag nicht im Browser, sondern vom Proxy aufgelöst wird. So kann sowohl das System der Seite als auch das System des Teilbereichs eigenständig dessen Frontend weiterentwickeln. Ebenso lässt sich eine solche Integration auch per AJAX im Browser lösen und an dieser Stelle möchte ich dann auf das Buch von Michael verweisen, weil wir sonst die Büchse der Pandora öffnen [8].

Es gibt noch diverse weitere Aspekte, die zu berücksichtigen sind, um die Unabhängigkeit zwischen den technischen Systemen nicht zu zerstören. Als besonders wichtig erachte ich noch das "Share-Nothing"-Prinzip, welches ich hier anreißen möchte.

Nicht nur synchrone HTTP-Schnittstellen sind eine harte Kopplung, sondern auch geteilte Dependencies, wie eine gesharete Library. Eine solche verursacht per se eine sehr harte Kopplung zwischen beiden Systemen und wirft die Frage auf: Wer ist für die Library verantwortlich? Und schon haben wir ein Problem.

Natürlich gibt es neben den erwähnten Web-Schnittstellen und Libraries noch weitere Arten solcher Kopplungen. Eine schöne Übersicht über diese bietet uns der strategische DDD-Teil, der mit Hilfe von Context Maps und deren Kopplungsarten Probleme aufzeigen oder vorweg verhindern kann.

Weitere Aspekte einer losen Architektur lassen sich bei den ISA-Principles nachlesen [9]. Und wir wollen jetzt zu einem weiteren Themenbereich kommen, der für unsere "Responsible Architecture" essenziell notwendig ist: Continuous Everything.

Nun haben wir die Unabhängigkeit über Makro-Architektur-Regeln sichergestellt und können etwas tiefer in den Mikro-Architektur-Bereich blicken. Die Makro-Architektur setzt den Rahmen, der es uns erst ermöglicht, auf der Mikro-Architektur-Ebene Geschwindigkeit zu erzeugen. Hier ist vor allem entscheidend, dass jedes Team von Continuous Everything Gebrauch macht. Das heißt, über CI/CD-Pipelines nicht nur Applikationen, sondern auch Infrastruktur und weitere Konfiguration zu deployen. Damit dies gelingt, empfiehlt sich eine ausgiebige Testautomatisierung und die Nutzung von Infrastruktur-Plattformen, wie Public Clouds und/oder Kubernetes, sowie Trunk Based Development. Mehr dazu ist im Buch "Accelerate: The Science of Lean Software and DevOps" sehr detailliert erörtert und sogar wissenschaftlich belegt [10]. Ein wirklich ausgesprochen spannendes Buch.

Es gilt die Regel, alles was mehrfach ausgeführt wird und einem festen Ablauf folgt, zu automatisieren. Das ist auf kurzen Zeitraum betrachtet aufwändig, zahlt sich aber schon schnell aus. Ich kenne ehrlich gesagt wenige Systeme, die nur über einen so kurzen Zeitraum entwickelt werden, dass sich Automatisierung nicht lohnt. Selbst beim Programmieren von Wegwerf-Prototypen während eines zweitägigen Hackathons zahlt sich der Aufwand einer rudimentären CI/CD-Pipeline schon vor dem ersten Mittagessen aus. Um sich in das Thema reinzudenken, empfehle ich als Anlaufstelle [11].

Fazit

Mit dem Werkzeugkasten der "Responsible Architecture" finden wir also unsere ganz eigene Architektur, die mit dem primären Gedanken an Verantwortung, durch Unabhängigkeit für Geschwindigkeit sorgt!

Um diese bestmögliche Architektur zu finden, sind diverse Bereiche zu beleuchten. Die Technik ist nur ein kleiner Teil, der sogar erst zuletzt betrachtet werden sollte. Architekten müssen ihre Rolle und vor allem ihren Horizont erweitern und Altgelerntes neu denken. Effizienz spielt eine immer geringerere Rolle als noch vor einigen Jahren und Unabhängigkeit der Teilbereiche wird immer entscheidender. Es reicht nicht aus, nur Technologien zu studieren, es ist auch notwendig, sich Wissen über fachliche und organisatorische Methoden anzueignen. Nur, wer alle Disziplinen kombiniert und nicht blind einem Konferenz-Hype folgt, wird am Ende eine Architektur finden, die Verantwortung, Geschwindigkeit, Effektivität, Spaß und damit unternehmerischen Erfolg hervorbringt.

Quellen