Das Software Architecture Gathering 2024 des iSAQB [1] fand vom 11. bis 14. November in Berlin im H4 Hotel am Alexanderplatz statt. Wir waren dabei und teilen hier unsere Eindrücke.

Die Veranstaltung richtet sich an ein internationales Publikum, so dass alle Vorträge auf Englisch gehalten wurden – auch wenn sicherlich ein Großteil der Teilnehmer als auch Redner deutschsprachig waren. Zielgruppe sind primär Softwarearchitekten – von denen das iSAQB laut eigener Aussage übrigens seit 2008 schon 30.000 zertifiziert hat.

Die Agenda umfasste ca. 45 Programmpunkte, darunter 4 Keynotes, 8 Workshops und 33 Vorträge. Die Workshops fanden am ersten und letzten Tag statt, während Keynotes morgens und abends an den mittleren Tagen gehalten wurden. Die parallelen Vortrags-Tracks machten einen Besuch aller Vorträge unmöglich, unsere zweiköpfige Präsenz erlaubte uns aber eine recht gute Abdeckung.

Ein inhaltlicher Blick auf die Agenda der Konferenz zeigt eine bunte Mischung an Themen, wobei “Künstliche Intelligenz” (KI) – oh Wunder – dieses Jahr dominierte. 8 Vorträge oder 18 % des Programms beschäftigten sich explizit mit KI. Indirekt kam das Thema sogar in fast der Hälfte der Vorträge vor. Das Top-Thema der vergangenen Dekade – Microservices – ist mit nur noch 4 ausdrücklichen Erwähnungen in der Agenda damit vom Thron gestoßen, obwohl sie auch noch in mindestens drei weiteren Sessions, in denen sie zwar nicht im Titel aufgeführt waren, thematisiert wurden. Agile und DevOps sowie Security waren mit jeweils 4 bzw. 3 Vorträgen vertreten. Abgerundet wurde das Programm durch Themen wie bspw. Legacy-Modernisierung oder Teamstrukturen im Umfeld Softwareentwicklung.

Der Kreis der Vortragenden bot wenig Überraschungen, es handelte sich um eine Mischung aus Vertretern der Industrie sowie Beratung und den “üblichen Verdächtigen” der Szene wie z.B. Carola Lilienthal, Gernot Starke, Eberhard Wolff, Michael Plöd, Rebecca Parsons oder Uwe Friedrichsen.

Vorträge

Die erste Keynote von Dr. Gernot Starke, „Tiger Alert: Better Run Away!“ [2], begann vielversprechend, entpuppte sich jedoch größtenteils als Zusammenfassung von Daniel Kahnemanns bekanntem Buch „Thinking, Fast and Slow“. Obwohl die Zusammenfassung gut präsentiert und mit zusätzlichen Quellen angereichert war, fehlte uns hier neben der Aktualität der Bezug zur Softwarearchitektur. Kahnemanns Werk ist zweifellos wertvoll, aber auf einer Konferenz, die sich an Softwarearchitekten richtet, hätten wir uns mehr Transferleistung, also Einblick in die Anwendung dieser Konzepte auf Herausforderungen in unserem Bereich gewünscht

Als ein mögliches Beispiel könnten wir hier die Schwachstelle CWE-1007 [3] aufzeigen, bei der Anwender, und dazu zählen in diesem Fall auch Entwickler und Architekten, durch visuell ähnliche Zeichen in die Irre geführt werden. Hierbei wird einem nicht das berühmte X für ein U, sondern bspw. eine Null für ein “O” oder das lateinische „e“ für das zum Verwechseln ähnliche kyrillische „е“ vorgemacht. Kahnemans System 1, die Intuition bzw. der Autopilot schlagen hier zu und wir klicken als Anwender auf die gefälschte URL, wodurch z.B. ein Trojaner heruntergeladen wird. Als Entwickler wird uns im Sourcecode so bspw. eine ähnlich lautende Methode mit anderer Funktionalität untergeschoben. Was kann ich als Softwarearchitekt dazu beitragen, damit so etwas nicht passiert? Bspw. darauf hätten wir uns als Teilnehmer dieses Vortrags Antworten erhofft.

Als nächsten Vortrag haben wir uns “Generative AI Meets Software Architecture” von Lars Röwekamp [4] angeschaut. Über Fragen der Modellauswahl und -integration sowie Grundlegendem zum Prompting führt der rote Faden hier zielgerichtet zum Thema Retrieval Augmented Generation (RAG) um aktuelles und Domänen-spezifisches Wissen in GenAI-Abfragen zu integrieren.

Für Anfänger im Umfeld Integration von GenAI, an die sich dieser Vortrag richtet, gab er einen durchaus interessanten Überblick.

Ein für uns interessanter, aber unbestätigter Fakt aus dem Vortrag besagt, dass der Bau der großen Large Language Modelle rund 50 Millionen USD alleine an Rechenkapazitäten kosten soll. Was aber erklären würde, warum die unserer Wahrnehmung nach oft leichtfertig dahin gesagte Aussage „Dann bauen wir eben unser eigenes Modell“ in der Praxis für die meisten Unternehmen absehbar nicht umsetzbar sein wird – und es wohl beim RAG bleibt.

