LLMs sind insbesondere dafür geeignet, Texte zu generieren. Ein wesentlicher Teil der Architekturarbeit scheint das Erstellen von Texten zu sein: Architekturdokumentationen oder -konzepte gehören dazu. Und auch Diagramme können aus textuellen Repräsentationen generiert werden. Das scheint also ein Bereich zu sein, den LLMs autonom abdecken können. Und tatsächlich kann man ein LLM dazu veranlassen, eine Architektur in diesem Sinne zu erzeugen.

Kann das, was dabei entsteht, aber eine sinnvolle Architektur sein? Um dieser Frage nachzugehen, ist ein Fall interessant [2], bei dem ein LLM ein vorhandenes System analysieren sollte. Ergebnis: Das LLM hat einige Aspekte korrekt wiedergegeben, aber die Information, dass das System Apache ActiveMQ und Apache Artemis nutzt, war schlicht falsch. ActiveMQ und Artemis sind zwei Messagingsysteme. Solche Technologien sind eigentlich nur sinnvoll, wenn das System asynchron kommunizieren soll. Damit liegt die Analyse auf technologischer Ebene daneben, und sie erzeugt auch einen falschen Eindruck von der Architektur, denn so würde man wahrscheinlich von einer asynchronen Architektur ausgehen. Zudem ist Artemis eine Art Nachfolger von ActiveMQ. Das macht die Analyse nahezu grotesk, weil sie behauptet, dass zwei sehr ähnliche Technologien genutzt werden, eine davon eine modernere Variante der anderen. So etwas wäre nur dann zu erklären, wenn von der einen zur anderen Technologie migriert wird.

Würde ein Mensch bei einem Architekturreview eine so fehlerhafte Analyse erstellen, würde man vermutlich dem Rest der Analyse ebenfalls keinen Glauben schenken und die Person nie wieder mit einer solchen Aufgabe beauftragen. Beim LLM waren die Reaktion deutlich anders, es überwog eher ein Erstaunen. Warum sind die Konsequenzen hier anders? Es liegt nahe, grundsätzlich infrage zu stellen, ob LLMs für solche Architekturaufgaben überhaupt geeignet sind.

Halluzinationen

In dem konkreten Beispiel hat das LLM also im Text eine Information – nämlich die Nutzung von Artemis und ActiveMQ – ausgegeben, obwohl diese Information in der Wissensbasis nicht vorhanden war. Der Fachbegriff für solche Fehler sind „Halluzinationen“. Es gibt sie auch in anderen Variationen. So gibt es ein Beispiel, bei dem ein LLM Code erzeugen sollte und im Rahmen eines Tests die Produktionsdatenbank gelöscht hat, obwohl das explizit verboten war. Hier hat das LLM also eine explizite und wichtige Anweisung missachtet.

Solche Halluzinationen bedeuten, dass LLMs Fake-Informationen produzieren und bei Aktionen, die sie auslösen, unzuverlässig sind. Wenn man Architekturarbeit vollständig an LLMs delegieren will, ohne sie anschließend manuell zu überprüfen, müssten solche Halluzinationen praktisch ausgeschlossen sein.

Zuverlässige LLMs?

Damit kommt den Halluzinationen eine entscheidende Bedeutung zu, wenn es um die Bewertung der Nutzbarkeit von LLMs für die Softwarearchitektur geht. Halluzinationen sind ein Phänomen, das beim Entwurf von LLMs bewusst in Kauf genommen wird. LLMs sollen in erster Linie gute Dialoge mit Menschen führen können. Dafür sind ansprechende und überzeugende Texte wichtig, die Korrektheit ist sekundär. Das ist bei der Kommunikation zwischen Menschen nicht sehr viel anders: Wenn man in einem Gespräch jede Aussage validieren würde, käme der Dialog zum Erliegen. Bei einem wissenschaftlichen Paper ist die Korrektheit hingegen sehr wichtig; dafür dauert das Erstellen auch viel länger als eine Antwort in einem Dialog, weil jede Aussage geprüft wird und durch einen Prozess wie eine Peer Review auch noch andere Menschen die Aussagen validieren.

Letztendlich sind LLMs reine Textgeneratoren. Sie haben kein Konzept einer Wahrheit oder von Fakten, sondern generieren nur Text. Aufgrund der Trainingsdaten haben die Texte eine gewisse Wahrscheinlichkeit, korrekt zu sein, wenn in den Trainingsdaten nur korrekte Texte enthalten sind. Aber logische Denkprozesse gibt es bei LLMs nicht.

DIE KUNST DER SOTWARE-ARCHITEKTUR

Architecture & Design-Track entdecken

Mehr erfahren

Man kann die Ergebnisse von LLMs nicht als Lügen klassifizieren. Lügen würden bedeuten, dass das LLM ein Konzept von Wahrheit hat und bewusst Texte erstellt, die dieser Wahrheit widersprechen. LLMs haben aber ein solches Konzept von Wahrheit nicht. Noch dazu sollte eine Lüge einer Absicht folgen. Wenn man beispielsweise behauptet, man hätte viel mehr Geld als man tatsächlich hat, stellt man eine Behauptung auf, die der Wahrheit widerspricht. Typischerweise verfolgt man damit ein Ziel, beispielsweise einen Menschen zu beeindrucken. Wegen dieser beiden Umstände ist es eine Lüge.

Anders ist es bei Bullshit: Da trifft man Aussagen ohne Rücksicht auf den Wahrheitsgehalt. Wer bei einer Prüfung beispielsweise den Stoff nicht beherrscht, kann irgendwelche Aussagen treffen. Ob sie wahr sind oder nicht, muss einem egal sein, weil man den Stoff nicht beherrscht. Entscheidend ist, die Prüfung zu bestehen, und wenn man ausreichend kompetent wirkt und keinen zu offensichtlichen Unsinn erzählt, kann das vielleicht gut gehen.
LLMs produzieren in diesem Sinne Bullshit, weil sie manchmal Fake-Informationen (Halluzinationen) produzieren, aber weder ein Konzept von Wahrheit haben noch eine Intention und daher nicht lügen [5]. Die Wahrheit ist ihnen noch nicht einmal egal, weil sie kein Bewusstsein haben, dass solche Entscheidungen treffen könnte, und keine Wissensbasis mit einer Wahrheit.

Damit ist sehr gut zu erklären, wie die ActiveMQ/Artemis-Fehlinformation zustande gekommen ist: Es ist schlicht ein generierter Text, der plausibel klingt, aber ohne Rücksicht auf Wahrheit erzeugt wurde.

Kritisch hinterfragen

Also muss man die Ergebnisse eines LLMs kritisch hinterfragen. Dann trifft man aber selbst die Architekturentscheidungen und nicht das LLM. Das ist auch sinnvoll, denn am Ende wird man wohl kaum die Verantwortung für ein Architekturproblem auf ein LLM abschieben können. Und selbst wenn das geht: Es ist auf jeden Fall besser, die Probleme frühzeitig zu erkennen und zu lösen.

Leider hat unsere Branche aber beim kritischen Hinterfragen und dem Treffen eigener Entscheidungen oft Schwächen. Deshalb ist es nicht ungewöhnlich, dass eine Architektur so entworfen wird, „weil man das eben heute so macht“ oder „weil das eine bekannte Person auf einer Konferenz so erläutert hat“. Natürlich ist es denkbar, dass sich in Zukunft die Begründung „weil das LLM es so entschieden hat“ dazu gesellt. Es ist sogar praktisch, weil man so Verantwortung abschieben kann. Dennoch sollten Softwarearchitekt:innen anders arbeiten und selbst Verantwortung übernehmen.

Text ist nicht Architektur

Wichtig dabei: Das LLM generiert genau genommen nur einen Text und keine Architektur. Das wirkt zunächst wie Haarspalterei. Aber tatsächlich kann man eine umfangreiche Architekturdokumentation schreiben, die alle möglichen Dinge erläutert, aber eben nicht die Hauptrisiken und die wichtigsten Entscheidungen definiert. Wenn man eine große Menge Text erzeugt, kann das sogar eher dazu führen, dass wichtige Entscheidungen irgendwo in dieser Textwüste begraben sind. Aber attraktiv ist es dennoch: Schließlich werden ja irgendwo in dieser Textmenge sicher alle Probleme diskutiert und gelöst sein.

Die Realität ist jedoch, dass solche umfangreichen Architekturdokumentationen existieren, die dennoch nichts über die wesentlichen Probleme aussagen, und erst bei einer Review – idealerweise mit einem unverstellten Blick von außen – fällt das auf. Das passt zum Phänomen des „Architekturtheaters“ [9], bei dem ein komplexer, bürokratischer Architekturprozess aufgesetzt wird, der am Ende aber die eigentlichen Herausforderungen und Themen nicht identifiziert. Insofern ist es nachvollziehbar, dass das Generieren von Text, wie es LLMs ermöglichen, wie Architekturarbeit wirkt. Sicher kann mit einem LLM das Generieren einer Architekturdokumentation als Scheinlösung umgesetzt werden – und sie kann sehr umfangreich sein und sehr überzeugend wirken. Eine sinnvolle Architektur stellt der Text dennoch nicht dar.

Worauf kommt es an?

Hilft ein solcher Text dann überhaupt? Wenn man Menschen danach fragt, was der wichtigste Skill in der IT ist, kommt mit einer überwältigenden Mehrheit als Antwort „Kommunikation“ oder etwas anderes im Bereich Social Skills [9]. Ähnliches gilt bei der Frage nach der Hauptherausforderung im Bereich Softwarearchitektur [1]. Auch dort geben Menschen typischerweise Themen wie Kommunikation, Organisation oder das Vermitteln zwischen Business und Technik an.

Aus diesen Gründen ist es so sinnvoll, Softwareentwicklung als soziotechnischen Prozess zu begreifen – also als einen Prozess, der sowohl eine technische Seite als auch eine soziale Seite hat. Dieser Ansatz hat sich gerade in letzter Zeit als vorteilhaft für Architekturarbeit gezeigt und stand auch wiederholt im Zentrum dieser Kolumne. Ansätze wie kollaborative Modellierung beispielsweise mit Event Storming unterstützen die notwendige Kollaboration beim Erstellen der Artefakte, haben also eine soziale Komponente. Nicht nur die Artefakte selbst, sondern auch der soziale Prozess, mit dem diese erstellt werden, wird zunehmend als wichtig erkannt, weil dabei Rollen und Zusammenspiel der Menschen deutlich wird. Und in diesem Bereich existieren oft die größten Herausforderungen.

Es wirkt wenig wahrscheinlich, dass man soziotechnische Probleme wie Softwarearchitektur dadurch lösen kann, dass man mit einem LLM allein vor dem Rechner einen Text erzeugt. In der Praxis besteht eine wichtige Aufgabe von Architekt:innen darin, mit Stakeholdern über Ziele, Ausrichtung und Randbedingungen zu diskutieren und technische Entwürfe mit Techniker:innen zu besprechen. Ein Projekt kann nur erfolgreich sein, wenn alle Stakeholder abgeholt sind und sich abgeholt fühlen. Und schließlich sind die Anforderungen bzw. Qualitäten zentral – egal ob funktional oder nichtfunktional. Wenn man diese Rahmenbedingungen nicht geklärt hat, baut man schlichtweg das Falsche. Die Techniker:innen müssen ebenfalls überzeugt sein, weil sie sonst die Entwürfe unterlaufen, und durch die Diskussion mit ihnen ergeben sich oft noch bessere technische Alternativen.

Wie also LLMs nutzen?

Aber man kann natürlich ein LLM Architekturentwürfe generieren lassen – wenn man es ethisch verantworten kann. LLMs sind schließlich sehr energieintensiv und Menschen müssen sie unter fragwürdigen Arbeitsbedingungen trainieren. Und die Entwürfe müssen kritisch hinterfragt und abgestimmt werden. Ob dadurch die Architekturarbeit einfacher wird, ist fraglich: Denn am Ende muss man einen Architekturentwurf kritisch prüfen und abstimmen, der ohne ein Konzept von Wahrheit entstanden ist und dazu noch überzeugend präsentiert wird.

Natürlich ist es denkbar, mit einem LLM statt einer ganzen Architekturdokumentation Texte zu bestimmten technischen Fragestellungen oder zu einzelnen architekturellen Entscheidungen zu generieren – so wie man sonst auch im Web nach solchen Informationen sucht. Man bekommt dann auf der einen Seite maßgeschneiderte Aussagen, die aber auf der anderen Seite Fake-Informationen bzw. Halluzinationen sein können. Oft ist dieser Ansatz aber tatsächlich der schnellere und einfachere Weg zum Ergebnis.

Am Ende liegen aber Verantwortung und Entscheidungsgewalt bei beiden Vorgehensweisen bei der Architekt:in. Das kritische Hinterfragen und Einarbeiten der Ergebnisse des LLMs ist ihre Aufgabe. Sie ist dann auch verantwortlich und nicht das LLM – so wie eben der Autor einer Webseite oder eines Buchs auch nicht dafür verantwortlich sein kann, was mit seinen generellen Aussagen in einem spezifischen Projekt geschieht.

Damit sind LLMs ein weiteres Werkzeug im Architekturwerkzeugkoffer. Der ist mit einer Vielzahl anderer Werkzeuge gefüllt – dazu zählen kollaborative Modellierung, Domain-driven Design und Architekturdokumentationsansätze wie arc42. Es erscheint unwahrscheinlich, dass LLMs die Produktivität von Architekt:innen massiv erhöhen oder sie überflüssig machen, wie das andere Werkzeuge auch nicht geschafft haben. Aber es gibt wahrscheinlich Einsatzmöglichkeiten wie für alle anderen Werkzeuge auch.

Fazit

Es ist zunächst wichtig zu verstehen, dass die Ergebnisse von LLMs prinzipienbedingt unzuverlässig sind, weil sie Halluzinationen bzw. Fake-Informationen erzeugen können. Daher muss man die Ergebnisse von LLMs immer kritisch hinterfragen – auch und gerade, weil sie so überzeugend sind. Und LLMs lösen nicht das zentrale Problem der Softwareentwicklung, das vor allem im Bereich Kommunikation und sozialen Faktoren liegt. Dass das die wesentlichen Probleme sind, ist der breiten Mehrheit klar [1],[10]. Warum dann LLMs massive Vorteile bringen sollen, bleibt offen – aber sie sind sicher ein interessantes Werkzeug, das man prinzipiell auch in der Softwarearchitektur einsetzen kann, wenn man es ethisch vertreten kann.

Links & Literatur

[1] Softwarearchitektur im Stream: „Was ist die Hauptherausforderung der Software-Architektur?“: https://software-architektur.tv/2025/06/27/folge269.html

[2] Mahler, Dirk: https://www.linkedin.com/posts/dirk-mahler-837a4b5_ai-neo4j-claude-activity-7321596753223340033-xz4r

