Heutzutage stehen viele Unternehmen vor der Herausforderung, ihre in die Jahre gekommenen Anwendungen zu modernisieren, flexibler zu machen und geeignet zu strukturieren. Während Microservices weit verbreitet sind, bietet ein Modulith – modular strukturierter Monolith – eine vielversprechende Alternative, die oft übersehen wird.

Dieser Vortrag liefert einen Einblick in die praktische Arbeit mit Modulithen und die Migration dort hin. Wir berichten auch von Erfahrungen mit passenden Technologien wie Spring Modulith, xMolecules, ArchUnit sowie jQAssistant und besprechen, worauf bei deren Einsatz zu achten ist.

Außerdem besprechen wir Vorteile und Herausforderungen, die sich gegenüber der Transformation hin zu Microservices ergeben. Wir betrachten Aspekte wie Implementierungsaufwand, Impact auf den vorhandenen Quellcode, grundsätzliche Risiken bei langlaufenden Ablösungsprojekten, Teststrategien, Cognitive Load, Abhängigkeiten auf fachlicher und technischer Ebene und die Auswirkungen, die all diese Themen in der Praxis haben.

Insgesamt bietet der Vortrag einen erfahrungsbasierten Überblick zu Modulithen und richtet sich an Softwarearchitekten, Entwickler und IT-Entscheider, die sich mit der Modernisierung ihrer bestehenden Systeme auseinandersetzen.

Zielpublikum: Architekten, Entwickler, Entscheider
Voraussetzungen: Erfahrungen in Enterprise-Projekten, Herausforderung von Legacy-Projekten kennen
Schwierigkeitsgrad: Advanced

Dynamikrobuste Softwareentwicklungsteams sind cross-funktional und fokussieren möglichst unabhängig von anderen Teams auf eine kognitiv bewältigbare (fachliche) Domäne. Um dies optimal tun zu können, benötigen sie Unterstützung von Plattform-Teams, die ihnen entlastende (Self-)Services anbieten.

Um von einem klassischen OPS-Team zu einem Plattform-Team zu werden, muss zum einen eine gewisse Kundenorientierung und Dienstleister-Mentalität etabliert werden, zum anderen braucht es ein passendes Angebot von Services und Produkten für die Entwicklungsteams. Im Optimalfall sind die Nutzung der Deployment-Plattform und die der unterstützenden Services für Entwicklungsteams freiwillig.

Welche Haltung, Rollen und Methoden es dafür braucht, beleuchten wir in diesem Vortrag.

Zielpublikum: Architekt:innen, OPS/Plattform-Teams, Führungskräfte, Menschen, die Dynamikrobustheit anstreben
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic

Eigentlich definiert Architektur „nur“ die Struktur der Software. Aber das Gesetz von Conway weist schon auf den Zusammenhang zwischen Architektur und Organisation hin. Durch das Inverse Conway Maneuvre ist klar geworden, dass die geschickte Aufstellung der Organisation die Architektur maßgeblich beeinflussen kann.

Dieser Vortrag zeigt auf, dass Team Topologies auch erhebliche Konsequenzen für die Architektur-Arbeit hat: Team Topologies fungiert nicht nur als Werkzeug für Architektur, sondern muss auch in die architektonische Planung einbezogen werden.

Zielpublikum: An Softwarearchitektur und Organisation Interessierte
Voraussetzungen: Grundlegendes Verständnis von Softwarearchitektur und Entwicklung im Team
Schwierigkeitsgrad: Basic

How to structure your program right? This has been a central question since the beginning of software development. This talk takes a look into the history of software architecture to understand why we are building software the way we are. We start with foundations like information hiding, modularity, separation of concerns, loose coupling. We move on to principles like layering and design patterns. We conclude with an outlook to modern ideas like hexagonal architecture, onion architecture, SOLID, and the software architecture hamburger.

Target Audience: Developers and architects
Prerequisites: Programming
Level: Advanced

Die Entwicklung typischer aktueller Webanwendungen kann einen erschlagen: Umfangreiche, komplexe JavaScript-Frameworks, Client-Side-Rendering/Server-Side-Rendering, (De-)Hydration, komplizierte Buildprozesse und und und

Die unterliegenden Technologien, Protokolle und Architekturmuster wie HTTP(2/3), HTML/CSS, Web Components, Representational State Transfer (REST) u. a. geraten dabei manchmal völlig aus dem Blick. Für die Entwicklung von Webanwendungen, die nachhaltig und skalierbar sein sollen, ist die Kenntnis dieser grundlegenden Prinzipien aber unerlässlich. Ansonsten droht die Gefahr, in einer ewigen Spirale dem gerade gehypten Framework, Architektur-/Entwicklungsansatz fürs Web nachzulaufen.

Dieser Vortrag versucht, den Blick wieder auf diese grundlegenden Prinzipien zu richten.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlegende Erfahrungen mit der Entwicklung und Architektur von Softwaresystemen
Schwierigkeitsgrad: Basic

