Software-Architektur ist allgegenwärtig. Trotzdem gibt es in vielen Organisationen kaum eine weitgehend anerkannte Definition der Rolle. Somit stellt sich die Frage, wie wir feststellen können, ob wir unseren Job "gut" machen.

In diesem Vortrag werden wir konkrete Wege kennenlernen, wie wir Architekturarbeit effektiv gestalten können. Wir streifen Themen wie Dokumentation, Entscheidungsfindung, Kommunikation und Skillset. Außerdem lernen wir Prinzipien kennen, die uns im Alltag als Software-Architekten eine Stütze sein können.

Zielpublikum: Software-Architekt:innen, Software-Entwickler:innen, Manager, Entscheider
Voraussetzungen: Grundwissen in Software-Entwicklung und -Architektur
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Die Rolle von Software-Architekten ist in vielen Organisationen nicht klar oder gar explizit definiert, geschweige denn gibt es eine Definition der Rolle, die allgemein anerkannt ist und entsprechend gelebt wird. Oft fehlt für diese Rolle im Berufsalltag eine klare Zielsetzung. Somit stellt sich die Frage, wie wir feststellen können, ob wir unseren Job "gut" machen.

Wir könnten nun versuchen, den Rollenbegriff von Software-Architekten bestmöglich zu schärfen. Doch ist das wirklich zielführend? Gerade in der Software-Entwicklung haben wir mit unterschiedlichsten Kontexten zu tun, die sich obendrein ständig ändern. Das macht eine einheitliche Definition der Rolle umso schwieriger.

Ein anderer Ansatz wäre, dass wir von Good Practices und (mehr oder weniger) etablierten Prinzipien ausgehen, um unseren Berufsalltag effektiv zu gestalten. Der Vorteil dieses Ansatzes ist, dass wir kontextspezifisch entscheiden können, welche Prinzipien für uns passen. Somit ergibt sich die Jobbeschreibung von Software-Architekten nicht aus einer allgemein gültigen Definition, sondern immer aus konkreten, kontextabhängigen Richtlinien.

Die Good Practices und Prinzipien versuchen wir im Vortrag aus folgenden Fragen abzuleiten:
-    Sollte man in der Rolle als Software-Architekt coden?
-    Ist breites oder tiefes technisches Wissen wichtiger?
-    Wie viele Vorgaben sollen effektive Architekturentscheidungen machen?
-    Wann ist der beste Zeitpunkt, um Architekturentscheidungen zu treffen?
-    Wie viel Kontrolle soll man in der Rolle als Software-Architekt ausüben?
-    Sollte man Top-Down oder Bottom-Up vorgehen?
-    Wie kann man die Zielerreichung von Software-Architektur unter ständiger Veränderung sicherstellen?
-    Sollte es die Rolle "Software-Architekt" überhaupt geben?

Aufgrund der oben erwähnten kontextspezifischen Unterschiede der Architekturrolle soll dieser Vortrag Raum für Interaktion bieten, um die Fragestellungen aus verschiedenen Gesichtspunkten durchleuchten zu können.

Teilnehmer sollen die Session mit Anregungen zum Nachdenken verlassen, wie sie ihre eigene Architekturarbeit effektiver gestalten können.

Mal angenommen, es gäbe ein (natürlich fiktives) Großprojekt zur Implementierung einer Microservices-Architektur. Die Entwickler:innen sind in zahlreichen Teams organisiert. Zudem gibt es ein übergreifendes Architekturgremium. Selbstverständlich wird auch ein proprietäres Framework programmiert. In jedem Team existiert die Rolle des "Technischen Architekten".

Kommt Ihnen das bekannt vor? Und haben Sie sich auch schon öfters gefragt, was er/sie eigentlich die ganze Zeit macht? In diesem unterhaltsamen Praxisbericht können Sie es herausfinden.

Zielpublikum: Entwickler:innen, Architekt:innen, Manager
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Tatsächlich erscheint es für viele Projektmitarbeitende immer wieder fraglich, was der/die Technical Software Architect eigentlich den ganzen Tag so macht. Scheinbar werden doch die Architekturvorgaben vom dafür verantwortlichen Gremium erarbeitet. In der Praxis ist es jedoch oft so, dass tatsächlich zahlreiche Themen anstehen.

Dazu zählt die Bewertung der Folgen solcher Technologievorhaben für das eigene Team, genauso wie der Versuch der Beeinflussung des Gremiums bei der Entscheidungsfindung. Hinzu kommen diverse "politische" Themen oder die Sicherstellung der Einhaltung von Architekturvorgaben und der Softwarequalität. Über die Jahre habe ich hier eine Reihe sehr interessanter und oftmals auch (rückblickend) amüsanter Erfahrungen gemacht, die ich gerne weitergeben möchte.

Alles hat eine API: Wir ITler sind megagut darin, Software-Architekturen zu durchleuchten und neue Integrations-Patterns für technische Komponenten zu entwickeln. Warum wenden wir diese Fähigkeiten nicht auch auf unser Mindset und unsere Teams an?

In diesem Workshop üben wir uns in der Transferleistung: Warum sind unsere Reaktionen oft hard-coded statt loosely-coupled und wie können wir das ändern? Ist meine Gedankenwelt wie ein Monolith aufgebaut, die sich nur mühsam weiterentwickelt oder lässt sie schnelle Updates zu, wie Microservices?

Zielpublikum: Entwickler:innen, Projektleiter:innen, Manager, Entscheider, Architekt:innen
Voraussetzungen: Architekturmuster- und Projekterfahrung ist von Vorteil, aber kein Muss
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Dieser Workshop macht Lust auf Selbstführung. Die Hypothese, zu der dieser Workshop einlädt, ist:
Das Gesetz von Conway gilt nicht nur für Abteilungen, sondern auch für die Teammitglieder: „Organisationen, die Systeme entwerfen, sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.“

Je mehr Dynamik das Umfeld und die Systeme einfordern, desto dynamischer muss mein Mindset im Team sein. Nicht nur, damit die Systeme funktionieren, sondern damit ich in dem Umfeld glücklich sein kann.
So kann ich beispielsweise das ganze Team inklusive mir selbst als Microservice-Architektur betrachten. Ich kann analysieren: welche Schnittstellen biete ich nach außen an, und sind die auch gut dokumentiert? Wissen die Anderen dass die meisten Schnittstellen vor dem ersten Kaffee nicht ansprechbar sind? Welche Reaktionen sind hart-verdrahtet, wo bin ich anfällig für eine Denial-of-Service Attacke, und was kann ich dagegen tun?

Mit interaktiven Übungen finden wir die richtige Balance für die eigene Mindset und Team-Architektur. Am Ende des Workshops haben Sie einige Entwurfsmuster im Gepäck, mit denen Sie die eigene Mindset-Architektur Step by Step refactoren können (wenn Sie das wollen). Und das spannende dabei: Die meisten Tools haben sie schon im Gepäck - Sie haben sie nur noch nicht auf sich selbst angewendet.

For a technology company, building a strong engineering culture is essential for long-term success. Today's software industry is growing so fast that a large proportion of developers will inevitably have less than 5 years experience. At the same time, many software systems contain code that is ten, twenty or even thirty years old.

It's a constant challenge to communicate a healthy culture to newcomers and prevent technical debt from getting out of control. Technical coaching is all about tackling those issues: culture and skills.

Target Audience: Developers, Architects
Prerequisites: None
Level: Basic

Extended Abstract:
The Samman method is a concrete coaching method for spreading skills and culture within an engineering organization. There are two main parts to the method:
- Learning Hour
- Ensemble working

In the learning hour the coach uses exercises and active learning techniques to teach the theory and practice of skills like Test-Driven Development and Refactoring. In two-hour Ensemble sessions the whole team collaborates together with the coach in applying agile development techniques in their usual production codebase.

In combination with strong technical leadership, the Samman method can enable the spread of skills and culture to bring a healthy engineering organization to the next level.

"Ich hatte keine Zeit, den Zaun zu flicken" - Dieses Zitat kennt wohl jeder, und doch ertappen wir uns selbst, unseren Zaun nicht geflickt, sondern stattdessen die Hühner gesucht zu haben.
Doch wie ändere ich das?
Dieser Vortrag zeigt mit dem Konzept der MLCs ein Tool auf, dieser Falle zu begegnen und sich selbst und andere in den Modus des kontinuierlichen Lernens zu versetzen.
Am Ende haben die Zuhörenden einen ersten MLC durchlaufen und ein Tool erlernt, um sich und anderen den Freiraum zum Lernen zu erschaffen.

Zielpublikum: Coaches, Entscheider, Projektleiter:innen, Transformation Manager, Architekt:innen, Lebenslange Lernende
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Micro-Learning-Cycles sind kein theoretisches Konstrukt, sie sind tatsächlich aus der Notwendigkeit entstanden, trotz vollem Terminkalender Zeit zum Lernen zu finden.
Neben der Vermittlung und Anwendung von MLC zeigt die Referentin auch aus der Praxis, wo sie MLCs einsetzte, was funktionierte und wo auch Limitierungen sind.

Es ist eine weitverbreitete Erfahrung, dass nur wenige Wege zu einer erfolgreichen Software-Architektur / zu einem erfolgreichen Projekt führen, aber viele Wege zu Problemfällen. Von welchen Ingredienzen hängt aber deren (Miss-)Erfolg ab?

Speziell gefragt: Welche Mittel haben Software-Architekten & -Entwickler in der Hand, um eine erfolgreiche Lösung zu erstellen? Und woran lässt sich erkennen, dass etwas gehörig schiefläuft?

Zielpublikum: Software-Entwickler:innen, Software-Architekt:innen
Voraussetzungen: Erfahrung mit Software-Architektur und Software-Engineering
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Es ist eine weitverbreitete Erfahrung, dass nur wenige Wege zu einer erfolgreichen Software-Architektur / zu einem erfolgreichen Projekt führen, aber viele Wege zu Problemfällen. Wichtig ist insbesondere, von Anfang an die richtigen Weichen zu stellen und möglichst frühzeitig zu erkennen, ob etwas faul ist im Staate Dänemark. Software-Architekten sind dem aber nicht hilflos ausgeliefert, sondern haben im Gegenteil die Möglichkeit, die Entwicklung maßgeblich zu einem Erfolg zu führen.

Von welchen Ingredienzen hängt aber deren (Miss-)Erfolg ab? Speziell gefragt: Welche Mittel haben Software-Architekten & -Entwickler in der Hand, um eine erfolgreiche Lösung zu erstellen? Woran lässt sich erkennen, dass etwas gehörig schiefläuft? Welche Eingangsvoraussetzungen müssen gegeben sein?

Fast 20 Jahre nach dem Start von Domain-driven Design (DDD) ist der Ansatz weit verbreitet - aber das ist noch keine Garantie dafür, dass DDD-Projekte auch erfolgreich beendet werden.

Dieser Vortrag zeigt typische Fehler, Missverständnisse und Probleme, die bei Domain-driven Design und insbesondere bei Strategic Design auftreten. Natürlich diskutiert die Präsentation auch, wie man solche Probleme sinnvoll lösen kann, um vielleicht nicht nur ein Scheitern zu verhindern, sondern sogar einen echten Erfolg zu landen ...

Zielpublikum: an Software-Architektur Interessierte
Voraussetzungen: Grundlegendes Verständnis von Software-Architektur
Schwierigkeitsgrad: Anfänger

Bei der Erstellung von Software werden großartige Technologien, Programmiersprachen und Werkzeuge eingesetzt. Aber leider wird oft aus den Augen verloren, dass der entscheidende Faktor nicht die Technologie, sondern die Domäne ist.

In diesem Vortrag zeige ich euch, wie ihr die Domäne in eurer vorhandenen Software wiederentdecken und als wichtiges Mittel der Architekturverbesserung einsetzen könnt.

Zielpublikum: Architekt:innen, Entwickler:innen, Product Owner, Projektleiter:innen, Requirement Engineers
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Bei der Erstellung von Software werden großartige Technologien, Programmiersprachen und Werkzeuge eingesetzt. Das ist gut und richtig. Aber leider wird oft aus den Augen verloren, dass der entscheidende Faktor nicht die Technologie, sondern die Domäne ist. Wenn wir die Fachsprache und die Geschäftsprozesse nicht in der Software abbilden, dann hilft sie unseren Anwender:innen nicht bei ihrer Arbeit. Keine Technologie der Welt kann uns davor schützen.

In diesem Vortrag zeige ich euch, wie ihr Probleme in eurer vorhandenen Software mit Domain-Driven Design angehen könnt.

Immer häufiger werden Anwendungen auf einem Kubernetes-Cluster betrieben. Umso wichtiger ist die Absicherung gegen Angriffe von außen, aber auch innerhalb des Clusters.

Wir demonstrieren anhand von praktischen Beispielen, wie mit wenigen Schritten ein Cluster abgesichert werden kann. Ausreden, warum nicht mehr Sicherheit möglich ist, gibt es dann nicht mehr.

Zielpublikum: Entwickler:innen
Voraussetzungen: Grundkenntnisse in Kubernetes und Security, Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In den letzten Jahren hat sich Kubernetes als Plattform für Anwendungen etabliert. Es verspricht, das Deployment deutlich zu vereinfachen, birgt aber auf der anderen Seite eine höhere Komplexität.

Oft wird der Betrieb auf einem Kubernetes-Cluster als zusätzliche Aufgabe auf das Entwicklungsteam übertragen, ohne die entsprechende Expertise aufzubauen. Das Wissen um Kubernetes bleibt dann lückenhaft, das Management des Clusters steht nicht im Fokus. In der Konsequenz stehen viele Kubernetes-Cluster ungeschützt im Netz.