[3] https://x.com/jasonlk/status/1946065483653910889

[4] https://arxiv.org/html/2202.03629v7

[5] Softwarearchitektur im Stream: „KI = Bullshit“: https://software-architektur.tv/2025/04/11/episode260.html

[6] https://winfuture.de/news,150778.html

[7] https://www.nature.com/articles/s41562-025-02194-6

[8] Softwarearchitektur im Stream: „Besteht ChatGPT die iSAQB-Advanced-Level-Prüfung? 2/2 mit Ralf D. Müller“: https://software-architektur.tv/2024/01/19/folge197.html

[9] https://mastodon.social/@kevlin/112003129757159797

[10] Softwarearchitektur im Stream: „Was ist der wichtigste Skill in der IT?“: https://software-architektur.tv/2024/08/16/episode228.html

The post LLMs in der Softwarearchitektur: Werkzeug statt Ersatz appeared first on JAX.

Aber was ist  Softwarearchitektur überhaupt? Man kann über dieses Thema lange und ausführlich diskutieren [1]. Tatsächlich gibt es zahlreiche unterschiedliche Definitionen von Softwarearchitektur. Für diesen Artikel soll die Definition gelten: „Architektur umfasst die wichtigen Dinge, was auch immer das sein mag.“ [2]. Damit ist klar, dass es Architektur geben muss. Schließlich gibt es immer irgendwelche wichtigen Dinge. In gewisser Weise ist diese Definition chauvinistisch, weil sie einfach definiert, dass Architektur wichtig ist und alles andere unwichtig.

Qualitäten

Aber was ist wichtig? Bei Software gibt es eine Vielzahl von möglichen, nichtfunktionalen Anforderungen bzw. Qualitäten. Bei einem Importer könnte beispielsweise die Performance wichtig sein, damit die Daten schnell genug in das neue System gelangen. Ein weiterer wichtiger Aspekt könnte die funktionale Korrektheit sein: Arbeitet der Importer tatsächlich richtig und importiert die Daten fachlich korrekt? Oft spielt die Benutzerfreundlichkeit eine Rolle: Wenn eine Anwendung besonders gut nutzbar ist, kann man besonders produktiv mit ihr sein. Produktivität ist oft ein Grund für das Schreiben von Software und Benutzerfreundlichkeit ein wichtiges Qualitätsziel. Software kann gegebenenfalls dank Benutzerfreundlichkeit einen hohen Marktanteil erreichen, weil Benutzer:innen sie gerne verwenden und anderen Lösungen vorziehen. Auch dann ist es ein wichtiges Qualitätsziel, den Marktanteil auszubauen.

Beim Neuschreiben des Importers liegt der Verdacht nahe, dass die alte Software irgendwelche Qualitäten so schlecht erfüllt, dass die Software neu geschrieben werden muss und daher sozusagen ein Totalverlust ist. Dabei können unterschiedliche Qualitäten ausschlaggebend sein: Der Importer kann beispielsweise viel zu langsam sein und mit den aktuellen Datenmengen nicht mehr mitkommen. Dann haben sich die Qualitätsanforderungen geändert und die Software muss diesen Anforderungen genügen. Ein Neuschreiben ist dann sinnvoll, wenn dieses Qualitätsziel mit einer Änderung des vorhandenen Codes nicht mehr möglich ist.

Oft ist der Grund für das Neuschreiben eine spezifische Qualität, nämlich die Wartbarkeit. Wenn der Code sehr schlecht verständlich ist und eine Anpassung kaum noch möglich erscheint, ist ein Neuschreiben vielleicht die einzige Möglichkeit, in Zukunft wieder Änderungen am System vorzunehmen. Auch die Performance kann möglicherweise nur durch Neuschreiben verbessert werden, weil die dafür notwendigen Änderungen sonst zu schwer umsetzbar sind.

Im konkreten Fall ist es also wahrscheinlich, dass der Import deswegen neu geschrieben wird, weil die Qualität des vorhandenen Importers nicht ausreicht. Dann ist aber die Architekturarbeit an der Qualität sehr wichtig: Es wäre mehr als peinlich, wenn man den Importer neu schreibt und danach die Probleme, die Auslöser für das Neuschreiben waren, gar nicht gelöst sind. Und ein Kernpunkt von Architektur sind eben die Antworten auf Fragen wie: Was ist das Ziel des Projekts, welche Qualitäten sind dafür notwendig und welche Maßnahmen sind erforderlich, um das Ziel und die notwendigen Qualitäten zu erreichen?

Diese Betrachtungen müssen auch bei diesem recht einfachen Projekt stattfinden. Vielleicht ist diese Abwägung nicht explizit, sondern implizit: Die neue Version wird mit einer anderen Programmiersprache oder einem anderen Algorithmus umgesetzt, damit die Performance gut genug ist. Oder die Struktur des Codes wird gemanagt und Metriken wie die Länge von Methoden oder Klassen werden erhoben, damit die neue Codebasis wartbar ist. Solche Punkte explizit aufzuschreiben, hilft dabei, die Probleme und die Lösungsstrategien zu durchdenken und Alternativen gegeneinander abzuwägen. So oder so sind die Qualitäten der Treiber für die Architektur (Abb. 1). Ein solches Vorgehen, bei dem die Qualitäten der Software die Basis für die Architektur bilden, kann man sich anhand von zwei Beispielen in Videos anschauen [3], [4].

Abb. 1: Qualitäten treiben die Architektur

Manchmal sind die Qualitäten nicht nur durch die reine Entwicklungsarbeit erreichbar: Eine gute Performance kann man auch durch bessere Hardware erreichen. Auch Ausfallsicherheit hängt neben der Software von der Hardware und Infrastruktur ab. Benutzerfreundlichkeit kann man typischerweise sogar gar nicht durch technische Maßnahmen, sondern nur durch Techniken aus dem Bereich User Experience (UX) erreichen. Dennoch muss jemand diese Aspekte betrachten, weil das Projekt sonst ein Fehlschlag werden kann.

Qualitätsszenarien

Um in komplexen Systemen solche Qualitätsanforderungen zu konkretisieren, haben sich Qualitätsszenarien bewährt [5]. Sie erlauben es, konkrete Anforderungen so aufzuschreiben, dass man später verifizieren kann, ob sie tatsächlich erfüllt sind. Zu oft sind die notwendigen Qualitäten nicht konkret genug erfasst: Wann ist ein System „schnell“ oder „benutzerfreundlich“? Auch eine Angabe wie „99,999 Prozent Verfügbarkeit“ reicht nicht. Was, wenn das System nur einmal pro Jahr für 50 Minuten ausfällt, aber dann in den entscheidenden 50 Minuten, in denen der höchste Umsatz realisiert wird? Das System erreicht zwar die geforderten 99,999 Prozent Verfügbarkeit aufs Jahr, aber das kann dennoch nicht ausreichend sein. Helfen kann ein Qualitätsszenario wie „Wenn das System zwischen 9 und 18 Uhr ausfällt, muss es nach zehn Minuten wieder zur Verfügung stehen.“ Diese Aussage ist viel konkreter als eine abstrakte Verfügbarkeit und trifft die technischen Anforderungen besser. Nun ist nämlich klar, dass das System zu bestimmten Zeiten nicht lange ausfallen darf, was bei einer allgemeinen Betrachtung der Verfügbarkeit vielleicht nicht offensichtlich geworden wäre und  zu einer unzureichenden Lösung geführt hätte.

Muss das sein?

Mindestens das Thema Qualitäten lässt sich nicht umgehen: Die entwickelte Software wird bestimmte technische Qualitäten haben wie Wartbarkeit, Performance oder Korrektheit. Man hat also nur die Wahl, sich aktiv um diese Qualitäten zu kümmern, sie genau zu verstehen, Prioritäten zu setzen und Lösungsmöglichkeiten zu identifizieren, oder das System wird zufällig irgendwelche Qualitäten haben. Es ist vermutlich deutlich besser, die Qualitäten zu steuern.

Den Prioritäten kommt dabei eine besondere Bedeutung zu: Man muss verstehen, wo welche Qualitäten gefordert sind und dafür eine passende Lösung entwickeln. Erfüllt man die notwendigen Qualitäten nicht, ist das Projekt offensichtlich ein Fehlschlag. Übererfüllt man die Qualitäten, erreicht man ein weiteres wichtiges Ziel nicht, nämlich eine möglichst wirtschaftliche Lösung. Es geht also gerade nicht darum, die in jeder Hinsicht perfekte Lösung zu bauen, sondern vielmehr die Lösung zu bauen, die das Problem löst und dabei auch möglichst kostengünstig ist.

Natürlich steht es jedem frei, diese Betrachtungen nicht anzustellen. Das ist aber kaum empfehlenswert – und meistens wird es zumindest eine oberflächliche Betrachtung geben. Und selbst wenn man diese Betrachtung nicht anstellt: Dann trifft man auch Entscheidungen, die Qualitäten beeinflussen – nur mit einer weniger guten Planung. Software hat immer Eigenschaften wie Performance, Korrektheit oder Wartbarkeit, auch wenn man sie nicht aktiv gestaltet, und diese Eigenschaften sind ein Ergebnis von technischen Entscheidungen.

Also kann man sich nicht aus der Architekturarbeit verabschieden: Das System wird irgendeine Architektur haben. Dafür ist es egal, ob man an der Architektur arbeitet oder nicht.

Architektur = Struktur?

Damit ist die Architektur also in erster Linie ein Ansatz, mit dem Qualitäten umgesetzt werden. Performance kann man durch die Auswahl geeigneter Technologien beeinflussen. Bei Korrektheit ist die Lösung eher im Bereich Tests zu suchen.

Viele verstehen unter Architektur aber nur die Struktur der Software, wie also der Source Code organisiert wird. Dazu zählt die Aufteilung in Klassen, Packages, Microservices, Source-Code-Projekte usw. – also die gesamte logische Organisation des Codes. Er wird typischerweise nach fachlichen Aspekten wie Bounded Contexts oder technischen Aspekten wie Schichten organisiert.

Die Struktur der Software hat aber nur begrenzten Einfluss auf die Qualitäten: Lediglich die Qualität „Wartbarkeit“ wird durch die Struktur der Software beeinflusst. Aber auch Wartbarkeit hängt von anderen Faktoren ab. Beispielsweise kann man Software mit vielen Tests besonders einfach warten. Bei dieser Auffassung von Architekturarbeit kommt der Struktur der Software also  keine so große Bedeutung zu, denn sie beeinflusst nur wenige Qualitätskriterien.

Das steht im Widerspruch zu der weitverbreiteten Annahme, dass die Struktur der Software im Wesentlichen die Architektur darstellt. Vielleicht kommt diese Wahrnehmung dadurch zustande, dass die Struktur der Software die Wartbarkeit und damit auch die Wirtschaftlichkeit entscheidend beeinflusst. Sie kann sogar den Aufwand beim initialen Erstellen der Software beeinflussen, nicht erst den Aufwand bei der Wartung. Wirtschaftlichkeit ist typischerweise eines der wichtigsten Ziele in der Entwicklung. Also treiben Wartbarkeit und Wirtschaftlichkeit den Fokus auf die Struktur der Software (Abb. 2).

Abb. 2: Wartbarkeit und Wirtschaftlichkeit bei der Entwicklung sind Gründe, sich auf die Struktur der Software zu fokussieren

Ein weiterer Grund für diese Gleichsetzung von Architektur mit der Struktur der Software ist, dass Architektur im Bauwesen eben auch für die Strukturen steht. In der Realität würde ein Fokus auf die Struktur als alleinige Eigenschaft der Architektur dazu führen, dass die Qualitäten jenseits der Wartbarkeit vernachlässigt werden. Das kann recht leicht zu einem Architekturfehlschlag führen.

Architektur skalieren

Bisher haben wir einen sehr einfachen Fall betrachtet: Den Importer schreibt nur eine Person und die Entwicklung dauert nicht sonderlich lange. Typischerweise arbeitet aber ein Team an einer Software. Damit ist eine Kommunikation der Architektur und eine gemeinsame Arbeit an der Architektur unumgänglich. Dabei geht es um die Koordination der Techniker:innen, deren Ideen in die Architektur einfließen sollen, und um die verschiedenen Stakeholder, die Erwartungen an die Software haben und damit eine Quelle von Qualitätsanforderungen sind.

Dementsprechend muss die Architektur dokumentiert und kommuniziert werden. Wenn das Projekt groß und komplex genug ist, kann das eine Vollzeitaufgabe sein. Dann gibt es die Möglichkeit, dass sich eine Person Vollzeit um das Thema Architektur kümmert und nicht an der Codeentwicklung selbst teilnimmt. Eine andere Möglichkeit ist, dass die Architekt:innen als „Coding Architects“ an der Entwicklung teilnehmen. Dann müssen sich aber mehrere Architekt:innen die Architekturarbeit aufteilen, wenn die reine Architekturarbeit tatsächlich ein Vollzeitjob ist und sie noch Zeit für Coding haben wollen. Die Architekt:innen müssen untereinander kommunizieren und sich koordinieren, was zu mehr Kommunikation und Koordination führt.

Coding Architects haben oft einen besseren Ruf, weil sie durch die Arbeit am Code wissen, was im Projekt geschieht und daher nicht von der Realität entkoppelt im Architekturelfenbeinturm enden können. Allerdings sollten auch Vollzeitarchitekt:innen, wenn sie kommunikationsstark sind, genügend Informationen über die Situation im Projekt haben. Sie sollten dann eine moderierende Rolle einnehmen und die anderen am Projekt Beteiligten als Expert:innen für die jeweiligen Bereiche wahrnehmen. Eine Person, die sich beispielsweise mit dem Frontend eines Systems beschäftigt, ist vermutlich qualifizierter, Entscheidungen über diesen Bereich zu treffen, als eine Person, die sich allgemein um die Architektur kümmert und in diesem Bereich keine Tiefe hat. Die Meinung der Frontend-Expert:in muss mindestens in die Entscheidung einfließen und wird sie vermutlich entscheidend beeinflussen. Dementsprechend müssen Vollzeitarchitekt:innen meistens Abstand davon nehmen, eine Entscheidungen alleine zu treffen. Es geht in dieser Rolle um Kommunikation und Koordination. Deswegen ist es nicht so einfach, die Rolle „Softwarearchitekt:in“ zu verstehen und gut auszufüllen [6], [7].

Manche Architekturentscheidungen werden auch gar nicht explizit getroffen. Entwickler:innen schreiben Code und treffen dabei immer wieder Entscheidungen, die die Struktur des Systems beeinflussen. Schließlich wird erst dann entschieden, wie der Code in Packages oder Microservices strukturiert ist, wenn er geschrieben wird. Ebenso wählen Entwickler:innen gegebenenfalls bestimmte Technologien aus und nehmen so Einfluss auf die technischen Eigenschaften des Systems, die wiederum die Qualitäten beeinflussen. Also treffen auch sie Architekturentscheidungen. All diese Entscheidungen zu kontrollieren, wäre zu zeitaufwendig, sodass auch Entwickler:innen manchmal die Rolle „Softwarearchitekt:in“ spielen. Damit diese Entscheidungen nicht konträr zu anderen Entscheidungen stehen, ist wieder Kommunikation und Koordination notwendig.

