In diesem Vortrag werden wir einen Überblick über die aktuellen Angriffsvektoren in der Cybersicherheitslandschaft geben und die spezifische Bedrohungslage in Deutschland beleuchten. Wir diskutieren, wie technologische Entwicklungen wie Digitalisierung und Künstliche Intelligenz die Bedrohungen verändern und welche Auswirkungen diese auf die Sicherheitslage in Deutschland haben. Der Vortrag bietet zudem eine Perspektive darauf, welche Maßnahmen erforderlich sind, um den neuen Herausforderungen effektiv zu begegnen.

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

Retrospektiven sind ein mächtiges Werkzeug, um Kollaboration in Teams zu fördern. Sie ermöglichen ihnen, im Plan-Do-Check-Act-Zyklus ihre Arbeitsweise strukturiert zu reflektieren, sie fördern Zusammenarbeit und die Lieferfähigkeit für Ergebnisse.

In manchen Teams werden Retrospektiven zwar halbwegs regelmäßig durchgeführt, sie haben jedoch ihre Strahlkraft eingebüßt. Hinter vorgehaltener Hand wird kritisiert, dass die wichtigen Themen nicht angesprochen, immer die gleichen Probleme diskutiert werden oder dass dem Moderator eine phantasievolle Methodenauswahl wichtiger scheint als echte Problemlösung.

In dieser Session wird mit einem Praxis-Theorie-Mix gezeigt, wie man die Ursachen für Zombie-Retrospektiven herausfindet, sie wiederbeleben und mit anderen Praktiken ergänzen kann.

Zielpublikum: Menschen, die Retrospektiven moderieren und/oder Impulse für ihr Team suchen
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic

KI, Digitalisierung, Nachhaltigkeit … Es gibt immer neue strategische Herausforderungen zu bewältigen, und strategisches Alignment bleibt eines der kritischsten Erfolgskriterien.

Outcome-orientierte Strategiearbeit (z. B. Objectives und Key Results, OKRs) kann der Katalysator und eine transformative Kraft sein, um das strategische Alignment in Organisationen zu schaffen, das über vertikale und horizontale Dimensionen hinausgeht.

Die weit verbreitete Praxis der Kaskadierung bzw. das Kopieren von Organigrammen bei der Umsetzung der Strategie behindert allerdings oft den Fortschritt und die Motivation. Aber es gibt eine Alternative: „Das Solar System“ – ein innovatives Modell, das aus der Praxis heraus entwickelt wurde, um bereichsübergreifendes Alignment und Kollaboration zu stärken.

In diesem Vortrag tauchen wir in die Feinheiten des „Solar Systems“ ein und präsentieren verschiedene Team-Modelle wie Shared Teams und Dynamische Teams, die sich auf bestimmte strategische Outcomes konzentrieren. Praxisnahe Beispiele beleuchten die Anwendung dieser Modelle in der realen Welt.

Zielpublikum: Strategic Leadership, Product Leadership, Organisational Development, Decision Makers, Coaches
Voraussetzungen: Erste Erfahrungen mit Strategiearbeit, OKR, Team- und Organisationsentwicklung
Schwierigkeitsgrad: Advanced

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

Most of us have heard that the decisions of an autocrat (or manager) might not always be the best to address complex environments. Luckily we have found other means of decision-making in groups throughout the years. from "democratic" consens, to consent, to consultative, commission based or any other decision making methods you can find out there. These methods sound much better than having a dictator and promise more involvement of the team. Yet how do you know if the method you chose in your team/department/company is well suited for the task? - absolutely right.

By experimenting and seeing/feeling different decision making methods in action. I'll create an environment where you create products for an ever changing market in a time bound setting - while using/trying the decision making method of your choice.

Target Audience: Project Leaders, Line Managers, Architects, Coaches, Scrum Masters
Prerequisites: Being able to work together in a group
Level: Advanced

"KI ist gekommen, um zu bleiben", ist von vielen Seiten zu hören. Das stimmt. KI ist nicht mehr wegzudenken. Millionenfach finden wir KI in Anwendungen und Funktionalitäten wieder. Die Entwicklung ist rasant und viele wollen noch "auf den Zug aufspringen". Darunter sind auch Lösungen, die ohne KI auskommen und sogar effizienter wären. Umso wichtiger ist es, bei der Planung zu erkennen, wann ein Problem auch ohne KI gelöst werden kann. In dieser Session lernen wir ein paar komplexe Beispiele aus der realen Welt kennen und zeigen auf, wo KI nützlich ist und vor allem wo nicht.

Zielpublikum: Projektleiter, Produktmanager, Anfänger in der Entwicklung
Voraussetzungen: Keine
Schwierigkeitsgrad: Advanced

Generative AI is the talk of the town. Anyone who spends just five minutes thinking about AI can surely come up with several useful business use cases. However, all too often, we find ourselves facing the following dilemma: we want to quickly launch our chatbots and assistant systems and bring our ideas to market readiness. Yet at the same time, important, complex, cross-functional aspects such as data protection, compliance, operational readiness, or model fine-tuning often slow down rapid development and deployment.

Furthermore, enterprise scale AI projects often involve many different stakeholders: data engineers, AI specialists, software engineers, operational experts, and business departments. Too much talking and no progress at all are the result.

AI platforms to the rescue! We believe that established platform engineering approaches and technologies, combined with LLM Ops practices, can tackle this dilemma. Only a robust, scalable, and flexible platform enables our teams to efficiently develop, operate, and manage their data, models, and applications. The platform hides the inherent technical complexity, while allowing users to fully focus on the use case and the creation of value and innovation.

We will explore what a corporate AI platform can look like and the components and services it requires. We discuss how a company-wide platform strategy not only simplifies technical implementation but also creates an ecosystem for innovation, fosters collaboration, increases reusability, and ultimately drastically shortens the time to market.

Target Audience: Developers, Architects, Data Scientists, Decision Makers, Platform Engineers
Prerequisites: Basic knowledge in AI
Level: Advanced

Corporate environments can be a tough nut to crack. Many departments and roles are involved, each with different priorities to yours, and you face changes that must be navigated. The Product Owner (PO) accountability, while critical, often doesn’t wield the power Scrum suggests. You can accept this status quo and focus on managing your backlog only, or take action and leverage your POwer to meet product needs and foster productive cross-department collaboration.

Join me if you want to:

• Discover strategies to overcome silos and build collaborative coalitions
• Hear real stories of using these strategies and their sustainable impact
• Learn effective stakeholder involvement techniques to advance your product’s goals
• Explore leadership strategies for daily integration to boost effectiveness
• Gain practical tools and techniques to implement these strategies in your daily work

POwer on!

Target Audience: Product Owners, Product Managers, Agile Coaches, Head of Product, All Product Leaders & Executives
Prerequisites: You should have at least 1 year experience in a product position and understand basic agility.
Level: Advanced

In the pressure cooker of product development, success depends not just on processes but on the strength of informal networks—the trusted relationships that cut across hierarchies and silos. Companies that fail to cultivate these networks struggle to adapt, innovate, and deliver.

At this session, we will explore how to intentionally foster informal networks that drive product development forward and enable seamless collaboration across departments, ultimately aligning efforts with business goals - both online and offline.

We’ll start with a real-world example from a startup environment and scale these insights for larger organizations.

Target Audience: Product Managers, Product Owners, Decision Makers, Agile Coaches, Team Leaders
Prerequisites: Agile Leadership, Process Facilitation and Change Management experience
Level: Advanced

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

If you have worked in the software industry for a while, you’ll have a hunch that technical skills are often not what stands between us and our success. Around software systems, there are always complex human systems, whose runtime dynamics seems full of fixes that don’t work. As software professionals, can we just tell jokes about SAFe, about being able to copy the Spotify Model, but not paste it? Or should we give the usual shrug – “it’s the system’s fault”?