What is the difference of a test architect to a commonly known software architect? And why do I need one? What do they have in common and where do they differ? Is there a gap where we need a bridge (Spoiler: yes)? What are the different expectations of other roles on a test architect?

Questions over questions which will be covered in this talk. With examples where it did go well because there was a test architect and examples where things got haywire maybe because a test architect was missing.

And you will also not be left alone with these questions:

• How can I become such a person which is able to be a test architect.
• How can I establish that role in my organization.

You will get input how we did this at Siemens and build up a living network of test architects.

Target Audience: Testers, Developers, Architects, Project Leads, Test Managers, Team Leads
Prerequisites: Architecture knowledge, challenges in software projects, basic testing knowledge
Level: Advanced

The objective of visual test automation is replace flaky and hard to read selectors with images. Many software packages offer the possibility of using images as selectors, but it rarely works reliably. Appium has the function "findElementByImage," Playwright has functions like "toHaveScreenshot." Code and no-code tools alike provide a number of options to tweak the sensitivity, where both, too low and to high values, produce their own set of artefacts. What makes this so difficult? Doesn't AI provide the solution to reliably compare two images? Wouldn't source code be much more readable if it showed the image of the item, rather than just a file name or its xpath?

Target Audience: Experienced test automators in code and no-code
Prerequisites: Images, test automation, CNN, AI
Level: Expert

Wie wir an der Softwarearchitektur eines Softwaresystems arbeiten, hängt stark von der jeweiligen Situation ab. In diesem Vortrag werfe ich einen Blick auf einen besonders wichtigen Faktor: Softwareevolution. Denn je nachdem, wie weit ein Softwaresystem evolviert ist, unterscheidet sich damit auch potenziell der Ansatz, wie Softwarearchitekturen erarbeitet werden: Von „No-Architecture“ über „Architekturdiktatur“ und „Multi-Level-Architektur“ hin zu „Architekturspezialisten“ diskutieren wir, wann welcher Ansatz welche Stärken ausspielt und wann es dringend Zeit für einen Wechsel ist. Wer sich jemals in endlosen Diskussionen über das „Warum?“, „Wie?“ und „Wie viel?“ Softwarearchitektur verloren hat, findet in diesem Vortrag erste Antworten für einen systematischen Ansatz der Softwarearchitekturevolution.

Zielpublikum: Softwarearchitekt:innen, Entwickler:innen
Voraussetzungen: Erfahrung mit optimierungsbedürftigen Softwaresystemen
Schwierigkeitsgrad: Basic

Legacy ist ein Wort das in der IT häufig benutzt aber ungern gesehen wird. Eigentlich wollen wir neue Ideen umsetzen, doch die Legacy Systeme fordern ihren Zoll. Mainframes bekommen Gesellschaft von Monolithen aus der frühen Java Zeit, und gleichzeitig wird immer deutlicher dass eine reine Migration in die Cloud nicht ausreicht sondern eine echte Modernisierung in der Regel Pflicht ist.

In dem aktuellen KI-Boom, der durch die Large Language Models (LLMs) ausgelöst wurde, wird viel über KI-assistiertes Software Engineering gesprochen. Dabei liegt der Fokus meistens auf dem Erstellen von Code und Tests. In diesem Talk beschreibt Erik aus praktischer Sicht wie LLMs auch für Legacy Modernisation genutzt werden können. Hier reichen einfache Chat Prompts nicht aus, sondern es sind weitergehende Lösungen gefragt, zum Beispiel zur Erstellung von Documentation on Demand oder der semantischen Beschreibung von Programmcode.

Neben praktischen Beispielen stellt Erik entsprechende Architekturmuster wie Retrieval Augmented Generation vor, das beim Reverse Engineering die zurecht gefürchteten Halluzinationen auf ein Minimum reduziert. Ausserdem beschreibt Erik wie die Nutzung von existierenden strukturierten Reverse Engineering Tools in geschickter Kombination mit LLMs die Legacy Modernisierug beschleunigen kann.

Zielpublikum: Architekten, Entwickler
Voraussetzungen: Allgemeine Programmierkenntnisse und Verständnis von LLMs
Schwierigkeitsgrad: Advanced

Seit über sechzig Jahren bauen wir Software, die immer größer und komplexer wird. Inzwischen haben wir nicht nur Mainframe-Altsysteme, sondern auch die Systeme in objektorientierten Programmiersprachen sind in den letzten zwanzig Jahren so schnell und immer wieder unkontrolliert gewachsen, dass sie zu einem großen Knäuel geworden sind. All dieser Legacy-Code treibt die Entwicklungskosten in die Höhe und führt dazu, dass wir diese alten Softwaresysteme nicht mehr gerne anfassen. Ist das unvermeidbar? Oder gibt es auch gute Legacy?

