Die Verbindung zwischen architektonischen Ideen und Code, der diese umsetzt, ist ein entscheidender Aspekt in der Softwareentwicklung. Sie ist notwendig, um im Team ein Verständnis und eine gemeinsame Vision darüber aufzubauen, was überhaupt entwickelt werden soll. Dennoch ist es seit jeher eine Herausforderung geblieben, diese Lücke zu überbrücken.

Der Vortrag behandelt grundlegende Konzepte wie Mustersprachen und wie beliebte architektonische Stile diese nutzen, um ein mentales Modell eines Systems zu etablieren. Wir begeben uns auf eine Tour durch verschiedene historische Ansätze, architektonische Konzepte im Code auszudrücken, die Herausforderungen, denen diese begegnet sind, und erfahren, warum vielleicht gerade jetzt der perfekte Zeitpunkt dafür ist, das Thema erneut anzugehen.

Wie schafft man es, die sich stetig ändernden Anforderungen in Langzeit-Projekten kontinuierlich umzusetzen? Bestehende Qualitätsanforderungen stehen immer in einem Spannungsfeld zu neuen Qualitätsanforderungen und neuen fachlichen Anforderungen. Das lässt sich besonders bei Legacy-Software beobachten: Dort ist es typischerweise entscheidend, dass das System erweiterbar und wartbar bleibt – dies bringt aber oft größere Anpassungen der Architektur mit sich.

Dieses Dilemma beleuchten wir anhand eines etwa 8 Jahre alten Projekts zur Verwaltung und Auslieferung von Firmware-Updates für IoT-Geräte. Wir betrachten konkrete Beispiele, wie wir in der Praxis die Architektur des Systems kontinuierlich an neue Anforderungen angepasst haben.

Dazu stellen wir unter anderem die Einführung eines neuen Technologiestacks, die Anpassung eines Prozesses an vollständig geänderte Qualitätsanforderungen und das Error Handling in unserer Microservice-Landschaft vor.

Immer mehr Softwareprojekte setzen auf eventgetriebene Architekturen, da sie einfache Erweiterbarkeit, Robustheit und Skalierbarkeit sowie lose Kopplung versprechen. Oft wird dabei jedoch die Komplexität der Implementierung unterschätzt. Diese ergibt sich nicht nur aus technischen Herausforderungen, die gelöst werden müssen, sondern auch daraus, dass viele unterschiedliche Vorstellungen davon existieren, was eine eventgetriebene Architektur eigentlich ist und wie sie zu funktionieren hat.

Diese unterschiedlichen Auffassungen können einerseits zu Problemen im Betrieb führen, andererseits kann ein wachsendes System neue Herausforderungen mit sich bringen, die man anfangs nicht berücksichtigt hat. Basierend auf unseren eigenen leidvollen Erfahrungen in Projekten und teils ähnlichen Erlebnissen unserer Kollegen haben wir eine Liste von Anti-Patterns identifiziert, die entweder aus unterschiedlichen Auffassungen und deren Umsetzung resultieren oder die durch Evolution des Systems die Entwicklung und den Betrieb eines solchen Systems erheblich erschweren können. In diesem Vortrag stellen wir diese Anti-Patterns vor, zeigen, welche Probleme sie verursachen und wie man sie vermeiden kann.

Architektur-Reviews finden zunehmend mehr Verbreitung und ergänzen die schon länger etablierten Code-Reviews. Das finden wir super, denn wir sind überzeugt davon, dass damit alle Entwicklungsprojekte ein sehr mächtiges Werkzeug an der Hand haben, um sich bei wichtigen Entscheidungen abzusichern oder um Probleme früh zu erkennen. Von ATAM über RATE bis zu LASR sind zahlreiche Methoden entstanden, um Architekturreviews strukturiert durchführen zu können. Aber die Methoden kennenzulernen ist nur ein erster Schritt, denn ein wesentlicher Erfolgsfaktor ist die Erfahrung aus anderen Architektur-Reviews.