Im Vortrag konzentrieren wir uns auf den Aspekt der Sicherheit eines Kubernetes-Clusters gegen Angriffe von außen, aber auch innerhalb des Clusters. Dabei gehen wir Schritt für Schritt durch die verschiedenen Schichten und zeigen anhand praktischer Beispiele, mit welchen Maßnahmen der Cluster abgesichert werden sollte.

Ein Erfolgsmuster zur Umsetzung von DevOps ist Site Reliability Engineering (SRE). Sie fördert objektiv die Zusammenarbeit zwischen Teams in einem skalierenden Umfeld. Besonderheit: Die System-Zuverlässigkeit wird zum Nummer 1 Feature! In diesem Vortrag werden die SRE-Prinzipien erläutert und SRE-Praktiken veranschaulicht. Abgerundet wird der Vortrag durch die Veranschaulichung des Aufbaus von Betriebsmodellen mit SRE.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Grundkenntnisse in agilen Methoden und Betriebsmodellen
Schwierigkeitsgrad: Anfänger

Vor drei Jahren als Idee gestartet, gibt es heute viele Produkte & Unternehmen im Data-Bereich, die mit dem Mesh werben. Höchste Zeit zu schauen: Was ist die Kernidee? Welche Probleme soll es eigentlich lösen?
Was ist der Unterschied zwischen Mesh und Data Lake & Data Warehouse? Wie kann es technologisch umgesetzt werden und welche weiteren Bereiche müssen angegangen werden: Organisatorische Aspekte wie Teamschnitt & Skills, Abstimmung zwischen Teams und notwendige Skills in Produkt- und Entwicklerteams.

Zielpublikum: Architekten:innen, Entscheider
Voraussetzungen: Grundlegende Erfahrungen mit Datenarchitekturen, insbesondere für analytische Zwecke
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die bessere Nutzung von Daten im Unternehmen ist schon seit Langem ein viel diskutiertes Thema. In diesem Kontext entstand die Idee des Data Mesh. In diese Session wird diese Idee nach einer kurzen Vorstellung kritisch hinterfragt: Wo sind Chancen? Wo sind Nachteil zu sehen? Insbesondere im Vergleich zu den bisherigen Konzepten, wenn es um die Bereitstellung und Nutzung von Daten für analytische Zwecke geht: Dem Data Warehouse und einem Data Lake.

So kommen wir in dem Talk auch zu der Frage, welche Unternehmen und Organisation die Prinzipien des Data Mesh näher betrachten sollten. Und wer diesen Hype auch getrost ziehen lassen kann.

IT-Architekt, ein Titel im Unternehmen, teils mit, teils ohne Rollenbeschreibung. Welche Aufgaben und Befugnisse die “Architekten” haben, ob es einen oder mehrere gibt, ob sie in Gremien organisiert sind, welche Regeln gelten, all das variiert total.

Meine Meinung ist: IT-Architekt ist eine Management-Aufgabe innerhalb der Organisation und es hilft, eine klare Rollenbeschreibung und eine klare Beschreibung der Gremien einer Organisation zu haben. Im Talk vergleiche und bewerte ich Beispiele aus verschiedenen Organisationen.

Zielpublikum: IT-Mitarbeiter, Software-Entwickler:innen, IT-Management, Produktmanager, QA nerds
Voraussetzungen: Erfahrung in der IT-Produktentwicklung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
IT-Architekt, ein Titel im Unternehmen, teils mit, teils ohne Rollenbeschreibung. Welche Aufgaben und Befugnisse die “Architekten” haben, ob es einen oder mehrere gibt, ob sie in Gremien organisiert sind, welche Regeln gelten, all das variiert total. Meine Meinung ist: IT-Architekt ist eine Management-Aufgabe innerhalb der Organisation und es hilft, eine klare Rollenbeschreibung und eine klare Beschreibung der Gremien einer Organisation zu haben. Im Talk vergleiche und bewerte ich Beispiele aus verschiedenen Organisationen.

Botschaften:
-    Softwareentwicklung ist Teamwork
-    Architekt sein bedeutet Teamworken
-    Exzellente natursprachliche / interkulturelle Kommunikationsfähigkeit ist Voraussetzung
-    Messbarkeit und KPIs helfen
-    Soziale Integrationsfähigkeit ist notwendige Voraussetzung
-    Richtungsleitende dauerhafte Kraft ist hilfreich
-    Überblick und Kooperationsfähigkeit sind nötig
-    Fehler sind gut, oder besser Erfahrungen sammeln
-    Rollenbeschreibungen sind notwendig
-    Gremien Beschreibungen sind notwendig
-    Prozessbeschreibung ist notwendig

Eine Organisation sollte sich selbst beschrieben habe, denn sonst versteht sie sich selbst nicht und neigt dazu, chaotisch und unordentlich zu sein. Verbesserungsprozesse in chaotischen und unordentlichen Organisationen sind fast unmöglich.

Beispiele:
•    Intersoft: 5 mio loc, lange QA-Zyklen
•    NewStore: teamnamen nach Farbe
•    Idealo: CTO & cpo im team
•    Otto: Performance vs Umsatz

For a microservices architecture to be successful it is crucial to have the right boundaries between the microservices. But where are the right boundaries? We would like to present a tool that helps us answer this question.

Domain Storytelling is a collaborative modeling method. It brings together domain experts and development teams. We let our users tell us stories about their work. While listening, we record the stories using a pictographic language.

In this talk we show how to find subdomains and which heuristics can help us.

Target Audience: Architects, Developers
Prerequisites: Project experience
Level: Advanced

Extended Abstract:
For a microservices architecture to be successful it is crucial to have the right boundaries between the microservices. But where are the right boundaries? We would like to present a tool that helps us answer this question.

Domain Storytelling is a collaborative modeling method. It brings together domain experts and development teams. We let our users tell us stories about their work. While listening, we record the stories using a pictographic language.

The experts can immediately see if we understand their story. After very few stories, we understand the language of our users and find different areas of the domain. Each of these areas (called a subdomain) is a good candidate to become a microservice in our architecture.

In this talk we show how to find subdomains and which heuristics can help us.

The developers have instrumented the applications with OpenTelemetry — great! But that doesn't mean you're ready to roll it out in production yet. What do you need to keep in mind for your instrumentation infrastructure?

* Quick OpenTelemetry overview.
* Tradeoffs between the three architectures you use with OTel (depending on your vendor): vendor exporter vs OTel Collector vs OTel protocol support
* Sampling, including head vs tail based, and how to keep it representative and / or useful.

Target Audience: Architects, Developers
Prerequisites: Software development knowledge and some monitoring experience is also helpful
Level: Advanced

Extended Abstract:
The developers have instrumented the applications with OpenTelemetry — great! But that doesn't mean you're ready to roll it out in production. What do you need to keep in mind for your instrumentation infrastructure? OpenTelemetry is THE emerging standard for monitoring and creating more observable systems. Starting with an overview, this talk then dives into two areas that make a big difference in cost, flexibility, and insights:

Firstly, the three possible integration architectures with vendor exporter, OpenTelemetry Collector, and native protocol support; and why a combination of Collector and native protocol are the most common choice today.
Secondly, sampling or how to get the big picture from a subset of the data (and cost). Here the tradeoffs evolve around head- vs tail-based sampling and how to keep the collected data representative and / or useful. It generally comes down to simpler and cheaper with the head-based approach, while the tail-based one is potentially more useful with higher overhead. And now it's time to roll it out in production!

Über Daten-Streaming und Apache Kafka redet die Welt. Kai Waehner, Field CTO bei Confluent, stellt uns in dieser Keynote die Prognosen für die fünf wichtigsten Use Cases und Architekturen in diesem Bereich für 2023 vor und welche Trends er bei Kunden industrieübergreifend feststellen konnte: Dezentraler Data Mesh: Fokussierung auf den Geschäftswert durch den Aufbau von Datenprodukten in unabhängigen Domänen mit verschiedenen Technologien. Cloud-natives Lakehouse: Anwendung einer Best-of-Breed-Unternehmensarchitektur für Echtzeit- und Batch-Datenanalysen mit dem richtigen Tool für jede Aufgabe (z.B. Databricks, Elastic, BigQuery, etc.). Daten-Sharing: Zusammenarbeit innerhalb und außerhalb des Unternehmens durch die gemeinsame Nutzung von Daten über offene APIs, Austausch von Streaming-Daten und Cluster Linking. Verbesserte Benutzerfreundlichkeit: Schnellere Markteinführung und einfachere Wartung durch bessere Entwicklertools, die verschiedene Personengruppen wie Entwickler, Citizen Integrators und Data Scientists unterstützen. Erweiterte Data Governance: Compliance und Datenschutz über alle Datenströme hinweg mit Data Lineage, Event Tracing, Policy Management und dem "Zurückdrehen" der Zeit zur retrospektiven Analyse von Events.

Many approaches to software architecture assume that architecture be planned at the beginning from the project's quality goals. This is problematic as the macroarchitecture is hard to change, and the quality goals it's based on tend to be unknown at the beginning of a project, or change later. Consequently, it would really be preferable if we could defer the macroarchitectural decisions until later.

This talk shows how to do this using systematic modelling and functional programming.

Target Audience: Developers, Architects
Prerequisites: Basic architecture knowledge
Level: Advanced

Extended Abstract:
What should we do first then? We should write down what we know, at the time we know it, and do it in such a way that we generate reusable components that can be assembled into any macroarchitecture.

Concretely, this can be done by using staple techniques from functional programming:
•    building small, flexible combinators instead of fixed attribute-structure OO models
•    decoupling pervasively using abstraction
•    using immutability to avoid hidden dependencies

The talk shows how to do this, and report on our experience in several concrete projects.

Die Digitalisierung schreitet voran! Geht es den einen zu langsam, gibt es andere, denen es zu schnell geht.

Beiden Parteien gemeinsam ist, dass es das richtige Mindset braucht, um den Herausforderungen der Digitalisierung und der damit einhergehenden Transformation Tempo zu verleihen oder mit ihr Schritt halten zu können.

In dem Vortrag schauen wir uns die unterschiedlichen Dimensionen an, für die ein Umdenken angesagt ist. Dabei spannen wir den Bogen von der Fachlichkeit über die Technologie hin zu den organisatorischen Herausforderungen.

Zielpublikum: Manager, Entscheider, Architekt:innen, Projektleiter:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Aufseiten der Technologie muss man sich einfach mal die Landkarte der Cloud Native Computing Foundation ansehen, um zu erkennen, dass wir hier vor neuen Herausforderungen stehen. Es müssen geeignete Architekturen entworfen und die Technologien sorgfältig ausgewählt werden.

Damit ist es aber nicht getan, denn wir müssen uns auch überlegen, wie wir Domänen finden und schneiden, wie wir in Zukunft mit unseren Daten umgehen, wie wir die Herausforderungen der KI meistern werden und welche Auswirkungen all diese Themen auf die Organisation und Kultur in den Unternehmen haben.

Bei allen Beteiligten, vom Kunden über den Product Owner zum Software-Engineer bis hin zum Management, kommt es in Zukunft auf das richtige Mindset an, um als Unternehmen oder Institution erfolgreich zu sein und am Markt bzw. bei den Bürgern bestehen zu können.

Dabei klären wir abschließend die Fragen:
•    Kann man jetzt noch von "einem" oder dem "richtigen" Mindset sprechen?
•    Wenn es das nicht gibt, wie bekommt man mehrere Mindsets unter einen Hut?

Re-purchasing an application is seen as the top of craftsmanship for cloud migrations. But people have rarely seen such a project in practice. This is the courageous journey of a real consumer product running on expensive infrastructure for years with 2 million active users and more than 6PB of data.

The talk takes you on a journey to a German public cloud and shares all the learnings - about shifting massive data, about terraforming infrastructures, about customizing open source and about all it takes to launch and stay in business.

Target Audience: IT people with no fear of few technical details
Prerequisites: Curiosity about a real public cloud modernisation approach
Level: Advanced

Extended Abstract:
The journey will have the following stages:

Stage 1: How architecture for such a quest looks like and how to start?
Three architecture goals will drive the rest of the journey:
- Efficient scaling
- Minimal run efforts
- Release robust customisation

Stage 2: Customisation of an Open Source product

Stage 3: Migration - decisions and actual experiences during migration

Stage 4: Rollout and staying alive

Eure Domänen sind identifiziert? Event Storming gemacht? Anti-Corruption Layer definiert? Sehr gut, das ist die halbe Miete.

In der Praxis geht es danach um technische Basisplattformen, zentrale Sicherheitskonzepte, UX-Strategien usw., aber auch um die Abbildung dieser Themen auf Teams und deren Zusammenarbeit.

Wir präsentieren Erfahrungen aus echten Projekten und zeigen, wie es nach dem ersten DDD-Aufschlag weitergeht. Wir vertiefen Konzepte wie Team Topologies und streifen Themen wie den Ideal Present Canvas oder soziotechnische Architekturen.