In meinem Vortrag zeige ich Ihnen, welche Überlegungen ich mit meinen Kunden üblicherweise anstelle, um zu entscheiden, ob das Legacy-System durch Refactorings wieder auf den Pfad der Tugend gebracht werden kann oder ob wir es abreißen und neu bauen müssen.

Zielpublikum: Architekten, Entwickler, Projektleiter, Manager
Voraussetzungen: Erfahrung mit Softwareentwicklung
Schwierigkeitsgrad: Advanced

Java-Legacy ist gelebte Realität. Teams müssen immer wieder produktiv kritische sowie unbekannte und schlecht dokumentierte Software übernehmen. Doch wie geht ein bestehendes oder neues Team vor, um sich schnell und strukturiert in kurzer Zeit ein Verständnis über die Codebasis aufzubauen?

In diesem Vortrag zeigen wir, mit welchen Methoden und Werkzeugen wir uns systematisch und in kürzester Zeit einen Überblick über die Topografie des Java-Source-Codes verschaffen. Wir erklären, wie Schwachstellen und Hotspots identifiziert und somit risikoarm die Wartung sowie Pflege von Java-Legacy-Systemen durch ein neues Team übernommen werden kann. Nicht zuletzt ist dies der entscheidende Schritt, um aus einer Erblast ein Erbstück zu machen und nicht die Fehler der Vergangenheit mit einer blinden Neuentwicklung zu wiederholen.

Zielpublikum: Architekten, Entwickler
Voraussetzungen: Java-Kenntnisse
Schwierigkeitsgrad: Advanced

Schwer zu ändernde Codebasen haben zwei Probleme: fehlende Ausrichtung an Domänengrenzen und fehlender Ausdruck architektonischer Ideen im Code. Entwickler:innen verwenden Separation-of-Concerns-Architekturen wie Onion-, Clean- und Hexagonal-Architektur, um dieses Problem anzugehen. Diese Ansätze erzielen jedoch gemischte Ergebnisse, da sie sich hauptsächlich auf die Trennung von technischem und Business-Code konzentrieren, ohne strukturelle Aspekte der Domäne zu berücksichtigen.

In der Präsentation diskutieren wir Strategien zur Übersetzung von architektonischen Ideen und Designpatterns in Code. Wir erkunden, wie Frameworks und Bibliotheken im Java-Ökosystem die Metainformationen im Code nutzen, um strukturelle Überprüfung, Testbarkeit und Dokumentationsgenerierung zu unterstützen.

Zielpublikum: Softwarearchitekt:innen, Senior Entwickler:innen.
Voraussetzungen: Grundlegende Softwarearchitektur, Basis Java (konzeptionell reicht)
Schwierigkeitsgrad: Expert

Data Contracts sind so etwas wie APIs, aber die Datenwelt funktioniert doch etwas anders. Ein Data Contract definiert das Datenmodell der bereitgestellten Daten und deren Qualitätsattribute in einem YAML-Format. Data Contracts enthalten zudem semantische Definitionen, SLAs, und legen die Nutzungsbedingungen für die Verwendung von Daten fest.

Data Contracts sind in erster Linie auch ein Kommunikationsinstrument, um ein gemeinsames Verständnis darüber auszudrücken, wie Daten strukturiert und interpretiert werden sollten. Sie machen implizite semantische und qualitative Erwartungen explizit. Später in der Entwicklung und Produktion dienen sie auch als Grundlage für die Codegenerierung und automatisierte Tests, um sicherzustellen, dass die bereitgestellten Daten auch der Spezifikation entsprechen.

In diesem Vortrag möchte ich die Data Contract Specification (datacontract.com) und das Data Contract CLI zur Validierung von Data Contracts in CI/CD-Pipelines vorstellen.

Zielpublikum: Data Engineers, Softwarearchitekten, IT-Verantwortliche
Voraussetzungen: Verständnis über grundlegende Datenarchitekturen
Schwierigkeitsgrad: Basic

Bounded Contexts spielen bei Domain-driven-Design-Diskussionen eine zentrale Rolle. Sie gelten als eine vielversprechende Lösung zur Modularisierung von Systemen, sei es in Form von Deployment-Monolithen oder Microservices. Doch die Anwendung in der Praxis bringt Herausforderungen mit sich: Es ist oft schwierig, eine Domäne sinnvoll in Bounded Contexts aufzuteilen. Zudem ist das Konzept nicht einfach zu verstehen. Einerseits steht es für die Aufteilung eines Softwaresystems in Module, andererseits soll es helfen, verschiedene Fachsprachen innerhalb einer Domäne voneinander zu trennen. Darüber hinaus wird ein Bounded Context oft als ein Team betrachtet. Wie lässt sich all das miteinander in Einklang bringen, und wie kann man in der Praxis erfolgreich damit arbeiten? Dieser Vortrag erklärt, was Bounded Contexts sind, und beleuchtet dann diese Herausforderungen. So zeigt er, wie man Projekte mit DDD noch erfolgreicher gestalten kann.