Zu viel oder zu wenig?

Man kann noch die Frage stellen, ob es zu wenig oder zu viel Architektur geben kann. Wenn man zu wenig Aufwand in die Architektur steckt, besteht die Gefahr, dass man die technischen Ziele nicht erreicht, weil man sie entweder nicht versteht oder sich keine Lösungen für die Erreichung überlegt hat. Ebenso kann es gut sein, dass die Struktur und der Rest der Architektur nicht ausreichend kommuniziert wird. Das kann dann dazu führen, dass die Architekturkonzepte nicht durchgehalten werden und das Softwaresystem im Chaos endet, also technische Konzepte nicht umgesetzt werden oder die Strukturierung des Systems von dem eigentlich geplanten Design signifikant abweicht.

Zu viel Architektur erscheint zunächst kaum möglich, aber man kann zu viel Aufwand für Architektur treiben, ohne dabei ausreichende Ergebnisse zu erzielen. Beispiel ist eine übermäßige Bürokratie für Entscheidungen. Ebenso können frühzeitige Entscheidungen eingefordert werden, statt Entscheidungen so spät wie möglich zu treffen. Das führt zu theoretischen Diskussionen, weil über Probleme in der ferneren Zukunft gesprochen wird. Zu einem späteren Zeitpunkt stehen mehr und bessere Informationen zur Verfügung, weil man mit der Zeit mehr über die jeweiligen Probleme lernt und sie dann besser lösen kann.

In der Praxis kommt beides vor, zu wenig und zu viel Architektur, sodass man hier keine generellen Hinweise geben kann, wie man typischerweise vorgehen soll (Abb. 3).

Abb. 3: Es kann zu wenig oder zu viel Softwarearchitektur geben – oder gar ein Architekturtheater

Architekturtheater?

Kevlin Henney hat den Begriff Architekturtheater geprägt [8]: Ein schwergewichtiger, komplizierter Prozess mit viel Bürokratie und Hierarchie, bei dem aber am Ende keine sinnvollen Entscheidungen getroffen werden. Hier ist  ein Zuviel an Prozess mit einem Zuwenig an Ergebnis kombiniert – es ist  gleichzeitig zu viel und zu wenig Architektur. „Architekturtheater“ beschreibt gut, was vor sich geht: Es wird vorgespielt, dass man sich intensiv um Architektur kümmert, aber weil der Prozess so schwerfällig ist und auch im Sinne des Elfenbeinturms keine echte Beziehung zur Realität hat, findet in Wirklichkeit keine effektive Architekturarbeit statt.

Fazit

Es gibt also in einem Softwaresystem immer eine Architektur. Sie umfasst neben der Struktur der Software auch die technischen Lösungen für die spezifischen Herausforderungen. Man kann die Architektur nur aktiv gestalten oder die Gestaltung dem Zufall überlassen. Dementsprechend gibt es irgendwelche Personen, die an der Architektur arbeiten. Die können sich entweder Vollzeit mit der Architektur beschäftigen oder es können mehr Menschen sein, die dann nur einen Teil ihrer Zeit mit Softwarearchitektur verbringen.Mit dem Thema des Artikels hat sich auch eine Episode von „Software Architektur im Stream“ beschäftigt [9].

Links & Literatur

[1] Software Architektur im Stream: „Was ist Softwarearchitektur überhaupt?“: https://software-architektur.tv/2022/02/11/folge109.html

[2] https://martinfowler.com/architecture

[3] Software Architektur im Stream, Folgen zu „Wir bauen eine Software-Architektur“: https://software-architektur.tv/tags.html#Wir%20bauen%20eine%20Software-Architektur

[4] Software Architektur im Stream, Folgen zur iSAQB-Beispiel-Aufgabe: https://software-architektur.tv/tags.html#iSAQB%20Advanced%20Beispielaufgabe

[5] Software Architektur im Stream: „Qualitätsszenarien“: https://software-architektur.tv/2021/07/16/folge67.html

[6] „Die Rolle ‚Software-Architekt:in‘ – Folge 1“: https://software-architektur.tv/2022/07/07/folge126.html

[7] „Die Rolle ‚Software-Architekt:in‘ – Folge 2“: https://software-architektur.tv/2022/07/15/folge127.html

[8] https://mastodon.social/@kevlin/112003129757159797

[9] „Softwarearchitektur – Muss das sein?“: https://software-architektur.tv/2024/03/08/folge206.html

The post Softwarearchitektur: Muss das sein? appeared first on JAX.

Redaktion: Domain-driven, DevOps und Unternehmensarchitektur – das sind die drei Schlüsselworte deines Talks auf der JAX 2020. Welchen Zusammenhang gibt es aus deiner Sicht zwischen den drei Disziplinen ?

DDD und Unternehmens- architektur zeigen erst dann ihren Effekt, wenn die IT-Organisation tatsächlich etwas Nützliches an IT-Anwender abliefert.

Bernd Rederlechner: In größeren Unternehmen gibt es klassischerweise Unternehmensarchitekten, die sich als Brücke zwischen IT und Business sehen. Doch meiner Erfahrung nach fokussieren sie stark auf Standardisierung und die Auswahl von Produkten – um Einsparungen mittels eigener Plattformen und Veränderung von Infrastruktur zu erzielen.

Wegen dem fehlenden Bezug zur Software-Entwicklung hat das wohl zu einer Wahrnehmung als “Elfenbeinturm-Architekten” geführt. Wenn diese nun die strategischen Aspekte von DDD anwenden, verschiebt sich ihr Fokus hin zu den logischen, wertliefernden Strukturen der IT. Plötzlich geht es darum, mittels sinnvoller Leitlinien wie Upstream-Downstream blockierte Teams arbeitsfähig zu machen.

Umgekehrt sollte man nicht unterschätzen, dass Unternehmensarchitekten viel näher am Geschäft dran sind als IT-Techniker oder sogar Fachseiten. Sie haben Methoden wie “Capability Mapping” oder “Managed Evolution”, die DDD gut um Geschäftsaspekte ergänzen.

DDD und Unternehmensarchitektur zeigen aber erst dann ihren Effekt, wenn die IT-Organisation tatsächlich etwas Nützliches an IT-Anwender abliefert. Was nutzen die schönsten Architekturen, wenn sie erst in ferner Zukunft geerdet werden? Deshalb benötigen alle, die etwas mit IT erreichen wollen, mehr als nur Halbwissen darüber, wie man Umbauarbeiten an einer Unternehmenslandschaft so aufteilt, dass sie früh und trotzdem qualitativ hochwertig in Produktion gehen.

Taktisches DDD liefert da sicher einen kleinen Beitrag, aber DevOps bietet viel mehr. DevOps erzwingt schnelle Feedback-Zyklen und fügt der Mischung den nötigen, frühen Schuss Realität hinzu, um eine effektive Produkt- bzw. Systemlandschaft für den Unternehmenserfolg zu bauen.

Redaktion: Und was hat DevOps mit Bounded Contexts zu tun?

Bernd Rederlechner: Conways Gesetz. Klingt komisch, ergibt aber schon Sinn: Conways Gesetz sagt, dass (Unternehmens-)Software nahezu unweigerlich die Kommunikationsstrukturen der Organisation widerspiegelt.

Aus dieser Erkenntnis ist im DevOps das “umgekehrte Conway-Manöver” entstanden: Man organisiert die Teams anhand der gewählten Architektur, damit Kommunikationspfade und gewählte Systemstrukturen zusammenpassen. Ziel hierbei ist, dass die entstehenden Teams so unabhängig wie möglich von anderen Parteien agieren und unabhängige (Micro-)Services liefern können.

Aber wie sieht eine zu diesem Vorgehen passende Architektur aus? Sicherlich kein Wald von Miniatur-Services, die sich wild gegenseitig aufrufen. Da fehlt die Entkopplung.

Bounded Contexts machen deshalb den Unterschied: Sie grenzen Bereiche mit einer unterschiedlichen Sicht auf die Geschäftswelt gegeneinander ab. Innerhalb des Kontexts arbeiten alle mit einem gemeinsamen Modell, also einem gemeinsamen Verständnis von der Realität: Ein Team, dass sich mit dem Erzeugen von Rechnungen beschäftigt grenzt sich beispielsweise durch seine Weltsicht von einem Team ab, das Online-Werbung produziert. Die Vereinigung vieler solcher schnell liefernder Teams mit ihren getrennten Kontexten ist die Basis für eine hochperformante Lieferorganisation nach DevOps.

Das wirkt so stark vereinfacht wie aus einem Werbeprospekt für Manager. Im Vortrag wird es unterhaltsamer und konkreter – versprochen.

Software-Architekten als Wertbeiträger

Redaktion: IT-Architektur ist allgemein ein breit gefächertes Gebiet – ebenso unterschiedlich ist das Rollenverständnis unter IT-Architekten. Worin siehst du persönlich in deiner Position als IT-Architekt deine Hauptaufgabe? Was ist dir besonders wichtig?

Für mich hat immer dazugehört, möglichst gute IT-Strukturen dem Chaos entgegenzustellen.

Bernd Rederlechner: Tatsächlich hatte ich das Glück (oder Pech?), in allen drei Bereichen arbeiten zu dürfen. Dabei hat für mich immer dazugehört, möglichst gute IT-Strukturen dem Chaos entgegenzustellen und technische Schulden als Zukunftshypothek wo immer möglich zu vermeiden. Die Welt rundherum erwartet das implizit von einem. Man kann damit sicher seine gesamte Zeit verbringen und sich von den realen Liefer-, Produktions- und Kundenherausforderungen fernhalten.

Aber irgendwann wird der IT-Architekt feststellen, dass er so als “Verkomplizierer” von den Geschäftsbereichen wahrgenommen wird, nicht als “Wertbeiträger”. Respekt auf Geschäftsebene gewinnt der, der mit den Methoden z.B. aus DDD, DevOps oder Unternehmensarchitektur Lieferblockaden auflöst und dafür sorgt, dass Verbesserungen durch IT auch tatsächlich wirksam werden.

Mit kleinen Erfolgen und einem guten persönlichen Image ergibt sich oft irgendwann die Möglichkeit, die neuen Methoden weiter ins Unternehmen zu tragen. Zumindest bleibt aber immer die Befriedigung, jemandem tatsächlich mittels Architektur geholfen zu haben.

Redaktion: Welchen Architektur-Trend findest du momentan besonders spannend?

Bernd Rederlechner: Ich feiere natürlich das Revival von DDD. Vor allem zwei Bereiche haben meine besondere Aufmerksamkeit: Zum einem sehe ich die Rückkehr von Modellen, die sowohl Entwickler als auch Nicht-ITler lesen können. Mit graphischen Notationen sind wir da ja schon mal grandios gescheitert. Die Idee, den Code zum gemeinsamen Modell für IT und Business zu machen, halte ich für pragmatisch und vielversprechend – wenn die Entwickler mitmachen…

Zum anderen wird Event Sourcing die Architektur von großen Anwendungen und Unternehmenslandschaften fundamental verändern. Beim Event Sourcing veröffentlicht ein Bounded Context geschäftliche Ereignisse für die Nutzug durch die Allgemeinheit. Das fördert nicht nur eine Kultur der Offenheit und des Teilens in Organisationen und sorgt für Entkopplung. Konsequent zu Ende gedacht stehen Streaming Event-Architekturen: Statt nur den aktuellen Zustand z.B. eines Vertrags oder Kunden zu verwalten, bewahren so designte Systeme und Landschaften alle geschäftlichen Veränderungen als Ereignisse auf. Zustand wird nur noch aus den Ereignissen für jeden gewünschten Zeitpunkt rekonstruiert. Sie ermöglichen das Beobachten von Verhalten und öffnen ganz neue Bereiche, wo IT das Business unterstützen kann.

Redaktion: Und welches Thema im Bereich der Software-Architektur ist deiner Meinung nach im aktuellen Diskurs etwas unterbelichtet?

Bernd Rederlechner: Ich sehe immer noch, dass Entwickler und Architekten Technik um der Technik willen bauen. Das ist zwar nicht falsch, aber immer schwerer geschäftlich vertretbar. Warum benötige ich beispielsweise meine eigene Installation eines Streaming-Clusters, wenn ich einen auf Knopfdruck in der Cloud schneller und unterm Strich auch günstiger bekommen kann? Überall dort, wo man eine neue Technologie so nutzt wie alle anderen, wird man in Zukunft immer mehr gezwungen sein, fertige Services einzusetzen.

Verbündet Euch mit den Architekten und Entwicklern aus anderen Disziplinen und Fachbereichen.

Budget zum Ausprobieren cooler Sachen wird dorthin fließen, wo Eigenentwicklung mein Unternehmen am Markt differenziert. Wie also arbeiten IT-Architekten, die konsequent Teile eines Systems durch PaaS/SaaS-Services ersetzen, sobald sie Mainstream geworden sind? Wie müssen Architekturen gestaltet sein, damit sie Sollbruchstellen enthalten – nicht ganz ohne Entwicklungsaufwand, aber wenigstens für einen schmerzfreien Austausch? Wie komme ich aus einer Legacy-Welt dorthin?

Redaktion: Was ist die Kernbotschaft deiner Session, die jeder Besucher mit nach Hause nehmen sollte?

Bernd Rederlechner: DDD als lokale Optimierung innerhalb eines Projektes oder Produktes verliert viel von seiner Schlagkraft. Verbündet Euch mit den Architekten und Entwicklern aus anderen Disziplinen und Fachbereichen, kombiniert Eure Stärken und liefert mutig viele kleine Veränderungen hin zu der IT-Welt, in der Ihr gemeinsam in Zukunft leben wollt.

Redaktion: Vielen Dank für dieses Interview!
Die Fragen stellte Hartmut Schlosser.

The post DDD, DevOps, Software-Architektur: „Verbündet Euch mit Entwicklern aus anderen Disziplinen und Fachbereichen“ appeared first on JAX.

Redaktion: Hallo Christian! Ihr bringt in eurem JAX Talk die Systemtheorie nach Luhmann mit Softwareentwicklung und -architektur zusammen. Was können Entwickler von der Systemtheorie lernen?

Es gibt eine starke Analogie zwischen der Kommunikation, die in sozialen Systemen stattfindet, und der Kommunikation innerhalb von Softwaresystemen.

Dr. Christian Mennerich: Den Vortrag halte ich ja zusammen mit Freddy Meseck, der bei uns als systemischer agiler Coach arbeitet und sich von daher mit der Systemtheorie sehr gut auskennt. Bei synyx arbeiten wir in den Softwareentwicklungsprojekten u.a. nach den Prinzipien des Domain-driven Design (DDD), folglich ist eine große gemeinsame Aufgabe das Finden der relevanten abgeschlossenen Kontexte (Bounded Contexts).