Unser Fazit – aus dem Vortrag, aber auch allgemein zum Thema:

  • GenAI ist mächtig – aber teuer.
  • (Gutes) Prompting ist der Schlüssel.
  • Jedes Modell hat seinen eigenen Charakter.
  • RAG, um Domänenwissen einzubinden und aktuell zu bleiben.
  • GenAI ist auch nur Software – behandle sie auch so.

Sowohl inhaltlich als auch hinsichtlich des Anspruchsniveaus (“Intermediate”) anschließend, war dann Robert Glasers “The Architecture of Reliable AI: RAG” [5]. Wenn auch technisch detaillierter hergeleitet, lautet aber auch seine Aussage, dass RAG das Mittel der Wahl für GenAI im Unternehmenseinsatz ist: “Put everything in the prompt”. Hier kommen allerdings die Begrenzungen der verschiedenen Modelle zum Tragen. Was u.a. erklärt, warum ich nicht einfach mein ganzes Unternehmens-Intranet in jede meiner GenAI-Abfragen packen kann, sondern relevante sogenannte Chunks finden (“retrieve”) muss, um die ich meine Abfrage (“Prompt”) erweitere (“augment”).

Für das Retrieval setzt der Redner auf einen hybriden Ansatz aus klassischer Volltextsuche (für spezifische Anfragen) und Vector-Suche mit Embeddings (für allgemeine Anfragen), deren Funktionsweisen er jeweils gut erläutert. Die Vorteile der Vector-Suche liegen demzufolge darin, dass sie immer Ergebnisse liefert, diese nach Ähnlichkeit sortiert, sprachübergreifend aufgrund semantischer Ähnlichkeit funktioniert und relevante Inhalte trotz unterschiedlicher Formulierungen findet. Ergänzt wird dies durch die klassische Volltextsuche, die insbesondere die Unschärfe in vektorbasierten Ergebnissen ausgleichen soll.

Das Ganze wird an einem Beispiel aus dem Leben eines Softwarearchitekten (“Wie kam es zu der Architektur unseres Online-Shops?”) durchgängig verdeutlicht – in Summe also ein runder Vortrag.

Technischer wurde Allard Buijze in seinem Vortrag “Event Sourcing – Technical Detail or Architectural Powerhorse?” [6]. Nun ist Event Sourcing kein ganz neues Pattern, Martin Fowler erwähnt es bspw. bereits 2005 [7], wir nehmen es in deutschen Softwareorganisationen seit rund 10 Jahren vermehrt wahr. Somit ist der Ansatz aber etabliert genug, um aus Softwarearchitektursicht zu hinterfragen, ob es sich dabei eher um ein zu vernachlässigendes Implementierungsdetail handelt oder er sich vielleicht doch zum Allzweckmittel (“Zugpferd”) des modernen Softwarearchitekten gemausert haben könnte.

In dem Vortrag wurde über eine historische Einordnung des Themas den Anwesenden zunächst der Spiegel vorgehalten. So hat sich sicherlich jeder Softwarearchitekt schon mal dazu hinreißen lassen, einer klassischen Mehrschichtarchitektur einfach eine weitere Abstraktionsschicht hinzugefügt zu haben, um das gerade anstehende Problem “elegant”, also schnell, gelöst zu bekommen. Meist dauert es dem Redner zufolge dann nicht lange und es werden in den Schichten Caches aufgebaut, um die – durch die vielen Schichten langsamer werdenden – Zugriffe wieder zu beschleunigen. Am Ende entsteht auch so dann doch wieder der gern zitierte Big Ball of Mud der Softwareentwicklung, für den es auch in diesem  Vortrag ein schönes Bild gab:

Die Umsetzung von Änderungen an der Software werden bei diesem Architekturstil also zwangsläufig über die Zeit länger dauern. (Etwas) Besserung kam dann mit Domain-Driven Design (“DDD”) [8] ins Spiel:

Im weiteren Verlauf des Vortrags wurden dann Event-Sourcing und die dazugehörigen Konzepte wie Event-Streaming, CQRS, Messaging, etc. und insb. ihre Vorteile wie z.B. Testbarkeit, Skalierbarkeit, einfache Anpassung an veränderte Business-Anforderungen (insb. in Kombination mit DDD) ausführlich dargestellt. Nicht ganz verwunderlich, da er Gründer und CTO einer Softwarefirma für Tools zum Event Sourcing ist, kommt der Redner zum Schluss des durchaus guten Vortrags zu der Erkenntnis, dass Event Sourcing sowohl Implementierungsdetail als auch Allzweckmittel für Softwarearchitekten sei.

Wir sehen die Vorteile von Event Sourcing und kennen auch zahlreiche erfolgreiche Implementierungen, sehen aber auch deren Komplexität und wissen, dass sie nicht immer passen, sondern es, wie so oft, auf den Use Case ankommt.