Mit unserem Vortrag möchten wir euch den Start erleichtern. Wir berichten von unseren Erfahrungen aus mehr als 15 Jahren und über 75 Architektur-Reviews und machen diese auch für eure Reviews zugänglich. Wir zeigen, welches Vorgehen sich für welche Projektsituation und Aufgabestellung eignet, von leichtgewichtiger Absicherung bis Vorbereitung einer Systemmodernisierung. Wir greifen konkrete, wiederkehrende und herausfordernde Fragestellungen heraus und zeigen, wie ihr damit umgehen könnt und worauf ihr besser verzichtet. 

Außerdem plaudern wir aus dem Nähkästchen, denn bei Reviews mit Bewertungscharakter geht es auch mal kritischer zur Sache. Umso mehr heißt es dann einen kühlen Kopf zu bewahren, um mit dem Architektur-Review bleibenden Nutzen zu erzeugen.

Hast du dich jemals in einer Diskussion über Softwarearchitektur zurückgehalten, weil du dir unsicher warst, ob dein Beitrag relevant sind? Oder hast du schon einmal erlebt, dass deine Meinungen unreflektiert übernommen wurden, obwohl du dir eine kritische Auseinandersetzung gewünscht hättest? Du bist nicht alleine. Denn solche Situationen kommen leider schnell zustande, auch wenn sie die Möglichkeiten für gemeinsames Lernen und Verständnis einschränken. Insbesondere im Bereich der Softwarearchitektur, wo der Austausch von Wissen und die kritische Auseinandersetzung mit Beiträgen von entscheidender Bedeutung sind, ist es essenziell, dass sich alle Beteiligten sicher fühlen, um ihre Kenntnisse und Erfahrungen einbringen zu können. Anders gesagt, dass Psychologische Sicherheit gegeben ist.

Die Relevanz Psychologischer Sicherheit für die Teamleistung wurde mit der Veröffentlichung des vielzitierten Artikel der New York Times "What Google Learned From Its Quest to Build the Perfect Team" weitläufig bekannt. Trotz der Anerkennung als kritischer Faktor für Teamdynamiken hat die breite Popularisierung auch zu Missverständnissen und einer Flut von teils anekdotisch basierten Förderansätzen geführt, was die Effektivität des Konzepts untergräbt und zahlreiche Mythen hervorrief. Unser Workshop zielt darauf ab, die wissenschaftlichen Grundlagen Psychologischer Sicherheit hervorzuheben und praxisorientierte, evidenzbasierte Ansätze für die Softwarearchitektur zu identifizieren.

Als Teilnehmer:in lernst du:

• die Relevanz Psychologischer Sicherheit in komplexen Umgebungen wie der Softwarearchitektur,
• dass Psychologische Sicherheit immer vom Kontext abhängig ist,
• warum Unsicherheit in vielen Situationen der Standard ist,
• warum alle Beteiligten gebraucht werden, damit Psychologische Sicherheit entstehen kann, und
• ein paar einfache Lösungsansätze, die nicht nur Symptome bekämpfen.

Vorkenntnisse sind nicht erforderlich. In interaktiven Segmenten bieten wir Gelegenheit zur Reflexion des Gelernten im Hinblick auf eigene Kontexte und zum Austausch mit anderen Teilnehmenden. Du verlässt den Workshop mit konkreten Ideen, um die Bedingungen für Psychologische Sicherheit in deinem Umfeld zu verbessern.

Migration von lange gewachsener Legacy-Softwareentwicklung birgt von vornherein viele Risiken. Häufig ist das Detailwissen zu großen Teilen der Fachlichkeit verloren gegangen. Der Code ist komplex und Tests gibt es sowieso nicht. Da liegt es in der Natur der Sache, dass der Aufwand für ein Migrationsprojekt schwer geschätzt werden kann. Das Ergebnis sind häufig Zeit- oder Budget-Überschreitungen. Nicht selten werden solche Projekte abgebrochen und als gescheitert erklärt.