Freddy und ich sind nun schon ein paar Jahre zusammen in verschiedenen Projekten und Teams unterwegs und waren uns einig, dass ein guter soziologischer Ansatz fehlt, um diese Kontexte systematisch zu finden und zu beschreiben. Die sozialen Systeme gemäß der Systemtheorie nach Luhmann, so wie wir sie interpretieren, sind unserer Meinung nach hierzu gut geeignet.

Für Entwickler*innen in einem agilen Projekt ist die Systemtheorie, insbesondere der darin enthaltene konstruktivistische Ansatz, unserer Meinung nach ein geeignetes Werkzeug um zu verstehen, warum es in Softwareprojekten immer wieder zu Missverständnissen kommen wird. Aus diesem Bewusstsein heraus lässt sich das gemeinsame Verständnis mit POs, Stakeholdern und Endanwendern erhöhen.

Die Systemtheorie liefert noch einmal eine andere Sichtweise auf iteratives Vorgehen und motiviert zu kleinen Inkrementen in einem kontinuierlichem Ausrollprozess, experimentellem Lernen, “fail fast” und anderen agilen Elementen. Weiter verändert Software ja auch die “Gesellschaft” der Anwender. Für Entwickler*innen ist das eine wichtige Erkenntnis. Es gibt eine starke Analogie zwischen der Kommunikation, die in und zwischen sozialen Systemen stattfindet, und der Kommunikation innerhalb und zwischen Softwaresystemen. Dies legt eine nachrichtengetriebene Systemarchitektur nahe, und die Kommunikation über Domänen-Events.

Die Herausforderungen, die nachrichtengetriebene verteilte Systeme mit sich bringen (wie die Fragen nach Zeiten, Reihenfolgen, Zustellhäufigkeiten usw.), erhalten so eine starke fachliche Komponente, da Kommunikation zwischen sozialen Systemen oft ebenso “unvorhersagbar” stattfindet. Für Entwickler*innnen wird es so natürlicher, diese Herausforderungen auch im Code anzugehen und gegenüber POs und Stakeholdern zu motivieren.

Redaktion: Ihr schreibt in eurem Abstract zum Talk, dass es darauf ankomme, “die Realitätskonsense der beteiligten sozialen Systeme isomorph zur Deckung zu bringen, um ein für alle zufriedenstellendes Softwareprodukt zu erhalten.“ Kannst du das einmal anhand eines Beispiels erläutern?

Dr. Christian Mennerich: Ja klar, die Systemtheorie ist als solche ja sehr abstrakt und als Universaltheorie ja nicht so ganz trivial. Unserer Meinung nach ist an dem Ansatz aber nichts Esoterisches! In unserem Vortrag bringen wir ganz konkrete Beispiele aus einem unserer Kundenprojekte, in dem es um die Digitalisierung von Prozessen an Containerterminals im Hinterland geht.

Schauen wir zum Beispiel auf das Terminalgate, den Ort, an dem LKWs, die Container bringen oder abholen, kontrolliert und eingelassen oder abgewiesen werden. Wir können das Gate als ein soziales System verstehen (einen Bounded Context), den wir in Software abbilden wollen. Die Mitarbeiter am Gate arbeiten schon seit langem zusammen, sind abgestimmt und haben einen “Konsens”, ein gemeinsames Verständnis über ihre Arbeitsweisen und -prozesse: Wie wird mit LKWs im “Normalfall” umgegangen? Wie mit welchen, die nicht angemeldet sind, die trotz Anmeldung nicht kommen usw.? In der Sprache Luhmanns spricht man hier von “anschlussfähiger Kommunikation”, von “Mustern” und “Prozessen”.

Nun soll das Gate durch eine Software unterstützt werden. Ein Requirements Engineer “verzerrt” diesen Konsens bei der Anforderungserfassung, da er das soziale System “Gate” verändert und zusätzlich seine Sichtweise unvermeidlich mit einbringt (seine “Konstruktion der Realität”). Das Ergebnis soll dann von einem Entwicklerteam umgesetzt werden. Die Entwickler sind aber auch ein soziales System, das eine eigene Konstruktion und Interpretation der Anforderungen ausbildet, sich also einen “Konsens” darüber bildet, was es umsetzen soll und was das bedeutet.

Um bei den Mitarbeitern am Terminal eine hohe Akzeptanz zu schaffen und sie bestmöglich in ihrem Prozessen zu unterstützen, sollten Mitarbeiter und Entwickler die Prozesse möglichst gleich verstehen. Das meinen wir damit, wenn wir davon sprechen, dass die Konsense zur Deckung kommen sollen. Für uns ist eine hohe Übereinstimmung der Konsense eine Art Maß dafür, dass die Software leistet, was sie soll und auch akzeptiert ist.

Software-Architektur Trends

Redaktion: Software-Architektur ist allgemein ein breit gefächertes Gebiet – ebenso unterschiedlich ist das Rollenverständnis unter Software-Architekten. Worin siehst du persönlich in deiner Position als Software-Architekt deine Hauptaufgabe? Was ist dir besonders wichtig?

Mir persönlich ist es wichtig, dass die Architektur-Entscheidungen fachlich getrieben sind.

Dr. Christian Mennerich: Mir persönlich ist es wichtig, dass die Architekturentscheidungen fachlich getrieben sind, das heißt, dass die Entwicklung Business-zentriert stattfindet, nicht technisch. Dies gilt für alle Ebenen der Softwarearchitektur, von den groben Systemschnitten bis hin zur konkreten Implementierung der einzelnen Services.

Hier achten wir verstärkt auf DDD, nachrichtenorientiertes Denken von Beginn an, das Einhalten hexagonaler Architektur-Pattern und ähnliches. Hier ist es meiner Meinung nach unerlässlich, iterativ zu arbeiten und die Teams von vorne herein mit möglichst breit gefächertem Wissen aufzustellen.

Redaktion: Welchen Architektur-Trend findest du momentan besonders spannend?

Dr. Christian Mennerich: Streng nachrichtenorientiertes Design in verteilten Systemen, vor allem den Gedanken der Domänen-Events konsequent anzuwenden, finde ich spannend. Wenn wir fachlich getrieben kleine abgeschlossene Services auch in verteilten Teams entwickeln lassen, dann bekommt auch die Kommunikation über Nachrichten und deren unterschiedliche Interpretation durch verschiedene Services eine fachliche Entsprechung. Das wirft eine gute neue Perspektive auf Diskussionen über Garantien in solchen verteilten Systemen (wie Zustell-Reihenfolgen und -zeiten, exactly-once delivery usw.).

Redaktion: Und welches Thema im Bereich der Software-Architektur ist deiner Meinung nach im aktuellen Diskurs etwas unterbelichtet?

Dr. Christian Mennerich: Was mich brennend interessiert, ist die Frage, was die neuen Architekturstile genau bedeuten und mit der Anwenderschaft machen. Wenn wir in Microservices (oder noch kleineren Einheiten) entwickeln, was bedeutet das dann beispielsweise für Bounded Contexts nach DDD und Conways Law, wie können wir diese Konzepte dann noch verstehen?

Das ist auch eine Frage, die Freddy und mich angetrieben hat, Luhmanns Systemtheorie und Softwareentwicklung zusammen zu bringen; Software und Digitalisierung machen ja etwas mit der Gesellschaft, und umgekehrt. An dieser Stelle fände ich eine breitere Diskussion spannend, wie sie beispielsweise momentan anläuft, wenn es um ML und moralische Fragestellungen geht.

Redaktion: Was ist die Kernbotschaft eurer Session, die jeder Besucher mit nach Hause nehmen sollte?

Dr. Christian Mennerich: Wir wünschen uns klar zu machen, dass eine objektive Realität keine Relevanz hat, da die Realität nicht objektiv beschrieben werden kann! Beschreibung ist immer Konstruktion des Beobachters. Um gute Software zu bauen, gilt es, gut und viel zu kommunizieren, um die richtigen Konsense zu finden. Denn alle am Softwareentwicklungsprozess beteiligten sozialen Systeme haben jeweils einen “eigenen Konsens”. Diese Konsense gilt es dann gemeinschaftlich zu harmonisieren, und da hilft nur das gemeinsame Ausprobieren kleiner Änderungen, um beweglich zu bleiben.

Redaktion: Vielen Dank für dieses Interview!

Das Interview führte Hartmut Schlosser.

The post Was Software-Architekten von der Soziologie lernen können appeared first on JAX.

Was ist eine Wardley Map?

Wir betrachten ein beispielhaftes Szenario, das sich an einen realen Anwendungsfall anlehnt. In diesem Szenario bietet ein Unternehmen seinen Kunden eine Übersicht über Verträge und Leistungen über ein webbasiertes Kundenportal an. Das Kundenportal greift auf ein cloudbasiertes CRM-System und auf ein internes System zur Vertragsführung zu. Letzteres ist an eine Standardlösung von SAP angebunden, um Ein- und Auszahlungsvorgänge abzuwickeln. Kundenportal, Vertragsführung und SAP werden inhouse im eigenen Rechenzentrum betrieben, das CRM wird als Software-as-a-Service-Angebot genutzt. Zusätzlich entwickelt das Unternehmen eine Kunden-App, die über ein Backend an das Kundenportal angebunden ist. Die App soll dessen Funktionen auch zur mobilen Nutzung anbieten. Die Entwicklung von App und Backend hat gerade erst begonnen.

_{Abb. 1: Eine Landkarte des Beispielszenarios}

Abbildung 1 zeigt eine Wardley Map unseres Szenarios, bestehend aus einem Bezugspunkt (Anchor) und miteinander verbundenen bedeutsamen Dingen (Components). Der Bezugspunkt ist der Nordpfeil unserer Landkarte, Positionen werden relativ zu diesem Bezugspunkt in der Karte vermerkt. Auf unserer Karte ist der Kunde der Bezugspunkt, alle Components werden also bezogen auf den Kunden ausgerichtet. Direkt verknüpft mit dem Bezugspunkt sind Components, die Bedarfe (Needs) repräsentieren. In unserem Fall drückt die Map aus, dass der Kunde mit den Components „App“ und „Kundenportal“ interagiert.

Components repräsentieren alle Dinge von Bedeutung im Kontext unserer strategischen Betrachtung. Es handelt sich um Abstraktionen, maximale Vereinfachungen komplexer Zusammenhänge. Softwaresysteme können ebenso in einer Map als Component vorkommen wie Dienstleistungen, Wissen oder physikalische Kräfte. Daumenregel: Ist es strategisch bedeutsam, wird es als Component Teil der Map.

Die Ausrichtung der Components erfolgt entlang der vertikalen Achse (Value), abhängig von der Sichtbarkeit des Werts für den Kunden (unser Bezugspunkt, Anchor). Components, mit denen der Kunde direkt interagiert, sind für ihn auch direkt wahrnehmbar und werden daher weiter oben angeordnet. Weiter unten stehende Components sind, relativ zum Bezugspunkt Kunde, weniger sichtbar – aber nicht weniger wichtig. Der Wert einer Component und seine vom Bezugspunkt aus wahrnehmbare Sichtbarkeit sind zwei voneinander zu unterscheidende Merkmale. Durch die Verbindungen zwischen den Components ergibt sich eine Wertkette (Value Chain), bei der Components aufeinander aufbauen.

Je weiter oben sich eine Component befindet, umso erkennbarer ist ihr Wert für den Kunden, je weiter rechts sie sich befindet, desto höher und reifer ist sie entwickelt. Die horizontale Achse beschreibt den Grad der Entwicklung (Evolution). Dieser sagt etwas über den Charakter der jeweiligen Component aus: Stellen wir ein Softwaresystem als Component am linken Rand der Map dar, sagen wir damit aus, dass das System sich am Anfang seiner evolutionären Entwicklung befindet. Gleiches gilt für Components, die Wissen oder Methoden repräsentieren. Steht eine Component weit links, kann das beispielsweise bedeuten, dass Technologien oder Konzepte eingesetzt wurden, zu denen bisher im Unternehmen wenig Wissen verfügbar ist. Dadurch erhält die Component im betrachteten Kontext experimentellen Charakter. Das birgt Chancen für neuartige Ideen und somit künftiges Potenzial sowohl für Wettbewerbsvorteile als auch für Risiken. Am linken Rand der Evolutionsachse sind die Unwägbarkeiten hoch. Je weiter eine Component sich entlang der Achse bewegt, umso reifer wird sie, d. h. umso geringer die Unwägbarkeit, und umso besser lassen sich Chancen und Risiken erkennen und bewerten. Die Einteilung der Achse in vier Segmente verdeutlicht das: Im ersten Segment (Genesis) findet die „Werdung“ statt. Der Fokus liegt auf der Erforschung und Erkundung und der ursprünglichen Entstehung von etwas Neuem. Im zweiten Segment handelt es sich um spezifische, maßgeschneiderte (Custom-Built-)Lösungen. Im dritten Segment erhält eine Component hinsichtlich ihrer Entwicklung und Reife die Eigenschaften eines Produkts. Components im vierten Segment sind so weit entwickelt, dass sie allgegenwärtig und einfach verfügbar sind (Commodity + Utility), vergleichbar mit Elektrizität, Radioempfang oder, dank Cloud Computing, Rechenleistung. Nicht alle Components erreichen auch die höchste Entwicklungsstufe, aber sie entwickeln sich entlang der Achse in diese Richtung – freilich in unterschiedlicher Geschwindigkeit.

Nun haben wir alle Bausteine kennengelernt, um eine Karte einer bestimmten Landschaft zu zeichnen: Wir haben einen Bezugspunkt (Anchor) und können strategisch relevante Elemente (Component) relativ dazu positionieren (Value). Entfernungen zwischen den Elementen sind für uns unterscheidbar und bedeutsam (Evolution). Diese Karte können wir anderen zeigen, um über die Landschaft zu diskutieren. Der beste Weg, eine Map zu erstellen, ist, dies direkt in einer Gruppe zu tun, gemeinsam mit den jeweiligen Experten. Dabei ergeben sich wertvolle Diskussionen: „Warum ist das so weit unten?“, „Warum wird X weiter als Y entwickelt dargestellt?“, „Ist A wirklich Teil der Landschaft? Warum ist B nicht abgebildet? Wo ist C?“. Durch kritische Auseinandersetzung werden Annahmen hinterfragt und Erkenntnisse geteilt – ein gemeinsames Verständnis wird aufgebaut und weiter gefördert. Wer dabei an Domain-driven Design (DDD) und die Ubiquitous Language denkt, liegt genau richtig. Sobald wir ein gemeinsames Verständnis der Landschaft haben, können wir uns den Umgebungsbedingungen (Climate) widmen und diese ebenfalls in unsere Map übertragen.