Gregor Hohpe hat in seiner Keynote „Architects Aren’t the Smartest People in the Room“ [9] einen Nerv bei uns getroffen. Wir stören uns schon länger daran, dass ein guter Softwarearchitekt laut manchen Quellen so etwas wie der mysteriöse Superheld eines jeden IT-Projekts ist. So soll dieser (laut ChatGPT) über

  • technische Fähigkeiten von Programmierkenntnissen, über Designprinzipien, Cloud- und Sicherheitsarchitekturen, DevOps und CI/CD bis hin zu Expertise in Datenbank-Systemen (natürlich relational wie auch non-relational) und Schnittstellendesign,
  • analytische und Problemlösungsfähigkeiten, insbesondere natürlich Komplexitätsmanagement und Abstraktionsvermögen,
  • Kommunikations- und Sozialkompetenzen, wie etwa Präsentations- und Moderationsfähigkeiten, Verhandlungskompetenzen, Erfahrungen im Stakeholdermanagement sowie idealerweise auch Führungserfahrung,
  • strategische Kompetenzen sowie
  • Expertise in agiler sowie klassischer Projektmanagementmethodik

verfügen. Natürlich hätten wir alle gerne nur solche Kolleginnen und Kollegen in unseren Projekten, jedoch ist diese Beschreibung wenig hilfreich, um das ohnehin schon überladene Bild eines Software Architekten [10] besser einzugrenzen.

Gregor Hohpe hat sich in seinem Vortrag nun in gewohnt launiger und kurzweiliger Art mit genau diesem Punkt beschäftigt. Wie bereits der Titel angibt, seien Architekten hierbei nicht die schlauesten Personen im Raum. Im Gegenteil: Es sei genau die Kernaufgabe eines Architekten, sein Umfeld smarter zu machen.

Hierzu stehen einem guten Architekten verschiedene Werkzeuge zur Verfügung, beispielsweise über Abstraktion oder Analogien (Gregor selbst liebt Analogien zu Automotoren), komplexe technische Fragestellungen diskutier- und entscheidbar zu machen. An dieser Stelle wurde der Vortrag für unseren Geschmack ein wenig generisch / oberflächlich, was aber für eine Keynote, die ein möglichst großes Publikum ansprechen soll, absolut im Rahmen war.

Insbesondere ein Prinzip ist uns lebhaft im Gedächtnis geblieben, vermutlich weil wir uns auch ein wenig ertappt gefühlt haben: “Don’t dumb things down”. Laut dem Redner gehören Top-Entscheider oftmals zu den am besten ausgebildeten, intelligenteren sowie hochmotivierten Personen innerhalb eines Unternehmens. Trotzdem neigen IT-Experten dazu, Zusammenhänge im Austausch mit IT-fremden Entscheidern sehr stark zu vereinfachen. Dass sie hierbei wirklich, wie humorvoll angemerkt wurde, beginnen besonders langsam zu sprechen, wenn eine Erklärung beim ersten Mal nicht verstanden wird, haben wir zwar noch nicht beobachten können, aber der Quintessenz, dass man diesem Gegenüber durchaus eine gewisse Komplexität zutrauen kann und es unsere Aufgabe als Architekten ist, sie genau zu dieser Diskussion zu befähigen (bspw. mit Abstraktion und Analogien), stimmen wir absolut zu.

Fazit

Dies war nur ein Auszug einiger der von uns besuchten Vorträge auf dem iSAQB Software Architecture Gathering 2024, welche unserer Einschätzung nach aber einen guten Eindruck von der Konferenz geben.

Durch die Corona-Pandemie sicherlich erzwungenermaßen, aber auch thematisch war es die vergangenen Jahre recht ruhig rund um Softwarearchitektur. Der ”KI”-Hype bietet unserer Zunft hier nun nach längerer Zeit wieder mal ein echtes Thema – “KI” ist schließlich auch “nur” Software – was es architekturell zu verstehen gilt. Echte Neuheiten bot die Konferenz in dem Umfeld allerdings nicht, durchgängiges Thema war Retrieval Augmented Generation (“RAG”), welches hier als das Mittel der Wahl beim Unternehmenseinsatz von generativer “KI” besprochen wurde – aber tatsächlich auch schon seit über einem Jahr diskutiert wird:

Das iSAQB Software Architecture Gathering bietet insgesamt eine gute Gelegenheit, sich einen umfassenden Überblick über aktuelle Themen und Trends im Bereich der Softwarearchitektur zu verschaffen. Allerdings hätten wir uns eine größere inhaltliche Vielfalt gewünscht – insbesondere bei tiefergehenden Formaten. Stellvertretend dafür steht die Tatsache, dass das Veranstaltungsprogramm ausschließlich Vorträge und Workshops der Kategorien „Beginner“ und „Intermediate“ umfasste.

Trotzdem ist das Gathering eine wertvolle Plattform für Softwarearchitekten verschiedener Erfahrungsstufen. Wir sind gespannt darauf, wie sich die Konferenz in den kommenden Jahren weiterentwickeln wird.

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting   

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting