Konferenzen zu Softwarearchitektur für Praktiker gibt es mittlerweile viele. Mit erfreulicherweise wirklich hohem fachlichen Niveau. Am 22. und 23. Oktober war wieder die Software Architecture Alliance. Sie hat sich im Kalender fest etabliert und gehört zu unseren absoluten Lieblingskonferenzen. Wir (Matthias & Dominik) waren wieder dort und wir hatten eine richtig gute Zeit. Die Konferenz ist mit Ihren tollen Vorträgen, der familiären Atmosphäre, der perfekten Organisation und vielen inspirierenden Gesprächen ein absolutes Highlight.

Gerne möchten wir in diesem Artikel auf ein paar ausgewählte Vorträge zurückblicken und ein paar Gedanken festhalten und teilen.

Softwarearchitektur überwindet Gräben und Lücken  

Architektur und Code

In der Keynote „Architektur von unten – die Brücke schlagen zwischen Code und Architektur“ hat Oliver Drotbohm (VMWare) schön aufgezeigt, wie weit auch heute noch häufig die Lücke zwischen intendierter Architektur und ihrer Umsetzung im Code klafft. Es ist schon erstaunlich, dass sich diese Lücke so hartnäckig hält und selbst scheinbar gut dokumentierte Architekturen häufig kaum im umsetzenden Code wiederzuerkennen sind. Dass dies zu Problemen bei Verständnis und Wartbarkeit eines Systems führt ist die zwangsläufige Konsequenz.

Oliver hat dabei noch mal schön an die „architecture-evident coding styles“ von George Fairbanks erinnert. Doch dieser Gedanke hat sich leider noch zu wenig durchgesetzt. Man fragt sich wirklich, wie es passieren konnte, dass diese Lücke immer noch so sehr klafft. Und das, obwohl die Architektur ja eigentlich genau dazu da ist, zu definieren und zu beschreiben, wie ein System und sein Code auszusehen haben bzw. aussehen.

Um diese Lücke zu schließen, hat Oliver zwei technologische Ansätze und Frameworks vorgestellt. xMolecules und Spring Modulith. Diese beiden Frameworks führen für bestimmte Arten der Systemmodellierung und -umsetzung Architektur und Code bedeutend näher zusammen: nämlich bei Domain-Driven Design (DDD) und bestimmten Programmiersprachen wie Java und Frameworks wie Spring. Sie bilden dabei z.B. Architekturkonzepte wie Aggregates aus DDD direkt sichtbar und qualitätssicherbar im Code ab.

Grundsätzlich sollten sich alle Architektinnen und Architekten immer Gedanken machen, wie sie die Architektur möglichst gut im Code sichtbar machen können und verhindern können, dass sich der Code von der Architektur schleichend entfernt. Zumindest für bestimmte Systemteile und Programmiersprachen gibt es mit den von Oliver vorgestellten Frameworks jetzt schon Unterstützung bei dieser Herausforderung.

Den Vortrag von Oliver bei einer anderen Konferenz gibt es als Video, sodass ihr euch alles in Ruhe anschauen könnt.

Architektur und Daten

Matthias Niehoff (Codecentric) kümmerte sich in seinem Vortrag „Data architectures in the wild“ um die Lücke, die zwischen Software Engineering (und damit Softwarearchitektur) und Data Engineering in großen Unternehmen klafft. Mit dem Bereich Data Engineering bezieht er sich dabei insbesondere um die Organisationseinheiten und Rollen in Unternehmen, die unternehmenseigene Daten analysieren und daraus Erkenntnisse und Aktionen für das Business ableiten.

Diese Organisationseinheiten sind meist separat von den Einheiten, die Software für die Unterstützung des Business entwickeln und betreiben. Und das, obwohl das Data Engineering auch in großem Stil mit Software arbeitet und nicht selten auch einiges an Software baut, um Datenanalyse machen zu können.

Trotzdem arbeiten diese Unternehmensbereiche bis dato meistens eher separat. Mit den entsprechenden Folgen dieser Lücke.

Um es hart auf den Punkt zu bringen: das Software Engineering kümmert sich meist nicht um Daten (siehe auch mein früherer Blogartikel) und das Data Engineering kümmert sich meist nicht um solide Software. Und das, obwohl jede Seite mehr als genug mit der anderen Seite zu tun hat. Aber traditionell war da nicht so der Fokus drauf und deshalb ist es auch heute noch oft so.

In einer Zeit, wo Software aber immer komplexer wird und Daten immer wichtiger für Unternehmen, um gute Entscheidungen zu treffen, darf diese Trennung nicht so bleiben. Beide Seiten müssen sich annähern. Und dafür hat Matthias Niehoff in seinem Vortrag sowohl die Dringlichkeit verdeutlicht als auch mögliche Lösungsansätze vorgestellt.

Architektur und KI

Lars Röwekamp (OpenKnowledge) sprang kurzerhand ersatzweise (und vor allem dankenswerterweise!) mit seinem Workshop „Generative AI – Vom Prototypen zum produktiven Einsatz“ ein. In diesem Workshop hat Lars insbesondere toll herausgearbeitet, was es bedeutet, Large-Language Models (LLMs) in produktionstauglichen Unterlösungslösungen einzusetzen.

Wichtige Erkenntnis dabei: im Moment kann nahezu kein Unternehmen mehr selbst von Grund auf ein LLM entwickeln und trainieren, das wettbewerbsfähig ist. Die schon existierenden Modelle z.B. von OpenAI, Meta, Nvidia, Anthropic, … sind so gut, dass es nicht mehr möglich ist, mit vertretbarem Aufwand etwas Ähnliches zu erschaffen. Es gilt deshalb, existierende Modelle möglichst geschickt zu verwenden und eigene Lösungen darauf aufzubauen.

Lars hat eindrucksvoll gezeigt, wie herausfordernd das ist und welche Gesamtarchitekturen aufgebaut werden müssen, um ein „Standard-LLM“ möglichst passend „einzupacken“ und es für individuelle Aufgaben fit zu machen. Dabei hat er insbesondere Ansätze für „Retrieval Augmented Generation“ (RAG) vorgestellt. Was für Softwarearchitekten besonders spannend dabei ist: Wie viele Schritte entlang der Verarbeitungspipeline notwendig sind, wenn im Inneren der Lösung ein LLM seinen Dienst verrichtet. Lars hat schön gezeigt, wie viele weitere LLMs typischerweise zum Einsatz kommen, um Vorverarbeitungen und Nachverarbeitungen zu machen und sowohl die Benutzer davon abzuhalten, Unfug mit dem LLM zu treiben als auch den Nutzer vor „Unfug (bzw. Halluzinationen)“ des LLM zu schützen.

Beim Experimentieren mit LLMs spielt Softwarearchitektur eine sehr untergeordnete Rolle. Wenn daraus aber produktive Lösungen werden sollen, kommt plötzlich wieder viel Softwarearchitektur ins Spiel Lars hat dazu aber auch schön gezeigt, dass es beim Aufbau von Pipelines rund um LLMs häufig um das geschickte, experimentelle Finden von geeigneten Konfigurationsparametern geht. Das ist eine Vorgehensweise, die sonst so in der Softwarearchitektur eher weniger üblich ist. Genauso wie es eher unüblich ist, dass man entlang der Verarbeitung recht wenig Einblick in die eigentliche Datenverarbeitung nehmen kann.

In diesem Sinne müssen Softwarearchitekten noch einiges lernen und sich darauf einstellen, dass zukünftige Lösungen immer mehr Anteile von KI-Komponenten haben werden. Mit allen damit einhergehenden Möglichkeiten, aber auch der schwierigeren Beherrschbarkeit.

Architekturdokumentation

Jacqui Read (Read the Architecture) hielt die Keynote „Design Patterns for Software Diagramming“. Sie setzt in diesem Vortrag am Problem an, dass selbst wenn Diagramme in einer Architekturdokumentation vorhanden sind, diese häufig schwer zu lesen, zu deuten und zu merken sind.

Dafür stellt sie zahlreiche Pattern und Anti-Pattern zur Verfügung, mit denen es leichter fällt, bessere Architekturdokumentation und vor allem Diagramme zu erzeugen. Es ist immer wieder erstaunlich, was für grundlegende Prinzipien leider häufig in der Praxis verletzt werden: Orientierung der Dokumentation an der Zielgruppe. Wiederkehrende Anordnungen. Verwendung von Legenden und Erläuterungen. Und viele mehr …

So erscheint manches Pattern als „offensichtlich“, aber auch unsere Erfahrungen in vielen Projekten zeigen, dass man diese Pattern gar nicht oft genug predigen bzw. sehen kann und dass es immer wieder gut ist, die Anti-Pattern als Warnung zu sehen.

Ein besonderer Ausflug und ein besonderes Anliegen von Jacqui ist die Berücksichtigung von Sehschwächen wie verschiedene Arten von Farbenblindheit. Sie legte viel Wert darauf, unterschiedliche Farb-Paletten und ihre Wirkungen bei Menschen mit bestimmten Arten von Sehschwächen zu zeigen. Das ist sicher ein Thema, das viele noch nicht so intensiv auf dem Schirm haben und das mehr Aufmerksamkeit verdient.

Wer sich den Vortrag anschauen möchte, kann ein Video von einem ähnlichen Vortrag von Jaqui bei einer anderen Konferenz ansehen.

Unsere Blog-Serie zu Architekturdokumentation setzt an der gleichen Zielstellung an: Einfache Tipps für bessere dokumentierte Softwarearchitekturen. Der aktuellste Beitrag der Serie findet sich hier.

Architektur-Reviews

Architektur-Reviews sind extrem hilfreich in zahlreichen Konstellationen rund um Softwaresysteme (siehe Blog-Artikel zu Architektur-Reviews).

Auch bei der Software Architecture Alliance hatten Architektur-Reviews wieder ihren Platz im Programm. Es ist immer schön zu sehen, dass auch solch methodische und wenig „hype-trächtige“ Beiträge ihren Weg ins Programm finden.

Die Methode LASR

Stefan Zörner (Embarc) hielt einen sehr schönen Vortrag zur neuen Bewertungsmethode LASR (Light-Weight Approach for Software Reviews). Er nahm das Publikum mit auf die Reise die Methode gleichzeitig kennenzulernen und zu erleben. Dazu hatte er toll ein Beispiel zum Messenger Threema integriert und die Zuhörer konnten selbst bei Einschätzungen und Beurteilungen im Rahmen des Reviews mitmachen.

Die Methode ist voll darauf ausgerichtet, Teams einen schnellen und leichtgewichtigen Einstieg in Software Reviews zu bieten. Selbst wenn nur vergleichsweise wenig Zeit zur Verfügung steht, wie z.B. ein Nachmittag.

Ein besonders attraktiver Bestandteil der Methode ist die Unterstützung durch ein Kartenset, das einerseits eine gewisse Gamification und Spaß reinbringt. Andererseits setzt es aber wichtige Trigger, damit zentrale Aspekte und Risiken bei einem Review nicht übersehen werden.

Erfahrungsschatz aus Architektur-Reviews

Review-Methoden kennenzulernen ist nur ein erster Schritt zu erfolgreichen Reviews, vor allem in kritischen Situationen. Denn ein wesentlicher Erfolgsfaktor ist die Erfahrung aus anderen Architektur-Reviews.

Deshalb hatten wir (Matthias & Dominik) beschlossen, einen Workshop bei der Konferenz anzubieten und gesammelte Erfahrungen aus zahlreichen Review-Projekten zu teilen. Wir zeigten, welches Vorgehen sich für welche Projektsituation und Aufgabenstellung eignet, von leichtgewichtiger Absicherung bis Vorbereitung einer Systemmodernisierung. Das Ganze anhand von konkreten, wiederkehrenden und herausfordernden Fragestellungen. Dazu gab es Tipps, wie man damit umgehen kann und was man besser bleiben lässt. Jedes Projekt (die wir natürlich komplett anonymisiert hatten) haben wir mit einem Tier illustriert, das für uns einige Eigenschaften des Projekts zusammenfasst.

Der Workshop war so angelegt, dass einerseits wir über unsere Erfahrungen plauderten, aber andererseits auch unsere Zuhörerinnen und Zuhörer sich sehr aktiv einbringen konnten. Und das taten sie mit tollem Engagement. So entwickelte sich genau die Art der Interaktion und des tiefgehenden Austauschs, die wir uns gewünscht hatten. Vielen Dank dafür noch mal allen, die dabei waren, sich so engagiert haben und den Workshop noch mehr als eine halbe Stunde mit uns in die verdiente Mittagspause verlängerten.

Die Folien des Vortrags gibt es auf Speakerdeck. Wir hätten noch zahlreiche Beispiele mehr gehabt. Vielleicht gibt es diese mal in einer Fortsetzung des Workshops …

Fazit

Die Software Architecture Alliance war wie immer großartig. Wir nehmen wie immer viele Eindrücke aus den tollen Vorträgen und Gesprächen mit. Zwei Tage, sich komplett in einen anderen Modus zu begeben, lässt uns gedanklich ein paar Schritte zurückzutreten. Dabei kommen direkt wieder neue Gedanken und Ideen für unsere Kundenprojekte und auch für zukünftige Vorträge. Es ist einfach großartig, in einem so spannenden Themenfeld und Umfeld arbeiten zu können!