Klimatische Einflüsse

Bodenwetterkarten enthalten neben der geografischen Abbildung der Landschaft weitere Informationen, etwa über Hoch- und Tiefdruckgebiete, Windverhältnisse, Niederschläge und Temperaturen. Die klimatischen Verhältnisse wirken auf die Landschaft ein und beeinflussen die geltenden Bedingungen. Je mehr relevante Details unsere Karte enthält, umso besser erkennen wir, dass der beste Weg von A nach B nicht zwangsläufig eine Gerade ist. Ein steiler Aufstieg an einer auf der Karte verzeichneten Felswand (Landscape) ist, je nach klimatischen Verhältnissen, anstrengend aber machbar, oder eben ein lebensgefährliches Wagnis. Dieser Informationsvorsprung ist entscheidend und stellt laut Simon Wardley den Unterscheid zwischen Maps und klassischen Methoden der Strategieplanung (siehe Kasten „Über die Methode“) dar.

Um eine erfolgreiche Strategie zu entwickeln, müssen wir uns explizit und ganz bewusst mit den Dingen beschäftigen, auf die wir keinen Einfluss haben. Während wir uns die Gegebenheiten der Landschaft zu Nutze machen und sie auch ein Stück weit verändern können, entziehen sich klimatische Einflüsse unserem Willen: Wir können sie nicht steuern, aber wir können sie entdecken und auch diese Erkenntnisse für uns vorteilhaft nutzen. Bewegungen an Märkten, strategische Entscheidungen von Wettbewerbern, technologischer oder gesellschaftlicher Wandel sind klimatische Einflüsse, die wir auf unseren Karten abbilden können und wollen.

_{Abb. 2: Wardley Maps mit klimatischen Einflüssen}

In Abbildung 2 werden klimatische Gegebenheiten genutzt, um eine Strategie zu entwerfen. App und zugehöriges Backend werden parallel vom gleichen Team entwickelt. Der gemeinsame Kontext wird durch die Umrandung sichtbar gemacht, da er für die strategische Entwicklung eine Rolle spielt. Beide Systeme sind noch in einem frühen experimentellen Status und nicht produktionsreif. Es müssen das UI optimiert und Performanceprobleme ausgeräumt werden, um eine positive Kundenerfahrung und somit Akzeptanz am Markt zu ermöglichen. Der rote Pfeil drückt die angestrebte Bewegung (Movement) entlang der Evolutionsachse aus. Die Software soll ihren experimentellen Charakter mit der Zeit verlieren und die Eigenschaften eines reifen Produkts erhalten. Die strategische Entscheidung wird zusammen mit der dafür zu nehmenden Hürde abgebildet: In unserem Fall mangelt es an Wissen und Kapazität, was als schwarzer Balken dargestellt wird. Der Balken beschreibt Inertia, die zu überwindende „Massenträgheit“. Nur wenn diese Hürde überwunden werden kann, ist der Weg frei für die Evolution von einer Eigenentwicklung (Custom Built) zu einem reifen und konkurrenzfähigen System mit Produktcharakter.

Cloud Computing ermöglicht nicht nur die Nutzung von SaaS, sondern auch alternative Betriebskonzepte für Eigenentwicklungen, was Einfluss auf die Bereitstellung hat. Der rote Pfeil beschreibt den Schritt weg vom rechenzentrumsbasierten Betrieb standardisierter VMs (Product) hin zu Container as a Service in einer Public Cloud (Commodity). Dieser Schritt ist jedoch nicht ohne Weiteres gangbar, denn auch hier existiert Inertia, also Widerstand durch eigene Trägheit. Das Know-how muss aufgebaut werden, Deployment und Betrieb erfordern neue infrastrukturelle Maßnahmen, die physische Anbindung zwischen Cloud und dem eigenen Haus muss ggf. neu dimensioniert werden. Sind diese Herausforderungen bewältigt, ergeben sich neue Möglichkeiten für andere Components auf der Map, sie können sich weiterentwickeln. Das Backend profitiert von der Umstellung auf containerbasierte Bereitstellung und kann cloudbasiert betrieben werden, sobald dieses Betriebsmodell zu einem späteren Zeitpunkt bereit ist. Die rote Linie beschreibt diese Verbindung der Components in der Zukunft. Dazu lohnt es sich, das Konzept der Evolution noch einmal genauer zu betrachten.

Evolution

Die Evolution beginnt mit dem Auftreten einer Component am linken Rand, der sogenannten Uncharted Domain (Abb. 3). Ihre Charakteristiken sind geprägt von Begriffen wie „experimentell“, „chaotisch“, „unzureichend verstanden“. Wir können schwer oder gar nicht vorhersehen, wie Dinge in der Uncharted Domain sich entwickeln werden. Daraus ergibt sich zum einen ihr hohes Potenzial in der Zukunft, aber auch ihr hohes Risiko durch eben diese Unsicherheit.

_{Abb. 3: Evolution von der Uncharted zur Industrialised Domain}

Je weiter eine Component sich entwickelt, umso mehr weicht die Unsicherheit der Gewissheit und es wird möglich, im industriellen Maßstab zu denken. Aus den ersten Laborversuchen mit transistorbasierten CPUs werden spezialisierte Kleinserien gefertigt, die später Produktreife erlangen und schließlich kostengünstig in Massenfertigungsprozessen in ausreichender Stückzahl produziert und für jeden erhältlich angeboten werden können. Je weiter wir uns auf der Map an den rechten Rand bewegen, umso mehr gelangen wir in die Industrialised Domain. Die Differenzierbarkeit zwischen verschiedenen Produkten nimmt ab, dafür sind diese wohl verstanden und lassen sich effizient her- und bereitstellen. Die Verfügbarkeit steigt rapide an, die Kosten pro Stück fallen. Je weiter entwickelt eine Component ist, umso eher kann sie die Ausgangsbasis für neue Entwicklungen sein, die dann ihrerseits wieder in der Uncharted Domain einsetzen. Aus kostengünstig in hoher Stückzahl gefertigten CPUs wurden Serverfarmen und wurde schließlich Cloud Computing, bei dem die Rechenleistung (nicht die Hardware) allgegenwärtig verfügbar ist. In unserem Beispiel ist die Evolution des Betriebsmodells vom eigenen Inhouse-Rechenzentrum hin zu cloudbasierten Containerdiensten die Basis für die technologische Weiterentwicklung des Backends. Das App-Experiment entwickelt sich zu einem reifen Produkt, je weiter es in die Industrialised Domain vorstößt.

Strategische Entscheidungen treffen

Bislang wurden die rein visuellen Eigenschaften von Wardley Maps besprochen. Mit Kenntnis der Landschaft und der Kräfte, die auf diese einwirken, können wir uns nun den strategischen Entscheidungsprozessen widmen. Kennen wir die Landschaft und die klimatischen Einflüsse, können wir individuelle Handlungen ableiten und universelle Prinzipien, die in jedem Kontext zutreffen, anwenden. Muster helfen uns dabei, diese zu erkennen und anzuwenden. Simon Wardley beschreibt dies mit den fortgeschrittenen Konzepten Doctrine und Leadership und gibt dem interessierten Leser Patternkataloge und Strategeme an die Hand, um eigene Strategien basierend auf Maps effektiver entwickeln zu können. Diese Konzepte sprengen den Rahmen dieses Artikels, sollen aber nicht gänzlich unerwähnt bleiben. Zusammen mit dem Konzept des Strategy Cycles bilden sie den wahren Kern des strategischen Mappings.

Um das zu verdeutlichen, wenden wir das gesammelte Wissen an und greifen das Pattern „No Single Method fits all“ heraus. Es besagt, dass es keine Methode gibt, die sich sinnvoll universell auf alle Components einer Map anwenden lässt. Beziehen wir das auf die unterschiedlichen Ansätze zur Softwareentwicklung und übertragen sie in das Konzept von Uncharted und Industrialised Domain, ergibt sich das Bild aus Abbildung 4.

_{Abb. 4: Verschiedene Methoden eignen sich je nach Evolutionsgrad besser}

Sowohl App als auch Backend befinden sich in der Uncharted Domain. Das bedeutet, dass mit häufigen Änderungen zu rechnen ist, sozusagen „by Design“. Dies ist eine wesentliche Eigenschaft von Components in der Genesis-Phase der Evolution und somit der Uncharted Domain. In diesem Fall bietet es sich an, mit agilen Methoden auf den steten Wandel zu reagieren, um die dadurch anfallenden Kosten unter Kontrolle zu behalten. Elemente am rechten Rand der Skala unterliegen diesem Wandel weniger stark. Ihre Charakteristiken sind wohl bekannt und somit kalkulierbar. Für Eigenentwicklungen, die es bis zu diesem Stadium schaffen, könnte (nicht muss!) Outsourcing eine Option sein. Das CRM ist beispielsweise von Anfang an als SaaS im Einsatz und keine individuelle Eigenentwicklung.

Fazit, Anwendungsmöglichkeiten und Ausblick

Wir haben die auffälligsten Merkmale von Wardley Maps angesprochen und anhand einfacher Beispiele verdeutlicht. Für fortgeschrittene Themen wie Doctrine, Gameplay und die Patternkataloge wird auf das frei verfügbare, unter CC-BY-SA lizensierte, Werk von Simon Wardley verwiesen, da dieser Artikel dafür nicht ausreichend Raum bieten kann [1], [2].

Die Entwicklung einer Map im Team kann im Rahmen eines Workshops stattfinden. Das Ergebnis kann leicht eine ganze Wand füllen. Entscheidend ist hier der nächste Schritt: Die Reduktion auf das Wesentliche, z. B. durch Aufspaltung einer Map in mehrere. Auf diesem Weg werden immer wieder neue Erkenntnisse über bestehende Annahmen gesammelt.

Im Kontext von DDD lassen sich Wardley Maps nutzen, um strategische Entscheidungen über Bounded Contexts zu treffen. Welche Veränderungen zeichnen sich ab? Welches Team und welche Methode eignen sich für welche Region der Karte? In welchen Bounded Context (nicht in welches System!) lohnen sich Investitionen, um neue Chancen nutzbar zu machen? Wardley Maps sind ein weiteres Werkzeug in unserer Designtoolbox, auf das wir im Bedarfsfall zugreifen können.

Auch wenn Wardley Maps ursprünglich für strategische Entscheidungen auf CEO-Level entwickelt wurden, können wir sie überall dort anwenden, wo wir uns ein Bild von komplexen Situationen verschaffen wollen, um fundierte Entscheidungen zu treffen. Das gilt für das strategische Architekturmanagement des Enterprise-Architekten ebenso wie für Projektleiter und System Owner, die eine vorausschauende (eben strategische) Planung betreiben wollen.

Abschließend lässt sich noch die Frage aufgreifen, ob es möglich ist, mit Wardley Maps komplexe Sachverhalte der realen Welt wirklich treffend darzustellen. Auch dazu gibt es ein mehr als treffendes Zitat von Simon Wardley: „All models are wrong but some are useful.“

Links & Literatur

[1] Ebook von Simon Wardley, frei verfügbar als Serie von Blogposts: https://medium.com/wardleymaps
[2] Projektseite mit Referenz und Artikeln für den Einstieg: https://learnwardleymapping.com/

The post Domain-driven Design: Strategisches Mapping mit Wardley Maps appeared first on JAX.

Was macht evolutionäre Software-Architekturen aus? Wie hält man die Balance zwischen Stabilität und Flexibilität? Wie lässt sich das Prinzip des Wandels mit dem agilen Prinzip vereinbaren, Software möglichst schnell auszuliefern, die einen echten Mehrwert bietet?

Evolutionäre Prinzipien

Evolutionäre Architekturen tragen zunächst einmal der Erkenntnis Rechnung, dass Software in inkrementellen Schritten entsteht. Software-Entwicklung ist kein linearer Prozess, an dessen Anfang eine Architektur-Skizze steht, die dann stur implementiert wird. Evolutionäre Software-Architektur vollzieht sich vielmehr in Schleifen: Nach dem Release einer kleinen Einheit wird Feedback eingeholt, auf dessen Basis Entscheidungen für die Weiterentwicklung getroffen werden können.

Weiterentwicklung vollzieht sich stets auf mehreren Dimensionen. Auf technischer Ebene sind dies zum Beispiel neue Sprachen, Frameworks, Tools und Systemupdates. Auf fachlicher Ebene können Änderungen des Marktes, neue Einkommensmodelle, ein verändertes Konsumverhalten oder eine neue Wettbewerbssituation Anpassungen an die Software-Architektur verlangen.

Kuas Fazit: Software-Architektur beschäftigt sich nicht nur mit dem Problem der richtigen technischen Entscheidung. Software-Architekten sind zunehmend mit der Frage konfrontiert, wie gewisse Entscheidungen getroffen werden sollten. Es geht um die Entscheidungskultur, die Grundlage für eine evolutionäre Software-Architektur ist.

The post Evolutionäre Software-Architektur appeared first on JAX.

The post 10 Gründe, warum wir gewisse APIs mögen und uns andere APIs nerven appeared first on JAX.

Wozu eigentlich Software-Architekten?

JAXenter: Die Rolle des Software-Architekten kann verschiedentlich interpretiert werden: Technologieplaner, Change Manager, Chefentwickler, Projektkoordinator, Kommunikator, Kundenberater, etc. Worauf kommt es dir persönlich in deiner Rolle als Software-Architekt an?

Ein Software-Architekt ist ein Vermittler zwischen Techniker und Nicht-Techniker

Sandra Parsick: Aus meiner Sicht ist ein Software-Architekt ein Vermittler zwischen Techniker und Nicht-Techniker. Dabei ist es hilfreich, wenn der Software-Architekt im Team mitentwickelt. Vermehrt sehe ich den Trend, dass die Rolle des Architekten als Teamaufgabe interpretiert wird, so dass die Entwickler aktiv an der Architektur mitarbeiten und auch gleich sehen, wie die Architektur sich im Code widerspiegelt.

Hanna Prinz: Meiner Meinung nach ist es wichtig, dass Architekten möglichst nah am Team sind und einen guten Draht zu Product Ownern haben. Nur mit regelmäßigem, direktem Austausch über Fachlichkeit, Architektur und Technologien können gute technische Entscheidungen gefällt werden. Viele – wenn nicht die meisten – Architektur-Entscheidungen fällen sowieso die Entwickler im Alltag. Umso besser das Team bei Architektur-Entscheidungen involviert und informiert ist, desto besser werden diese Entscheidungen sein und desto weniger erodiert die Architektur.

Thomas Kruse: Ich denke, dass ein guter Softwarearchitekt tatsächlich von allem etwas mitbringen muss. In erster Linie muss ein Architekt das Geschäft des Kunden besser verstehen, als der Kunde selbst. Nur so lassen sich geeignete technische Loesungen auswählen, mit denen sowohl die aktuellen Anforderungen als auch vorhersehbare Änderungen umgesetzt werden können.