Xin has been a design and architecture practitioner for more than a decade. Drawing on her own developmental journey, Xin makes a case for the rising relevance of sociotechnical design in a post-modern world, where aging companies struggle with aging software, while adding new software and complexity to their IT portfolio.

This talk weaves together experience reports that illustrate different facets of complexity in software and human systems. It highlights the sociotechnical principles and practices that lie at the center of Domain-Driven Design (DDD) and adjacent practices such as Systems Thinking and Constraints Framework.

From a systems standpoint, we are part of the same mess. If we can become better at seeing and naming the elephants in the room, not as random events, but as systemic patterns described through a consistent systems language, then the current messy reality is no longer our enemy but our ally. It can become a generative force for us to identify leverage and sustain influence, making better impact with our craft.

Join Xin to reflect together on, how we can leverage a multi-dimensional, sociotechnical design toolbox to help us see the system, share the system, and build the system in a reality of vast complexity and constant change.

Target Audience: Architects, Developers, Product Professionals, Engineering Managers, UX Designers
Prerequisites: Prior knowledge of Domain-Driven Design is beneficial for in-depth understanding but not a must
Level: Expert

Vergleichen Sie KI mit Fahrzeugen. Ein Familienauto für die Ausflüge Kindern. Ein Fahrzeug für den Weg zur Arbeit. Ein Fahrrad für die kurzen Wege im Dorf oder in der Stadt. Für das Wochenende ein Motorrad oder Sportwagen und für die Urlaube ein Wohnmobil.

Der Vergleich mit verschiedenen Fahrzeugen im Alltag verdeutlicht, dass es nicht die eine KI gibt, sondern vielfältige, auf unterschiedliche Anwendungsfälle spezialisierte KI-Lösungen.

Es werden praxisnahe Beispiele vorgestellt, die zeigen, wie diese KIs datenschutzkonform in Unternehmen integriert und an spezifische Unternehmensbedürfnisse angepasst werden können. Dies kann ein ChatBot für ihre Webseite sein, ein kleiner Helfer zum Verfassen von Texten oder Analysieren von großen Daten. Die Möglichkeiten sind schier unendlich und einige davon werden vorgestellt.

Ziel des Vortrags ist es, den Teilnehmern ein klares Verständnis darüber zu vermitteln, wie und in welcher Form KI gewinnbringend in ihrem Unternehmen eingesetzt werden kann.

Zielpublikum: Projektleiter, Manager
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic

We make decisions all the time in software – our architectures are the sum of them; both conscious and unconscious.

Yet we have so little awareness about *what* decisions are and *how* we decide. This is not only the source of great friction and waste, it is leading to terrible outcomes for our software.

In this talk I’ll describe what architectural decisions are, and the different ways that we approach them (individually and collectively) making clear the pros and cons of each. I’ll then compare them all, describing the ideal characteristics of a decision-process for modern software development. As a consequence, not only will you be able to decide better as an individual, you will also be able to diagnose failings in your group decision processes and resolve them.

Target Audience: Architects, Lead developers, Product Managers, Project Managers
Prerequisites: Experience delivering a software system
Level: Advanced

Retrospectives are the key event for ensuring continuous improvement in agile and non-agile teams. However, many participants tend to have bad experiences with poorly facilitated retrospectives, which demotivates them from sharing personal insights and, in the end, might lead to a cancelling of retrospectives from the team's schedule.

There are many books and articles about how a good retrospective looks like. They describe the result but often they lack the crucial part of HOW to get to engaging and sustainable retrospective. It is unfortunately not sufficient to simply combine different formats for each of the five retrospective stages from template collections (like e.g. the retromat) - there is more to that.

In this talk I will share my visual template for designing flowing retrospectives and I will guide the participants through my intention of each of the designing steps.

Among others the participants will learn:

• Why it is important to change between focus topics in retrospectives
• How important a clear retrospective goal is for the design
• Why  not to start with the Set-the-Stage phase when designing a retrospective
• With which phase to start instead
• What the prerequisit informations for a successful retrospective design are
• How to smoothly connect the different phases of the retrospective
• How to increase your (short- and long-term) success of retrospectives
• What to do if things don't work out as planned

This talk is perfect for all those who have the feeling that there is still some room for improvement in their retrospectives and/or their retrospective design.

Target Audience: Project Leaders, Scrum Masters, Agile Coaches
Prerequisites: None
Level: Basic

The EU AI Act was established to promote trustworthy AI. This legislative framework outlines comprehensive and rigorous requirements for AI systems, sorting them into four risk groups: prohibited, high-risk, limited-risk, and minimal-risk AI systems. With a grace period of 6 to 24 months from the regulation's publication, it is recommended for companies using AI to start preparing for the upcoming requirements. To ensure technical readiness for compliance with the AI Act, it is crucial to integrate established data governance, AI governance, and MLOps techniques throughout the life cycle of an ML/AI system.

My talk is intended to provide practitioners with a thorough understanding of the EU AI Act's requirements. They also offer practical guidance on implementing MLOps, observability, and data governance processes that align with the regulation. While exploring the legislation to identify the requirements for AI systems and general-purpose AI applications, our discussions will provide an engineering perspective on the proactive implementation of the provisions of the EU AI Act.

Target Audience: Architects, Developers, ML Engineers
Prerequisites: MLOps
Level: Advanced

In früheren Zeiten, als Organisationen lediglich ein einzelnes Produkt anboten, war eine produktzentrierte Ausrichtung einfach. Mit der Skalierung entstanden Herausforderungen: Produkte wurden in kleinere Teilbereiche unterteilt, was kurzfristig Vorteile bot, jedoch die kohärente Produktstrategie schwächte und einen Wandel hin zu einer projektzentrierten Denkweise einleitete.

Der Vortrag wirft ein Licht darauf, wie Organisationen durch eine Neuorientierung an Markt- und Kundenbedürfnissen signifikante Erfolge erzielen können. Wesentlich sind eigenständige Produkte und ein effektives Produktportfolio-Management, die den Gesamtwert steigern und die Anpassungsfähigkeit an Marktveränderungen verbessern, indem sie über einzelne Produkte hinaus ein kundenorientiertes Ökosystem schaffen.

Zielpublikum: CEOs, CTOs, Portfolio-Manager, Programm-Manager, POs, Product Manager, Solution Owner, SMs, Coaches
Voraussetzungen: Erfahrung in Produktmanagement, Produktportfolio-Management, Skalierung, Transition
Schwierigkeitsgrad: Advanced

Nachdem lange Jahre zunächst Selenium und dann Cypress den Markt der Web-Testwerkzeuge beherrscht haben, kommen inzwischen neue Player auf das Spielfeld. Mit Playwright und WebdriverIO bekommt insbesondere Cypress eine starke Konkurrenz. Beide stellen sich nicht nur im Bereich der End2End-Tests auf, sondern besetzen auch das Feld der Komponententests. Auch in anderer Hinsicht sind sie Cypress ebenbürtig.

Der Webentwickler hat erneut die Qual der Wahl. Welches Werkzeug passt am besten zur eigenen Arbeitsweise, zum Projekt und zum Softwareprodukt? Wo liegen die Stärken und Schwächen der Gegenspieler? Und lassen sich bestehende Testsuiten einfach auf ein anderes Werkzeug migrieren? Wir werfen einen vergleichenden Blick auf die drei Kontrahenten und demonstrieren ihre Fähigkeiten in Aktion.

Zielpublikum: Tester, Testmanager, Testautomatisierer, Web-Entwickler
Voraussetzungen: Grundlegende Kenntnisse von Web-Entwicklung, TypeScript, Testautomatisierung
Schwierigkeitsgrad: Advanced

Weitere Informationen zu dieser Keynote folgen in Kürze.

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

Creating high-quality software is challenging due to a focus on solutions over understanding organizational context. Developers need to engage with stakeholders across contexts. However, stakeholder communication can lead to misunderstandings and conflicts, disrupting knowledge sharing. This often results in autocratic decisions by architects. Achieving sustainable and design decisions, it's more effective to employ visual techniques, improving collaboration with stakeholders.

This talk explores collaborative modeling, a technique for analyzing complex decisions with all stakeholders. Inclusive sessions and skills like observing, listening, neutrality, and empathy are key. The goal is for teams to understand stakeholder needs, guiding software architecture through collaborative design.

Target Audience: Technical leaders, decision makers, software engineers, architects
Prerequisites: None
Level: Advanced

In der modernen Softwareentwicklung bekommt das Plattform-Engineering einen immer größeren Stellenwert. Es ist nicht nur die Plattform, sondern es sind weit mehr Faktoren, die unsere Arbeitsweise in der Produktentwicklung beeinflussen und damit Auswirkungen auf das Plattform-Engineering haben. In der Vergangenheit hat man sich intensiv um die eigentliche Entwicklung gekümmert und die Bedienung der Plattform als gegeben hingenommen. Diese Zeiten sind seit DevOps und agiler Softwareentwicklung mit autonomen Teams auf heterogenen Plattformen endgültig vorbei.

Im Vortrag sehen wir uns das Thema Plattform-Engineering aus mehreren Perspektiven an und werden feststellen, dass eine Dimension – die Technik – nicht reicht.

Zielpublikum: Architekten, Manager, Entscheider, Software-Engineers, Platform-Engineers
Voraussetzungen: Grundkenntnisse IT-Plattformen
Schwierigkeitsgrad: Advanced

In den letzten Jahren hat das Strategische Design aus DDD einen enormen Zuspruch gewonnen, was auf jeden Fall gut und wichtig ist. Aber das bedeutet nicht, dass wir das Taktische Design von DDD vernachlässigen sollten.

Für diesen Vortrag beginnen wir mit einer starren und fragilen Codebase, wie sie häufig im Laufe der Jahre entsteht. Wir führen Schritt für Schritt Refactorings durch, wobei wir den Supple Design Strategien (supple: englisch für “geschmeidig”) aus DDD sowie anderen bekannten Refactoring-Patterns folgen. Dabei führen wir Value Objects, Entities und weitere Elemente des Taktischen Designs nach und nach ein. Dies erlaubt es uns, die Codebase klar zu strukturieren, so dass Änderungen schnell und leicht möglich sind und das Arbeiten mit dem Code wieder Freude bereitet.

Konkret lernen die Teilnehmer, in welchen Schritten diese Strategien gut anwendbar sind. Die einzelnen Schritte sind einfach und klar verständlich. Sie fordern zum Nachdenken heraus und geben Einblicke, mit denen wir das Domänenmodell im Laufe des Refactorings signifikant verbessern.

Zielpublikum: Architekten, Entwickler
Voraussetzungen: Programmiererfahrung, Erfahrung mit größeren und älteren Codebasen hilfreich
Schwierigkeitsgrad: Advanced

Neues Lernen ist entscheidend, um mit den ständig wandelnden Anforderungen der modernen Gesellschaft und Arbeitswelt Schritt zu halten. Der Vortrag diskutiert Trends im organisatorischen Lernen, darunter das Movement-Lernen, das auf individueller Begleitung und gemeinschaftlichem Lernen basiert. Diese neuen Ansätze fördern die Selbstorganisation, den Austausch und das Experimentieren und bieten vielfältige Vorteile für Organisationen und Mitarbeiter.

Zielpublikum: Führungskräfte, Manager, Personalverantwortliche, am Lernen Interessierte
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic

GenAI services have been rapidly integrated into various digital business models, but what if your data holds better answers? How can this technology be combined with an organization's knowledge and data?

This talk explores Large Language Models (LLMs) and their augmentation with custom data via Retrieval-Augmented Generation (RAG). Discover Statista's pioneering journey from rich search results to concise, informed answers with their LLM-based application, ResearchAI. We'll discuss challenges such as building a skilled team, the impact of exclusive data on answer quality, high costs, query latency, and LLM hallucinations despite accurate data. This session provides a realistic look at the hurdles and strategies for optimizing RAG applications in the real world.

Target Audience: Data Scientists, Data Engineers, Developers, Decision Makers
Prerequisites: Basic knowledge of GenAI
Level: Expert

You know our natural world is burning and climate disaster is upon us. We need system change - not climate change. We as IT people are in the perfect position to help the system change happen, because what we do in IT product development matters; rather a lot to be honest. Let's uncover better ways to develop IT products in a more sustainable way.
This talk will take you on a crash course of thinking like a 21st century economist (it will be all about doughnuts), principles of circular design and what you need to know about the concept of degrowth. And then the talk will tie this knowledge to our day-to-day-work in product development: how could you start using these ideas in your work to contribute to building a more sustainable future?

I will tell you what happened when we started applying circular design principles in IT product development (we ended up with modularity and microservices). If one starts applying the "Sharing principle" your product vision will change (for us it changed into "something as a service") and your product goal and OKRs will change too - we moved away from the goal "endless growth in number of customers".

This talk will leave you with practical tips on how to weave sustainability in your entire product development chain, like Product design principles for circularity and like Sharing principles for less (economic) growth.

This talk will also leave you with a bigger - or reaffirmed - love for Agile Principle nr 10. The planet needs more simplicity.
(and no, this talk is not just about carbon emissions because "net zero" will not be enough to get us through)

Target Audience: Product Owners, Product Managers, Architects, Leadership
Prerequisites: Some basic knowledge of how agile product teams work together is assumed
Level: Basic

Nach Vorfreude auf den AI-Coding-Assistant kam Ernüchterung: Viele Vorschläge waren unbrauchbar, es wurde zu viel „halluziniert“. Wir fragten uns, ob es der richtigen Technik bedarf. Wir experimentierten mit Techniken (Chat-Assistant, Auto-Completion, Comment-driven) und Vorgehensweisen (Chat-first, Code-first, Test-first, TDD).

Dieser Vortrag konzentriert sich auf TDD mit AI-Coding-Assistants. Wir erläutern die Vorgehensweise von AI-Coding-Assistants, erklären Begrifflichkeiten, Einschränkungen, Ansätze und demonstrieren das Vorgehen mit Live-Coding. Wir versuchen, Grenzen der AI-Assistants auszuloten: Verbesserte Code-Completion oder Pair-Programming-Partner.

Zielpublikum: Entwickler:innen
Voraussetzungen: Grundkenntnisse in Programmierung
Schwierigkeitsgrad: Basic

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

Disclosure - this is a talk about people - not about AI. This is a talk about how we will continue to apply our humans strenghts in a world enhanced by AI.

One of the LLM engines I work with seems to think it can take over my job as an architect. I say with some confidence that for the next few decades, my job will be heavily influenced by AI, but not replaced by AI. For example I am presenting and OOP and *it* is not.

Software architects and system architects will not be replaced anytime soon by Generative AI or LLMs. They will be replaced by software architects that know how to leverage Generative AI and LLMs, and just as importantly, know how NOT to use Gen AI. For the last two years, Avraham has been on a journey exploring the use of AI to augment the way he does architecture and makes architecture decisions as well as assimilate the architectural understanding within the organization.

Along the way, Avraham has learned so much both about generative AI's abilities and limitations, and even more about himself as an architect and as a person. For example, Avraham has learned that AIs can propose tradeoffs along with convincing suppporting arguments, but only a human Architect can be held accountable. An AI might be able to create a drawing and talk you through it, but only a human architect will appriciate the look of confusion on your face and emphasize that one dotted line that makes everything clearer.

In the talk, Avraham invites you to join him on his journey. This talk will equip you with the knowledge and very practical tools to start on your own adventure to leverage the power of GAI, elevate your architectural practice, and hopefully stay ahead of the curve.

Target Audience: Software Architects, Developers, Decision Makers
Prerequisites: Basic Curiosity about AI and machine learning
Level: 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