Was kann man dagegen tun? Ein Schlüssel zu einer erfolgreichen Legacy-Migration ist ausreichendes Testen. Dabei geht es zunächst darum, die bestehende Applikation mit automatisierten Tests zu versehen, um einerseits ein Gefühl für die Funktionalität und den Umfang zu bekommen und andererseits eine deutlich höhere Sicherheit bei der Migration selbst. 

In der Session zeige ich, wie das gelingen kann und wie wir es dadurch geschafft haben, Migrationsprojekte, die vorher bereits als gescheitert oder unmöglich erschienen, erfolgreich zu Ende zu führen.

Resilience is an important issue these days. Many companies claim to have a resilient IT, very few have one.

What does it mean to be resilient? How do I get there? How can I figure out where I currently am? How can I improve?

We will look at several gradations of becoming resilient. We will examine their properties and tradeoffs and how to get there. We will discuss what we can achieve at an IT system level and when we need to address the whole socio-technical system.

At the end of the session, we will have drawn a map from here to resilience you can use as a travel guide towards your resilient IT.

Domain-Driven Design ist kein Patentrezept und löst kein Problem auf magische Weise. Die Herausforderungen und die Komplexität, die wir mit DDD zu bewältigen versuchen, sind schwierig, und es gibt keinen einfachen Lösungsansatz. Nichtsdestotrotz gibt es eine wachsende Popularität und Wertschätzung für das Thema auf dem Markt, was zu überhöhten Erwartungen und schließlich zu Enttäuschungen führen kann.

Der Referent dieses Vortrags arbeitet seit 17 Jahren mit Domain-Driven Design an vielen Softwaresystemen, und dieser Vortrag handelt von meinen Erfahrungen mit dem Scheitern. Glauben Sie mir: Ich bin oft gescheitert, aber es gibt immer eine Gelegenheit, etwas daraus zu lernen. Der Vortrag zielt darauf ab, Ihnen die Möglichkeit zu geben, aus den Fehlern von mir als Berater und den Teams/Organisationen, mit denen ich gearbeitet habe, zu lernen.

Der Vortrag behandelt Themen wie:

• Domain-Driven Design im Wasserfall
• Ignoranz für Code (aka nur Fokus auf strategisches Design)
• übermäßiger Gebrauch von Mustern um ihrer selbst willen
• kulturelle Implikationen
• Cargo-Kult
• Developer Experience
• eingeschränkte Verfügbarkeit von Fachexperten
• Umgang mit etablierten Modellierungstechniken/Methoden
• Unkenntnis über die Definitionen/Bedeutung von Heuristiken und Mustern

Dieser Vortrag zielt darauf ab, Ihnen eine Sensibilität für potenzielle Gefahren zu vermitteln, wenn Sie versuchen, DDD für Ihr Team und Ihre Organisation einzuführen, und wird nur reale Situationen beschreiben, die tatsächlich passiert sind. Jeder beschriebene Misserfolg wird mit einer Erkenntnis darüber einhergehen, wie man es besser machen kann.

Es handelt sich um einen interaktiven Vortrag, bei dem Ihnen, dem Publikum, Fragen und Umfragen (über ein Online-Tool) gestellt werden. Sie werden sich beteiligen können.

Finding the right balance at work is neither an individual task nor is it only a team’s responsibility. It’s an interaction of both - and more! Leaders also play a vital role as they often (still) have a higher organizational lever.

In this session I will:

1. define what sustainable pace is
2. share common pitfalls that can “unbalance” a system (i.e. team, whole company, and also yourself)
3. offer simple yet powerful self-care practises for individuals and for teams
4. mix in psychological background (e.g. on stress & coping)

YOU are invited!