Dabei ist der Schritt dann nicht mehr weit, den Kunden auch dahingehend zu beraten, wie er seine Geschäftsprozesse optimiert oder sogar dank geeigneter Software völlig neue Prozesse oder Modelle anbieten kann.

In zweiter Linie finde ich es wichtig, dass man nicht ausschließlich seine Lieblingsarchitektur hat, sondern über ein breites Spektrum an Wissen und Erfahrung verfügt und unter Berücksichtigung aller Anforderungen und Rahmenbedingungen dann eine passende Auswahl treffen kann.

Markus Harrer: Mir kommt es einfach darauf an, dass sich das Entwicklungsteam bei der Technik nicht übernimmt, um noch genug Zeit zu haben, einen Mehrwert für die Kunden zu liefern. Bei meinen Beratungen zum Entwurf oder der Modernisierung von Softwaresystemen stehen daher der Abbau unnötiger Komplexitäten und Standardisierung mit Hirn im Vordergrund. Ich will nicht, dass die besten Entwickler*innen ihre wertvolle Zeit mit dem Aufbau von eigenentwickelten Infrastrukturlösungen oder dem Zurechtbiegen von Standard-Frameworks verwenden. Sie sollen ihr Gehirnschmalz in die fachlich anspruchsvollen Teile stecken und hier die inhärente Komplexität clever in einfache Softwaresysteme gießen. Das bringt den wahren Wert der Software – und letztendlich auch den Mehrwert für die Kunden.

Stephan Pirnbaum: Als Software-Architekt ist es meiner Meinung nach besonders wichtig, die verschiedenen Anforderungen der einzelnen Stakeholder sowohl von technischer als auch besonders von fachlicher Seite sinnvoll zu vereinen und auf dieser Basis zukunfts- und evolutionsfähige Entscheidungen für das Software-System zu treffen. Dabei ist Kommunikation ein essentieller Bestandteil der Tätigkeit. Dokumentation von Entscheidungen und ein aktiver Wissensaustausch gehören aber für mich ebenso selbstverständlich dazu wie das Mitentwickeln an der Software.

Franziska Dessart: Software-Architektur ist das, was entsteht, wenn Software geschaffen wird. Genauso wie etwas bei seiner Herstellung automatisch eine Gestalt (-ung, also ein Design) bekommt. Hierzu braucht es keinen Designer. Architektur entsteht immer, egal ob Entscheidungen bewusst getroffen werden oder nicht. Unabhängig davon, ob ein sogenannter “Architekt” dazu beigetragen hat oder nicht. Auch die Sandburg meiner Kinder hat sowohl eine Gestalt, als auch eine Architektur.

Idealerweise werden jedoch die meisten Entscheidungen bewusst getroffen und nicht basierend auf Vorlieben oder dem “Bauchgefühl” Einzelner. Hierzu gilt es, Vor- und Nachteile aller erdenklichen Möglichkeiten zu beleuchten und gegeneinander abzuwägen. Es gibt keine perfekten oder allgemeingültigen Entscheidungen, aber immer die unter den momentanen Bedingungen bestmögliche Variante (die das unter Umständen schon Tage, Wochen oder Monate später nicht mehr sein muss, wenn sich die Rahmenbedingungen ändern).

Dabei spreche ich von Architekturentscheidungen auf allen Ebenen. Von weitreichenden Makroarchitekturentscheidungen (wie z.B. “Datenreplikation immer per Feed”) bis hin zu extrem detaillierten Entscheidungen (etwa Variablen- und Methodennamen bzw. Anzahl und Art ihrer Parameter), sowie allen Schattierungen dazwischen. Mir ist wichtig, dass jeder, der an der Herstellung von Software beteiligt ist, sich jederzeit so gut wie möglich mit seinem Wissen und seinen Fähigkeiten in die Architekturarbeit einbringen kann und dadurch die bestmögliche Architektur entsteht. Die Vorraussetzung dafür ist, dass eine offene und sichere Kommunikationskultur herrscht, die das überhaupt erst ermöglicht.

Architektur-Trends 2019

Welchen Trend in Sachen Software-Architektur findest du momentan besonders spannend?

Sandra Parsick: Ich finde es momentan spannend zu beobachten, wie die Wahl der Cloud-/Infrastrukturtechnologie Auswirkung auf die Software-Architektur hat. Noch vor ein paar Jahren haben sich Entwickler/Architekten wenig Gedanken darüber gemacht, so zumindest meine Wahrnehmung, ob die Architektur der Software die Anforderungen aus der Infrastruktur erfüllen kann. Ich denke da an Beispiele wie: “Kommt meine Software damit zurecht, dass sie im Kubernetes-Cluster einfach mal beendet wird und wo anders wieder gestartet wird?”

Hanna Prinz: Ich habe natürlich einen Starken Bias in Richtung Cloud, Kubernetes und Service Mesh. Es fasziniert mich immer wieder, wie beliebt und erfolgreich Microservices sind, obwohl es bis vor kurzem so schwer war, sie zu betreiben, zu kontrollieren und Einblicke in das Gesamtsystem zu gewinnen. In diesem Bereich gibt es ständig neue interessante Ideen und Technologien.

Der Trend zu Containern zieht unglaublich viele Bereiche nach sich.

Thomas Kruse: Der Trend zu Containern ist in meinen Augen eine Bewegung, die Auswirkungen auf unglaublich viele Bereiche nach sich zieht. Neben etablierten Technologien stehen dabei auch Organisationsstrukturen und etablierte Verfahrensweisen zur Diskussion. Das Potential, das Kubernetes bietet, liegt dabei natürlich auf der Hand. Auf der anderen Seite sollte man auch mit Bedacht vorgehen,. Nur um bei einem Trend dabei zu sein, aber dann doch eigentlich nichts ändern zu wollen, bringt aus meiner Sicht keine Vorteile und potentiell viel Frust und vergebene Energie. Dabei ist Kubernetes in der Tat bei vielen Firmen ein Wegbereiter zur Cloud und den damit verbundenen Chancen.

Markus Harrer: In vielen Firmen sind mittlerweile eine Unmenge an Softwaresystemen mit zahlreichen Anbauten und undurchsichtigen Kommunikationsbeziehungen entstanden. Für Softwarearchitekt*innen wird es dadurch immer schwerer, den Überblick zu behalten. Meist kennen diese nur Methoden zur Analyse einzelner Systeme. Das bringt Softwarearchitekt*innen bei der Beratung des Managements zur strategischen Ausrichtung des vorhandenen Systemzoos an ihre Grenzen. Daher finde ich besonders neu aufkommende Methoden interessant, welche ganze Systemlandschaften überschaubar machen.

Hier haben es mir besonders Wardley Maps [1] angetan. Eine Wardley Map ist eine Art Strategielandkarte, auf der Softwaresysteme nach ihrem Nutzen für einen Stakeholder (meist dem zahlenden Kunden) und dem jeweils gegebenen Evolutionsstadium (Prototyp, Eigenentwicklung, Produkt oder Gebrauchsgut) eingeordnet werden. Dadurch entsteht ein sehr kontextspezifisches Situationsbewusstsein über die eigene Systemlandschaft. Dank des immer vorhandenen Bezugs zum Stakeholder-Nutzen können auch Nicht-Techniker*innen bei strategischen Überlegungen zur IT mitreden. Durch die Einordnung der Systeme gemäß ihrer Evolutionsstufe können situationsspezifische Maßnahmen wie Know-How-Aufbau, Standardisierung oder Outsourcing sachlich diskutiert werden – je nachdem, wohin sich ein Softwaresystem entwickeln soll.

Stephan Pirnbaum: Aktuell finde ich Service-Meshes sehr spannend, denn leider wird der einfache Betrieb von Anwendungen bei deren Entwicklung häufig erst zweitrangig betrachtet. Dabei stellen insbesondere dynamisch skalierende Microservice-Landschaften große Herausforderungen insbesondere bezüglich Resilienz, Security, Monitoring und Logging. Zwar gibt es zahlreiche Frameworks, um dies zu bewerkstelligen, doch fügen diese weitere Komplexität sowohl in der Entwicklung als auch im Betrieb hinzu. Service-Meshes wie Istio erachte ich durch das Sidecar-Konzept und die Control Plane daher als einen interessanten Ansatz, diese Komplexität zumindest etwas einzudämmen. Dabei ist jedoch auch zu prüfen, ob die Mächtigkeit von Service-Meshes in dem jeweiligen Projektkontext notwendig ist.

Franziska Dessart: Mob Programming – hier ist jeder im Team an jeder wichtigen Entscheidung beteiligt und gleichzeitig immer über alles informiert. Ich mache das jetzt schon mehrere Monate erfolgreich bei meinem aktuellen Kunden. Von zuhause, vom Homeoffice aus. Wir nennen das Remote Mob Programming. Wie das funktioniert, haben meine Kollegen Jochen Christ, Simon Harrer und Martin Huber auf remotemobprogramming.org aufgeschrieben. Das funktioniert auch mit Teilzeit und sonstigen Abwesenheiten (Urlaub, Konferenzen, …), ganz ohne lästige Übergaben. Der Mob fängt das auf!

Jenseits der Trends

Welches Architekturthema außerhalb der Trends liegt dir besonders am Herzen und sollte deiner Meinung nach mehr Beachtung finden?

Sandra Parsick: Ist vielleicht kein direktes Architekturthema, aber ich finde, dass sich viel zu wenig Gedanken darüber gemacht wird, wie Architekturentscheidungen die Testmöglichkeiten einer Software beeinflussen. Daher wünsche ich mir, dass bei der Entscheidungsfindung mitberücksichtigt wird, wie ich das Ganze auch getestet bekomme.

Hanna Prinz: Man kann förmlich dabei zusehen, wie Softwareentwicklung immer dynamischer wird. Es geht häufig darum, schnell handeln zu können, selbst wenn dieser Vorteil auch mit ganz offensichtlichen Nachteilen einher geht. Architektur ist aber etwas, wo diese Dynamik nicht möglich und häufig auch nicht sinnvoll ist. Eine Architektur sollte deshalb nur so viel vorgeben, wie unbedingt nötig, und genug Raum für kontinuierliche Verbesserung lassen. Entscheidungen können nur dann wirklich in Frage gestellt werden, wenn der Aufwand, sie zu ändern, beherrschbar ist. Dieses offene Reflektieren über den Ist-Zustand setzt voraus, dass Alternativen bekannt sind.

Man kann förmlich dabei zusehen, wie Software-Entwicklung immer dynamischer wird.

Im Alltag ist man aber mit den immer gleichen Tools und Ideen konfrontiert. Deshalb brauchen wir Kollaboration und Austausch mit anderen. Meetups, Podcasts, Blogs und Workshops sind ein guter Anfang. Aber längst nicht alle Unternehmen ermutigen ihre Entwickler, sich so kontinuierlich weiterzuentwickeln und auszutauschen.

Thomas Kruse: Ich sehe oft, dass klassische Muster immer wieder Anwendung finden, die durch neue Optionen wie bspw. leistungsfähigere Hardware in Frage gestellt werden sollten. Ein Klassiker ist zum Beispiel die Verwendung von Batch-Jobs, weil auf Datenmengen im Gigabyte-Bereich gearbeitet wird – also Datenmengen, die locker in aktuellen Systemen auch im Hauptspeicher gehalten und performant verarbeitet werden könnten.

Markus Harrer: Es sind zwei Themen, die mir persönlich zu kurz kommen. Das eine Thema ist die Softwaremodernisierung. Auf Konferenzen reden wir meist nur über den Neubau von Software. Aber gefühlt sind doch 80% von uns in den sogenannten Legacy-Systemen unterwegs. Meistens haben diese Systeme vor allem bei der jüngeren Generation einen eher schlechten Ruf. Das finde ich sehr schade, denn es kann geistig sehr erfüllend sein, schwerwiegende Probleme in Bestandssystemen systematisch zu lösen. Es gibt viele Methoden und Vorgehen, wie etwa die Object-Oriented Reengineering Patterns [2] oder die Architecture Improvement Method aim42 [3], um Softwaresysteme Stück für Stück zu verbessern. Es fehlt leider jedoch noch an mehr Ausbesserinnen und Ausbessern, die sich in das Licht der Konferenzsäle wagen, um über solche Techniken und die eigenen Erfahrungen zu sprechen.

Das andere Thema ist das Dokumentieren von Softwaresystemen. Ich finde hier den Ansatz Docs-As-Code [4] insbesondere in der Ausprägung Arch-As-Code sehr spannend. Dokumentation auf den Stellenwert von Code zu heben, um damit Entwickler*innen keine Ausweichmöglichkeiten mehr zu geben, nichts zu dokumentieren? Genial! Gleiche Tools, gleiche Prozesse, gleiche Regeln. Die zusätzliche Verzahnung von den dokumentierten, architekturellen Spielregeln und deren Prüfung gegenüber dem echten Code bei Arch-as-Code treibt das noch ein Stück weiter. Werkzeuge wie ArchUnit [5] oder jQAssistant [6] prüfen hier beim Test oder Bau der Software automatisiert, ob die dokumentierten Architekturregeln auch eingehalten werden. Damit gibt es zusätzlich noch eine neutrale Instanz, welche dem sonst schleichenden Verfall von Softwaresystemen entgegenwirkt.

Stephan Pirnbaum: Für mich ist das Thema „Monolith“ und deren Verbesserung sehr wichtig, obwohl es leider in der Vergangenheit aufgrund neuer Trends als nicht sehr ansprechend galt. Im Gegenteil, schaut man zurück, waren lange Zeit Microservices (zumindest gefühlt) das Nonplusultra und Monolithen alles andere als attraktiv. Ebenfalls gefühlt hat sich diese Situation aber wieder gelegt, und es geht viel stärker darum, was tatsächlich für den Use Case und die Projektzukunft notwendig und sinnvoll ist. Dies kann ich nur unterstützen und finde, dass die Diskussion um die „richtige“ Architektur (soweit es diese überhaupt gibt) noch viel stärker auf Basis geschäftlicher Anforderungen und Rahmenbedingungen geführt werden sollte, anstatt auf der Grundlage aktueller Trends zu entscheiden.

Franziska Dessart: ADRs, also Architecture Decision Records, sind ein Mittel, das auf effiziente Art und Weise die wichtigsten Architekturentscheidungen dokumentiert. Es wird sowohl die Entscheidung selbst explizit dokumentiert, als auch, wie das Team zu dieser gekommen ist. Welche Information zum Zeitpunkt der Entscheidungsfndung zur Verfügung standen und welche Alternativen möglich gewesen wären.

Das hilft dem Team selbst: Entscheidungen werden explizit gemacht, Alternativen beleuchtet, Vor- und Nachteile abgewogen. Gleichzeitig schafft man Transparenz für Stakeholder außerhalb des Teams und erleichtert das Onboarding für neue Kollegen. Das Aufschreiben fördert die strukturierte Herangehensweise an die Entscheidung und gibt allen die Möglichkeit, sich daran zu beteiligen.

Architektur-Themen der Experten

Hanna, du hältst auf der W-JAX einen Talk namens Istio & Co: Service Mesh – das Missing Piece der Microservices-Architektur. Welche Vorteile hat man beim Einsatz eines Service Mesh Tools?

Hanna Prinz: Die Automatisierungs-Werkzeuge, die wie nutzen, sind teilweise schon so unsichtbar geworden, dass wir uns ihrer gar nicht mehr bewusst sind. Erst wenn man einen Container-Orchestrierer wie Kubernetes oder das CI/CD-Tooling wegnehmen würde, würde uns deren Mehrwert auffallen. Ich denke, dass es im Bereich solcher Automatisierungswerkzeuge noch viel mehr Potential gibt. Ein Service Mesh fügt einer beliebig großen Microservice-Anwendung essentielle Features wie Monitoring, Routing, Circuit Breaking und die Absicherung des Netzwerkverkehrs hinzu – und zwar ohne, dass die Anwendungsentwickler auch nur eine Zeile Code ändern müssen. Der Hype um das Thema ist also durchaus berechtigt.

Neben den vielen Vorteilen: Erkauft man sich dabei auch einige Nachteile?

Selbst die sinnvollsten Veränderungen haben immer den Nachteil, dass es Zeit und Ressourcen kostet, die Veränderung zu evaluieren, zu planen, zu kommunizieren und herbeizuführen. Das trifft auch auf die Einführung eines Service Mesh zu. Noch dazu unterscheiden sich die verfügbaren Service-Mesh-Implementierungen stark – nicht nur im Feature-Umfang und was die Kompatibilität mit anderer Infrastruktur wie Kubernetes angeht, sondern auch in der Benutzbarkeit der API für Entwickler. Der mentale Overhead ist meiner Meinung nach aktuell der größte Nachteil von Service Meshes.

Schließlich ist das auch nicht die einzige Veränderung, mit denen die Teams konfrontiert sind. Ein Service Mesh hat außerdem einen Einfluss auf die Antwortzeit einer Anwendung und auf deren Ressourcenverbrauch. Ich empfehle deshalb immer, einen Benchmark mit der individuellen Anwendung zu machen.

Ein Service Mesh fügt einer beliebig großen Microservice-Anwendung essentielle Features wie Monitoring, Routing, Circuit Breaking und die Absicherung des Netzwerkverkehrs hinzu.

Sandra, du bist auf der W-JAX und dem Software Architecture Summit aktiv. Dabei geht es beides Mal ums Testen: auf der W-JAX mit dem Vortrag Testen von und mit Infrastruktur, auf dem Summit mit dem Workshop Softwarearchitektur automatisiert testen. Was bedeutet es überhaupt, eine Architektur zu testen?

Sandra Parsick: Es geht in erster Linie darum, die Frage zu beantworten, wie ich erkenne, ob meine Architektur die gewählten Qualitätsmerkmale erfüllt. Da können oft schon klassische Testtechniken helfen. Bei anderen Fällen muss ich den Begriff “Testen” eher als Qualitätssicherung interpretieren, und dann kommen auf einmal andere Methoden in Spiel, die man erstmal nicht so auf dem Schirm hatte.

Thomas, deine Session auf der W-JAX lautet Frontend-Architektur für Microservices. Dabei gehst du explizit auf Chancen ein, die sich dank des etablierten Web-Components-Standards ergeben. Welche Chancen gibt es da?

Thomas Kruse: Der Vortrag liefert ein ganzes Buffet an Optionen, wie Webfrontends für eine Microservice-Architektur umgesetzt werden können. Ziel des Vortrages ist dabei vor allem, das Spektrum aufzuzeigen und nicht einen goldenen Hammer zu vermarkten. Webcomponents spielen für mich eine besondere Rolle, wenn es darum geht, wiederverwendbare Widgets oder Teilfunktionalitaet anzubieten, die nicht an ein spezifisches Framework gekoppelt ist. Auch wenn der Tradeoff besteht, dass dann nicht unmittelbar Frameworkvorteile bei der Einbettung genutzt werden können, stellen Webcomponents einen guten Mittelweg dar, wenn Team, Projekt oder sogar unternehmensübergreifend Funktionalität wiederverwendet werden soll. Dabei ist es z.B. mit Angular Elements oder Polymer auch möglich, bei der Entwicklung der Komponenten auf ein Framework mit den entsprechenden Vorteilen zurückzugreifen.

Markus, du übernimmst auf der W-JAX den Workshop Architektur 101: Praktisch, konzentriert und ohne Hype. Dabei ist dein Spezialgebiet die datenzentrierte Analyse von Softwareprodukten. Weshalb ist diese aus deiner Sicht so wichtig?

Markus Harrer: Die Analyse von Softwaresystemen mit Hilfe von Werkzeugen aus dem Data-Science-Bereich ist für mich einer der Wege, wie Softwareentwickelnde ihre Bedenken und Schmerzen an Nicht-Techies kommunizieren können [7]. Durch nachvollziehbare Datenanalysen werden die ansonsten verborgenen Gedankengänge der Bedenkenträger*innen offengelegt. Probleme können somit Stück für Stück systematisch herausgearbeitet werden – von den Rohdaten zu den Erkenntnissen bis hin zur managementgerechten Darstellung. Dies ermöglicht eine sachliche Diskussion auch über unangenehme Probleme, deren Schwere in politisch überhitzten Projekten gerne heruntergespielt wird.

Stephan, du bist Trainer auf dem Software Architecture Summit. In deinem Workshop Lasst uns einen Monolithen (z)erlegen gehst du von einem Legacy-System aus, das schrittweise in eine Microservices-Struktur überführt wird. Welchen typischen Problemen begegnet man dabei?

Eine Anwendung ist nicht aufgrund ihrer technischen Architektur, sondern ihrer fachlichen Fähigkeiten so wichtig für den Kunden.

Stephan Pirnbaum: Ich sehe primär drei Probleme. Erstens: Die Lieferfähigkeit ist zu jeder Zeit zu erhalten. Das heißt, dass für die Umsetzung geplanter Refaktorisierungen die Lieferung neuer Features nicht gefährdet werden darf. Schließlich ist die Anwendung nicht aufgrund ihrer technischen Architektur, sondern ihrer fachlichen Fähigkeiten so wichtig für den Kunden und damit für uns. Demzufolge kann es erforderlich sein, zunächst architekturell suboptimale Lösungen zu finden, um dafür langfristig sicher zum Ziel zu kommen.

Zweitens: Fehlendes Wissen (z. B. durch Mitarbeiterfluktuation) und mangelhafte Dokumentation erschweren sowohl die Wartung und Weiterentwicklung als auch die Planung von Refaktorisierungen. Dies wird verstärkt durch über Jahre gewachsene Strukturen, unterschiedliche Entwicklungsstile und verschiedene eingesetzte Technologien.

Drittens: Die vollständige Entkopplung auf Java-Code-Ebene bringt ganz neue Herausforderungen mit sich. Dabei geht es sowohl um die Änderung von Abhängigkeitsstrukturen, zum Beispiel durch Einführung von asynchronem Messaging, aber auch um Themen wie Laufzeitverhalten, Verfügbarkeit und Resilienz gegenüber Infrastrukturproblemen. Allesamt Themen, die im Monolithen nie derart bedacht werden mussten.

Franziska, du bist auf der W-JAX ebenso im Workshop „Architektur 101: Praktisch, konzentriert und ohne Hype“ aktiv. Dabei soll auch das Handling von nichtfunktionalen Anforderungen nicht zu kurz kommen. Kannst du einmal ein Beispiel ausführen, wie man mit einer nichtfunktionalen Anforderung umgeht?

Franziska Dessart: In meinem aktuellen Projekt spielt Resilienz eine sehr große Rolle. Das System soll funktionieren, auch wenn Probleme auftreten oder umliegende System nicht so arbeiten, wie erwartet. Wir sind hier auch für den Betrieb zuständig und halten uns dieses Ziel in Diskussionen immer wieder vor Augen: “Wir wollen nachts nicht angerufen werden!” Das hilft, zu priorisieren und insgesamt bessere Entscheidungen zu treffen.

Take-aways – was haben wir nun gelernt?

Zum Schluss noch ein Take-away. Was sind eure Kernbotschaften, die die Leser – und natürlich die Teilnehmer eurer Sessions und Workshops – mitnehmen sollten?

Sandra Parsick: Die Kernbotschaft soll sein, dass, wenn ich Ziele definiere, ich mir auch darüber Gedanken machen muss, wie ich erkenne, dass ich diese Ziele erreicht habe – und das auf Dauer!

Hanna Prinz: Am besten nehmen die Teilnehmer natürlich ein Service Mesh für ihre Microservice-Anwendung mit und setzen es gleich in ihrer Microservice-Anwendung ein Aber Spaß beiseite. Es gibt viele gute Gründe für ein Service Mesh, aber auch ein paar dagegen. Meine Teilnehmer werden den Workshop mit einer Einschätzung verlassen, ob sich ein Service Mesh für ihr Projekt lohnt. Es würde mich wundern, wenn der Großteil keine überzeugenden Gründe dafür sieht. Deshalb, und weil der Markt nicht ganz einfach zu durchschauen ist, wird es auch darum gehen, das richtige Service Mesh Tool auszuwählen. Doch auch wenn ein Service Mesh nicht sofort in die Projekte eingeführt wird, möchte ich die Teilnehmer dazu anregen, darüber nachzudenken, wie (oder ob) typische Service-Mesh-Funktionen wie Monitoring, Resilienz und Sicherheit aktuell umgesetzt sind – oder auch nicht.

Es gibt nicht nur Nachteile bei einem monolithischen Ansatz. Gerade wenn es um hochintegrierte Frontends geht, kann hier eine Architektur, die auf ein Modulsystem aufsetzt und im Backend Microservices nutzt, viele Vorteile ausspielen.

Thomas Kruse: Es gibt nicht nur Nachteile bei einem monolithischen Ansatz. Gerade wenn es um hochintegrierte Frontends geht, kann hier eine Architektur, die auf ein Modulsystem aufsetzt und im Backend Microservices nutzt, viele Vorteile sowohl für Entwickler als auch Anwender ausspielen.

Typischerweise ist ein Frontend eher nach fachlichen Aufgaben aufgeteilt und weist eine etwas gröbere Granularitaet auf, als dies bei Microservices möglich ist. Jedoch bieten sich dafür auch flexiblere Möglichkeiten zur (Re-)Integration an, wie zum Beispiel Hyperlinks. Mit der passenden Architektur merkt dabei ein Nutzer nicht einmal unbedingt, dass er die Anwendung wechselt.

Markus Harrer: Softwarearchitekt*innen sollen sich von Anfang an mit den Qualitätsansprüchen der Stakeholder beschäftigen, um deren ganz konkreten Bedürfnisse frühzeitig als Einflussfaktoren für Architekturentscheidungen nutzen zu können.

Stephan Pirnbaum: Euer bestehendes System ist nicht ohne Grund so wertvoll und schwer ersetzbar geworden, wie es heute ist. Dieser Schatz darf aufgrund neuer Hypes nicht einfach weggeworfen werden. Eine Bewertung der Umsetzbarkeit neuer Technologien und Ansätze im Rahmen der kontinuierlichen Verbesserung ist daher unabdingbar. So kann man mit kontinuierlichem Einsatz und planvollem Vorgehen dem Monolithen zu neuem Glanz verhelfen, egal ob am Ende eine Microservices-Landschaft oder ein strukturierter Monolith steht.

Franziska Dessart: Unser Workshop ist ja in vier Teile gegliedert, die sich jeweils auf unterschiedliche Aspekte von Software-Architektur konzentrieren. Jeder der Teile bringt sicherlich eine eigene Kernbotschaft mit sich. Allen gemeinsam ist aber vermutlich: Am Ende geht es immer irgendwie um Kommunikation, um das Miteinander-Reden, um den Austausch und auch das Festhalten von Informationen. Wenn wir darin gut sind, schaffen wir es auch, eine gute Architektur für unsere Systeme zu erarbeiten.

Vielen Dank für Eure Interviews!

The post Software-Architektur-Trends 2019: Das sagen die Experten! appeared first on JAX.

The post Das namespace-Desaster: Jakarta EE ohne javax! appeared first on JAX.

Hans betreibt ein kleines Arthouse-Kino, das unter Cineasten einen hervorragenden Ruf genießt. Vorführungen werden oft durch Filmanalysen ergänzt. Lokales Craft-Bier rundet das Kinoerlebnis ab. Eines Tages begegnet Hans seiner Schulfreundin Anna. Als er erfährt, dass Anna seit fast zehn Jahren Apps entwickelt, kommt ihm eine Idee.

Hans: „Meine Kunden mögen den altmodischen Charme meines Kinos. Aber keiner hat Lust, drei Tage vor einer Vorstellung an die Kasse zu kommen und Karten zu kaufen. Und dann gibt’s lange Gesichter, wenn eine Vorstellung ausverkauft ist. Kannst du nicht eine App für mich entwickeln?“

Anna: „Ein Kinosaal, zwei bis drei Vorführungen pro Tag, Karten verkaufen. Klingt machbar.“

Hans: „Super! Aber eine Kleinigkeit noch: Wir haben auch Vorträge von Filmkritikern im Programm. Und die Abendkasse brauche ich schon noch, komplett auf die App zu setzen ist mir dann doch zu riskant. Aber die Abos würde ich schon gern über die App verwalten.“

Anna: „Abos? Vorträge? Abendkasse? Das ist ja komplizierter als gedacht…“

Am nächsten Tag treffen sich die beiden wieder. Sie stehen vor einem Whiteboard, Anna hält einen Whiteboard-Marker in der Hand.

Anna: „Ich hab gestern verstanden, dass die App im Wesentlichen drei Anwendungsfälle hat: Abos verkaufen, Einzeltickets verkaufen und Tickets für Vorträge verkaufen.“

Hans: „Äh, ja, das klingt gut.“

Anna: „Ich würde gern verstehen, wie du heute arbeitest. Die App muss ja schließlich in deine Arbeitsabläufe reinpassen. Wollen wir vielleicht mal mit dem Ticketverkauf an der Abendkasse anfangen?“

Hans: „Das ist einfach. Man verkauft die Karten und streicht den Sitzplatz aus dem Saalplan und…“

Anna: „Warte mal. Wer verkauft die Karten?“

Hans: „Ich habe zwei Studenten, die bei mir jobben. Aber manchmal mach ich das auch selbst.“

Anna: „Okay, aber welche Rolle hast du dann?“

Hans: „Ach so, bei uns heißt das Kartenverkäufer.“

Anna malt ein Männchen an das Whiteboard und schreibt „Kartenverkäufer“ darunter (Abb. 1).