Zielpublikum: Entwickler:innen, Agile Coaches, Management-Rollen
Voraussetzungen: DDD Grundlagen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Domain-Driven Design und verwandte Techniken eigenen sich sehr gut, um den fachlichen Schnitt einer Anwendung und den Teamschnitt von Produktteams zu definieren bzw. weiterzuentwickeln. Blicken wir auf ganze Entwicklungsvorhaben in der Praxis, gibt es jedoch eine Menge an Themen, die nicht zwangsläufig in Domänenservices landen: Wie gehen wir mit technischen Basisplattformen um? Wo entstehen zentrale Sicherheitskonzepte? Wo UX-Strategien oder Logging und Tracing-Konventionen? Die Abbildung dieser Themen auf Teams und deren Zusammenarbeit ist schwierig zu besprechen.

Team Topologies beinhaltet Konzepte und Prinzipien, aber auch eine Notation, um hier zu helfen. Es spielt gut mit Praktiken aus dem DDD-Bereich zusammen und kann um weitere Werkzeuge (wie den Ideal Present Canvas) ergänzt werden. So wird es möglich, komplexe Softwaresysteme über die fachliche Gliederung hinaus zu besprechen und Teamschnitt sowie Team-Zusammenarbeit explizit weiterzuentwickeln.

Wir haben in mehreren Branchen - wie E-Commerce, E-Mobilität, Logistik und anderen - Erfahrung in der Anwendung gesammelt. In dieser Session präsentieren wir unsere Erkenntnisse aus dieser Praxis, zeigen Beispiele und geben Hinweise zur eigenen Anwendung. Wir sprechen über Minimal Viable Platforms, Interaction Modes für Teams, die Herausforderungen bei Enabling Teams in Ramp-up-Phasen usw. Alles ausgehend von der gängigen DDD-Praxis.

I will share our hands-on experience with a cloud native (container) transformation that is currently unfolding. Technically, implementing an Open Shift Container Platform (bare metal) is pretty challenging. Doing this in a way that we will have pretty stuff in our data centers and at the same time making sure that our technical possibilities are actually being used effectively by product developers ... is a different challenge all together.

Join this session if you'd like to hear what we figured out about the people side of this kind of change!

Target Audience: Architects, Management, Developers, Operational Heroes, Product Owners, Agile Coaches, Scrum Masters
Prerequisites: Basic knowledge of DevOps concepts
Level: Advanced

Extended Abstract:
In this session I will share our hands-on experiences implementing a container-based architecture in our organisation. Choosing to implement Open Shift (bare metal) as your container platform is pretty difficult and challenging technically. It is also rather exciting and not too difficult to find smart people willing to help you build and run this new platform. However, it turns out that there is far more to this challenge than just the technology. Therefore, we are adopting an evolutionary implementation approach - stringing together small experiments - towards a flexible, more experimental and proactive culture that will allow us to actually benefit from the technical possibilities our new platform offers. This session is our story of our evolutionary and experimental approach and what we discovered along the way that works in this kind of transformation. Our main "discovery" is that even though at first it seemed mostly a technical transformation, it actually is far more of a human challenge.

We are right in the middle of this transformation so in this talk, I will bring you the latest and most valuable insights and experiences regarding this organisational and cultural transformation that is needed to turn the potential of our container platform into actual value for our organisation. We will summarise our ideas in a practical "this might work" list (bear in mind however there are no best practices, just patterns that might work in your specific situation).

An example of an experiment that turned out useful in our situation is: "create a small separate team that will drive this change". In our organisation we strive to build end-to-end teams, so at first we tried to get this new platform started from within the regular Infra DevOps team (as a huge Epic on the backlog). But people however got swamped in work and annoyed by all the context switching this required. Team members got tired and frustrated with the huge amounts of work, sky high ambitions and lack of progress. So, in the end we did a small experiment by creating a separate, dedicated, core team to get things going. This experiment turned out to be successful (and was thus extended) because it allowed team members to focus on the development of the platform and to build, document and share their experiences along the way, so that this team is also able to incrementally onboard the other teams along the way. Busy OPS-teams and product teams can't just develop the new platform on the side, next to all their other ongoing work. Building a container platform is epic and needs dedicated time and focus, also to keep people in their best energy.

I will share some of our most useful experiments and experiences, all having to do with the human side of this container transformation.

This session is not meant for decision making on going cloud native or not. If you do go cloud native, please bear in mind it is still about people, most of all!

Integrationsarchitekturen sind der entscheidende Schlüssel in einer sich schnell entwickelnden Welt. Dabei ändern sich sowohl Geschäftsmodelle als auch technologische Grundlagen schnell und nachhaltig. Wir können aber nicht bei jeder Änderung die Software neu auf der grünen Wiese entwickeln.

Der Beitrag diskutiert den Prozess des Architekturdesigns und typische Integrationsmuster in hybriden Cloud- und On-Promise-Umgebungen.

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Prinzipielle Architekturkenntnisse
Schwierigkeitsgrad: Anfänger

Extended Abstract:
1. Entwicklung einer Architekturvision mit Domain Storytelling und Event Storming
2. Anwendung der Vision in der realen Welt
3. Allgemeine Architekturmuster für Integrationen
4. Eventintegration für Server-zu-Server-Integrationen
5. REST-Integrationen für Benutzerzugriffen
6. Take Aways

Die Architekturkritik bezeichnet bahnbrechende Bauwerke als Architekturikonen.

In diesem Vortrag greife ich den Begriff auf und diskutiere die Lösungsstrategien einiger prominenter Softwarelösungen. Ich stelle den Architekturzielen die gewählten Entwurfsentscheidungen gegenüber und mache auf diese Weise das Geheimnis ihres Erfolges sichtbar. Sie erwartet eine kleine Galerie prägnanter Architektur-Porträts vom Framework bis zum Quelltext-Editor, von 2002 bis 2020.

Was ist die Sydney-Oper der Softwarearchitektur? Welchen Systemen haben wir Architektur-Stile wie Microservices oder Serverless zu verdanken?

Zielpublikum: In erster Linie alle, die Software entwerfen und entwickeln, Führungskräfte können folgen
Voraussetzungen: Erfahrung in Softwareentwicklungsvorhaben sind von Vorteil
Schwierigkeitsgrad: Anfänger

Diese Session zeigt auf, wie sich die Ideen von DevOps und DDD ergänzen und warum man beide Ansätze kombinieren sollte. Wir werden dabei auf die kulturellen Aspekte beider Ansätze eingehen und herausarbeiten, dass die Kombination aus DevOps und DDD zu sehr gut geschnittenen cross-funktionalen Teams mit Ende-zu-Ende-Verantwortung für einen klar abgegrenzten fachlichen Bereich führt.

Der Vortrag zeigt zudem auf, welche Wege sie beschreiten können, damit aus einem "you build it, you run it" ein "you design it, you build it and you run it" wird.

Zielpublikum: Architekt:innen, Projektleiter:innen, Entscheider
Voraussetzungen: DevOps- und DDD-Grundlagen sind vorteilhaft
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Das DevOps-Versprechen "You build it, you run it" wird mittlerweile in zahlreichen Unternehmen ernst genommen und erfolgreich etabliert. Durch die enge Zusammenarbeit zwischen Entwicklung und Betrieb können zahlreiche Hürden überwunden und Release-Prozesse beschleunigt werden.

Darüber hinaus wollen wir mit einer agilen Denkweise weg von einem traditionellen Projektdenken hin zu einem Produktdenken kommen. Für Letzteres ist jedoch eine weitere Fähigkeit relevant: das Wissen über die Geschäftsdomäne.

Hier kommt die Softwarearchitekturdisziplin Domain-driven Design (DDD) ins Spiel, die eine sehr enge Zusammenarbeit zwischen Domänenexpert:innen und Entwicklungsteams propagiert.

Dieser Vortrag gibt Ihnen einen Überblick über Domain-driven Design und zeigt auf, wie sich die Ideen von DevOps und DDD ergänzen und welche Vorteile sich aus der Kombination der beiden Ideen ergeben. Darüber hinaus wird kurz erörtert, wie Microservices mit Domain-driven Design harmonieren. Zusammenfassend werden wir im Laufe der Präsentation sehen, dass aus einem "you build it, you run it" dank Domain-Driven Design ein "you design it, you build it and you run it" werden kann.

Mit Terraform, Ansible/Nixos und Continous Deployment per Knopfdruck zum Betrieb.

In diesem Vortrag betrachten wir Herausforderungen, die bei der Inbetriebnahme von Software aufkommen und setzen Infrastructure as Code mit Terraform, Ansible/NixOS und Continous Deployment beispielhaft um. Wir legen für ein Beispielprojekt live Infrastruktur an, konfigurieren diese und spielen die Software darauf. Bei allen Schritten gehen wir auf die Vorteile und die wenigen Nachteile von Infrastructure as Code ein.

Zielpublikum: Architekt:innen, Entwickler:innen, Admins, DevOps
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Mit Terraform, Ansible/Nixos und Continous Deployment per Knopfdruck zum Betrieb. Der Mehrwert jeder Software kann frühstens erlangt werden, wenn sie betrieben wird. In vielen Fällen ist das dann der Fall, wenn sie auf entsprechender Infrastruktur installiert und betriebsbereit ist. Dafür benötigen wir die Infrastruktur, müssen diese mit Betriebssystemen und nötigen Softwarekomponenten versehen und konfigurieren. Dies ist bei kleinen Systemen oft trivial, doch bei zunehmender Komplexität stellt sich schnell heraus, dass der Aufbau und die Wartung einer stabilen Infrastruktur schwierig ist.

Daher sollen alle nötigen Schritte automatisiert werden, nachvollziehbar sein und jederzeit reproduzierbar durchgeführt werden können. Dafür kommt Infrastructure as Code zum Einsatz. Alle nötigen Definitionen und nötigen Schritte werden mit Konfigurationsdateien, als Code oder mit Domain Specific Languages (DSL) zum eigentlichen Quellcode der Software festgehalten.

Mit Terraform wird die Infrastruktur an sich definiert. Dabei wird z. B. festgelegt, wie viele virtuelle Maschinen mit welchen Ressourcen benötigt werden, wie die Netzwerk- und IP-Konfiguration erfolgen oder in welchem Rechenzentrum die Software betrieben werden soll.

Sobald die Infrastruktur vorhanden und zugänglich ist, muss diese konfiguriert werden. Mit Ansible und NixOS gibt es zwei Ansätze jeden Installations- und Konfigurationsschritt zu definieren und automatisch zur Anwendung zu bringen.

Im Betrieb stellt man sich dann der nächsten Herausforderung: Software muss häufig und regelmäßig aktualisiert werden. Eine Automatisierung ist nahezu unumgänglich. Mit Continuous Deployment und als Code definierten Schritten in z. B. Github Actions gelangt die Software vollautomatisch auf die Infrastruktur.

In diesem Vortrag betrachten wir Herausforderungen, die bei der Inbetriebnahme von Software aufkommen und setzen Infrastructure as Code mit Terraform, Ansible/NixOS und Continous Deployment beispielhaft um.

Wir zeigen das Werkzeug Terraform, mit dem Infrastruktur providerabhängig definiert und einheitlich angewendet und erstellt werden kann. Mit Ansible oder NixOS stellen wir eine (oder beide) Möglichkeiten vor, das Betriebssystem eines Servers mit Quellcode und Konfigurationsdateien automatisiert zu konfigurieren.

Mit einem kurzen Einblick einer möglichen Continous Deployment Konfiguration in Github Actions zeigen wir eine weitere Möglichkeit, Code zu schreiben, anstatt händische Arbeit zu verrichten.

Bei allen Schritten gehen wir auf die Vorteile und die wenigen Nachteile von Infrastructure as Code ein. Ein größeres Augenmerk liegt auf der Dokumentationseigenschaft von Infrastuktur, die auf diese Weise definiert werden. Dies erspart viel weitere Arbeit im Betriebskonzept. Sofern zeitlich machbar wird im Vortrag live Infrastruktur angelegt, konfiguriert und eine Software darauf aufgespielt werden.

API Expand Contract ist ein Pattern zur Weiterentwicklung von APIs. Aber was verbirgt sich hinter der Idee? Wie kann ich damit eine API weiterentwickeln, ohne dass Client und/oder Server im Wartungsaufwand alter Schnittstellen(-Versionen) ersticken?

In der Realität erweist sich Management von APIs und deren Versionen als gar nicht so einfach. Diese Session zeigt mögliche Wege und Alternativen, um der Versionierungshölle zu entkommen und dabei das oberste Gebot beim API-Design - nämlich „Don’t break the Client“ - jederzeit einzuhalten.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Kenntnisse in der API-Entwicklung, Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der Thoughtworks-Technologie-Radar empfiehlt, das Pattern „Expand-Contract“ auf APIs anzuwenden.
Aber was verbirgt sich hinter der Idee?
Und wie kann ich das in der Praxis realisieren?

Wie kann ich sicherstellen, dass trotz Weiterentwicklung alle meine Clients weiterhin funktionieren und dennoch APIs unabhängig vom Server aktualisiert werden können - und das Ganze am besten ohne, dass Client und/oder Server im Wartungsaufwand alter Schnittstellen(-Versionen) ersticken?

Welche Versionierungsstrategie sollte ich in welcher Situation fahren und wie implementiere ich die verschiedenen Strategien geschickt?
In der Realität erweist sich Management von APIs und deren Versionen als gar nicht so einfach. Diese Session zeigt mögliche Wege und Alternativen, um der Versionierungshölle zu entkommen und dabei das oberste Gebot beim API-Design - nämlich „Don’t break the Client“ - jederzeit einzuhalten.