Eine explizite Softwarearchitektur ist der Garant für erfolgreiche Softwareprojekte. Zur Unterstützung der Kommunikation braucht es eine inhaltlich hinreichende und aktuelle Dokumentation. Der Docs-as-Code-Ansatz unterstützt, in dem die Dokumentation in Form leichtgewichtiger Text- und Grafikformate näher an den Quellcode gebracht, in der Versionsverwaltung abgelegt sowie mit Entwicklerwerkzeugen (IDE/Texteditor, Build-Tools, CI/CD-Pipelines) bearbeitet und in die Softwareentwicklungsprozesse integriert wird.

Der Vortrag stellt einfach anzuwendende Methoden, Vorlagen und Tools vor, die zum Erstellen einer hochwertigen, sich selbst validierenden Softwaredokumentation eingesetzt werden. Wir schauen uns Ansätze wie Docs-as-Code, leichtgewichtige Textformate, Ablage in der Versionsverwaltung und die Einbettung in die Build- und Review-Prozesse an. Das Sichtbarmachen von Softwarearchitekturkonzepten im Code und das Einbinden von Software-Analyse-Werkzeugen ermöglichen den kontinuierlichen Abgleich der Soll- mit den Ist-Strukturen und machen die Architekturdokumentation lebendiger.

Architekturarbeit bedeutet oft auch, Wandel zu gestalten. 

In dieser Session geht es darum, Modelle zur Betrachtung von Wandel im Unternehmen kennen zu lernen, wie z.B.

• das Change-Modell von John Kotter,
• das Kultur-Modell von William Schneider,
• Ray Immelmans Tribel Assessment,
• das Tribal Leadership Model von Logan, King, Fischer-Wright,

und zu erarbeiten, wie das zu den modernen Herausforderungen im Unternehmenswandel – auch im Zusammenhang mit den Themen 'Agile' und 'Architektur' – passen kann.

In unserer Zeit der "Agilen Transformationen" oder "Transitionen" wird oft davon ausgegangen, dass der Wandel schon passieren wird. Die Realität zeigt aber immer wieder, dass man den Wandel tatsächlich aktiv begleiten muss. In diesem Workshop werden wir uns nicht nur die oben genannten Modelle erarbeiten, sondern auch Ideen kennen lernen und erproben, sie zur Gestaltung des Wandels zu nutzen. Außerdem schauen wir ein bisschen tiefer in den zunehmend populären Begriff der Post-Agilität und betrachten, was das für das tägliche Arbeiten innerhalb und außerhalb von Vorhaben unter der Flagge "Agil" bedeutet.

usePAT ist Anbieter einer neuen Ultraschalltechnologie, die von einem multidisziplinären Team entwickelt wird. Die angebotenen IoT Systeme schließen Hard- und Softwarekomponenten ein, die Schnittstellen sind besonders komplex. Sie verbinden einerseits das Gerät mit der Steuerung eines industriellen Prozesses und andererseits die im Gerät erhobenen Daten mit den Menschen dahinter. Es werden auf Grund der Analysen sicherheitskritische Entscheidungen getroffen, die regulatorischen Anforderungen an diese Systeme sind dementsprechend anspruchsvoll.

Diese Komplexität gab den konkreten Ausschlag für die Evaluation einer neuen Methodik. usePAT hat sich dabei entschieden, die modellbasierte Systementwicklung als strategisches Entwicklungselement über das gesamte Unternehmen einzuführen, um diese Komplexität zu meistern. 

Die Herangehensweise:

• ermöglicht durch Daten-, Infrastruktur- und Applikationsarchitekturen eine ganzheitliche Entwicklung von IoT Systemen, 
• dokumentiert diese Systementwicklung über den gesamten Lebenszyklus,
• stellt das Wissensmanagement auch bei Fehlentwicklungen sicher.

Diese Evaluation und Einführung der modellbasierten Systemarchitektur erfolgt im Rahmen des EU Förderprojektes PENTA  „ECOMAI“, Ecological Motor Control and Predictive Maintenance with Artificial Intelligence. 