Abb. 1: Hans‘ Rolle ist „Kartenverkäufer“

Anna: „Und wer kauft die Karten?“

Hans: „Ein Besucher. Also einer ohne Abo.“

Anna malt ein zweites Männchen und nennt es „Besucher“. Am Rand notiert sie, dass der Besucher kein Abo hat (Abb. 2).

 

Abb. 2: Der „Besucher“ hat kein Abo.

Anna: „Was muss ich als Besucher tun, um eine Karte zu kaufen?“

Hans: „Du sagst dem Kartenverkäufer, welche Vorstellung du sehen willst. Also welchen Film an welchem Tag und welcher Zeit. Und wie viele Karten du haben willst.“

Anna: „Ich male hier eine Sprechblase, weil die beiden miteinander reden.“

Anna zeichnet weiter. An den Pfeil schreibt Anna eine Eins (Abb. 3).

 

Abb. 3: Kartenverkäufer und Besucher kommunizieren

Anna: „Und dann?“

Hans: „Meistens schlägt der Kartenverkäufer die besten noch verfügbaren Sitzplätze vor.“

Anna: „Und wie macht der Kartenverkäufer das?“

Hans: „Man schaut auf den Saalplan der Vorstellung. Darauf sieht man, welche Sitzplätze schon verkauft sind und wo noch was frei ist.“

Anna zeichnet und wiederholt, was sie verstanden hat (Abb. 4).

 

Abb. 4: Der Ticketverkäufer sucht nach freien Sitzplätzen für den Besucher

Anna: „Der Ticketverkäufer sucht im Saalplan nach der gewünschten Anzahl freier Sitzplätze. Stimmt das so?“

Innerhalb weniger Minuten füllt sich das Whiteboard mit einer fachlichen Geschichte, die erzählt, wie ein Kinobesucher Karten an der Abendkasse kauft (Abb. 5). Am Ende erzählt Anna die Geschichte noch einmal von vorne.

 

Abb. 5: Wie ein Besucher Karten an der Abendkasse kauft

Hans: „Ja, das passt so. Nur die Filmanalysen habe ich vergessen.“

Anna: „Du meinst das mit den Filmkritikern? Sind das nicht eigene Veranstaltungen?“

Hans: „Nein. Die Filmanalysen finden nach der Vorführung statt. Wir bieten das bei ein, zwei Vorführungen pro Woche an. Die sind dann etwas teurer. Extra verkaufen tun wir die Vorträge nicht, das wäre zu kompliziert. Man muss die Besucher nur darauf hinweisen, dass die Vorführung im Anschluss von einem Filmkritiker analysiert wird.“

Anna: „Wann macht der Kartenverkäufer das?“

Hans: „Hier.“

Hans zeigt auf den Pfeil mit der Nummer 3. Anna ergänzt einen Kommentar (Abb. 6).

 

Abb. 6: Anna und Hans füllen ihr Modell mit Kommentaren

Anna: „Du verkaufst auch Abos. Wie funktioniert das?“

Anna dreht das Whiteboard um und Hans beginnt mit einer neuen Geschichte (Domain Story).

Nach wenigen Domain Stories hat Anna einen guten Einblick in die Domäne „Kino“ erlangt. Sie kennt Begriffe wie „Saalplan“, „Vorführung“ und „Kartenverkäufer“. Sie hat ein erstes Verständnis der wichtigsten Abläufe und kann sich nun Gedanken machen, was die Einführung einer App für diese Abläufe bedeuten würde.

Das Bild zur Geschichte

Es ist sehr einfach, jemandem zuzuhören und zu glauben, dass man ihn verstanden hat. Man nickt und stimmt zu – und hat dabei ein völlig anderes Bild im Kopf. Menschliche Kommunikation ist durch Missverständnisse geprägt. Deshalb unterstützt Domain Storytelling beim aktiven Zuhören. Wir lassen uns nicht nur einfach eine Geschichte erzählen. Beim Zuhören zeichnen wir die Domain Stories vor den Augen der Fachleute auf. Dazu verwenden wir bewusst einfache Symbole. Die Fachleute sehen unmittelbar, ob wir ihre Geschichte richtig wiedergeben können. Damit folgen wir dem agilen Grundprinzip des möglichst frühen Feedbacks.

Die Bildsprache besteht aus zwei Arten von Symbolen und einer Art von Pfeil (Abb. 7):

Actors – Die handelnden Personen und IT-Systeme einer Geschichte. Typischerweise benannt mit einer Rollenbezeichnung oder Persona.

Abb. 7.1: Der “Actor”-Teil der Bildsprache
 
Work Objects – Die Arbeitsgegenstände, mit denen die Akteure ihre Arbeit machen. Oft etwas, das man anfassen und sehen kann, wie der Saalplan. Manchmal auch ein vergegenständlichtes Konzept, wie die Vorstellung.

Abb. 7.2: Der “Work Object”-Teil der Bildsprache
 
Activities – Das, was die Akteure tun.

Abb. 7.3: Der “Activity”-Teil der Bildsprache

Durch die Symbole der Work Objects sehen wir, welche Informationen verbal ausgetauscht werden (Symbol: Gesprächsblase) und in welchen Schritten (digitale) Dokumente eine Rolle spielen (Symbol: Dokument). Die Symbole dienen also nicht bloß der Optik, sondern veranschaulichen wichtiges Wissen über den Prozess. Je nach Domäne werden die Symbole angepasst. In einem Logistikunternehmen ist beispielsweise ein Symbol für einen Container nützlich, wenn in der Domain Story dargestellt wird, dass Container verladen werden. Für diesen Artikel verwenden wir einige Google Material Icons [1], die gut zu typischen Bürotätigkeiten passen und sich in vielen Domänen bewährt haben.

Mit dieser einfachen Notation können wir leicht verständliche Sätze verbildlichen: „Der Kartenverkäufer sucht freie Sitzplätze im Saalplan“ wird zu Abbildung 8.

 

Abb. 8: Via Icons lassen sich Sätze leicht verbildlichen

Reiht man mehrere Sätze aneinander, entsteht eine Geschichte. Die Aktivitäten zu nummerieren drückt die Reihenfolge der Sätze aus. Da eine Geschichte ohne Fallunterscheidungen erzählt wird, benötigt die Bildsprache keine Symbole für Verzweigungen. Annahmen, Varianten und Ausnahmen einer Domain Story können als textuelle Notizen festgehalten werden. Wichtige Varianten, die sich nicht mit einer kurzen Notiz beschreiben lassen, verdienen eine eigene Domain Story.

Die Akteure sind der Dreh- und Angelpunkt einer Domain Story. Daher kommt jeder Akteur nur einmal pro Domain Story vor. Work Objects können hingegen mehrfach auftauchen, wenn sie zu unterschiedlichen Zeitpunkten der Geschichte eine Rolle spielen. Im Lauf der Geschichte können Work Objects durch unterschiedliche Symbole repräsentiert werden. In unserem Kinobeispiel könnte eine Kinokarte etwa erst digital als E-Mail verschickt und später auf Papier gedruckt werden.

Von der Erzählung zum Bild

Domain Stories werden in Workshops erzählt. Neben einem Moderator braucht es dazu Fachexperten, die aus erster Hand zur Geschichte beitragen können. In komplexen Domänen gibt es immer seltener eine einzelne Person, die eine Geschichte von Anfang bis Ende kennt. Deswegen versammelt man Vertreter verschiedener Fachabteilungen und der IT, die die Geschichte gemeinsam erzählen.

Domain Storytelling macht auf unterschiedliche Arten Spaß. Wenn man noch unerfahren ist, wird man es schätzen, wenn ein Moderator die Diskussion führt und zentral die Domain Story aufzeichnet. Häufig ist der Moderator der wichtigste Nutznießer der Domain Stories – etwa, wenn er als Product Owner, Softwareentwickler oder Businessanalyst das erworbene Wissen für ein Entwicklungsprojekt nutzt. Erfahrene Teams machen auch gerne Sessions, bei denen alle zusammen vor dem Whiteboard stehen und gemeinsam Pfeile malen und Zettel kleben.

Je nachdem, was mit dem Workshop bezweckt wird, müssen die Geschichten mal oberflächlich und breit und mal mit klarem Fokus und detailliert erzählt werden. Außerdem muss ein Moderator gegensteuern, wenn sich Diskussionen entwickeln, die das Fortschreiten der Geschichte verhindern. Ein typisches Beispiel: An einem Punkt der Geschichte diskutieren die Teilnehmer, was alles passieren könnte. Solche Diskussionen lassen sich auflösen, indem die Geschichte konkretisiert wird und Annahmen ergänzt werden: “Nehmen wir an, es sind genügend Sitzplätze nebeneinander frei. Was passiert als Nächstes?”. So verzetteln sich die Teilnehmer nicht in Sonderfällen.

Je nach Anzahl der Teilnehmer, verfügbarer Raumausstattung und der Anzahl an Domain Stories können unterschiedliche Werkzeuge zur Visualisierung eingesetzt werden. Flipcharts und Marker sind in den meisten Besprechungsräumen vorhanden. Leider sind Flipcharts am schlechtesten geeignet, weil Änderungen damit schwierig sind. Und weil man so oft missversteht, was eigentlich gemeint wurde, muss man Domain Stories häufig ändern. Deshalb hat sich als bisher gängigste Offlinevariante eine Kombination aus Whiteboard und Klebezetteln entwickelt (Abb. 9). Diese eignet sich auch sehr gut für kooperatives Domain Storytelling ohne dedizierten Moderator.

 

Abb. 9: Offlinevariante mit einer Kombination aus Whiteboard und Klebezetteln

Auch computergestützt gibt es einige Möglichkeiten, etwa mit Tablet und Stift oder auf Smartboards wie dem Surface Hub (Abb. 10). Generische Modellierungs- und Zeichenwerkzeuge eignen sich zwar, um Domain Stories nach einem Workshop zu digitalisieren, aber für den Einsatz in den Workshops selbst fühlen sich solche Werkzeuge oft zu sperrig an. Aus dieser Unzufriedenheit heraus entstand der Domain Story Modeler, ein Modellierungswerkzeug, das im Browser läuft. Einfach online ausprobieren [2] oder herunterladen [3]. Die Bilder für das einführende Kinobeispiel haben wir mit dem Modeler erstellt.

 

Abb. 10: Computergestützt stehen Tablet und Stift oder Smartboards wie das Surface Hub zur Verfügung.

Jedes Werkzeug hat seine Stärken und Schwächen. Egal, welches man verwendet – es ist wichtig, dass die Domain Story jederzeit für alle sichtbar ist. Nur so funktioniert Domain Storytelling als Methode für aktives Zuhören.

Am Ende geht es nicht um die Schönheit der visualisierten Domain Story, nicht um das perfekte Werkzeug und nicht um syntaktische Korrektheit. In den Workshops steht der gemeinsame Erkenntnisgewinn über dem Erstellen von Dokumentationen. Die abfotografierten oder digital erstellten Domain Stories dienen als Gedächtnisstütze für die Teilnehmer eines Workshops. Sie können die Teilnahme am Workshop aber nicht ersetzen.

Von Domain Stories zum Code

Wer nur einen Hammer als Werkzeug hat, sieht die Welt voller Nägel. In Entwicklungsprojekten reicht selten nur ein Modellierungsansatz aus. Wir starten zum Beispiel manchmal mit einem Big-picture-Event-Storming (siehe vorhergehender Artikel). Wenn wir dabei auf eine Häufung von Ereignissen stoßen, die von kooperativer Arbeit geprägt sind, nutzen wir im zweiten Schritt Domain Storytelling für eine tiefere Analyse.

Um eine Domäne zu verstehen und mit Fachexperten darüber zu sprechen, reicht es in der Regel aus, 80 Prozent der Fälle abzudecken: die wichtigsten, häufigsten, schwierigsten und aufwendigsten Varianten eines Geschäftsprozesses.

Aus diesem Verständnis heraus entstehen, oft parallel zur Softwareentwicklung, weitere Dokumente. Beispielsweise eignen sich Domain Stories, um Soll-Prozesse zu entwerfen. In unserem Kinobeispiel würden Hans und Anna visualisieren, wie der Verkaufsprozess an der Abendkasse in Zukunft abläuft. Sie werden dabei feststellen, dass die Kartenverkäufer einen digitalen Saalplan brauchen werden, der auch die per App verkauften Sitzplätze anzeigt (Abb. 11).

 

Abb. 11: Ein digitaler Saalplan zeigt auch per App verkaufte Karten an.

Aus solchen Domain Stories lassen sich leicht funktionale Anforderungen ableiten. Ein Beispiel: Will eine Besucherin unseres Kinos vor Ort Karten kaufen, sucht der Kartenverkäufer nach dem passenden Saalplan für die Vorstellung und bietet die freien Plätze an (Aktivitäten 2 und 3 in der Domain Story). Dazu kann man folgende Anforderung an das Kinosystem formulieren: “Als Kartenverkäufer will ich die freien Plätze für eine Vorstellung ermitteln, damit ich sie einem Besucher anbieten kann.”

Domain Storytelling und Domain-Driven Design

Domain Storytelling passt ideal zu Domain-Driven Design und unterstützt die drei Säulen des Domain-Driven Design (Kasten: „ Die drei Säulen des Domain-Driven Design“).

Überspannt werden diese drei Säulen vom Konzept der Ubiquitous Language. Diese haben wir als Fachsprache innerhalb eines Bounded Contexts bezeichnet. Diese Fachsprache soll allgegenwärtig (engl. ubiquitous) sein – vom Whiteboard bis hinein in den Code. Domain Storytelling hilft dabei, die Worte zu finden, die die Ubiquitous Language formen. Diese Worte werden wir später auch im Code wiederfinden.

Zum Schluss: Domain Storytelling lernen und selbst machen

Domain Storytelling ist eine einfache Technik. Um sie aber auch in größeren Gruppen sicher anwenden zu können, braucht man als Moderator etwas Erfahrung. Die bekommt man nur durch Übung. Wir empfehlen daher, erstmal klein anzufangen. Probieren Sie Domain Storytelling allein, mit Stift und Papier oder online mit dem Modeler. Wenn Sie die Notation verinnerlicht haben, schnappen Sie sich eine Kollegin oder einen Kollegen, um die Rolle des Fachexperten zu übernehmen. Üben Sie, wie Domain Storytelling im Dialog funktioniert. Danach sind Sie bereit für Workshops mit mehreren Teilnehmern.

Mehr zu Domain Storytelling finden Sie auf: http://domainstorytelling.org.

Links & Literatur

[1] Google Material Icons: https://material.io/icons/
[2] Domain Story Modeler ausprobieren: wps.de/modeler
[3] Domain Story Modeler auf GitHub: https://github.com/WPS/domain-story-modeler

The post Domain-Driven Design: Wie Domain Storytelling Fachexperten und Entwickler zusammenbringt appeared first on JAX.