Zielpublikum: An Softwarearchitektur oder Domain-driven Design Interessierte
Voraussetzungen: Grundlegendes Verständnis von DDD
Schwierigkeitsgrad: Advanced

Die Grundlage für gute Software ist eine gute Architektur. Eine zum System passende Architektur kann jedoch nicht im luftleeren Raum entstehen – um eine geeignete Architektur definieren zu können, muss man die Domäne und ihre Anforderungen verstehen. Moderne Architekturarbeit beginnt somit ein ganzes Stück vor der eigentlichen Architektur. Für diese Exploration der Domäne wurden im Rahmen von Domain-Driven Design (DDD) verschiedene kollaborative Modellierungstechniken entwickelt. Deren Ziel ist es, dass alle an einer Software beteiligten Personen die Domäne und ihre Anforderungen kennen und verstehen. Insbesondere soll eine gemeinsame Sprache entwickelt werden, um über Problemstellungen innerhalb der Domäne diskutieren zu können, die auch als Ubiquitous Language im Sinne von DDD verwendet werden kann.

Obwohl all diese Modellierungstechniken dieselben Ziele verfolgen, unterscheiden sie sich in ihrem Ansatz. Das beliebte Event Storming modelliert Wissen als Sequenz von Events. Beim Domain Storytelling werden die Interaktionen zwischen Personen und/oder Systemen modelliert und die Ergebnisse können zur Visualisierung von Szenarien verwendet werden. Weitere Methoden verwenden andere Elemente in der Modellierung oder versuchen, die Stärken anderer Methoden zu kombinieren. In diesem Vortrag möchten wir einige beliebte Modellierungstechniken kurz vorstellen und ihre Stärken hervorheben. Wir möchten einige Ratschläge geben, wie man auf Basis des Szenarios eine kollaborative Modellierungstechnik auswählt.

Zielpublikum: Architekten, Entwickler, Projektleiter
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Basic

Consider for example, this line of C++ code:

std::pmr::vector<std::variant<int,double,std::pmr::string>> values;

Are you aware that this line of code contains at least five Gang-of-Four (GoF) design patterns? If not, then this talk is definitely for you! It will help you realize that design patterns are everywhere. They are the key to managing dependencies between software entities. They help us to structure our software, to separate concerns, and to communicate our intentions. Even better, they are universally applicable to object-oriented programming, function programming, and generic programming. And no, design patterns are not old-fashioned, outdated, or even dead. They are at the very core of our software and our daily work.

Target Audience: Architects, Developers
Prerequisites: Foundational knowledge in C++ (examples in C++)
Level: Advanced

AI for testing to generate test code or AI for coding (see Copilot) to suggest good code examples; this is almost "state-of-the-art". But isn't something missing? Aren't we largely dealing with brownfield software that needs to be transformed in order to be cloud-ready and scalable? Couldn't AI help here too?

In the presentation, we will look at what AI-based methods could do to simulate architecture restructuring (based on data that goes beyond code to evaluate feature/temporal coupling, Conway’s law or a mix of all), check their feasibility and efforts. We also provide an outlook on what support AI could provide with respect to architecture quality analysis. Finally, we will talk about challenges in relation to knowledge management in projects and how to get assistance based on AI.

Target Audience: Project Leaders, Architects, Key Developers, Managers, Decision Makers
Prerequisites: Architecture Knowledge
Level: Advanced

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. We 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.

Target Audience: Developers and architects
Prerequisites: Programming experience
Level: Expert

Daten sind elementarer Bestandteil jeder Software – und doch kommen sie bei der Betrachtung der Architektur oft zur kurz, insbesondere im Hinblick auf die analytische Nutzung. Ideen wie Data Mesh haben dafür gesorgt, dass „analytische Daten“ auch in der Softwarearchitektur wieder populärer wurden. Schließlich sind sie die Grundlage für GenAI, ML und Data Analytics.

Ich gehe auf typische Vorgehen in der Vergangenheit und auf neue Wege in modernen Softwarearchitekturen ein. Wie schaffe ich es, frühzeitig im Entwicklungsprozess die analytische Nutzung zu berücksichtigen? Welche Methoden und Techniken gibt es, um die Lücke zwischen Softwareengineering und Data Teams zu überbrücken? Außerdem gibt es einen Überblick über die mögliche Implementierung einer solchen Data Aware Architecture.

Zielpublikum: Architekten, Entwickler, Entscheider, sowohl auf der Anwendungs- als auch der Data-Seite
Voraussetzungen: Erfahrung mit der Nutzung oder Bereitstellung von Daten für analytische Zwecke
Schwierigkeitsgrad: Advanced

Jeder möchte in die Cloud. Unterwegs stellt man fest, dass der Weg dorthin oft lang und steinig ist.
Damit man die typischen Probleme vermeiden und Risiken reduzieren kann, stellen wir Lösungen vor, die sich in unserer Praxis bewährt haben.
Es werden Rehost- und Replatforming-Beispiele mit AWS und der Open Telekom Cloud vorgestellt. Dabei werden folgende Fragen beantwortet:

• Welche Stolperfallen gibt es und wie lassen sie sich vermeiden? Abkürzungen & Sackgassen
• Wie kann eine gute Informationsbasis und Dokumentation geschaffen werden?
• Wie kann der Migrationsprozess beschleunigt werden?
• Wie können Cloud-Vorteile genutzt werden?

Zielpublikum: Architekten, Projektleiter, Manager, Entscheider
Voraussetzungen: Cloud-Grundkenntnisse, Erfahrung mit Anwendungsmodernisierung, Migration
Schwierigkeitsgrad: Basic

Wir wissen heutzutage ziemlich gut, wie man ein neues Entwicklungsprojekt auf der grünen Wiese beginnen sollte und wie wir dabei Schritt für Schritt eine gute Softwarearchitektur aufbauen. Aber die meisten von uns arbeiten in Projekten, die schon lange laufen und deren Architektur nicht mehr ganz so wohlgeformt ist. „Monolith“ und „Big Ball of Mud“ sind die unschönen Bezeichnungen, die wir für diese Systeme haben.

In diesem Vortrag stelle ich Domain-Driven Transformation vor, eine Methode, die Henning Schwentner und ich in den letzten Jahren beim Verbessern von Altsystemen entwickelt haben. Domain-Driven Transformation besteht aus vier Schritten, die uns von der Analyse des aktuellen Zustands zu einer fachlichen Vision der Architektur führen. Anhand des aktuellen Zustands bestimmen wir die Reihenfolge der Umbaumaßnahmen, um zügig und mit einem stets einsetzbaren System voranzukommen.

Zielpublikum: Architekten, Entwickler, Projektleiter, Manager
Voraussetzungen: Erfahrung mit Softwareentwicklung
Schwierigkeitsgrad: Advanced

Die Architekturmodelle Clean, Onion und Hexagonal Architecture basieren auf dem Dependency Inversion Principle (DIP). Damit bspw. Domänenlogik nicht von der Datenbank abhängig ist, wird ein Interface dazwischen gestellt. Die Anwendung des DIP ist so allgegenwärtig, dass wir uns an die damit verbundenen Umstände wie Tests mit Attrappen gewöhnt haben.

Mit der Integration Operation Data API Architecture (IODA) gibt es eine Alternative: Durch das Herauslösen der Integration als eigene Verantwortlichkeit entsteht ein einfacheres Architekturmodell. In seinem Vortrag erläutert Stefan Lieser die Prinzipien und Hintergründe. Ferner stellt er die Architekturmodelle anhand von Beispielen gegenüber und zeigt, wie gut die IODA-Architektur sich auf Korrektheit und Wandelbarkeit von Software auswirkt.

Zielpublikum: Architekten, Softwareentwickler
Voraussetzungen: Architekturkenntnisse
Schwierigkeitsgrad: Expert

Jährlich fließen große Investitionen in die Erstellung von Softwaresystemen. Diese erodieren aber mit der Zeit, behandelt man sie nicht pfleglich. Spätestens wenn z. B. aus dem Legacy-Code eine moderne SaaS-Lösung entstehen soll, rächt sich dieses Vorgehen. Wie soll das Entwicklungsteam agieren? Auf einen Greenfield-Ansatz setzen oder das Altsystem runderneuern? Wie lassen sich solche Probleme in Zukunft vermeiden? Welche Fallstricke lauern in der Praxis? Darauf möchte die vorliegende Paneldiskussion in Gestalt eines Fishbowls Antworten aus der Praxis geben.

Agenda:

• Beispielbasierte Einführung in die Problematik
• Diskussionsrunde, die als Fishbowl mit Sprechern startet
• Wrap-Up

Zielpublikum: Softwarearchitekten, Entwickler
Voraussetzungen: Praktische Kenntnisse in Softwarearchitektur und Softwareengineering
Schwierigkeitsgrad: Advanced

Eric Evans' Big Blue Book has a chapter titled "closure of operations", largely ignored by the community and subsequent works on DDD. This is tragic, as closure of operations is one of the most powerful techniques for domain modeling. A concept imported from functional programming, it makes for flexible and long-lived domain models with the help of combinators - operations that build big domain objects from smaller ones recursively. This is refreshing alternative to the rigid hierarchical taxonomies that often result from naive application of DDD modeling techniques "close to the domain", and which require continual adjustments and extensions. The talk shows what "closure" is and how you can harness it in your project.

"Closure of operations" applies abstraction over rigid models. It avoids common problems of overabstraction through a systematic process and the use of simple mathematical principles. The talk will also cover these.

Target Audience: Developers, Architects
Prerequisites: Basic DDD
Level: Advanced

Was haben wir nach 30 Jahren Systementwicklung eigentlich alles gelernt? Im Kern stoßen wir immer wieder auf die gleichen Grundprinzipien, die in überraschend vielfältiger Form auftreten. So unterschiedlich Systeme sind, die Hauptprobleme lassen sich tatsächlich häufig auf die gleichen Ursachen zurückführen.