Die Veröffentlichung von ChatGPT jährt sich nun bald zum zweiten Mal. Ein Ende des Hypes ist noch lange nicht abzusehen. Zu groß sind die Mehrwerte dieser Technologie, zu intuitiv ist der Umgang in Form eines Chats. Für das Jahr 2024 wurde erwartet, dass der Sprung vom explorativen Herumspielen mit Large Language Models (LLMs) zum produktiven Einsatz gewagt wird. Diese Prognose bewahrheitete sich und viele Unternehmen lagerten beispielsweise den Customer Support auf LLM-powered ChatBots aus. Dass dies nicht immer eine gute Entscheidung war, zeigten Fälle wie der des DPD-ChatBots, welcher anstelle nützlicher Antworten lieber Gedichte über den schlechten Service des eigenen Unternehmens verfasste. Auch die sogenannten Halluzinationen von LLMs führten immer wieder zu Versprechungen oder Preisnachlässen, welche es in dieser Form nie gab.

Eine Lösung, derartige Probleme zu mitigieren, bietet die RAG-Architektur (Retrieval Augmented Generation). Durch ein vorgeschaltetes Retrieval, um relevante Informationen aus einer eigenen dynamischen Datenbasis hinzuziehen, können fundierte Antworten geliefert werden. Halluzinationen können vermieden und toxische Sprache durch weitere Mechanismen abgefangen werden. Anhand eines konkreten Praxis-Beispiels möchte ich zeigen, wie ein RAG-System funktioniert und welche Vorteile es bietet. Zudem werde ich auch auf noch ungelöste Herausforderungen eingehen.

Single-Page-Anwendungen (SPA) sind einerseits weit verbreitet, andererseits aber auch umstritten. Sie bieten ein hohes Maß an Interaktivität und Komfort für Benutzer:innen, aber nicht für jede Anforderung ist eine SPA deswegen automatisch die richtige Wahl. Auf der anderen Seite wiederum sind "klassische" auf dem Server gerenderte Anwendungen oftmals nicht ausreichend, wenn es um Webanwendungen mit viel Interaktivität geht. Diese Lücke möchte die Bibliothek HTMX schließen, die serverseitiges Rendering mit einem beliebigen Backend ermöglicht. Im Frontend verspricht sie sowohl eine nahezu JavaScript-freie Entwicklung als auch feingranulare Aktualisierungen der Oberfläche, ähnlich wie von SPAs gewohnt. Ist HTMX also die perfekte Allzwecklösung fürs Frontend?

Anhand praktischer Beispiele möchte ich Single-Page-Anwendungen und HTMX gegenüberstellen. So werden wir sehen, wo die Stärken und Schwächen der beiden Ansätze liegen und für welche Anwendungen sie jeweils geeignet sind. 

Neben Beispielen mit Java und Spring werde ich ein paar React-Beispiele zeigen, die du aber auch ohne React-Vorkenntnisse verstehen wirst. Wenn du dich also für moderne Webentwicklung interessierst, bist du in diesem Vortrag genau richtig!

Vor zehn Jahren habe ich zum ersten Mal einen Vortrag über Event-driven Architecture gehalten. Kafka war gerade seit zwei Jahren Open Source und bei Version 0.8, und nur ein paar Wochen vorher war Java 8 erschienen, und die erste Version von Spring Boot. Damals war gerade das Label "reactive" populär, und so hieß er "From Enterprise To Reactive". Unter anderem habe ich das Saga-Pattern propagiert.

In den zehn Jahren habe ich einiges dazugelernt - musste aber vor allem auch vieles erst einmal verlernen. In diesem Vortrag ziehe ich eine kleine Bilanz: Welche Ansätze haben sich in den zehn Jahren bewährt, und welche waren für mich enttäuschend? (In welcher Kategorie wird wohl das Saga-Pattern wieder auftauchen?)

Nicht alles wird sich übertragen lassen, aber manche Einsicht kann vielleicht hilfreich sein.