Homeoffice, Remote-Arbeit, verteilte Teams – alles das sind heute gängige Arbeitsformen, die uns überall begegnen. Kann es nach der Team-Definition „Ein Team ist eine Gruppe von Menschen mit einem gemeinsamen Ziel, das sie nur durch Zusammenarbeit erreichen können“ das klassische Agile Team heute überhaupt noch geben? Womit haben wir es heute oft zu tun? Wir möchten dich in diesem interaktiven Vortrag auf unsere Erfahrungs- und Gedankenreise der Akzeptanz von Agilen Gruppen – und den damit geänderten Anforderungen an Führung – mitnehmen.

Agile Gruppen unterscheiden sich von Agilen Teams dadurch, dass eine enge Zusammenarbeit nicht stattfindet, sondern jede Person einen individuellen Beitrag leistet, der später ins Ganze eingefügt wird. Trotzdem ist agiles Arbeiten immer noch möglich.

Damit so eine Agile Gruppe erfolgreich sein kann, braucht sie allerdings bestimmte Rahmenbedingungen und Vorgehensweisen, die sich von jenen eines Teams zum Teil stark unterscheiden. Die Vorteile, Rahmenbedingungen – und natürlich auch mögliche Nachteile einer Agilen Gruppe – werden wir gemeinsam beleuchten. Dazu bekommst du einige lösungsfokussierte Techniken des Gruppencoachings an die Hand, um Agile Gruppen noch besser unterstützen zu können. Damit möchten wir eine spannende Diskussion anregen oder – wer weiß – vielleicht sogar motivieren, die Zwangsvorstellung, Agile Teams trotz stark veränderter Rahmenbedingungen um jeden Preis erhalten zu müssen, aufzugeben.

Zielpublikum: Scrum Master, Agile Coaches, Führungspersonen, Organisationsentwickler:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic

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

Datenintensive Softwaresysteme, insbesondere Empfehlungssysteme, prägen zunehmend unseren Alltag. Damit diese Technologien der Menschheit dienen, müssen sie ethisch entwickelt und von den Werten ihrer Nutzer getragen werden. Ethische Prinzipien sind zwar wichtig, ihre praktische Anwendung gestaltet sich oft schwierig. Deshalb schlagen wir einen praxisorientierten, wertebasierten Ansatz vor. Das HYBRIDA-Framework unterstützt die Ideenfindungsprozesse und sorgt für verantwortungsbewusstes Design. Es konzentriert sich auf zwei Hauptaspekte: die Integration von Werten in Designprozesse und die Förderung interdisziplinärer Zusammenarbeit in datenintensiven Entwicklungsumgebungen. Das HYBRIDA-Framework unterstützt insbesondere die Ideenfindungsprozesse und besteht aus drei Phasen („Dive In“, „Tune In“, „Look Out“) für verantwortungsbewusstes Design, die die Ausrichtung von Team und Stakeholdern betonen.

In der ersten Phase werden die Werte des Teams und des Projekts identifiziert, beginnend mit einer Erkundung der Werte, die jede Person einbringt. In der nächsten Phase werden die Bedürfnisse, Motive und Werte der Stakeholder sowie der Nutzungskontext untersucht. Darauf basierend etabliert das Team Designprinzipien, die den Prozess leiten und als Ideen-Trigger fungieren. Das Team wird zudem herausgefordert, mögliche Probleme zu durchdenken und wie mögliche Dystopien verhindert werden können.

Der methodische Ansatz von HYBRIDA betont auch die kollaborativen Aspekte des Entwicklungsprozesses, indem hybride Werkzeuge und intensive Reflexion genutzt werden, um ein umfassendes Verständnis der ethischen Prinzipien zu fördern. Dieser interaktive Rahmen stärkt nicht nur die ethische Grundlage des Entwicklungsprozesses, sondern stellt auch sicher, dass vielfältige Perspektiven und Expertisen berücksichtigt werden, was zu robusteren und ethisch fundierten Softwarelösungen führt.

Zielpublikum: Produkt Owner, Projektleiter:innen, Entscheider:innen, Anforderungsingenieur:innen, UX-Designer
Voraussetzungen: Projekterfahrung, Produktkonzeption, Anforderungserhebung und -gestaltung, User-Centered Design
Schwierigkeitsgrad: Basic

Bei langlebiger Software lauern die meisten Fehler in dem Code, der kürzlich verändert wurde. Das zeigen empirische Forschungsarbeiten seit Langem und unser Bauchgefühl sagt uns das vermutlich noch viel länger.

Viele Teams setzen daher die sogenannte Test-Gap-Analyse ein, die Test-Gaps (ungetestete Änderungen) automatisiert aufdeckt. Unsere Erfahrung zeigt jedoch, dass oft mehr Test-Gaps gefunden werden, als (rechtzeitig) getestet werden können.

Im Vortrag stellen wir einen risikobasierten Ansatz zur Priorisierung von Test-Gaps vor, in den mehrere Dimensionen der Code-Änderung einfließen (u.a. Zentralität im Abhängigkeitsgraph, Komplexität der Änderung, Findings-Churn). Wir haben den Ansatz empirisch validiert und stellen die Ergebnisse für acht Systeme der Munich Re und der LV 1871 vor.

Zielpublikum: Tester, Test-Manager, Testautomatisierer, Entwickler, Architekten
Voraussetzungen: Interesse an Software-Qualität und Testen
Schwierigkeitsgrad: Basic

„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? Passende Blaupausen dazu gibt es mehr als genug. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloud-Anbieter glauben machen wollen? Natürlich nicht. Diese Session zeigt anhand typischer Antipatterns, wie der Weg in die Cloud garantiert im Desaster endet und wie man sich dagegen wappnen kann. Ähnlichkeiten zu existierenden Projekten sind rein zufällig – oder auch nicht.

Zielpublikum: Architekten, Entwickler, Projektleiter, Manager, Entscheider
Voraussetzungen: Keine
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

In den letzten Jahren haben generative KI-Tools, insbesondere im Bereich des Designs, erheblich an Bedeutung gewonnen. Die meisten Diskussionen konzentrieren sich jedoch auf die Bildgenerierung und vernachlässigen das breitere Spektrum an Aufgaben im Designprozess, insbesondere im Kontext des User-Centered Design (UCD). Das UCD-Framework betont das Verständnis der Benutzerbedürfnisse, die Generierung von Ideen und Anforderungen, das Prototyping konkreter Lösungen und die Einbeziehung von Benutzerfeedback in verschiedenen Phasen. Dieser umfassende Ansatz erfordert eine sorgfältige Integration generativer KI und wirft die Frage auf, inwieweit KI-Tools der UCD-Prozess unterstützen können.

In diesem Vortrag wird eine theoretische Perspektive auf den Designprozess präsentiert, wobei kognitive Prozesse und die wesentlichen Kompetenzen von Entwicklungsteams berücksichtigt werden. Basierend auf einem Anwendungsfall werden Bereiche vorgestellt, in denen KI den Designprozess verbessern oder behindern kann. Es wird aufgezeigt, wie KI-Tools in verschiedenen Phasen des UCD eingesetzt wurden und welche Vor- und Nachteile dabei festgestellt wurden. Der Vortrag zeigt sowohl das Potenzial als auch die Grenzen von generativen KI-Werkzeugen im Designprozess auf.

Zielpublikum: Projektleiter:innen, Product Owner, UX-Designer:innen, Anforderungsingenieur:innen
Voraussetzungen: Projekterfahrung, User-Centered Design, User Experience
Schwierigkeitsgrad: Basic

Wie verändert unsere Sprache die KI und die KI unser Denken?

Der Einsatz von LLMs hat rasant zugenommen, ohne KI kommen wir gefühlt kaum noch aus. Gleichzeitig wissen wir, dass die Modelle Biases beinhalten, die zu ethisch fragwürdigen oder nach menschlichem Ermessen unfairen Ergebnissen führen können, und dass die KI diese Vorurteile von uns gelernt hat! Wenn nun aber die KI von uns lernt und wir von der KI, wo setzen wir dann an, um uns gemeinsam zu verbessern?

In diesem Talk greife ich alte und neue Beispiele zu inklusivem Design und Diversität in der Softwareentwicklung auf und zeige, wie ich diese Beispiele beim Bau eines Custom GPT im Prompting genutzt habe, um einen Diversity Bias in Dokumenten oder auf Webseiten aufzuspüren, und welche Erfahrungen ich daraus mitgenommen habe.

Zielpublikum: Business-Analyst:innen, UX-Designer:innen, Product Owner, Entwickler:innen, Menschen
Voraussetzungen: Keine
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

Join us for an immersive exploration into the world of technical teams through engaging and educational simulations.
Understanding Technical Debt: Learn about technical debt from a non-technical perspective. Discover how it accumulates, impacts projects, and strategies to mitigate its effects.
Navigating Dependencies and Silos: Experience the tension of organizational silos by engaging in Testing Jenga.
The Power of Pair Programming: Discover the advantages of pair programming without writing code. Through team-based solving battles, see how collaboration enhances problem-solving and learning.
Prepare to think, play, and learn as we decode the secrets of successful technical teams using non-technical examples!

Target Audience: Developers, managers, non-developers who want to learn about these concepts
Prerequisites: None
Level: Advanced

Es gibt eine große Zahl an Werkzeugen, die Qualitätsprobleme in Bestandscode mittels statischer Analyse erkennen und sichtbar machen. Die automatische Behebung dieser Probleme war bisher aber nur in vergleichsweise einfachen Fällen möglich. Die derzeitigen Entwicklungen in der künstlichen Intelligenz, speziell die Large Language Models (LLMs), verschieben die Grenzen des Möglichen jedoch deutlich.

In diesem Vortrag möchte ich auf Basis eines hierfür erstellten Benchmarks aufzeigen, wie weit sich Qualitätsprobleme heutzutage durch KI beheben lassen. Neben Erfahrungen aus unserer internen Entwicklung möchte ich auch beleuchten, welchen Einfluss die Wahl des Basismodells hat, welche Informationen die LLMs dabei als Input benötigen und an welchen Problemen die KI heute noch scheitert.

Zielpublikum: Architekten, Entwickler, Projektleiter
Voraussetzungen: Interesse an Software-Qualität und KI
Schwierigkeitsgrad: Basic

Es gibt viele Tools, die AI nutzen, um uns in der Softwareentwicklung zu assistieren. Einige generieren Code oder Testfälle, andere schlagen Code-Verbesserungen vor oder selektieren Tests auf Basis von Code-Änderungen uvm.

Leider wissen wir wenig darüber, welche Fehler diese AI-Assistenten sporadisch oder häufig machen. Allerdings müssen wir uns vermutlich darauf einstellen, dass sie in allen Phasen der Softwareentwicklung Einzug halten werden, alleine schon deshalb, weil sie bequem sind.

In diesem Vortrag möchte ich darüber sprechen, wie wir dieser Herausforderungen aus Sicht der Qualitätssicherung begegnen können und welche automatisierten Analysen ergänzend oder begleitend zu AI-Tools eingesetzt werden können, um dem Risiko ihres Einsatzes zu begegnen.

Zielpublikum: Entwickler, Architekten, Manager
Voraussetzungen: Interesse an Qualitätssicherung, Code-Analysen und AI-Assistenten
Schwierigkeitsgrad: Basic

Let’s face it, the only way to make it in our fast-paced, ever-changing business environment is to focus on learning. Learning as leaders, learning as team and learning as an organization. Learning about our business direction, learning about our work and work environment, learning about our customers’ needs, and more. Essential for sustained success and innovation, the heart of an effective Organizational Learning culture lies with leadership. Leaders not only set the vision and strategic direction, but also model the behaviors and create the environment necessary for learning to thrive.

In this interactive talk, Diana Larsen (co-author of Lead without Blame: Building Resilient Learning Teams), engages participants in exploring the pivotal role that leadership plays in cultivating a robust organizational learning culture. You will walk away with custom-designed first steps toward boosting the impact of learning work for you, your peers, and your organization.

Target Audience: Executives, CxO's, Senior Management, Vice-Presidents, Directors, Department Heads, Managers, Leads
Prerequisites: Experience in a stressful leadership role in organization, business, or enterprise
Level: Advanced

So... in our organisation we've been busy trying to bridge the gap between Dev and Ops. And we've been moving towards an almost completely automated Infrastructure enablement. We thought we were doing so well. And then... it turned out that even without human intervention, IT infrastructure is secretly still about human interaction. I will tell you our real life story of how we hit rock bottom Developer Experience because as enablement teams we were so focused on IaC and automating everything that somehow we forgot to talk to our very own customers: the other teams in the organisation that are building software products. We thought we knew what they needed - because we were all developers ourselves too, innit. Well...-DevEx metrics showed us. Thankfully, this is a story with a happy ending too. We quickly retraced our steps and reverted to practical communication strategies to bridge the gap between us "software defined infrastructure product group" and the other teams.

Practical take-aways from this talk are some practices that can be applied straight away, to restore lost connections:

• Heard, seen, respected (learn to listen without showing any judgement)
• Finnish listening (remain silent! it allows conversations to evolve naturally. And we will practice some during the talk)
• Back-to-back (ha, that will be the mystery practice & exercise)

Target Audience: Architects, Developers, Managers, DevOps team members
Prerequisites: None
Level: Basic

In this constantly changing world, we face new challenges: rapidly changing customer needs, increasing competition, and a shortage of skilled workers. Agility and speed are essential. Adopting Platform Engineering can be key, providing the flexibility and scalability to adapt swiftly, outpace competitors, and bridge the skills gap through automation and optimization.

I will demonstrate, using a real Platform, how Platform Engineering can help companies overcome hurdles and scale issues with DevOps practices.

Target Audience: Architects, Developers, Project Leaders, Managers, Decision Makers, Platform Engineers, DevOps Engineers
Prerequisites: Basic DevOps knowledge, understanding of platform engineering concepts
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

Die jährlichen Mengen an Elektronikschrott nehmen weltweit immer größere Ausmaße an. Software ist sehr häufig dafür verantwortlich, dass diese riesigen Abfallmengen überhaupt entstehen. Die negativen Umweltauswirkungen von Software betreffen mehrere Aspekte, denn steigende Anforderungen an Software führen häufig zu vorzeitiger Hardwareerneuerung. Das Umweltbundesamt hat diese Problematik unter anderem durch die Entwicklung des Umweltzeichens Blauer Engel für ressourcen- und energieeffiziente Software adressiert. Der Blaue Engel für Software ist 2020 für Desktop-Software in Deutschland eingeführt worden. Das Umweltzeichen Blauer Engel ist ein unabhängiges, staatliches und multikriterielles Label, es beinhaltet neben der Transparenz des Energie- und Ressourcenverbrauchs auch Kriterien wie Abwärtskompatibilität und Nutzerautonomie. Mitunter werden beispielsweise die Garantie von Sicherheitsupdates, aber auch die Dokumentation von Schnittstellen und die Offenlegung von Datenformaten gefordert. Mit diesen Kriterien soll verhindert werden, dass die Hardwarelebensdauer von Geräten durch Software verkürzt wird. Damit fordert das Konzept des Blauen Engels die größtmögliche Transparenz von Software. Das Konzept, das auf Offenlegung und Weiterbenutzung von Programmiercode basiert, kann damit ein wesentlicher Treiber für die Entwicklung von nachhaltiger Software sein. In diesem Vortrag werden der Blaue Engel und seine Kriterien für Software vorgestellt und die aktuelle Erweiterung des Geltungsbereiches auf mobile Apps und Client-Server-Software. Es wird dabei herausgestellt, wie mit einem solchen Umweltlabel ein Problembewusstsein für den Energie- und Ressourcenverbrauch von Software in der Softwarecommunity etabliert werden kann. Gleichzeitig soll durch den Blauen Engel die Open-Source-Szene, die häufig Pionierarbeit im Bereich der Produktinnovationen betreibt, dazu angeregt werden, nachhaltige Software z. B. durch Green-Coding-Methodiken zu programmieren.

Zielpublikum: Architekten, Entwickler, Projektleiter, Manager, Entscheider, Product Owner
Voraussetzungen: Interesse an Nachhaltigkeitsthemen
Schwierigkeitsgrad: Basic

BDD is not new, but is very useful. If you have never used it before, or have tried and it didn't work, this session will give a good grounding to using BDD successfully. We'll cover the basics, working through some examples and discuss how to succeed.

We will focus on the process, learning how to write scenarios and have a brief glimpse at what happens under the hood. We'll also think about helping everyone engage with testing.

If you want more people to get involved in testing and need ideas, come along. I'll tell you about my experiences and what has and hasn't worked. You can share your experience too, so we can all go away ready to test, think and communicate better.

Target Audience: Developers, testers, business or product owners
Prerequisites: An awareness of automatic testing
Level: Advanced

Organisationen ähneln Organismen, sie besitzen einen Überlebenswillen, fressen Dinge, haben Ausscheidungen und hoffentlich auch eine Absicht und Intelligenz. Leider ist die Intelligenz der Organisation oft nur ein Bruchteil der Summe der Intelligenz der einzelnen Teilnehmenden. Eine Organisation, die gestern noch schlau agierte, kann morgen schon dumm sein, wenn sich das Umfeld schnell ändert.
Was macht eine dumme Organisation aus? Kann eine dumme Organisation ihre Ziele gut erreichen? Warum verdummt eine Organisation? Geht es einem Einzelnen in einer dummen Organisation gut?
Beispiele aus dem praktischen Leben, Inspirationen zu intelligenten Schritten und Berichte über Organisationen, die schrittweise schlauer wurden.

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

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

In ihrem Podcast „Die Wertstoffsammler“ diskutieren Alexander Marquart und Holger Koschek Bemerkenswertes aus der modernen Arbeitswelt. Dabei sind sie über das „Real Book of Work“ von Christina Grubendorfer und Christina Ackermann gestolpert. In diesem Buch räumen die Autorinnen mit neun Mythen auf, die sie im Kontext von Arbeit, Führung und Organisation immer wieder hören und sehen. Alexander und Holger werden in ihrer Session (die als Podcast-Episode live aufgezeichnet wird) einige dieser Mythen mit den Teilnehmenden diskutieren: Muss eine Organisation agil sein? Brauchen wir flache Hierarchien und mehr Eigenverantwortung? Natürlich wird auch die Perspektive der Autorinnen auf diese Mythen gewürdigt. Am Ende ist „New Work“ für die Teilnehmenden hoffentlich mehr als ein Buzzword.

Zielpublikum: Menschen, die nicht nur in, sondern auch an ihrer Organisation arbeiten
Voraussetzungen: Erfahrung mit Organisationsentwicklung ist hilfreich, aber nicht notwendig
Schwierigkeitsgrad: Advanced

Mit dem Cloud-Boom steigen auch IT-Kosten rasant. Kosten entstehen anders als früher real-time und dezentral. Aus diesem Paradigmenwechsel ist „FinOps“ entstanden – ein Framework, das sinnvolles Cloud-Kostenmanagement ermöglicht.
Einige der FinOps-Praktiken wirken ressourcenschonend und senken damit zusätzlich Emissionen. Diese sind wesentlicher Teil von „GreenOps“. GreenOps etabliert sich als FinOps' „best friend“. Doch was hat DevOps damit zu tun?
Wir diskutieren praxisnah:

• welche FinOps- und GreenOps-Praktiken zur Senkung von Emissionen und Betriebskosten beitragen,
• welchen wesentlichen Beitrag DevOps leisten muss,
• was DevOps von zentraler Seite erwarten kann und was auch nicht.

Am Ende haben wir die Brücke geschlagen von Entwicklung und Betrieb über IT-Controlling zum Umweltschutz.

Zielpublikum: Manager, Entscheider, Architekten, Entwickler, Product Owner, Projektleiter
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic

In my lifetime, we’ve experienced the equivalent of 20,000 years of change. Nonlinear change. We’re the architects of change, yet we seem to do the same things again and again, expecting different results. Digital information systems have a staggering effect on relational complexity. Yet, we still approach software development in a mechanistic, industrial & reductionistic way. To design information systems, we need to think in systems. Don’t just adopt Kubernetes, change the structure of your thinking. As Robert Pirsig said, “If a factory is torn down but the rationality which produced it is left standing, then that rationality will simply produce another factory.”

What’s “the rationality that produced” our current approaches? What are the 4 mindshifts that will thrive in the system's age?

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

Software verwendet meist quelloffene Abhängigkeiten. In diese Abhängigkeiten können sich Sicherheitslücken einschleichen. Daher nutzen wir Werkzeuge, beispielsweise Nexus IQ Server, um Software auf bekannte Sicherheitslücken zu scannen.
Im März 2024 wurde eine mögliche Hintertür in der XZ-Bibliothek gefunden. Solche Lücken sind meist außerhalb unseres Quellcodes, aber stellen ein immenses Risiko dar.
Hier kommen Software Bill of Materials (SBOMs) als Standard ins Spiel. Sie spezifizieren, wie genutzte Softwarebibliotheken in einem maschinenlesbaren Format sowohl für Software als auch für Betriebssysteme beschrieben werden können.
Wir schauen uns in diesem Vortrag an, was SBOMs sind und wie wir sie generieren und nutzen können. Darüber hinaus schauen wir uns Tools an, mit denen wir SBOMs auswerten können.

Zielpublikum: Architekten, Entwickler, Entscheider
Voraussetzungen: Projekterfahrung, Risk Management
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

The development and deployment of AI and Generative AI systems in a way that promotes environmental, social, and economic well-being for current and future generations is referred to as sustainable AI. To do this, AI must be built with energy-efficient algorithms and run on renewable energy sources to reduce carbon footprints. Ethical considerations are crucial, ensuring that AI respects human rights and diversity while avoiding increasing disparities. Data management must uphold the ideals of fairness, accountability, and transparency, while also protecting privacy. The overarching goal is to develop AI that not only innovates but also protects and enriches our environment. We will discuss some examples from our experience at Amazon.

Target Audience: All
Prerequisites: None
Level: Basic

Generative AI jenseits des Buzzword-Bingos. In diesem Vortrag präsentiert Christian Weyer konkrete Patterns und Lösungen für die Integration von Large Language Models (LLMs) in eigene Softwarearchitekturen. Wichtige Themen wie Semantic Routing, Tool Calling, Guarding oder Observability werden mit Code-Beispielen illustriert. Es erwartet Entwickler und Architekten ein pragmatischer Einblick zur Umsetzung in eigenen Projekten.

Zielpublikum: Entwickler, Architekten, Entscheider für KI-Lösungen
Voraussetzungen: Interesse an Generative AI, Architekturverständnis, ggf. Python lesen können ;-)
Schwierigkeitsgrad: Basic

Ever worked on a deathmarch like project? Or rewrote a codebase "because CTO told us"?
Ever saw such an endeavour succeed? WITHOUT burning money, motivation, reputation and: people?
The quest for Sustainable Pace is – at least – as old as XP.
It's neither individual nor is it only a team's responsibility.
It's an interaction of both and beyond: it's all about systems!
Without sustainable organisational systems - how can we develop decent socio-technical systems with customers?

In this session you:

1. learn what sustainable pace is (and what it's NOT)
2. see common pitfalls that can un-balance a system (i.e. team, org, or yourself)
3. get powerful practises for yourself & your team(s)
4. learn necessary psychological background (e.g. coping)

Bring curiosity! The No.1 tool to bridge gaps.

Target Audience: Developers, Architects, System Engineers, Managers of all flavours, curious human beings
Prerequisites: Curiosity and some work/project experience is beneficial
Level: Advanced

There is a clear trend: ICT is responsible for more and more greenhouse gas (GHG) emissions: it has already reached an estimated level of 4% of global GHG emissions, which is comparable to the entire aviation sector, and ICT energy consumption is growing at an estimated rate of ca. 9% per year. Fortunately, there are ways to reduce these negative effects. One of these ways is DevGreenOps. It is an extension of the DevOps approach to software development. DevGreenOps takes additional inspiration from DevSecOps, GreenOps and agile development practices. It enables teams to incorporate environmental sustainability into every part and step of their software development projects.

I will introduce the DevGreenOps concept as well as helpful tools, open-source projects, recommendations, and inspiring examples, which will help you to implement your own DevGreenOps approach in your projects. All of which will help you to create transparency, generate insights, inform decisions, and ultimately help you to bridge the gap between software that is excellent to use and software that is excellent to the planet.

Target Audience: DevOps Engineers, Tech Leads, Project Leads, Sustainability Leads, Software Engineer
Prerequisites: Basic knowledge about the DevOps Cycle
Level: Advanced

Weitere Informationen zu dieser Keynote folgen in Kürze.

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

In an era where digital transformation is paramount, regulatory frameworks like the European Data Act and the upcoming Financial Data Access (FIDA) are reshaping the landscape of data management and security. Our presentation aims to demystify the complexities of API security and user consent management under these new regulations, drawing parallels from the successful GSMA Open Gateway Initiative in the telecommunications sector.

Key Points of Discussion:

Introduction to API Challenges in Regulated Industries:

• Importance of compliance with upcoming regulations such as the European Data Act and FIDA.
• The role of API management in enhancing security and operational efficiency.

Insights from Telecommunications: The GSMA Open Gateway Initiative as a Model:

• How the telecommunications industry has successfully implemented standardized API protocols and consent management systems.
• Lessons learned and best practices applicable to the financial and insurance sectors.

A Simplified Framework for API Security and Consent Management:

• Introduction of a straightforward, effective framework for enhancing API security with a focus on OAuth2, fine-grained authorization, and avoiding overengineering.
• Practical application of the framework to ensure compliance and improve user experience.

Implementation in Finance and Insurance:

• Tailoring the framework to meet the specific needs of the finance and insurance industries.
• Integration of apinity’s solutions (Xplore, Xact, Xpand) to facilitate regulatory compliance and data security.

Future Outlook and Industry Impact:

• Predictive insights into the evolution of API security frameworks and their implications for regulatory compliance.
• How continued innovation will influence the landscape of financial and insurance services.

Interactive Q&A Session:

• Engaging with the audience to address specific queries and discuss potential challenges and solutions in API management.

Target Audience: Software Architects and Engineers, IT Security Professionals, API Managers and Developers
Prerequisites: Understanding of APIs, OAuth2, Awareness of Data Security, Interest in Digital Transformation
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

„Verstehe ich nicht. Zeigst du das noch am Beispiel?“, „Das hast Du sehr vereinfacht erklärt. Hast du noch ein realitätsnahes Beispiel?“ Solche Aussagen sind oft die ersten Reaktionen auf die Vorstellung neuer Ideen. Denn leider fehlen oft gute Beispiele, um die Ideen (besser) zu verstehen. Obwohl wir selbst oft als Erstes nach einem guten Beispiel fragen, vergessen wir die Beispiele gerne bei unseren eigenen Präsentationen. Gute Beispiele bauen stabile Brücken über Verständnislücken und sind daher besonders wichtig, wenn Ideen außerhalb der eigenen Arbeitsgruppe präsentiert werden. Der Vortrag zeigt, warum „Lorem Ipsum“, „Max Mustermann“, „Unternehmen 1“ und „Produkt XYZ“ nicht ausreichen, um andere mitzureißen, und gibt konkrete Hilfestellungen, wie man richtig gute Beispiele gestaltet.

Zielpublikum: Für alle OOP-Teilnehmenden, denn alle müssen andere von ihren Ideen überzeugen
Voraussetzungen: Keine
Schwierigkeitsgrad: Basic

The pace of innovation in generative AI offers immense opportunities while also introducing new security challenges. As organizations seek to leverage generative AI for innovation, security leaders must take concrete steps to enable rapid experimentation without compromising security.

We will then discuss key strategies for securing generative AI applications, including threat modeling, guardrails, observability, and evaluation of effectiveness of security measures. Through case studies and practical examples, we will show how to apply these strategies in real-world scenarios. Attendees will learn how to identify and mitigate potential risks, and how to evaluate the effectiveness of their security measures.

Target Audience: Security leaders, developers, practitioners, decision makers, software architects, CTOs
Prerequisites: Interest to learn about new technology
Level: Advanced

Ever seen an expert work on a problem and come to a solution, and it looked like magic because you didn’t understand the steps they were going through internally? For the outsider (or new manager/leader), leadership is no different. We make multiple decisions per hour, deal with planned and unplanned situations, and decide on strategies - and we hardly ever “show our working”.

Of course, if leadership was simply complicated as opposed to complex, then we would have a catalogue of activities and steps or even decision charts for each one. That’s not likely to happen, nor is it the aim of this talk. But what if we could use a mix of labelling and describing plus storytelling about our experiences to make the workings of our mind and our depth of experience more tangible and accessible? What if, by narrating our thoughts, it was like adding logging for others to understand our inner workings?

The power of labelling (giving something a name) is that we can refer to it explicitly. Then we can practise it and structure it as an activity in our mind. We can “tag” our stories with it. And we can talk about it more easily to other people to teach them. Even if my labels are different to yours – we have a basis on which to compare our thought processes and share experiences. In this talk, I’ll share my process for identifying and describing the activities I do as a CEO (for example, “making decisions”, “doing conflict”, “accepting reality”, “managing time and tasks”, “leading managers”, “staying sane”, “working strategically”). I’ll also share what those processes look like, and I’ll include stories to show how those processes were formed and are evolving. Newer leaders will get input on how to approach these activities, and leaders of leaders will be encouraged to reflect on and describe their own so that they can communicate them more easily.

Target Audience: Leaders, managers,
Prerequisites: Some leadership experience
Level: Advanced

Let’s be honest, the tech we have today is amazing but it can also be complex. So, it’s only natural that the platforms we build want to hide that complexity to improve productivity, avoid mistakes, and reduce cognitive load. So, the more complexity we can hide, the better our platform? Actually no - we need to be careful that we create useful abstractions, not dangerous illusions. This talk reflects on two decades of building complex distributed systems, highlighting where abstractions helped and where illusions led to major disappointments.

Target Audience: Architects, Platform Teams
Prerequisites: Architecture concepts
Level: 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

Bei soziotechnischen Architekturen geht es um einen ganzheitlichen Entwurfsansatz technischer, fachlicher und organisatorischer Systeme. Für Perspektiven wie Organisation oder Softwarearchitekturen gibt es bereits etablierte Sichten und Visualisierungsansätze.

Dieser Vortrag adressiert die Herausforderung, Zusammenhänge in soziotechnischen Architekturen zu visualisieren. Es werden Visualisierungsansätze vorgestellt, wobei der Schwerpunkt auf der Darstellung der Zusammenhänge zwischen Modellen, Domänen, Architektur, Organisation und Deployment-Einheiten liegt. Im Vortrag wird gezeigt, wie sich Visualisierungsansätze kombinieren lassen und wo Lücken bestehen. Der Referent bringt eigene Ideen ein, um Trade-Offs in soziotechnischen Architekturen optimal darzustellen und zu diskutieren.

Zielpublikum: Architekt:innen
Voraussetzungen: Grundlagen soziotechnischer Architekturen
Schwierigkeitsgrad: Advanced

GAIA-X is a strategic initiative of the European Union in order to support secure and trustworthy dataspaces. But what does it mean to set up a GAIA-X compliant data space, polished powerpoint aside?
In this presentation we will report about our experiences learned from almost three years' work in one of the GAIA-X lighthouse projects "COOPERANTS". COOPERANTS is the world’s only collaborative alliance of industry, SMEs and research institutes in the Aeronautics and space sector that solves pressing digital collaboration problems by creating a common data space.
We will talk about experiences on how to navigate the confusing data-space ecosystems and tech-stacks and how and why we chose a specific solution (EDC vs. GXFS vs. Pontus-X, e.g.) and how we implemented the services.

Target Audience: Architects, CDO, Decisions Makers
Prerequisites: Knowledge in Data Management, IT Architecture
Level: Advanced

– Ein Spickzettel für Menschen, die Menschen in neuen Führungsrollen helfen –

Gerade in großen Organisationen scheint es oft schwierig, selbstorganisierte, oder besser selbstmanagende, Teams zu etablieren. Eine komplette „tut einfach, was ihr für richtig haltet“-Haltung führt meistens zu hohem Stress für alle Beteiligten, aber das Festhalten an alten Führungsideen würde der sich wandelnden Welt auch nicht gerecht.

Was also dann?

Von „enabling constraints“ über „acts of leadership“ über eine feinere Differenzierung von Motivation (jenseits von intrinsisch vs. extrinsisch) bis hin zu „Leadership Styles“ und „Ehrlicher Delegation“ werden in dieser Session praxiserprobte und sofort umsetzbare Ideen vorgestellt.

Zielpublikum: Team-, Abteilungs- und Bereichsleitungen, Change-Agents
Voraussetzungen: Keine
Schwierigkeitsgrad: Advanced

Psychologische Sicherheit macht unsere Teams performanter, sogar zu „High Performance Teams“, sagen zumindest die Wissenschaft und auch Google. Aber wie wir diese ominöse psychologische Sicherheit erreichen, ist doch sehr schwammig beschrieben.

Diese sehr interaktive Workshop-Session gibt dir Anregungen, Inspiration und Werkzeuge an die Hand, wie du als Leader in dir selbst auf die Suche nach der (psychologischen) Sicherheit gehen kannst. Denn in einem ist sich die Wissenschaft einig, psychologische Sicherheit beginnt mit dem Leader.

Um psychologisch sichere Umfelder gestalten zu können, brauchen wir eine spezifische Form der Selbstkenntnis, die wir durch überwiegend reflektorische, aber auch impulsgeführte Fragen und Aufgaben in dieser Session bearbeiten. Gelegentliche Checkins mit einem Gegenüber halten dabei den wichtigen Spiegel vor, der es ermöglicht, sich selbst im Gespräch zu überprüfen. Neue Erkenntnisse sind hoch wahrscheinlich! Diese Session wird ein Tanz zwischen Impulsen, Wissenschaft und Case Study mit einer guten Portion Reflexionsarbeit für alle Teilnehmer.

Zielpublikum: Architekten, Projektleiter, Manager, Führungskräfte, Scrum Master, Leader
Voraussetzungen: Lust und Wille zu reflektieren
Schwierigkeitsgrad: 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

Architecture work can be tough: juggling tech stacks, new tools, facilitating decisions, working with different stakeholders & even some organisational development. Herding cats is easier, isn’t it?

With Architecture in ACTion, I introduce you to decades of practical science on the Human Mind. We’ll dig into Psychological Flexibility and ACT - concepts that are (still) rarely used in biz but have huge impact at work!

Because: Deep tech expertise, domain navigation *and* change skills is a lot!

You'll leave this session with:

• practical, low-tech tools for effective operational work as architects
• a reflection canvas for laser-focussed strategic work as tech leaders
• digestible science bits on Human Mind and Behaviour
• (hopefully!) a desire to learn more about your “thinking machine”

Target Audience: Software Architects, (Technical) Leaders, curious humans in IT who work with other humans (in IT)
Prerequisites: Some work/project experience and openness for new ways of thinking (and potentially behaviour)
Level: Basic

Code that is well-designed and easy to understand is cheaper to extend and modify - so you can deliver more value, sooner. Many organizations struggle with older codebases that use outdated designs and have too much cruft.

I found that the technical coaching I was doing was addressing those kinds of issues successfully, but it was slow to scale up to large projects where there are tens of teams of developers working on different parts of the same codebase.

Recently I’ve been using a complementary approach. The basic idea is regular, short interactive training for teams of developers, led by a peer. They use high quality materials and content I’ve designed. In this talk I will explain what I’ve found and how you could adapt my ideas and materials for your situation.

Target Audience: Tech lead, senior dev, architect
Prerequisites: Experience writing code in a development team (even if it was a while ago)
Level: Advanced

Measuring software engineering productivity can significantly enhance managerial decision-making, improve developer enablement, and optimize development workflows. However, despite the potential benefits, there is no uniform approach in industry or research. We present our solution, which is designed to use quantitative data generated during the development process. We gather data from popular software development tools, looking further then simply using the oversimplified source lines of code metric. Using the data, we create a composite index, visualize the results across a range of newly developed projects, and report on potential pitfalls and misconceptions.

Target Audience: Decision Makers, Project Managers, Project Leaders, Developers
Prerequisites: Basic knowledge of software engineering processes, Basic knowledge in project management
Level: Advanced

If you ship a software product that includes open-source software, (1) you need to make sure it does not include unwanted open source code, (2) you need to declare its software bill of materials, (3) you need to create and deliver correct legal notices, and (4) you need to monitor security vulnerabilities of your current and past shipped code. Ignore these requirements, and you risk being sued by copyright trolls or get embarrassed by irate customers. This tutorial shows you how to get purchasing requirements, open source governance, license compliance, and vulnerability management right.

Target Audience: Product leaders, engineering leaders, architects, developers
Prerequisites: Basic understanding of open-source software development
Level: Advanced

Im Zuge der Digitalisierung wächst der Energieverbrauch und damit der ökologische Fußabdruck von Software stetig. Das gilt insbesondere für die in Clouds laufenden Microservices. Mit geeigneten Werkzeugen, von denen wir drei vorstellen und vergleichen, kann dieser gemessen werden. Anhand von Benchmarks zeigen wir, dass allein die Wahl der Technologie zu deutlichen Einsparungen beim Energieverbrauch führt, wodurch Microservices deutlich nachhaltiger werden können.

Zielpublikum: Architekten, Entwickler, Entscheider
Voraussetzungen: Interesse an Nachhaltigkeit und Microservices
Schwierigkeitsgrad: Basic

Wenn obskure Backend-Fehler im Web-Frontend aufschlagen, die Tentakel undokumentierter Inhouse-Frameworks in jede Projektecke hineinragen oder der JSF-Dschungel gänzlich undurchdringlich scheint, ist die Verzweiflung oft groß. Doch egal wie schwer die Legacy-Last auch auf den Entwicklerschultern liegt, es gibt im Web-Frontend immer einen Ausweg ... über Webstandards! Die Standards der Browser sind zum einen der kleinste gemeinsame Nenner, den sowohl fossile Projektruinen als auch die futuristischsten Frontend-Frameworks gemein haben, und zum anderen mindestens ein Zwischenschritt auf dem Weg in die technische Schuldenfreiheit. Denn mit modernen Browsertechnologien und einem moderat langen Atem lässt sich so ziemlich jedes verkorkste Frontend-Projekt retten ... und dieser Talk erklärt, wie!

Eingebettet in diverse Refactoring-Horrorszenarien aus der Praxis des Vortragenden beleuchtet diese Session, wie und warum moderne Webstandards das Mittel der Wahl zum Refactoring von Legacy-Frontends sind – selbst wenn das Endziel etwas anderes ist, als 100 % handgeschriebener Standards-Code. Hinzu kommen Handreichungen und mentale Tools, um zu verhindern, dass nach dem Refactoring direkt wieder die Legacy-Horror-Uhr lostickt.

Zielpublikum: Architekten, Entwickler, Projektleiter
Voraussetzungen: Grundlagenkenntnisse in den fundamentalen Webtechnologien (HTML, CSS, JS)
Schwierigkeitsgrad: Advanced