In dieser Session beleuchten wir unsere wichtigsten „üblichen Verdächtigen“ und zeigen auf, wie man sie adressieren kann. Gewürzt mit zahlreichen Anekdoten, plaudern Jutta und Nico aus ihrem Nähkästchen.

Zielpublikum: Architekten, Entwickler, Projektleiter, Manager, Entscheider, ...
Voraussetzungen: Keine
Schwierigkeitsgrad: Advanced

Agile methodologies promise rapid delivery, flexibility, and resilience, allowing teams to respond swiftly to customer needs and market changes. However, the success of these agile practices is deeply intertwined with the underlying software architecture. An enabling architecture can enhance agility, while a restrictive one can significantly hinder it.

This talk explores how architectural and organizational decisions impact the agility of development teams. We will discuss the role of modularity in team autonomy and how aligning module boundaries with communication paths within the organization can leverage Conway's Law to promote fast flow.

We will examine the importance of testability for quick feedback cycles and how observability can lead to more informed responses to technical and business challenges. Additionally, we will delve into understandability in architectural design, which can expedite onboarding and reduce cognitive load, thus supporting agile practices. Finally, we will explore the influence of platform engineering on agile outcomes. A well-designed development platform provides a flexible infrastructure that supports and enhances the implementation of agile practices.

Drawing on principles from the Agile Manifesto, DevOps practices, and the DORA metrics, we will provide actionable advice on designing and transforming software architectures so that they enable rather than inhibit agility. We will also suggest tools to understand when a software architecture does not support agility and how to justify investing in improving it. These investments help with performance, faster delivery, higher quality, and shorter development cycles and range from simply prioritizing architectural tasks in the teams’ backlogs to fully-fledged modernization projects.

This session is a call to action for product managers, software architects, developers, and software leaders to rethink how their architectural decisions impact their agile practices.

Target Audience: Architects, Managers, Project Leaders, Coaches, Developers, Product Owners, Decision Makers
Prerequisites: Architecture, Modernization, Leadership, Project Management, Working with Teams, Agile mindset
Level: Advanced

Existierende Softwarearchitekturen stehen von Anfang an einer hohen Dynamik ihres Umfelds gegenüber. Anforderungen ändern sich, neue Technologien entstehen, technische Schulden häufen sich an. Der Vortrag zeigt, wie sich existierende Systeme so renovieren bzw. verbessern und integrieren lassen, dass ihre Nachhaltigkeit auch langfristig gesichert bleibt. Es illustriert, welche konkreten Maßnahmen sich wann und wie nutzen lassen.

Agenda:

• Motivation und Problemstellung
• Architekturbewertung
• Maßnahmen für Evolution und Verbesserung
• Integration von Legacy-Code
• Migration
• Zusammenfassung

Zielpublikum: Softwarearchitekten, Entwickler, Projektleiter
Voraussetzungen: Grundlegende Kenntnisse in Softwarearchitektur und Softwareentwicklung
Schwierigkeitsgrad: Advanced

Die Modernisierung eines Legacy-Systems ist eine komplexe Herausforderung, die sorgfältige Analyse und Planung erfordert. In diesem Vortrag zeige ich, wie wir über vier Jahre ein umfangreiches Legacy-System schrittweise migriert haben. Durch Domänenarchäologie erkannten wir fachliche Strukturen im Altsystem und identifizierten Bereiche für neue Lösungen. Ich erläutere Strategien zur Risikobewertung und Priorisierung: Was zuerst – hohes Risiko oder einfache Umsetzungen? Der Parallelbetrieb von Alt- und Neusystem war entscheidend für eine reibungslose Integration und eine hohe Nutzerakzeptanz. Erfahren Sie, wie wir die Systeme gekoppelt haben und wann und wie wir das Altsystem und seine Datenbanken abgeschaltet haben, ohne den Betrieb zu gefährden. Dennoch lief nicht alles glatt.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: DDD, Projekterfahrung, Softwarearchitektur
Schwierigkeitsgrad: Advanced

When considering how to Take Advantage of your Legacy Applications and existing Competence for future-driven innovative development, the technical, financial and resource constraints are a deciding factor. What justification, approaches and added value are possible and appropriate for defining and securing the required budgets to address innovation? What aspects are crucial to success and what hypes should be avoided? What role might Artificial Intelligence play in the success of projects? A long journey has accompanied and still awaits Legacy applications, and there is much at stake. Quo Vadis Innovation and Legacy?

Target Audience: Architects, IT strategists, IT decision-makers
Prerequisites: Good knowledge of English
Level: Expert