Microservices sind der Hammer, aber nicht alles ist ein Nagel. Trotzdem ist man leicht in der Versuchung, immer diesen Hammer auszupacken, wenn man eine gut modularisierte Software-Architektur zimmern will. Genau das hatten wir mit unserem System auch vor. Wir erzählen euch die Geschichte, warum wir unsere erste Entscheidung revidiert und mit modularen Monolithen ein passenderes Architektur-Werkzeug für uns gefunden haben.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlagen zu Architektur- und Designpatterns
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Woran lässt sich erkennen, ob das jeweilige Architekturproblem in die Kategorie „Nagel“ fällt oder nicht? Das kommt auf die Rahmenbedingungen an: Hat man die Domain schon so gut verstanden, dass die Modellgrenzen oder „Bounded Contexts“ klar sind? Ist es wichtig, einzelne Bausteine unabhängig ausrollen zu können? Wenn nicht, können Modulare Monolithe anstelle von Microservices zwei Vorteile bringen: Erstens verbinden sie ein einfaches Deployment mit einer fachlichen Modularisierung. Damit gewinnt man die Flexibilität, den Code einfach umzubauen. Zweitens spart man sich den Verwaltungs-Overhead von Microservices, ohne dabei den Weg zu einer stärkeren Trennung zu verbauen.

Das klingt attraktiv, aber der Teufel steckt im Detail. Wie stellt man sicher, dass die einzelnen Module getrennt bleiben und kein „Big Ball of Mud“ entsteht? Wie kann man auf der anderen Seite eine Kommunikation zwischen den Modulen erlauben, um fachliche Abhängigkeiten abzubilden?

Wir zeigen euch an unserem System, wie wir die Trennung der fachlichen Module, aber auch die Kommunikation zwischen ihnen umgesetzt haben, auf welche Probleme wir gestoßen sind, welche Lösungen wir gefunden haben und welche Kompromisse wir eingegangen sind.
Damit möchten wir euch einen Eindruck vermitteln, welche Herausforderungen wir mit dem Werkzeug „Modularer Monolith“ meistern konnten, damit ihr es ebenfalls in euren Architektur-Werkzeugkoffer aufnehmen könnt.

Discipline, determination, a highly visible area, and a few sticky notes, are all you need to move beyond problems with technical debt.

Target Audience: Developers, Project Leader, Designers, Product Owners, Decision Makers
Prerequisites: Basic Knowledge of Software Development Process
Level: Basic

Extended Abstract:
## Making great software is challenging
It doesn't matter how qualified a team is, it will never be able to produce perfect, flawless, entirely bug-free software.
While teams are discovering how to build the right software in the right way, the environment the team operates in changes.
This results in a constant reorientation of the product, and the corresponding software solution, which will cause gaps between how things work, and how they should work.
Unfortunately, the market won't wait infinitely until teams have addressed these issues in the software, and organizations tend to run out of patience too.
That is why teams often have to move forward with designs and code that are ... let's call them sub-optimal.
These gaps, they are technical debt: a loan against the future, where things will be fixed, at some point ... Hopefully.
According to a global survey performed by Stripe, Inc. amongst software engineers in 2018, researchers found that **engineers estimate to spend 17,3 hours per week on addressing technical debt**.
That same research established that developers work about 41.1 hours per week. With that in mind, addressing technical debt constitutes well over a third of the time a typical engineer spends per week.
**If engineers are spending that much time, how could they better utilize their attention?**
Why do they seem unable to gain control over this metric and push it downwards?
While technical debt sounds nice and predictable: "you just have to pay interest", it really is like a loan with a mobster, and not with a bank.
It will show up unannounced at your doorstep at 3.30 in the morning, demanding that you pay up now!
How can you prevent being surprised by this goon?! And what can you do to leverage the benefits of borrowing against the future?
Because when the conditions are right, taking out a loan and paying it back Tomorrow might just help you ship a better product today.

## Imagine...
- A lightweight process to discover technical debt without a big investment up front
- A data-driven approach to identify the technical debt that needs attention right now
- A system that is easy to introduce, and simple to enforce
- Something that will guide engineers to articulate technical debt in terms of our roadmap
- Which will ultimately improve the flow of work in your organization

## The Wall of Technical Debt™️
A few years ago [Mathias Verraes coined the term "_The Wall of Technical Debt_"][1]. During this presentation Marijn Huizendveld will show you how to institute such a process for managed technical debt. Doing so will provide you with a safety net that allows you to make "naive" design choices every now and again to ship your ideas as fast as possible, without sacrificing sustainable delivery in the long run.
[1]: verraes.net/2020/01/wall-of-technical-debt/

Even in the time of agile software development and devOps, maintenance and evolution of large-scale software systems remain challenging. This is not only caused by technical debt, but is heavily caused by lost knowledge, high complexity of micro-service architectures, difficult requirements management, not available documentation, and the complexity of communication among and coordination of the many stakeholders. In our session we will talk about the challenges we identified in our study and present new approaches to address these challenges.

Target Audience: Architects, Developers, Project Leader, Manager, Decision Makers
Prerequisites: Project Management Experience, Software Maintenance
Level: Expert

Integration war und ist immer noch relevant - vielleicht mehr denn je. Insbesondere, wenn wir über Anwendungsmodernisierung sprechen. In Zeiten von Cloud- und Microservice-Architekturen müssen wir neu darüber nachdenken, wie wir Integrationsherausforderungen bewältigen können. Klassische ESB-Lösungen sind meist veraltet - was aber ist die Alternative?
Anhand der Erfahrungswerte aus unserem eigenen IT-Modernisierungsprojektes, werde ich vorstellen, wie Integrationsherausforderungen heute mit Hilfe moderner Technologien adressiert werden können.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Cloud, Integration, API, Events
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Integration ist ein wichtiges Thema. In jedem Modernisierungsprojekt existieren entsprechende Herausforderungen, die nach einer entsprechenden Integrationsstrategie verlangen.
In der Regel starten wir ja nicht auf der grünen Wiese, sondern müssen die alte und neue Welt zusammenbringen. Auch ein Monolith kann nicht im Rahmen eines Big Bang Ansatzes einfach mal eben so abgelöst werden.

Im Kontext des Vortrages werde ich von unserem eigenen IT Modernisierungsprojekt berichten, im Kontext dessen wir einen über 30 Jahre gewachsenen Oracle Forms Monolithen in einem inkrementellen Vorgehen ablösen und durch SaaS-Lösungen ersetzen wollen. Die Integration zwischen alter und neuer Welt erfolgt basierend auf modernen Technologiekonzepten wie Containern, API Gateway, Service Mesh und Event Hub mit Kubernetes als zentrale Runtime Plattform.
Dies ermöglicht uns perspektivisch mehr Flexibilität und Agilität sowie eine Steigerung der Developer Productivity durch die Verwendung entsprechender Konzepte und Technologien sowie eine hochgradige Automatisierung im Kontext der Applikationsbereitstellung.

Die Welt der operativen, transaktionalen Systeme und der analytischen Systeme ist seit jeher getrennt. Unterschiedliche SW-Entwicklungsparadigmen, andere Technologien, andere Datenmodelle, usw. prägen die jeweiligen Systeme. Statt Silos zu bauen, geht es darum, eine Balance zu finden zwischen Dev und Data: DevDataOps? Wie können Data Mesh und Data Lakehouse dazu beitragen?

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Die Welt der operativen, transaktionalen Systeme und der analytischen Systeme ist seit jeher getrennt. Unterschiedliche SW-Entwicklungsparadigmen, andere Technologien, andere Datenmodelle, usw. prägen die jeweiligen Systeme. Statt Silos zu bauen, geht es darum, eine Balance zu finden zwischen Dev und Data: DevDataOps? Wie können Data Mesh und Data Lakehouse dazu beitragen?

Data Mesh ist ein Ansatz, der mit Prinzipien wie domänengetriebener Entwicklung, Produktorientierung oder Self-Service Infrastruktur die Welten verschmelzen möchte. Beim Data Lakehouse stehen dagegen technische Eigenschaften im Mittelpunkt der Veränderungen gegenüber gängigen Architekturen. DevDataOps wird von beiden Architekturen unterstützt – die Gewichtung ist jedoch grundverschieden. Auch die Anforderungen an die Umsetzung sind unterschiedlich: Data Mesh führt beispielsweise organisatorische Änderungen nach sich. Im Vortrag werden solche Fragestellungen anhand praktischer Erfahrungen vertieft.

How much design is enough design? How much is overdesign? When does — or should — design happen? How big is 'design'?
Anyone who has ever looked at the methodology landscape or has juggled different roles in software development — programmer, architect, coach, therapist, code paramedic, politician — knows that there are many answers to these questions, and they often contradict one another.

In this talk, we will consider different scales and time frames of design in software, bringing some balance to competing perspectives and recommendations

Target Audience: Developers, Architects, Tech Leads, Project Leads
Prerequisites: Interest in software architecture and design
Level: Advanced

Unfortunately, this presentation has to be cancelled at short notice for personal reasons.

Traditional (i.e. hands-off, blessed-few) approaches to architecture rarely (if ever) work. But in the world of microservices, autonomous teams, and continuous delivery, architecture is more important than ever. Is there an alternative?

Target Audience: Architecture Practitioners (Architects, Lead Developers, etc.)
Prerequisites: Experience delivering software architecture
Level: Advanced

Extended Abstract:
I’m an architect, and I think a lot about architecture. Mostly I think about how irrelevant architecture is if it doesn’t get shipped to production. I worry a lot too. I worry about how to help all the teams I’m supposed to be helping, without slowing them down, getting in their way, or making their lives harder rather than easier.

This paper introduces a mindset and an associated set of practices which do away with the traditional idea of “Architects” while bringing the practice of “Architecture” to the fore. I’ll explain how I and colleagues have used this approach at multiple clients to help everyone become an architect, without things reducing to chaos (though there is a healthy dose of anarchy).

Firmen können kaum noch IT-Systeme neu entwickeln, ohne dass existierende Funktionalität mitwandert. Vor die Aufgabe gestellt, ein System von einem Fremdanbieter in eine Public Cloud zu überführen, hat sich gezeigt, dass hilfreiche Wanderführer rar sind.
Diese Session strukturiert Entscheidungswege und Erkenntnisse bei Cloud-basierten Migrationsvorhaben - abgeleitet aus der Migration und Modernisierung von einem Konsumenten-Service mit 6 PB Daten und ca. 2 Mio. Nutzern.

Zielpublikum: Business-Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Erfahrung mit IT-Projekten
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Wanderungen versprechen Entspannung, Panorama oder Sehenswürdigkeiten auf dem Weg. Selten steht bei der Planung die erwartete Anstrengung im Vordergrund. Ähnlich ist es mit Cloud-Migrationen: Der positive Beitrag zur geschäftlichen Entwicklung lockt, aber nicht ohne Mühe.

Wir streifen die folgenden Etappen:
1. Tourenplanung: Wie wähle ich den richtigen Migrationsweg, aka. die "Migrationsstrategie"
2. Lohnt sich der Weg: Wie überzeuge ich Entscheider, ein solches Vorhaben zu sponsoren
3. Auf dem Weg bleiben: Wie managt man den Migrationsfortschritt?
4. Bleibende Erinnerungen: Wie begegnet man übergroßen Erwartungen und vermeidet Enttäuschung bei Endkunden und Produktverantwortlichen?

Modernization projects are not a straight line as there’s no one-stop shop. Balance is definitely the right word: we talk here about finding the proper trade-off between quality/costs/timeframe requirements and customized patterns for a successful legacy system modernization. Based on actual use cases, we’ll discuss the available solutions (ERP implementation, code rewriting, middleware, cloud…), and see why combining the relevant tools is key.
Let us take you on a modernization journey and get your IBM mainframe to embrace innovation!

Target Audience: Architects, Developers, Project Leaders, Chief Information Officers
Prerequisites: IBM i (AS400) and IBM z environments, mainframes, software development
Level: Advanced

Extended Abstract:
Trusted by major players in the insurance, banking, industrial and public services, IBM i and IBM z mainframes are undoubtedly powerful and reliable. Yet, the core business applications developed decades ago are no longer suited for today's requirements nor for tomorrow's innovations. Issues are piling up: maintenance, regulations, cybersecurity, mobility, UX/UI, technical debt … all made worse by the lack of skilled and motivated developers able to untangle layers of spaghetti legacy COBOL or RPG codes.

When the Total Cost of Ownership (TCO) is rising, some may consider simply shifting to modern architectures. Remember the massive rush to a famous ERP in the 2000s? Disarray, downtime, sleepless nights dreading data loss … History has taught us that forced march towards efficiency is possible but also that balance to consider the actual business environment and needs could have been a far better solution, both for systems and people.
Successful modernization is about making the most of the existing mainframe (remember, IBM i and IBM z systems are powerful and reliable!), adapting it to the latest IT trends and strategically relocating applications, inside or outside the mainframe.

Let us introduce you to an interesting use case we had a few years ago: this financial institution, specialized in consumer loans, is struggling with the obsolescence of its mainframe core business applications:
•    Accounting
•    Human resources and payroll
•    Customer Relationship Management (CRM)
•    Documentary reporting

Lately, legacy applications had had issues to address new demands from their various users (accountants, HR, sales, management):
•    How to work over 2 accounting exercises?
•    How to add new data and issue monthly statements of account?
•    How to call an external webservice to check customer solvency?
•    How to cope with the stricter compliance checks requested by financial regulations?
•    How to secure remote access for other branches?
•    How to provide a modern, secure and multi-session interface?
•    How to offer mobile access to all kinds of devices?

We’ll discuss a fully customized and easy to implement solution to modernize:
developers’ workstations: Java Integrated Development Environment (IDE)
systems and software: migration, decommissioning, revamping, middleware, runtime, mobile connectivity, web services, cloud
Let’s dive together into this real-world use case and deploy the full array of modernization tools to support this financial institution in her quest for innovation.

This talk explains how Scenario Casting enables agile teams to pull together despite diverse ideas and concerns - in three iterative collaborative steps:
1. Find example scenarios of how ideas and concerns affect the domain - strictly in domain language! This provides an initial Scenario Backlog outlining the problem space.
2. Prioritize the Scenario Backlog and agree on scope.
3. Combine the top scenarios into coherent overarching Orientation Scenarios.

Let the agile teams focus on their parts of the Orientation Scenarios over the next iteration(s).

Target Audience: Stakeholders, Non-IT Domain Experts, BAs, Developers, Architects, QMs, Agilists
Prerequisites: Project experience, basic knowledge of DDD, basic knowledge of agile methods
Level: Advanced

Extended Abstract:
Scenario Casting is a collaborative planning and requirements engineering method that has emerged over the past four years in various Domain-Driven Design projects. It is used intensively with dozens of teams most of them involved in ambitious transformation projects.
Scenario Casting is especially helpful for getting a handle on complex or even overwhelming domains. If your domain feels like this and there are a lot of people involved too, you should give Scenario Casting a try.
Scenario Casting lays the groundwork for focused collaborative modeling sessions using domain storytelling or event storming. It ensures that all relevant points are addressed step by step. Also, it helps to quickly identify your domain's subdomains and determine the people who should be involved.

More relevant scenarios are discovered during collaborative modeling. They all go into the Scenario Backlog and will be considered in future Scenario Castings.
Unlike other concepts that try to scale agile, the Scenario Backlog is strictly limited to DDD's problem space, thus avoiding upfront design and premature planning.
Instead, Scenario Casting sets a common focus in problem space for agile teams by defining Orientation Scenarios. An Orientation Scenario illuminates parts of the problem space very precisely. It defines the actual results that solutions must deliver from a domain perspective - but without prescribing specific solutions. Finding and implementing good solutions remains the responsibility of the individual agile teams!

This talk contains examples from real projects and gives you best practices - so you get a good idea of how to try Scenario Casting yourself!

With GraphQL a modern and flexible way of providing APIs for our data is emerging.
The clients specify which data they need, the provisioning of data becomes more flexible and dynamic. Over-fetching or under-fetching are history.
But does this mean we have to rewrite all APIs to benefit? How can we retrofit a GraphQL API onto our existing API landscape?
We will explore three different approaches.

Target Audience: Architects, Developers
Prerequisites: Basic knowledge in API design and Java
Level: Advanced

Extended Abstract:
In this talk we explore three different alternatives:
- The Developer Way: Writing a GraphQL API layer by hand
- The Cloud-native Way: Using lightweight API gateways such as Gloo or Tyk
- The Serverless Way: Using Cloud Provider native services
We will look at all three approaches conceptually and justify when and why each makes sense. Additionally, we will show in a live demo how GraphQL APIs can be added to an existing REST API.

Irgendwann trifft es mal jeden. Anwendungen veralten automatisch, egal, ob ein oder zehn Jahre alt, ob sie "fertig" entwickelt sind oder nicht. Die Gründe sind vielschichtig: Die Programmiersprache entwickelt sich weiter, Bibliotheken brauchen ein Update, Good Practices entwickeln sich weiter. Diese Wartungsarbeiten werden nicht gerne gemacht, da sie scheinbar unnötige Aufwände erzeugen und zum Teil recht stupide sind. Ignoriert die Entwicklerin sie, dann sammelt sie automatisch technische Schulden und die Aufwände sind in der Zukunft höher.

Zielpublikum: Entwickler:innen, Architekt:innen, Entscheider
Voraussetzungen: Allgemeine Entwicklungskenntnisse
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Irgendwann trifft es mal jeden. Anwendungen veralten automatisch, egal, ob ein oder zehn Jahre alt, ob sie "fertig" entwickelt sind oder nicht. Die Gründe sind vielschichtig: Die Programmiersprache entwickelt sich weiter, Bibliotheken brauchen ein Update, Good Practices entwickeln sich weiter. Diese Wartungsarbeiten werden nicht gerne gemacht, da sie scheinbar unnötige Aufwände erzeugen und zum Teil recht stupide sind. Ignoriert die Entwicklerin sie, dann sammelt sie automatisch technische Schulden und die Aufwände sind in der Zukunft höher und bei Sicherheitslücken schmerzhafter.

Dieser Vortrag zeigt, was alles unter Wartungsarbeiten zu verstehen ist und in welche Probleme Unternehmen laufen können, wenn sie es unterlassen. Außerdem stellt es Vorgehensweise und Werkzeuge vor, die bei Wartungsarbeiten helfen können und somit zumindest den stupiden Teil reduzieren.

Die Zertifizierung von Energie aus erneuerbaren Quellen in Europa weist Mängel auf. Wir stellen die Architektur einer Anwendung für Herkunftsnachweise mit einem reaktiven System und einer vertrauenswürdigen Buchführung vor. Sie ist in der Lage, das heutige Verfahren aus Sicht von Endkunde und Energielieferant durch eine zeitnahe Zuordnung von erzeugter und verbrauchter Energie sowie durch Nachvollziehbarkeit maßgeblich zu verbessern. Unser Vorschlag fügt sich in das aktuelle System ein und hat das Potenzial, dieses mittelfristig zu ersetzen.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Interesse an heterogenen Software-Architekturen und vertrauenswürdigen Systemen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Heutzutage legen Kunden großen Wert auf elektrische Energie, die aus erneuerbaren Quellen stammt. Sie sind bereit, dafür einen höheren Preis zu bezahlen, erwarten aber im Gegenzug einen vertrauenswürdigen Herkunftsnachweis. Vertrauenswürdig bedeutet hier, dass der Weg vom Produzenten zum Konsumenten von elektrischer Energie lückenlos transparent aufgezeichnet wird, eine doppelte Zuordnung unmöglich ist und die Buchführung jederzeit überprüfbar ist.

Gemäß europäischem Regelwerk können Herkunftsnachweise in einem Zeitfenster von einem ganzen Jahr nach der Erzeugung entwertet werden. So kann beispielsweise im Winter um Mitternacht erzeugter Strom aus Wärmekraftwerken zusammen mit einem im vorhergehenden Sommer um die Mittagszeit erzeugten Solarstromzertifikat als Ökostrom verkauft werden.
Herkunftsnachweise können sogar unabhängig von der Energielieferung gehandelt werden, wodurch es möglich wird, dass Nachweise für Energie aus Wasserkraft in Island in Deutschland entwertet werden, obwohl keine Möglichkeit zum Energieaustausch besteht. In der Schweiz und in Europa gibt es Vorstöße, die «mehr Transparenz bei der Stromherkunft» fordern.

Wir messen den Verbrauch und die Erzeugung von elektrischer Energie mit geeichten und plombierten «intelligenten» Zählern, die digital signierte Messergebnisse liefern. Die Anwendung empfängt diese Messwerte und legt diese unveränderbar als Erzeugungs- oder Verbrauchs-Datensatz ab. Anschließend ordnet der Matcher dem Verbrauchs-Datensatz die entsprechende Menge an nachhaltig erzeugter Energie zu. Damit wird der Herkunftsnachweis erbracht. Der Erzeugungs- und Verbrauchs-Zeitpunkt darf maximal 15 Minuten auseinanderliegen, damit Erzeugung und Verbrauch einander zugeordnet werden können. Andernfalls erfolgt keine Zuordnung, der Herkunftsnachweis kann nicht erbracht werden.

Ausgehend von der Problemanalyse leiten wir mögliche Geschäftsmodelle und Anforderungen an eine Lösung ab. Wir stellen verschiedene Varianten vor und begründen unsere Wahl. Wir erläutern außerdem, wie wir das System konzipiert haben, damit es robust ist, nachweislich eine korrekte Buchführung gewährleistet und gleichzeitig einen hohen Durchsatz ermöglicht.
Zusätzlich zu den digital signierten Messwerten muss die Vertrauenswürdigkeit der gesamten Kette von Systemkomponenten und Technologien nachgewiesen werden. Dies umfasst sowohl technische Aspekte wie verifizierbare Datenhaltung als auch organisatorische Aspekte wie Vertrauen zwischen Geschäftspartnern.

The cloud has fundamentally changed how we design applications and introduced whole new categories of software-development disasters. With a focus on Java, this talk will introduce some of the new tools, patterns, and best practices for modern distributed application development. It also gives a tour of some of the most painful anti-patterns Holly has seen as a cloud consultant.

Target Audience: Architects, Developers, Strategic Decision Makers
Prerequisites: Basic experience of cloud computing, Knowledge of Java
Level: Advanced

Extended Abstract:
The cloud is just someone else's data center, but it has fundamentally changed how we design software and what we expect from our platforms. Our applications have gotten bigger, more distributed, and more complicated, and there are whole new categories of mistakes we can make. Some things that were a good idea ten years ago turn out to be a terrible idea in the cloud; and what used to be ‘good enough’ for testing really isn’t anymore. Managing microservices architecture demands a lot of us, to ensure observability, operational resiliency, and organisational agility. With a focus on Java, this talk will introduce some of the new tools, patterns, and best practices for modern distributed application development. It also gives a tour of some of the most painful anti-patterns Holly has seen as a cloud consultant.

Funktionale Programmier:innen empfehlen meist "FP-first". Dieser puristische Ansatz passt leider nicht zu den Realitäten existierender Projekte, die objektorientiert auf DDD aufsetzen. Schade, weil diese Projekte von funktionalen Techniken profitieren können.
Der Vortrag beschreibt eine Kooperation zwischen Blume2000 (fest in OO-Hand) und der Active Group (alles FP-Puristen), um Probleme in einer hexagonalen DDD-Architektur (implementiert in Kotlin) mit funktionalen Techniken zu lösen.

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: OO-Grundkenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Dazu gehören:
- Validierung mit applikativen Funktoren
- freie Monaden, um die Domäne von den Ports zu trennen
- funktionale Dependency Injection, auch mit Monaden

Wir zeigen, wie wir's gemacht haben - und wie auch andere Projekte von funktionaler Programmierung profitieren können.
Das alles harmoniert wunderbar mit dem Kotlin/Spring-Boot-Kontext des Projekts.

Es gab aber durchaus auch Reibungspunkte: Die strikte Domänen-/Technik-Separierung des hexagonalen Modells hilft Entwickler:innen, sich zurechtzufinden - funktionale Programmierer:innen benutzen normalerweise feingranularere Abstraktionen im Rahmen der Functional-Core/Imperative-Shell-Architektur. Entsprechend präsentieren haben wir auch einige Vorschläge, wie Spring Boot verbessert werden könnte, um diesen Ansatz besser zu unterstützen.

How to structure your program right? This has been a central question since the beginning of software development. Layers are a start, but not enough. Hexagonal, Onion, and Clean Architecture have joined the club together with DDD's Tactical Design and Pattern Languages. Great system design is not achieved with one of these alone. Putting all the ingredients together we can build the Architecture Hamburger – the combination that makes high quality software possible.

Target Audience: Architects, Developers
Prerequisites: Experience in mid-size to large projects
Level: Advanced

In der Produktentwicklung unterscheidet man zwischen Discovery („Identifizieren von Features“) und Delivery („Umsetzen von Features“). Im Gegensatz zum Wasserfall findet die Discovery nicht am Anfang, sondern kontinuierlich statt. Wie wechselt man regelmäßig zwischen Discovery und Delivery und verfällt nicht wieder in den Wasserfall? Ich berichte anhand der Umsetzung der SPIEL.digital aus der Praxis, mit welchen Methoden wir Discovery, Design und Entwicklung verzahnt haben.

Zielpublikum: Product Owner, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In der agilen Produktentwicklung unterscheidet man zwischen Discovery („Identifizieren von Features“) und Delivery („Umsetzen von Features“). Im Gegensatz zum Wasserfall findet die Discovery nicht am Anfang, sondern kontinuierlich statt. Wie aber geht man damit um, regelmäßig die Flughöhe zwischen Discovery und Delivery zu wechseln und nicht in dieselben Muster wie in der Analysephase des Wasserfalls zu verfallen? Ich berichte anhand der Umsetzung der SPIEL.digital aus der Praxis, mit welchen Methoden wir Discovery, Design und Entwicklung verzahnt haben. Und das alles bei einem festen Endtermin.

Wir entwickeln heute Software nicht mehr auf der grünen Wiese, sondern wir erweitern und verändern vorhandene Systeme. Dabei wird der Code immer komplexer und sammelt technische Schulden an. Im Entwicklungsteam ist uns das allen klar, aber wie erklären wir dem Management, dass es sinnvoll ist, frühzeitig technische Schulden abzubauen?

In diesem Vortrag berichte ich von meiner Erfahrung aus verschiedensten Kontexten und gebe Empfehlungen, wie die Kommunikationsbarriere zwischen Management und Entwicklungsteams übersprungen werden kann.

Zielpublikum: Architekt:innen, Entwickler:innen, Product Owner, Projektleiter:innen, IT-Management
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger

Daten endlich sinnvoll nutzen! Data Mesh befähigt Entwicklungsteams, innerhalb ihrer Domäne Datenanalysen selbstständig durchzuführen, um ihre Services selbstständig verbessern zu können. Über definierte Schnittstellen werden qualitativ hochwertige analytische Daten als Produkte auch anderen Teams zur Verfügung gestellt.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Daten endlich sinnvoll nutzen! Data Mesh befähigt Entwicklungsteams, innerhalb ihrer Domäne Datenanalysen selbstständig durchzuführen, um ihre Services selbstständig verbessern zu können. Über definierte Schnittstellen werden qualitativ hochwertige analytische Daten als Produkte auch anderen Teams zur Verfügung gestellt.

Data Mesh überträgt die Prinzipien aus DDD, Team Topologies und Microservices auf die Datenwelt. Es hat aber auch weitreichende soziotechnische Auswirkungen, und lassen sich die zusätzlichen Aufgaben überhaupt mit dem Projektalltag vereinbaren?

In diesem Talk beschreibt Jochen Christ von INNOQ, wie eine Data Mesh-Architektur in der Praxis umgesetzt werden kann, welche organisatorischen Transformationen notwendig werden und welche Technologien sich dabei eignen.

Learn key patterns, practices, tools, and techniques which lead to successful cloud adoption. Lynn's work with research teams around genomic-scale data pipelines for human health will be highlighted in this keynote.

One of the fundamental strategies of Agile Modeling is that artifacts, including architecture models, should be just barely good enough (JBGE). Another way of saying this is your models should be sufficient for the task at hand, no more and no less. But sufficiency is contextual in nature, it depends.
In this session we will look at the issue of model sufficiency, exploring the risk factors that motivate us to model more as well as the conditions that enable us to model less.

Target Audience: Software Architects, Software Developers
Prerequisites: Basic knowledge of agile, understanding of software architecture
Level: Advanced

Extended Abstract:
One of the fundamental strategies of Agile Modeling is that artifacts, including architecture models, should be just barely good enough (JBGE). Another way of saying this is your models should be sufficient for the task at hand, no more and no less. But sufficiency is contextual in nature, it depends.

In this session we will look at the issue of model sufficiency, exploring the risk factors that motivate us to model more as well as the conditions that enable us to model less. We model to think things through, to identify potential avenues for moving forward so that we can choose what we believe to be the most likely path for success. But the more effort we spend doing so potentially motivates us to make commitments earlier than we should and to lose time, and value, doing so. Balancing these tensions is how we determine model sufficiency in the context that we face. Proven agile architecture strategies that enable us to invest in less up-front modeling will also be explored. It's never just about modeling.

Agenda:
1. Architecture throughout the agile lifecycle.
2. What is initial architecture modeling?
3. What does it mean to be just barely good enough (JBGE)?
4. What risk factors motivate us to invest in more up-front modeling?
5. What factors enable us to invest in less up-front modeling?
6. What are the development practices that support an agile approach to architecture?

Eine auf Microservices basierende Architektur umzusetzen bedeutet, dass auch die Datenhaltung auf die verschiedenen Services verteilt werden muss. Was aber bedeutet das in der Praxis? Was ist, wenn Daten einer Entität - vollständig oder in Teilen - in mehreren Services benötigt werden? Wie wird referenzielle Integrität über mehrere Services hinweg realisiert? Wie lassen sich serviceübergreifende Transaktionen realisieren?

Dies sind nur einige von vielen Fragen, die im Rahmen der Session beantwortet werden. So viel vorab: Umdenken ist gefragt!

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Session zeigt anhand eines praktischen Beispiels typische Data Pitfalls, die einem bei der Zerlegung eines Monolithen in eine Vielzahl von Microservices mit Sicherheit begegnen werden.
Für jede dieser Herausforderung werden mehrere Patterns als Lösungen vorgestellt und in ihrem jeweiligen Kontext bewertet.

In 2022, is having a dedicated software architect still useful, or are there better ways to fulfil this role? The answer, as usual, is "it depends”.

Target Audience: Software Developers and Architects
Prerequisites: None
Level: Advanced

Extended Abstract:
Traditional approaches to software architecture usually trigger thoughts of ivory tower dictators who are a long way removed from the process of building software, probably because they no longer write code anymore. This unfortunate stereotype of “architecture astronauts” delivering large design documents to the development team before running away to cause havoc elsewhere has unfortunately resulted in a backlash against having a dedicated architect on a software development team, particularly in environments where teams are striving to be autonomous and self-organising.
But, in 2022, is having a dedicated software architect still useful, or are there better ways to fulfil this role? The answer, as usual, is “it depends”.

Product Owner treffen regelmäßig Entscheidungen in der Produktentwicklung, die eine fundierte Kenntnis der Fachdomäne und versteckte Anforderungen an wertstiftende Anwendungsfälle und Features erfordern.

Am Beispiel einer komplexen Softwareentwicklung wird der flexible, zeitsparende Einsatz von Domain Storytelling aufgezeigt, um die Qualität fachlicher Entscheidungen zu verbessern. Dazu gehören u. a. die Problemraumanalyse, SOLL-Szenarios im Lösungsraum, strategisches Design (DDD), Releasemanagement (MVP) und arbeitssparendes Dokumentieren.

Zielpublikum: Product Owner (m/w/d), Business Analysts, Manager, Architekt:innen, Entwickler:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Was lernt man:
• Eine kurze Einführung in Domain Storytelling
• Konkrete Beispiele zum Einsatz des Werkzeugs in der Anforderungsermittlung und Softwareentwicklung
• Den Einsatz des Open-Source-Tools Domain Story Modeler Egon.io zum Entwickeln von Szenario-Diagrammen
• Den Zusammenhang von Domain Storytelling und Domain-Driven Design in der Aufgabenstellung Strategisches Design

Leider muss dieser Vortrag aus persönlichen Gründen kurzfristig abgesagt werden.

Die Twin Peaks sind ein Modell, dass die Wichtigkeit des Zusammenspiels zwischen Anforderungen und Architektur beschreibt. Domain Storytelling hilft, das Twin Peaks Model in der Praxis zu leben. In drei Sprints erarbeiten wir gemeinsam das erste Inkrement eines praxisnahen Anwendungsfalls. Dabei wird die Methodik Domain Storytelling, Tipps und Tricks für die Moderator:in sowie der Übergang zur Software-Architektur interaktiv vermittelt.

Zielpublikum: Architekt:innen, Entwickler:innen, Product Owner, Agile Coach
Voraussetzungen: Projekterfahrung und Grundkenntnisse Domain-driven Design und Scrum
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Ersatzteil, Bestellung, Auftrag und Kunde. Alles klar, das kennen wir! Die im Planning gefühlte Klarheit endet, wenn Entwickler:innen bei der Implementierung von User Stories auf offene Fragen stoßen. Eine schnelle Klärung komplexer Fragen oder Annahmen seitens der Entwickler:innen führt oft nicht zum Erfolg.

Das Ergebnis: Die software-technische Realisierung deckt sich nicht mit den wirklichen fachlichen Anforderungen und es muss nachgearbeitet werden. In der Folge steigen Aufwand und Kosten. Das Projekt befindet sich in einer Abwärtsspirale aufgrund fehlenden Domänenwissens und einer daraus resultierender Softwarearchitektur, die die Domäne nicht unterstützen kann.

Die Twin Peaks sind ein Modell, das die Wichtigkeit des Zusammenspiels zwischen Anforderungen und Architektur beschreibt. Die Abwärtsspirale wird durchbrochen, indem wir die Twin Peaks von der Spitze an, mithilfe von Domain Storytelling, hinabsteigen.

In diesem Talk stelle ich euch Domain Storytelling vor und wie diese Methode dabei hilft, das Twin Peaks Model in der Praxis zu leben. In drei Sprints erarbeiten wir gemeinsam das erste Inkrement unseres Softwareprodukts. Dabei wird die Methodik Domain Storytelling, Tipps und Tricks für die Moderator:in sowie der Übergang zur Software-Architektur interaktiv vermittelt. Denn vermutlich liegt es nun an dir, die entscheidenden Impulse zur Verbesserung der Situation in deinem Projektkontext zu setzen.