Softwaresysteme bestehen aus Bausteinen. Aber kann ein Softwaresystem Baustein eines anderen sein? Andersherum: Besteht ein System aus "Bausteinen all the way down"? Das wäre gut, weil beim Zusammensetzen die Details verschwinden und so konsequent abstrahiert wird – wir komponieren dann, anstatt einfach nur zu basteln.  Das gleiche gilt für Domänenmodelle – sogennante Kombinatormodelle sind flexible Baukästen statt starrer Formulare.

Die Realität der meisten Systeme sieht leider anders aus: Softwaresysteme und ihre Bausteine werden mehr schlecht als recht miteinander verschaltet, bedingt auch durch gängige Architekturmuster wie die hexagonale Architektur, die einfach nicht komponieren. Bei den Domänenmodellen ist es ähnlich: Elemente typischer OO-Modelle lassen sich oft nur begrenzt zusammensetzen – in der obersten Schicht ist Schluss. Entsprechend groß ist der Refaktorisierungs- und Modernisierungsaufwand, wenn sich die Anforderungen ändern.

Im Talk gehen wir auf eine Reise der Kompositionalität auf verschiedenen Ebenen: Wir besuchen Projekte aus der Praxis, bei denen Kompositionalität ein zentrales Designprinzip ist, nahezu unbegrenzt flexible Kombinatormodelle und kompositionale Modulsysteme. Wir ziehen Paralleln zum Prinzip "closure of operations" im DDD und zeigen die Prinzipien, die du beim Einsatz von Komposition beachten solltest.

Code-Basen, die schwer zu ändern sind, leiden oft unter zwei großen Problemen: einer fehlenden Ausrichtung an Domänengrenzen und dem fehlenden Ausdruck architektonischer Ideen im Code. Um dieses kritische Problem anzugehen, greifen Entwickler auf Separation-of-Concerns-Architekturen wie Onion-, Clean- und Hexagonal-Architektur zurück. Diese Ansätze erzielen jedoch oft gemischte Ergebnisse, da sie sich hauptsächlich auf die Trennung von technischem und Business-Code konzentrieren, ohne die strukturellen Aspekte der Domäne zu berücksichtigen.

In dieser Präsentation diskutieren wir Strategien zur Übersetzung von architektonischen Ideen und Designpatterns in Code auf verschiedenen Abstraktionsebenen. Wir erkunden, wie verschiedene Frameworks und Bibliotheken im Java-Ökosystem diesen Prozess unterstützen, indem sie die im Code vorhandenen Metainformationen für eine strukturelle Überprüfung, Testbarkeit und das Generieren von Dokumentation nutzen.

Dieser Workshop muss zusätzlich gebucht werden.

Were you ever forced to use an API you don't understand? You hated more or less. Do you want to create APIs someone would love (or at least won't hate)?
The talk discusses those questions using a sample and using Domain Story Telling and Event Storming. Out of them, you will get nice APIs, which your developers won’t hate.

1. Introducing a task management system with results out of a domain storytelling and event storming
2. Context Map based on the Event Storming
3. Hands on in groups: Discussion of the interfaces - asynchronous vs. synchronous
4. Hands on in groups: Definition of the interfaces using OpenAPI and AsyncAPI
5. Discussion of the interfaces

Max. Teilnehmendenzahl: 30
Es wird ein Rechner mit einer Entwicklungsumgebung benötigt.

Dieser Workshop muss zusätzlich gebucht werden.

Today we know very well how to start a new project on a greenfield and how to build a good architecture. But most of us work in projects that have been around for a long time and whose architecture (to put it mildly) is not quite so beautiful. “Monolith” and “Big Ball of Mud” are the unflattering labels put on such systems.

This talk will show how we can introduce (or bring back) structure. Every system is different here, so it’s important to first understand where you are. Then the right steps have to be taken. I present a catalog of refactorings to choose from and heuristics which are the right choices.

The catalog contains refactorings that help to cure: BBOM architecture, anemic domain models, and badly organized teams.

Max. Teilnehmendenzahl: 30
Es wird ein eigener Laptop benötigt.

Dieser Workshop muss zusätzlich gebucht werden.