Hast Du schon einmal gehört: „Die (Micro-)Service-Architektur funktioniert nicht wie erhofft“? Viele Unternehmen erleben diese Enttäuschung, da sie nur die Architektur ändern, aber die Organisationsstruktur vernachlässigen. Microservices erfordern Dezentralisierung, doch hierarchische Strukturen führen zu Abhängigkeiten und Komplikationen. Führungskräfte spielen eine entscheidende Rolle, um Teams unabhängig zu organisieren und die Struktur an die gewünschte Architektur anzupassen. In unserem Vortrag zeigen wir anhand typischer Probleme, was das Leadership tun kann und wie das Inverse Conway-Manöver helfen kann, Microservices erfolgreich zu implementieren. Wir bieten Praxisbeispiele und konkrete Tipps. Sei dabei und optimiere Deine Architektur!

Zielpublikum: Manager, Entscheider, Führungskräfte, Architekten
Voraussetzungen: Keine
Schwierigkeitsgrad: Advanced

INITIAL SITUATION

When modernizing enterprise applications that were developed many years ago and adapted over decades, you are often faced with several challenges.

• What does the current architecture actually look like?
• Which technologies have all been utilized?
• Which and how much technical debt, i.e. things that would have to be changed anyway, are hidden in the source code?

Normally, various developers have "immortalized" themselves in the code and the architecture. And a uniform and up-to-date documentation is nowhere to be found.

OPTIONS

In addition to manual analysis, static and dynamic code analysis can also be used. However, the information derived from this is no substitute for comprehensive software documentation. And despite the use of frameworks and libraries, the creation of new source code is usually purely manual work.
Couldn't the silver bullet AI do this for us?

KEY MESSAGE

AI can support software architects and software engineers both in analyzing applications and in redesigning them.
But how exactly? What steps are necessary? And where are the pitfalls and limitations?
I will answer precisely these questions in my presentation, based on a real project whose source code is more than 20 years old.

KNOWLEDGE CONVEYED

• Steps for a successful modernization of applications and their architectures with the help of LLMs available today.
• Limits of AI.

Target Audience: Architects, Developers, Project Leader, Manager, Decision Makers
Prerequisites: Basic knowledge in software development and application architecture
Level: Advanced

In der modernen Unternehmensarchitektur ist eine enge Zusammenarbeit zwischen IT-Demand und IT-Supplier essenziell, um reibungslose Abläufe und nachhaltigen Erfolg zu gewährleisten. Dieser Beitrag untersucht die Spannungsfelder zwischen IT-Demand und IT-Supplier, die oft durch Unwissenheit und mangelnde Feldkompetenz entstehen. Solche Herausforderungen können zu erheblichen Strömungsabrissen führen, die den Projekterfolg gefährden.Um diese Risiken zu minimieren, werden pragmatische Kooperationsmodelle vorgestellt, die auf der Definition gemeinsamer Architektur Artefakte basieren. Transparenz in der Zielsetzung sowie ein effektives Stakeholdermanagement sind entscheidend für den Erfolg der Zusammenarbeit. Der Beitrag bietet praxisnahe Lösungsansätze und Handlungsempfehlungen.

Zielpublikum: Manager, Entscheider, Projektleiter, Architekten
Voraussetzungen: Projekterfahrung, Fachkenntnisse, agile Methoden, Architektur
Schwierigkeitsgrad: Basic

In der Praxis begegnet uns bisher kaum die konkrete Anforderung, Softwarearchitekturen mit Blick auf ihre Umweltverträglichkeit zu gestalten. Die zunehmenden Auswirkungen des menschengemachten Klimawandels zeigen jedoch, dass der eigene Beitrag zu mehr Klimaschutz nicht mehr optional ist.

Dieser Vortrag geht darauf ein, wie GreenIT, Nachhaltigkeit und Umweltverträglichkeit im Architekturentwicklungsprozess natürlich integriert werden können. Wir betrachten Möglichkeiten zur nachhaltigen Umgestaltung bestehender Systeme und zeigen Wege auf, neue Softwarearchitekturen von Anfang an umweltbewusst zu denken. Weiterhin erkunden wir organisatorische Aspekte, die zur Entwicklung grünerer Softwarearchitekturen beitragen können.

Zielpublikum: Architekten:innen, Entwickler:innen, Manager:innen
Voraussetzungen: Grundlagen der Softwarearchitektur
Schwierigkeitsgrad: Advanced

Am Anfang eines Projekts ist die Produktivität hoch. Architektur, Bausteine und Abhängigkeiten sind klar definiert. Doch mit der Zeit wird der Code immer umfangreicher und die Anforderungen werden komplexer. Es schleichen sich ungewollte Abhängigkeiten ein. Code und Architekturdiagramme passen nicht mehr zusammen.

Architekturtests wirken dem entgegen. Sie funktionieren wie Unit Tests, testen aber Anforderungen an die Architektur. Sie laufen automatisiert im Continuous Build und verhindern dadurch, dass sich Verstöße gegen die anfangs aufgestellten Architekturregeln einschleichen.