In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. This talk will help you shape an answer for the typical questions (like shall I be synchronous or asynchronous and what's a good protocol to use?). You will better understand not only the architectural implications but also the effect on the productivity of your teams.

Target Audience: Developers, Architects
Prerequisites: Basic programming skills helpful
Level: Advanced

Extended Abstract:
In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. Now there are so many questions about this communication:

•    What are the general possibilities to communicate? For example, synchronous, asynchronous, or event-driven communication. What are the tradeoffs and which communication style should you prefer?
•    What is the influence on the coupling of your services? For example, asynchronous communication reduces temporal coupling between services.
•    What do I have to consider when selecting a certain communication style?

For example, you need to apply certain resilience patterns if you want to use synchronous communication.
This talk will help you answer these questions for your project. You will better understand not only the architectural implications but also the effect on the productivity of your teams.

As developers, our job is to deliver working software. With the shift to CI/CD and the move to the cloud, the need to have the right feedback at the right time only increases. There are many ways that testing can help us with that. Not only can testing help us verify our solution and prevent us from breaking things, it can also help us design our software, find flaws in our architecture and come up with better solutions. In this talk I will highlight some of the many ways that testing can help you to develop better software faster.

Target Audience: Developers
Prerequisites: Basic knowledge in Java
Level: Advanced

Extended Abstract:
Testing doesn't always get the attention it deserves in software development. Many developers claim to be bad at it, or are just not that interested. (These may or may not be related.)

As developers, our job is to deliver working software. With the shift to CI/CD and the move to the cloud, the need to have the right feedback at the right time only increases. There are many ways that testing can help us with that. Not only can testing help us verify our solution and prevent us from breaking things, it can also help us design our software, find flaws in our architecture and come up with better solutions.

In this talk I will highlight some of the many ways that testing can help you to develop better software faster.

In this session I’ll examine some of the things that can go wrong when organisations jump headfirst into micro-service architectures without understanding the potential pitfalls.

I'll explain contract testing from the ground up. You'll learn how it can decouple micro-service dependencies during development, allowing your teams to work effectively. And I'll describe sophisticated, free, open-source tooling that helps integrate contract testing into your software lifecycle, giving you the confidence to release micro-services independently.

Target Audience: Architects, Developers, Decision Makers, Release Managers, DevOps
Prerequisites: English, basic software design/architecture, software lifecycle
Level: Advanced

Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierte Enterprise Computing-Lösungen geht. Dies gilt zumindest immer dann, wenn die Anwendung als Monolith in einem Application Server deployed werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind?

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so, mithilfe von Side-Projekten wie dem Eclipse MicroProfile, den Anforderungen moderner Cloud-native-Anwendungen gerecht zu werden.
Ein Ausblick auf das Zusammenspiel mit GraalVM und Quarkus zeigt, dass Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien, aka Serverless, eine gute Figur macht.

Webanwendungen ohne automatisiert getestete APIs machen im Betrieb und Weiterentwicklung schlechte Laune, egal, ob es um APIs zwischen Frontend und Backend, zwischen Microservices oder zu Drittparteien geht. Typischerweise beschreiben wir das erwünschte Verhalten der Anwendung, in dem wir uns selbst Beispiele als Testfälle ausdenken. Da geht mehr. In diesem Beitrag werfen wir einen Blick auf über "naive Integrationstests" hinausgehende Ansätze, von Contract Based bis hin zu KI-Unterstützung.

Zielpublikum: Entwickler:innen, Tester:innen
Voraussetzungen: Erfahrung in der Entwicklung und im automatisierten Testing von Webanwendungen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Älteren unter uns werden sich noch an die Anfänge der Webentwicklung erinnern: Tester:innen klickten sich wieder und wieder durch umfangreiche Testpläne durch, die typischerweise nach dem Entwickeln erstellt wurden. Dieser Ansatz ist leider gerade in Konzernen immer noch nicht ausgestorben. Schlecht getestete Schnittstellen werden schnell zur Achillesferse gerade in modularen Architekturen und vor dem Wunsch, fertige Software schneller in die Produktion zu bringen. Consumer driven contract testing ist zumindest theoretisch mittlerweile in den Teams angekommen, neuere Ansätze wie Search based Software Testing oder Property based Testing sind dagegen noch exotisch.

Die Session will einen praxisorientierten Überblick über unbekanntere Verfahren geben.

Ursprünglich war agile Entwicklung und allen voran XP für Entwickler:innen gedacht. Inwiefern werden diese heutzutage noch von agilen Vorgehensweisen unterstützt? Diese Frage wird von Erik Dörnenburg mittels "25 Jahre XP: Die Balance zwischen neuen Technologien und bewährten Praktiken" und Ina Einemann durch "Take it Back" untersucht und in einem Panel mit Frank Buschmann diskutiert.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Software-Ingenieur:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Als Kent Beck vor fast 25 Jahren Extreme Programming (XP) beschrieb sah die IT-Industrie noch recht anders aus. Seitdem sind agile Ansätze und die Nutzung von Open Source Software Mainstream geworden, und die Public Cloud Anbieter haben sich und ihre Ökosysteme etabliert. Diese Trends haben unsere Fähigkeiten komplexe Software-Systeme zu entwickeln verbessert. Das eigentliche Handwerk – effektiv in einem Team beständig Software zu schreiben – ist aber genauso wichtig wie immer. In diesem Talk geht es um die Rolle, die XP für die moderne Software-Entwicklung spielt.
Das agile Manifest wurde vor über 20 Jahren von Entwicklern für Entwickler geschrieben. Mittlerweile fühlt es sich aber immer mehr an, als ob die agile Bubble eine eigene Welt ist, die von Scrum Mastern und Agile Coaches übernommen wurde. Developer nehmen eher passiv an den vorgeschriebenen Meetings teil, statt den Prozess aktiv zu gestalten.

Was läuft da schief? Und wie können wir das ändern?

In dieser Session geht es um Motivation, sinnvolle Konflikte und Empowerment.

Qualitätsziele helfen uns, Architekturentscheidungen fundierter zu treffen. Die genau richtige Qualität ist jedoch oft subjektiv und ändert sich über die Zeit hinweg. Dies macht das Arbeiten mit und an Qualitätszielen vor allem bei langlebigen Softwaresystemen spannend.

In diesem Vortrag stelle ich eine neue Sicht auf Softwarequalität vor, bei der wir Qualität im evolutionären Kontext betrachten. Als Basis verwende ich das ISO 25010-Qualitätsmodell sowie Wardley Mapping, um die passende Qualität nach Wichtigkeit und Evolutionsstufen zu finden.

Zielpublikum: Software-Architekt:innen, Entwickler:innen
Voraussetzungen: Erfahrung mit optimierungsbedürftigen Softwaresystemen
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Die Balance der passenden Qualitätszielen ist ein herausforderndes Thema. Qualitätsziele sind aber sehr wichtig in der Entwicklung passender Softwaresysteme. Sie helfen uns, Architekturentscheidungen fundierter zu treffen. Die „genau richtige Qualität“ hängt dabei stark vom Betrachtungspunkt verschiedener Stakeholder ab. Zudem ändern sich Ansprüche an die Qualitäten eines Softwaresystems über die Zeit hinweg. Dies macht das Arbeiten mit und an Qualitätszielen vor allem in langlebigen Softwaresystemen immer wieder spannend.

In diesem Vortrag stelle ich eine neue Sicht auf Softwarequalität vor, wo wir Qualität im evolutionären Kontext betrachten. Als Basis verwende ich hierzu das ISO 25010-Qualitätsmodell sowie Wardley Mapping. Damit lassen sich notwendige Qualitäten nach ihrer Wichtigkeit und Evolutionsstufen von Softwaresystemen kommunizieren. Der Vortrag verzahnt die evolutionäre Sicht auf Softwarequalität mit Beispielen aus der Praxis und zeigt, wie sich damit die richtige Balance zwischen zu viel und zu wenig Qualität gestalten lässt.

Ist uns Softwerkern wirklich klar, was wir meinen, wenn wir von Technischen Schulden sprechen? “Klar”, ist die Antwort. Wirklich? Warum haben wir dann Schwierigkeiten, POs/Projektleiter/Abteilungsleiter vom notwendigen Budget zu überzeugen?
Im Vortrag zeigen wir, wie es datenbasiert besser geht. Wie man für Technische Schulden KPIs erfasst und wie man jeweils Code-, Architektur-, Test-Qualität, Team-Kollaboration mit den KPIs korreliert, um eine Kosten-Nutzen-Analyse durchzuführen. Trotz Microservices und DevOps - die Herausforderungen bleiben.

Zielpublikum: Architekt:innen, Projekt-/Technische Leiter:innen, Key Developer, Manager, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Ist uns Softwerkern wirklich klar, was wir meinen, wenn wir von Technischen Schulden sprechen? “Klar”, ist die Antwort, “es geht um Smells, Bugs, Bedarf an Refactoring, fehlende Tests …”. Zum Teil können wir deren Umfang und Bedarf sogar messen. Aber wie entscheiden wir, was wir zuerst angehen sollen? Wie und was messen wir, sodass andere Stakeholder uns überhaupt verstehen und wir POs, Projektleiter und Abteilungsleiter vom notwendigen Budget überzeugen können?
Im Vortrag zeigen wir, wie man datenbasiert bessere Antworten findet. Was man mit den Folgen der Technischen Schulden anfängt, Wartungs- und sich verstärkende Mehraufwände in der Entwicklung als KPIs erfasst und deren Hotspots im Code identifiziert. Wie man jeweils Code-, Architektur- und Test-Qualität usw. als Ursachen identifiziert und mit den KPIs korreliert. Und wie man Technische Schulden in der Architektur in Zahlen prognostiziert, um eine Kosten-Nutzen-Analyse durchführen zu können. Und wie sich Team-Kollaboration auch auf Technische Schulden auswirkt.
Diese Herausforderungen sind seit mehreren Jahrzehnten die gleichen. Daran haben auch Microservices nichts geändert.

Die Teilnehmer erhalten Antworten auf folgende Fragen:

•    Was sind Technische Schulden genauer?
•    Wie misst man die Folgen?
•    Wie sieht eine effektive Ursachenanalyse aus?
•    Wie überzeuge ich andere Stakeholder von der Notwendigkeit?
•    Wie wirkt sich Team-Kollaboration auf Technische Schulden aus?

Software containerisiert auszuliefern, ist mittlerweile sehr etabliert. Selbst bei Beachtung gängiger Best Practices ist es jedoch schwierig, Docker-Images reproduzierbar und sicher zu machen. Mögliche Folgen sind beispielsweise Versionskonflikte oder plötzlich fehlschlagende CI-Pipelines.

Mit dem Package-Manager Nix kann man einen großen Teil dieser Probleme vermeiden. Insbesondere das Nix-Tooling rund um Docker ermöglicht eine schmerzfreie Erstellung vollständig reproduzierbarer und minimaler Docker-Images.

Zielpublikum: Entwickler:innen, Architekt:innen, Dev-Ops-Ingenieure
Voraussetzungen: Docker-Basiswissen
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Es wird eine kurze Einführung in die Nix-Toolchain und -Programmiersprache geben. Wir schauen uns ein Beispielprojekt an, in dem verschiedene Technologien zum Einsatz kommen. Dabei identifizieren wir gemeinsam diverse Problem einer sehr naiven Dockerisierung des Projekts, und versuchen im Anschluss, diese mit einer "nixifizierten Variante" zu lösen. Als Resultat erhalten wir cache-freundlich minimale und reproduzierbare Docker-Images ‒ baubar sogar ohne Docker-Installation.

Grundlegende Erfahrung mit Docker wird vorausgesetzt. Vorwissen zu Nix ist keine Notwendigkeit.

Immer mehr Entwickler:innen schreiben Anwendungen, die später in einem Kubernetes Cluster laufen sollen. Was kann dabei so schwierig sein? Angefangen "Wie strukturiere ich meine Repositories?", "Wo lege ich meinen Code für das Deployment ab (Containerfiles, Helm Charts, Config Values)?", "Was muss bei der Entwicklung der Anwendung beachtet werden?", "Wie bekomme ich den Code lokal getestet?", "Wie bekomme ich mit, was im Test-Cluster passiert?"

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Kubernetes-Kenntnisse, allgemeine Entwicklungskenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Immer mehr Entwickler:innen schreiben Anwendungen, die später in einem Kubernetes Cluster laufen sollen. Was kann dabei so schwierig sein? Angefangen "Wie strukturiere ich meine Repositories?", "Wo lege ich meinen Code für das Deployment ab (Containerfiles, Helm Charts, Config Values)?", "Was muss bei der Entwicklung der Anwendung beachtet werden?", "Wie bekomme ich den Code lokal getestet?", "Wie bekomme ich mit, was im Test-Cluster passiert?"
Dieser Vortrag geht am Beispiel einer Java-Anwendung die typischen Entwicklungsschritte von der Ablage im VCS bis hin zum Deployment auf einem Cluster aus Sicht einer Entwicklerin durch.

APIs sind die Bindeglieder moderner Architekturen und nicht selten integriert ein System APIs im zweistelligen Bereich. Damit die API-Integration nicht zur Irrfahrt wird, unterstützen API-Guidelines die Developer Experience. Mit einem Blick auf öffentliche Guidelines und APIs gibt der Vortrag einen Eindruck von der allgemeinen Situation und liefert Impulse für das eigene API-Management. Da es in der Regel zu kurz gegriffen ist, einfach öffentliche API-Guidelines zu referenzieren, geben wir Tipps für eigene API-Guidelines und deren Etablierung.

Zielpublikum: Architekt:innen und Entwickler:innen
Voraussetzungen: Erfahrung oder Interesse am Design von Remote APIs
Schwierigkeitsgrad: Anfänger

Extended Abstract:
APIs sind die Bindeglieder unserer modernen, verteilten Systemarchitektur und nicht selten liegt die Anzahl der APIs im zweistelligen Bereich, wenn ein System integriert werden muss. Damit der Überblick gelingt und die API-Integration nicht zur Irrfahrt wird, unterstützen API Style Guidelines bei einer besseren Developer Experience und sind ein wichtiger Bestandteil der API Governance.
Mit einem Blick auf öffentlich zugängliche API-Guidelines und der Analyse öffentlicher APIs werden wir uns einen Eindruck von der allgemeinen Situation verschaffen und liefern Impulse für das eigene API-Management und -Design.

Hierüber wird auch schnell klar, warum es in der Regel zu kurz gegriffen ist, einfach eine öffentliche API-Guideline zu referenzieren. Deshalb werden wir auch Wege zur eigenen API-Design-Guideline aufzeigen und Tipps geben, die bei der Etablierung im Unternehmen helfen werden.

You know the story, one dev in the team found out about this amazing new framework which will solve potentially aaaall your problems; but the product owner stops him right away. There is definitely no time until the next roadmap milestone is reached and you’re already late. We have introduced the tool Tech Radar – in two different organisational setups – to make technology strategy explicit.

In this talk I’ll share our learnings on how we made sure our teams don’t drown in legacy, train them on time for new tech and foster exchange across teams.

Target Audience: Architects, Developers, Team Lead
Prerequisites: Everyone interested in technology strategy
Level: Basic

Java applications are widely used and often several years old. You can use these applications in the cloud via lift-and-shift (helps nothing) or you can rewrite the application in cloud-native style and use the advantages of the cloud.

An alternative for existing applications is missing here. It must be possible to go to the cloud and use advantages such as serverless and scale-to-zero WITHOUT having to rewrite the entire application.
I will show what is already working well today and where the rough edges are.

Target Audience: Architects, Developers
Prerequisites: None
Level: Basic

Additional information:
In the session, we'll move an existing application to the cloud and save over 70 % of operating and maintenance costs with serverless and scale-to-zero.

Jede kleine Änderung an einem Embedded System kann bösartigste Auswirkungen haben. Findet und behebt man die Probleme zu spät, ist die Behebung zudem sehr teuer.

In Vortrag und Demo wird gezeigt, wie man durch Verbindung von Hardware-in-the-Loop und Continuous Integration jede Änderung an einem Embedded System innerhalb von Minuten testen kann, statt lange auf die Durchführung von Systemtests zu warten.

Zielpublikum: Architekt:innen, Embedded Entwickler:innen, Qualitätsmanager, Projektleiter:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Jede kleine Änderung an einem Embedded System kann bösartigste Auswirkungen haben. Findet und behebt man die Probleme zu spät, ist die Behebung zudem sehr teuer.

Daher sollte jede Änderung an einem Embedded System innerhalb von Minuten getestet werden können. Nur so kann man sicherstellen, dass man die Probleme schnell entdecken und beheben kann.
Bei reinen Softwareprojekten hilft eine vollständige Automatisierung der Tests über Continuous Integration (CI). Hierbei löst jede Codeänderung automatisch den Bau und Test der kompletten Software aus. Dadurch kann innerhalb von Minuten ein vollständiger Regressionstest Fehler in bestehendem und neuem Code entdecken.

Aber wie kann man das für System- oder Integrationstests bei Embedded Systemen erreichen?

Dafür nötige Hardware-in-the-Loop-Tests (HIL-Test) oder manuelle System-Tests sind häufig schwer zu automatisieren.

* Echte Hardwareanteile im Testaufbau verhindern die Automatisierung und Wiederholbarkeit
* Häufig kann nur der "Happy Path", nicht aber ein Fehlverhalten getestet werden
* Der Teststand ist häufig zu teuer, um für jedes Projekt, jederzeit für Automatisierung verfügbar zu sein

Durch den leichtgewichtigen Hardware-in-the-Loop-Test mit dem miniHIL kann man die Tests vollständig über Continuous Integration automatisieren.
Wie geht das?

* Hardwareschnittstellen werden nur auf Signalebene simuliert und passen daher gut in die Test-Automatisierung
* Testhardware wird größtenteils durch Softwaresimulationen ersetzt
* Fehlverhalten kann einfach über fehlerhafte Signale simuliert und getestet werden
* Die dazu nötige Hardware ist signifikant einfacher, kleiner und preiswerter als traditionelle HIL-Systeme. Für jedes Projekt steht jederzeit ein eigener Testaufbau für die Automatisierung zur Verfügung.

So kann jede Änderung innerhalb von Minuten automatisch getestet werden. Erst durch die vollständige und schnelle Testautomatisierung kann effektiv in Teams gemeinsam komplexe Embedded Software entwickelt werden.
Der Vortrag schließt mit einer Live-Demo eines solchen Testaufbaus.

Angetrieben durch Bewegungen wie Fridays For Future hat sich unser Fokus wieder auf die Klimaveränderung gerichtet. Unternehmen achten immer mehr darauf, klimaneutral zu werden und/oder klimaneutrale Produkte zu liefern.

Was hat das eigentlich für Auswirkungen auf unser herkömmliches IT-Verständnis? Machen wir einfach weiter wie bisher? Gibt es Einflüsse auf die DevOps-Bewegung?

Dieser Vortrag versucht Aufklärung und gibt erste Schritte, wie wir unsere Denkweise anpassen können.

Zielpublikum: Alle DevOps-Fans, Entscheider
Voraussetzungen: Cloud Verständnis, DevOps
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
DevOps und eigentlich auch die agile Bewegung stellen eine hohe Valueorientierung in den Fokus, und zwar Valueorientierung für den Kunden.

Ist das überhaupt noch gültig? Oder können wir bestehende Methodiken wie Wertstromanalysen noch weiterhin benutzen?

Zudem schauen wir uns an, wie uns Cloudprovider helfen bei der Unterstützung, CO2-Emissionen erst mal zu verstehen. Wie schon in Gemba, heißt es zunächst, den Verbrauch zu sehen und danach Maßnahmen zur Verbesserung durchzuführen.

Was können Maßnahmen sein? Da werden wir uns auch paar Beispiele ansehen. Unter anderen neue Faktoren in der Auswahl einer Cloudregion.

Since the dawn of software development, programmers have been perpetually occupied with migrating our "legacy" code to "the new platform". As soon as we finish, it is obsolete, and we need to start over. Today we are typically in the midst of moving to the cloud. We need DevOps, microservices, new frontend frameworks ... there is always some new tool that promises to deliver much better value than our existing solutions. Millions - even billions - are spent on these initiatives. Are they worth it? For whom?
In this presentation we will go through various strategies and their tradeoffs. How can we work with our code bases, staff and users to maximise the actual value delivered? The answer will depend on many things. Be conscious of what exactly you are aiming to achieve.

Eine der größten Herausforderungen im Systems Engineering ist die viel beschworene Beherrschung der Komplexität. Bisher in der Praxis etablierte Ansätze betrachten die Strukturierung von Anforderungen und die Dokumentation der Realisierung durch die entsprechenden Architekturelemente. Aber was ist mit den Testfällen, dem Feature-Tree für Produktvarianten und der Organisationsstruktur? Diese Strukturen gilt es im Rahmen der Systementwicklung angemessen zu berücksichtigen und nachvollziehbar mit anderen Arbeitsergebnissen in Beziehung zu setzen.

Zielpublikum: Entwickler:innen, Architekt:innen, Requirements-Engineers, Systems Engineers
Voraussetzungen: Verständnis zum Zusammenspiel der Entwicklungsdisziplinen
Schwierigkeitsgrad: Experte

Extended Abstract:
Bei der Entwicklung von komplizierten technischen Systemen treffen unterschiedliche Disziplinen wie Anforderungs- und Architekturentwicklung, Test und Abnahme etc. aus verschiedenen Gewerken (Software- und Hardwareentwicklung) aufeinander. Trotz unterschiedlicher Ausrichtungen und Schwerpunkte leisten alle Beteiligten einen Beitrag in Form von Arbeitsergebnissen zum fertigen Produkt. Jedoch unterscheiden sich diese Arbeitsergebnisse häufig in ihrer Darstellung, betrachten aber letztlich doch das gleiche System und stehen dadurch inhaltlich in einem Zusammenhang.

Eine wesentliche Herausforderung ist es, diese Zusammenhänge in den Arbeitsergebnissen (Anforderungen, Architekturdokumentation, Testfälle etc.) transparent zu machen und zu nutzen, um dadurch disziplinen- und gewerkübergreifend eine durchgängige Systementwicklung zu gewährleisten. Für Anforderungen und Architekturdokumentationen haben sich dafür sowohl das Twin-Peaks-Modell als auch das SPES 2020-Framework mit dem RFLP-Ansatz etabliert. Beide Modelle vernachlässigen allerdings weitere Disziplinen der Systementwicklung wie z. B. Integration, Test und Abnahme oder das Produkt- und Portfoliomanagement und verzichten auf eine Betrachtung der dabei erzeugten Arbeitsergebnisse. Und wie sind diese Disziplinen eigentlich in der Organisation verortet? Welche Abteilung oder welches Team leistet welchen Beitrag am Gesamtprodukt?

Ziel dieses Vortrages ist es, ein Denkmodell zu vermitteln, das unterschiedliche, graphen- oder baumartige Strukturen und Sichten miteinander in Beziehung setzt, um dadurch typische Probleme in der Systementwicklung wie z. B. unklare Verantwortlichkeiten transparent zu machen und zu lösen. Anhand eines durchgängigen Beispiels erfahren Sie, welche weiteren Sichten neben den Anforderungen und der Architekturdokumentation auf unterschiedlichen Abstraktionsebenen in der Systementwicklung (System, Subsysteme, Komponenten) sinnvoll sein können. Neben einer Motivation, den Inhalten dieser Sichten und deren Wechselwirkungen erhalten Sie einen Einblick, welche Probleme mithilfe dieses Denkmodells gelöst werden können.

Im Gegensatz zu den klassischen Ansätzen verfolgt Docs-as-Code das Ziel, die in Softwareprojekten relevante Dokumentation genau wie den Quelltext zu behandeln. Somit können die gleichen Werkzeuge wie für die Entwicklung verwendet werden, um die Erzeugung und Auslieferung in die automatisierten Build-Prozesse einzubinden.

Jedwede Art von Dokumentation gewinnt somit an Sichtbarkeit und durch die Eingliederung in die Entwicklungsprozesse und die damit verbundene kontinuierliche Weiterentwicklung steigen Qualität und Akzeptanz bei den Lesern.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider
Voraussetzungen: Grundlegende Kenntnisse von Architekturdokumentation und für automatisiertes Build-Management
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Dokumentation wird häufig vernachlässigt. Mit dem Docs-as-Code-Ansatz wird die in Softwareprojekten relevante Dokumentation genau wie Quellcode behandelt, in der Versionsverwaltung abgelegt, mit leichtgewichtigen Entwicklerwerkzeugen (IDE/Texteditor, Build-Tools, CI/CD-Pipelines) bearbeitet und in die Softwareentwicklungsprozesse integriert. Die Inhalte können redundanzfrei verwaltet und manche Informationen aus Modellen oder dem Quellcode generiert werden. Durch die Verwendung leichtgewichtiger Text- und Grafikformate lassen sich die Ergebnisse einfach zielgruppenorientiert zusammenstellen. Die Verarbeitung erfolgt automatisiert über die schon vorhandenen Build-Prozesse.

Jedwede Art von Dokumentation gewinnt somit an Sichtbarkeit, durch die Eingliederung in die Entwicklungsprozesse und die damit verbundene kontinuierliche Weiterentwicklung steigt die Qualität und damit die Akzeptanz bei den Lesern. Dokumentation kann sogar ausgeführt werden, um zum Beispiel eingebettete Architekturregeln regelmäßig automatisiert zu testen. Die Zuhörer erfahren in diesem Vortrag an konkreten Beispielen, wie sie mit Documentation as Code starten können, welche typischen Fallstricke sie umschiffen und mit welchen konkreten Tools sie am besten arbeiten sollten.

Software Development based on a distributed architecture provides both several advantages and new challenges. In order to take advantage of the distribution it requires implementation of service discovery, routing, load-balancing, resilience mechanisms and more. These requirements can be covered by language frameworks or the underlying platform.

This talk will walk through a comparison of various approaches with focus on frameworks, Kubernetes and extending options like Service Meshes and eBPF. The talk will be lecture style with demo.

Target Audience: Developers, Architects, DevOps
Prerequisites: Introductory style, basic IT and dev skills probably helpful, but not required
Level: Basic

Extended Abstract:
Software Development based on a cloud-native (or distributed) architecture provides both several advantages and new challenges. In order to take advantage of the distribution it requires implementation of service discovery, routing, load-balancing, resilience mechanisms and more. Initially software frameworks provided dedicated implementations for API Gateways, Service Registries, Circuit Breakers and many more. These functionalities are declared as code dependencies and need to be set at build time.

With Kubernetes there are alternative options to address these requirements. Kubernetes provides concepts for service discovery, load-balancing and resilience. So-called service meshes extend this functionality with more granular network interaction. They are not part of the application code and can hence be added during runtime. A fairly new approach is emerging with the eBPF technology, which claims to enable service meshes with minimal overhead.

With this talk Matthias wants to explain "the why" of cloud-native application design and how various cloud-native technologies facilitate this. It shows the possibilities and limitations of technologies and which forms of integration can make sense. The talk mostly consists of graphical visualisations/explanations and contains a live demo.

What should you do if you are promoted or hired to be the first Head of Architecture in a big, international organisation? What should you do to shape the role to deliver value to the organisation and its customers? How do you work with many development teams to shape the current legacy spaghetti mess into a coherent system, without becoming a bottleneck?

In this talk I'll respond to all questions and more, by sharing my experience in becoming the first Head of Architecture in a big international organisation.

Target Audience: Architects, Developers, Senior Managers
Prerequisites: Knowledge of software architecture
Level: Expert

Extended Abstract:
In this talk I'll share my experience in becoming the first Head of Architecture in a big international organisation, and on how I shaped the role to deliver value both to the organisation and its customers. Among other things, I'll share what I did to:

- Work productively with the development teams and be relevant.
- Navigate the political landscape to influence decisions.
- Create an architectural decision process tailored to the needs of the organisation.
- Provide guidelines and constraints to decentralise decision making while avoiding chaos.

The attendees will get a better understanding of what the role encompasses, and future heads of architecture may get a better view of what expects them in this role.

Fast jeder kennt das Problem, dass die Konfiguration eines Systems oft (weit) vom gewünschten Zustand (desired state) abweicht. Statt den Zustand (nur) zu dokumentieren oder programmatisch herzustellen, kann man ihn bei GitOps auch deklarativ beschreiben, z. B. mit Terraform, und in Git ablegen. Änderungen lassen sich als Workflow z. B. über eine Pipeline-Engine realisieren.

Der Workflow ermöglicht den flexiblen Roll-Out von Änderungen. Ursprünglich wurde GitOps auf Kubernetes realisiert, das Konzept lässt sich aber auf andere Systeme übertragen.

Zielpublikum: Architekt:innen, Entwickler:innen, Site Reliabilty Engineers
Voraussetzungen: Dev- oder Ops-Kenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der Vortrag erläutert das Konzept von GitOps am Deployment einer einfachen Anwendung und der dazugehörigen Infrastructure as Code mit Terraform. Dabei werden die typischen Abläufe von Deployments als Workflow auf einem Git-Repository über eine Pipeline realisiert, angelehnt an das bekannte two-phase-commit Pattern aus verteilten Transaktionen:

•    Vorbereitung des Deployments (prepare)
•    (Optionale) Qualitätssicherung des Deployments (review, test)
•    Durchführung des Deployments (perform/commit)

Zur Qualitätssicherung kann explizit ein personalisiertes Review (4-Augen-Prinzip) gehören. Darauf aufbauend lässt sich auch ein Rollback auf einen früheren Zustand durchführen (reverse commit).
Der Autor hat ein solches System mehrfach außerhalb von Kubernetes implementiert bzw. solche Implementierungen benutzt. Damit lässt sich zeigen, dass das Konzept, das ursprünglich für Kubernetes gedacht war und in mehreren Implementierungen vorliegt, auch außerhalb von Kubernetes nutzbar ist.

When building systems, it can be too easy to focus on features and overlook software qualities related to architecture. If not enough attention is given to qualities related to the architecture, technical debt and design problems can creep in until it becomes muddy with the effect of teams being less agile. Sustainable architecture requires ongoing attention, especially when there are evolving priorities, technical risks, and many dependencies. This talk presents practices for creating and evolving an architecture while remaining agile.

Target Audience: Architects, Managers, Coaches, Developers, POs, QA
Prerequisites: Understanding of Agile and Architecture is useful
Level: Advanced

Extended Abstract:
Being Agile, with its attention to extensive testing, frequent integration, and focusing on important product features, has proven invaluable to many software teams. When building complex systems, it can be all too easy to primarily focus on features and overlook software qualities, specifically those related to the architecture. Some believe that by simply following Agile practices — starting as fast as possible, keeping code clean, and having lots of tests — a good architecture will magically emerge. While an architecture will emerge, if there is not enough attention paid to it and the code, technical debt and design problems will creep in until it becomes muddy, making it hard to deliver new features quickly and reliably.
It is essential to have a sustainable architecture that can evolve through the project lifecycle. Sustainable architecture requires ongoing attention, especially when there are evolving priorities, a lot of technical risks, and many dependencies. This talk presents a set of patterns that focus on practices for creating and evolving a software architecture while being Agile. These practices include a set of tools that allow teams to define “enough” architecture at the beginning of the project and to manage the state and the evolution of the architecture as the project evolves.

Language defines the boundary to our world: it sets what we can describe and what we can’t. This talk describes how to formalize a ubiquitous language into a domain-specific language. The resulting language is used for communication and collaboration as well as used as a basis for generating code, tests, configs, etc. The talk is based on industry cases from various domains, such as banking and insurance, industry automation and automotive.

Target Audience: Developers, Subject Matter/Domain Experts, Managers
Prerequisites: Experiences on applying some modeling language
Level: Advanced

Extended Abstract:
Language defines the boundary to our world: it sets what we can describe and also what we can’t. This talk describes how to formalize a ubiquitous language into a domain-specific language. The resulting language is then used for communication and collaboration, and also as a basis for generating code, tests, configuration, etc. The talk is based on industry cases from various domains, such as banking, insurance, industrial automation and automotive. A particular emphasis in industry cases is how experts from different fields can apply the same language. We will describe language definition cases from practice and illustrate how the created languages have become the cornerstone of development activities.