Der Vortrag gibt einen Überblick über die Möglichkeiten von Architekturtests und demonstriert anhand einer Beispielarchitektur, wie sich verschiedene Aspekte der Architektur testen lassen. Der praktische Anteil des Vortrags ist sehr hoch. Die Teilnehmer sind nach dem Vortrag in der Lage, das neu erworbene Wissen umgehend in eigenen Projekten praktisch anzuwenden.

Zielpublikum: Architekten und Entwickler
Voraussetzungen: Softwarearchitekturgrundlagen, Grundkenntnisse in .NET
Schwierigkeitsgrad: Advanced

Fitness functions are an essential part of evolutionary architectures – and they can also bring desired structures and properties to legacy code bases, step by step. But how do they look like in practice? What kinds of fitness do they check and assert?

After a general introduction to fitness functions we'll do a deep dive into some concrete examples, covering use cases for common architectural patterns. We'll see examples in Java code, based on ArchUnit and jMolecules. But the basic ideas and concepts are applicable to other languages and technologies as well.

The session closes with a discussion about when and where to write fitness functions and who should write them – and why the use of fitness functions can help bridge the gap between architects and software developers.

Target Audience: Architects, Developers
Prerequisites: Some coding experience is helpful but not required for this session.
Level: Basic

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.

Target Audience: IT architects, lead devs, decision makers
Prerequisites: Broad knowledge of IT-related topics (we will travel from the engine room to the penthouse)
Level: Advanced

Wann hat euch das Dokumentieren eures Softwaresystems zum letzten Mal Spaß gemacht? Noch nie? Lasst uns das ändern!

Wir alle wissen, dass Architekturdokumentation sehr wichtig und auf lange Sicht von unschätzbarem Wert ist, doch immer fällt das Thema hinten runter. Dokumentation kann abschreckend wirken: unsicher, womit ihr starten sollt, Zeitmangel oder noch nie vorher gemacht und nur Negatives gehört.

Wir zeigen euch den Architecture Communication Canvas – einen pragmatischen und prägnanten Ansatz, Softwaresysteme zu dokumentieren und die wichtigsten Aspekte eurer Architektur und Implementierung an Stakeholder zu kommunizieren. Dieser Ansatz – übrigens kompatibel zu arc42, nur wesentlich knapper – wird euren Dokumentationsprozess maßgeblich verändern.

Wir werden euch beweisen, dass Dokumentation Spaß machen und gleichzeitig sinnvoll sein kann: mit vielen Beispielen, aber auch ausreichend Zeit, es selbst auszuprobieren.

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Interesse an Architekturdokumentation
Schwierigkeitsgrad: Basic

Auf der grünen Wiese lässt sich leicht eine modulare Anwendung schreiben. Was aber, wenn es – wie leider so häufig in der Praxis – einen bestehenden, historisch gewachsenen Monolithen gibt, der schon einmal bessere Tage gesehen hat? Wie kann die Lücke zwischen dem alten monolithischen Architekturansatz zu einer modernen, modularen Architektur geschlossen werden, die ggf. in Microservices mündet?

Diese Session bietet eine praxisnahe Einführung in bewährte Methoden und Strategien, um eine Migration erfolgreich zu bestreiten. Wie kann ich Event Storming zum Finden von Modulgrenzen einsetzen? Wann und wie wende ich das Strangler Fig Pattern an? Wie teste ich einen Monolithen, wenn nicht mehr viel Wissen über Implementierungsdetails vorhanden ist? Diese und andere Fragen werden beantwortet.

Zielpublikum: Architekten, Entwickler, Projektleiter
Voraussetzungen: Erfahrungen mit monolithischer Legacy-Software
Schwierigkeitsgrad: Advanced

„Cloud is the new Normal“, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer Cloud spezifischer Architekturmuster?

Der Workshop zeigt an einem praktischen Beispiel, wie eine klassische Enterprise-Anwendung Schritt für Schritt in die Cloud überführt werden kann und welche grundlegenden Abwägungen und Entscheidungen dafür im Vorfeld getroffen werden müssen. Es werden sowohl die notwendigen architektonischen Schritte diskutiert als auch die verschiedenen, damit verbundenen Risiken aufgezeigt und bewertet.

Maximale Teilnehmendenzahl: 30

Zielpublikum: Architekten, Entwickler, Projektleiter, Manager, Entscheider
Voraussetzungen: Grundlegendes Architekturverständnis
Schwierigkeitsgrad: Basic

Good Software Design — the proper management of dependencies — is the foundation for the success of a project. The basic building blocks for software design are design patterns. Design patterns have proven themselves invaluable over several decades and thus knowledge about them is essential to design robust, decoupled systems. Modern C++, however, has profoundly changed the way we use C++, how we think about design and implement solutions. This also affects how we implement design patterns.

This workshop explores modern C++ software design and the modern forms of classic design patterns. It provides guidelines, idioms and best practices for sustainable and maintainable design, which enables programmers to create professional, high-quality code.

Target Audience: C++ developers
Prerequisites: Solid C++ knowledge, some knowledge about GoF design patterns
Level: Advanced