Micro-Frontends eigenen sich nicht in allen Szenarien! Diese Session stellt einen alternativen Ansatz vor: Frontend-Modulithen. Wir besprechen das Abbilden fachlicher Domänen, die Kategorisierung von Bibliotheken sowie Zugriffseinschränkungen zum Erzwingen entkoppelter Teilsysteme. Außerdem nutzen wir inkrementelle Builds und einen Build Cache zur drastischen Beschleunigung des CI-Prozesses. Am Ende wissen Sie, ob Frontend-Modulithen für Sie der richtige Ansatz sind und wie Sie Ihre Anwendungen damit aufbauen.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlagenwissen zu JavaScript von Vorteil
Schwierigkeitsgrad: Fortgeschritten

Imagine you have an enterprise frontend monolith. Due to explosive growth, around 30 teams work on it, with about 100 different use cases. How do you keep this system scalable and consistent?
That's the question we faced inside Partner Home at Wayfair. I'm going to share our experience implementing a micro frontend architecture based on React to distribute shared concerns as long-lived applications. We used module federation, a new feature in Webpack 5.
I'll talk about the general architecture, plus an overview of our technical solution.

Target Audience: Architects, Developers
Prerequisites: English, Frontend Architecture, React
Level: Expert

Der CEO der Sustainable Digital Infrastructure Alliance (SDIA) Max Schulze referiert über die Inhalte und Notwendigkeit des Forschungsvorhabens “SoftAWERE”, das vom Umweltbundesamt finanziert durch das BMWi ins Leben gerufen wurde. Ziel des Vorhabens ist die Entwicklung von Kriterien und Messmethoden, um die Energieeffizienz von Software-Komponenten zu steigern und Entwickler*innen Werkzeuge an die Hand zu geben, mit denen sie nachhaltige Entscheidungen abseits von ökonomischen Parametern treffen können.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheidende
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

How will organizations keep agility alive after their initial agile transformation? The question of what happens if agile becomes daily business is even more intriguing in this post-pandemic COVID era. Will AGILE survive these unparalleled insecure times? Participants in this workshop will explore what is needed to sustainably ‘safeguard’ an enterprise agile delivery culture after the initial ‘agile transformation’. The workshop hosts will share their observations of working in a big financial organization and will invite participants to share theirs so that collectively, we can gain insight and define potential countermeasures.

Target Audience: Anyone interested in transformational agility challenges, e.g. Change Lead, Coach, BusArchitect
Prerequisites: None
Level: Advanced

Extended Abstract
Participants in this workshop will explore what is needed to move forward after the initial ‘agile transformation’, to sustainably ‘safeguard’ an enterprise agile delivery culture. The question of what happens if agile becomes daily business is even more intriguing in this post-pandemic COVID era. How will organizations keep agility alive after their initial agile transformation? When organizational systems come under too much pressure; how ‘VUCA’* resistant are our agile enterprise cultures?
Lieke Jansen and Eric Abelen are senior Agile Enterprise Coaches at ING in the Netherlands. They both contributed to ING's Spotify inspired, big-scale transformation towards an agile way of working, some seven years ago. As of then, they have successfully coached a wide variety of departments and organizations within ING to adopt and sustain an effective healthy agile delivery culture. Being key players of a massive enterprise agile transformation, they also observe some challenges related to upkeep of the resulting way of working. Because people come and go, and in our VUCA world business and process change is frequent. What options do we have in this reality of ongoing change to keep the ‘agile enterprise culture’ strong and resilient?
Also, in the Covid pandemic we learned that people and organizations can respond to change quickly, especially those organizations that adopted a culture of agility. But after a period of unparalleled social restrictions, how does this affect our agile corporate cultures? Has the trauma of the pandemic infected us with a renewed urge to feel ‘in control’ of the future and has this irrevocably injured our appetite for organic growth and agility?
In this workshop we will explore this interesting and urgent question together with you. We will share key observations from experience working with a wide variety of delivery and leadership teams and their related organizational structures. We hope that workshop participants are willing to add their observations and experiences to ours. In interactive dialogue sessions we hope to collectively engage in sense-making and to define basic anti-patterns and growth-paths.
( * VUCA = Volatility, Uncertainty, Complexity, Ambiguity)

Im Zeitalter der Smartphone-Apps sehen sich viele Entwickler:innen dem immer wieder gleichen Problem ausgesetzt: Wie synchronisiert man Daten zwischen den verschiedenen Clients? Vom Telefon, was zeitweilig offline sein kann, zum Tablet, was überhaupt nur im WLAN hängt, zur Weboberfläche. Auf keinen Fall darf man dem User Konflikte anzeigen, die verwirren nur! “Konfliktfreie verteilte Datentypen” sind die Lösung; eine recht junge Technologie, die verspricht, alle diese Probleme anzugehen

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Grundkenntnisse Web-Entwicklung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Im Zeitalter der Smartphone-Apps sehen sich viele Entwickler*innen dem immer wieder gleichen Problem ausgesetzt: Wie synchronisiert man Daten zwischen den verschiedenen Clients? Vom Telefon, was zeitweilig offline sein kann, zum Tablet, was überhaupt nur im WLAN hängt, zur Weboberfläche. Auf keinen Fall darf man dem User Konflikte anzeigen, die verwirren nur! Und das alles bitte auch mit Historie und effizient, um Bandbreite zu sparen. Können wir das schaffen? “Konfliktfreie verteilte Datentypen” sind die Lösung; eine recht junge Technologie, die verspricht, alle diese Probleme anzugehen. Dieser Vortrag soll ein Rundgang durch die Forschung & Praxis geben und die (wenigen) Haken aufzeigen.

While Rust is typically pitched as systems programming language, it is equally adept at application development thanks to its high level features and great tooling. In addition to increased performance, native code has the advantage that it can easily be reused across different system components, an advantage even more pronounced in polyglot environments. In this talk, we would like to present our experience of using Rust to write core components in such a polyglot system.

Target Audience: Architects, Developers
Prerequisites: Basic knowledge of Python, Java
Level: Advanced

Extended Abstract
While Rust is typically pitched as systems programming language, it is equally adept at application development thanks to its high level features and great tooling. In addition to increased performance, native code has the advantage that it can easily be reused across different system components, an advantage even more pronounced in polyglot environments.
In this talk, we would like to present our experience of using Rust to write core components in such a polyglot system. The systems spans different contexts, from client to cloud, and different programming languages, from Python to Java, respectively. We will showcase how the Rust language itself and its tooling simplified this task and discuss different integration patterns.

Die Vergabe von Softwareprojekten und Umsetzung durch Dritte ist ein übliches Verfahren im Umfeld der öffentlichen Hand. Es handelt sich dabei oft um Projekte mit langer Lebenszeit, für die zwar hohe Anforderungen an Wartbarkeit bestehen, aber oft nicht erfüllt werden. Der Vortrag beschreibt Erfahrungen des ITZBund beim Aufbau entsprechender Qualitätssicherungsmaßnahmen. Es werden Möglichkeiten und Grenzen von Coding-Standards sowie Architektur-Vorgaben, deren automatisierte Überprüfung und das Zusammenspiel mit Auftragnehmern beleuchtet.

Zielpublikum: Architekt:innen, QA-Verantwortliche, Entscheider
Voraussetzungen: Software-Architektur, Softwarequalität, Projekterfahrung
Schwierigkeitsgrad: Experte

Was, wenn der Prozess, in den man sich verliebt hat, nicht zur Organisation passt? Unternehmen umbauen? Prozess zurechtbiegen? Vernunftehe führen? Unreflektierte Nutzung des “bildhübschen Scrum” führt oft zu Kündigungswellen, Unzufriedenheit und Burn-out, ohne die erhoffte Glückseligkeit. Muss das so sein?
Scrum ist manchmal die “passende Lösung” – aber kaum jemand beschreibt die Bedingungen dazu und es gibt wenig Aussagen darüber, wie man handeln könnte, wenn die Bedingungen nicht passen. Deswegen versuchen wir das mal.

Zielpublikum: Menschen, die nach einem Weg aus ihrer Scrum-Hölle suchen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Was tun, wenn der Prozess, in den man sich verliebt hat, weder zur Ablauf- noch zur Aufbauorganisation passt? Das Unternehmen umbauen? Den Prozess zurechtbiegen? Doch eine Vernunftehe führen?
Eine unreflektierte Nutzung des “bildhübschen Scrum” führt in immer mehr Unternehmen zu Kündigungswellen, Unzufriedenheit, unwesentlich besserer Produktivität und teilweise sogar zu Burn-outs, nur leider ohne die erhoffte Glückseligkeit.
Aber muss das so sein? Wir meinen: Das muss nicht so sein und das sollte nicht so sein.
Scrum ist nur unter bestimmten Bedingungen “die passende Lösung” – aber kaum jemand beschreibt heute noch diese Bedingungen und vor allem gibt es wenig Aussagen darüber, wie man denn handeln könnte, wenn die Bedingungen nicht passen.
Wir betrachten noch mal die Grundlagenarbeit zu Scrum und beschreiben, was die aus unserer Sicht wichtigsten der Rahmenbedingungen, für die Scrum entworfen wurde, sind.
Und wir stellen vor, für welche der fehlenden Vorbedingungen es gute alternative Ansätze gibt und zeigen, wie einige davon genutzt werden könnten.

Software is often resistant to modernization efforts, no matter if it's about phasing out obsolete technologies, migration to the cloud, or establishing modern architecture. The culprit is usually a dependency or obsolete assumption that's too closely coupled to the codebase. But what's the underlying root cause of all that coupling? Often, it's shared, mutable, synchronous state. We will look at a real-world project, and we'll dig ourselves out of the hole it's dug itself into using refactoring, event sourcing, and functional programming.

Target Audience: Architects, Developers
Prerequisites: Some programming
Level: Basic

Extended Abstract:
As shared mutable state is the core paradigm of object-oriented programming, it tends to be ubiquitous in OO projects. How to avoid it then? The example has followed a familiar path: Convenient tooling allowed the project to get off the ground fast, but tied it to its underlying technologies. By the time support for those technologies has expired, coupling has gotten so strong that huge resources are expended on keeping things going "just one more day". If you've seen projects like this hit a wall, this talk is for you.

arc42 ist gerade in Version 8 erschienen - Zeit für eine Übersicht der Neuerungen „am lebenden System“: Primär geht's um die Lösungsstrategie, Querschnittskonzepte und Architecture Decision Records. Zusätzlich gibt's die acht wichtigsten Praxistipps für bessere Architekturdokumentation. Insbesondere das Thema "Nachdokumentation" greife ich auf - mit anschaulichen Praxisbeispielen. Schließlich zeige ich Ihnen die Möglichkeiten der "Hilfe zur Selbsthilfe" der neuen arc42 Doku-Website.

Zielpublikum: Architekt:innen, Entwickler:innen, alle, die mit technischer Dokumentation zu tun haben
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Das (open-source) arc42-Template, erstmalig erschienen 2005, ist zu einem in vielen Branchen und Organisationen etablierten Hilfsmittel für die Kommunikation und Dokumentation von Software-Architekturen geworden. Passend zu frischen "V8" von arc42 bekommen Sie in diesem Vortrag die aktuellen Änderungen „am lebenden System“ erläutert.
Parallel dazu gebe ich Ihnen die 8 wichtigsten Tipps für pragmatische und zeitgemäße Architekturdokumentation - konkret und praxisnah. Diese Tipps beziehen sich unter anderem auf Lösungsstrategie, Qualitätsanforderungen, Querschnittskonzepte sowie Architektur-Entscheidungen.
Insbesondere erkläre ich Ihnen ein paar geschickte Möglichkeiten der Nachdokumentation - Wie Sie von Null auf eine angemessene Doku kommen, ohne einen lästigen Doku-Sprint einlegen zu müssen.
Und schließlich erleben Sie live die Möglichkeiten der "Hilfe zur Selbsthilfe": Bei den über 300 Tipps, Ratschlägen und FAQs sollte auch für Ihr System etwas zu finden sein.
Zielgruppe: Alle IT'ler, die bereits unter schlechter Architekturdokumentation gelitten haben und/oder Vorsätze für bessere Dokumentation gefasst haben.
## Lessons learned vom Vortrag
* arc42 Version 8: Was ist neu, warum eine neue Version, wie kann ich migrieren
* Wie ich ein bestehendes System effektiv und mit überschaubarem Aufwand dokumentieren kann
* Wie die Teile von arc42 inhaltlich zusammenhängen, und was mir das an Synergien bringt.

Softwareplattformen bieten eine Reihe attraktiver Vorteile: Mit ihnen können neue Produkte nicht nur schneller und kostengünstiger entwickelt, sondern auch neue Einnahmequellen erschlossen werden. Dazu ist es aber notwendig, sie nicht nur richtig zu entwickeln, sondern auch effektiv zu managen. In unserem Vortrag stellen wir Techniken vor, um Plattformen dauerhaft erfolgreich zu nutzen. Dies beinhaltet, eine Plattform als eigenständige Produkt zu managen, einen dedizierten Platform Owner zu benennen und ein Nutzer-zentriertes Mindset zu etablieren.

Zielpublikum: Product Owners, Produktmanager, Architekten:innen, Entscheider (Head of Product, Head of Development)
Voraussetzungen: Kenntnisse agiler Methoden
Schwierigkeitsgrad: Fortgeschritten

Machine Learning-Diskussionen drehen sich oft um Datenbeschaffung, geeignete Werkzeuge und Modelle. Und natürlich um beeindruckende Anwendungen von Spotify, Tesla und Co. Doch wie entstehen ML-Lösungen? Oft scheint Genialität und Zufall bestimmend, doch in dieser Session zeige ich, was wirklich hinter erfolgreichen ML-Vorhaben steckt und wie man erfolgreich professionalisiert. Mit den Überschriften der Architektur-Disziplin sortiere ich die Herausforderungen von ML-Vorhaben und zeige, wie man mit ML nicht nur experimentiert, sondern arbeitet.

Zielpublikum: Entwickler:innen, Architekte:innen, ML-Interessierte, Management
Voraussetzungen: Erfahrung in der Entwicklung von Systemen
Schwierigkeitsgrad: Anfänger

Extended Abstract
Machine Learning-Diskussionen drehen sich oft um Datenbeschaffung, geeignete Werkzeuge und gut verallgemeinernde Modelle. Und natürlich um die beeindruckenden Anwendungen, die Spotify, Facebook, Tesla und andere Firmen bauen. Doch wie entstehen ML-Lösungen eigentlich? Oft scheint Genialität und Zufall bestimmend, doch in dieser Session werfen wir einen Blick darauf, was wirklich hinter erfolgreichen ML-Vorhaben steckt und was es zu bedenken gibt, wenn man Machine Learning professionalisieren möchte.
Mit der Architektur-Brille durchleuchte ich die Gemeinsamkeiten und Unterschiede zu klassischen Softwareprojekten und arbeite neun wichtige Architektur-Themen im Machine Learning-Bereich heraus. Dabei geht es um Entscheidungen zum Technologiestack, aber auch um Zielumgebungen, bzw. den Weg dort hin, methodische und organisatorische Aspekte sowie die Integration von ML-Lösungen in eine Systemlandschaft.
Die Teilnehmer lernen nicht nur fundierte über eigene Vorhaben nachzudenken, sondern sehen auch die neuen Herausforderungen, die Machine Learning mit sich bringt. Abgerundet wird die Session durch einen groben ML-Prozess, der diese Herausforderungen gut aufgreift.

The purpose of Serverless is to focus on writing the code that delivers business value and offload undifferentiated heavy lifting to the Cloud providers or SaaS vendors. Today’s code quickly becomes tomorrow’s technical debt. The less you own, the better it is from the maintainability point of view. In this talk I will go through examples of the various Serverless architectures on AWS where you glue together different Serverless managed services, significantly reducing the amount of the code written to perform the task. Own less, build more!

Target Audience: Developers, Architects, Decision Makers
Prerequisites: Basic understanding of AWS Serverless Services
Level: Advanced 

Der Modularity Maturity Index (MMI) bewertet die Langlebigkeit von Architekturen aus drei verschiedenen Perspektiven: Modularität, Hierarchisierung und Muster. Man kann den MMI sowohl zur initialen Standortbestimmung einsetzen, also um festzustellen, ob das eigene Softwaresystem eine langlebige Architektur hat bzw. wie weit es davon entfernt ist. Außerdem kann man den MMI verwenden, um seine Software-Entwicklung über den gesamten Lebenszyklus der verschiedenen Systeme regelmäßig auf ihre Langlebigkeit hin zu überprüfen.

Zielpublikum: Software-Architekt:innen, Softwareentwickler:innen, Projektleiter:innen, Manager:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Ich stelle sowohl den von uns gewählten Prozess der Architektur-Bewertung als auch die Prüfkriterien vor und erläutere die typischerweise getroffenen Maßnahmen und Konsequenzen. Mein Ziel ist, dass andere Architekt:innen in die Lage kommen, solche Analysen selbst durchzuführen.

In a world of rapid changes and increasing uncertainties, organizations have to continuously adapt and evolve to remain competitive and excel in the market. In such a dynamic business landscape organizations need to design for adaptability. Designing for adaptability requires understanding the landscape organizations are operating in, identifying patterns of change, applying principles for organizational fitness, and making mindful strategic decisions to adapt change.

Target Audience: Software Architects, Tech Leads, Engineering Manager, VP of Engineering
Level: Basic

Extended Abstract
Organizations need to aim for building systems and team organizations aligned to the business needs and business strategy and evolving them for adaptability to new changes and unknown environments.
This talk brings different perspectives and techniques together from business strategy (Wardley Mapping), software architecture (Domain-Driven Design), and team organization (Team Topologies) as a powerful toolset to design, build and evolve adaptive systems and team structures for a fast flow of change.

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, Manager, Entscheider
Voraussetzungen: Kenntnisse Microservices
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract

Nur wenn die Auftrennung der Fachlichkeit in verschiedenen Microservices auch konsequent bis hin zur Ebene der Datenhaltung vollzogen wird, kann die angestrebte Unabhängigkeit der Services zur Entwicklungs- und Laufzeit erreicht werden. Ohne diesen Schritt dagegen würde sich das Problem der starren Kopplung und der damit einhergehenden Abhängigkeiten einer monolithischen Architektur lediglich um eine Schicht nach unten, in die Datenbank, verlagern. Was aber bedeutet das konsequente Einhalten des Database-per-Service-Patterns und einer damit einhergehenden Verteilung der Datenhaltung in der Praxis? Die Session zeigt die wesentlichen Herausforderungen auf und liefert passende Lösungsansätze.

On-Call is an increasing reality for developers, especially when a site has strict uptime requirements. And sadly, the experience often sucks. It's easy to mandate 24x7 support, it's much harder to set it up in a way that doesn't make the life of the people in the rotation miserable.
I want to talk about improving alerting. I'm focusing on creating high-quality alerts that trigger when they should and don't trigger when nothing is happening. Continuous tuning, automation, and using the right metrics are core parts of this process.

Target Audience: Developers, Architects, DevOps, Operators
Prerequisites: Monitoring, operating production software
Level: Advanced

Extended Abstract
Do you believe in “you build it, you run it”? What if you have on-call rotations, where you are responsible 24x7 for the health of a system? Nothing is quite so infuriating as a collection of poorly structured alerts that trigger randomly.
So, let’s do better! I want to talk about how to improve your monitoring capabilities. There are a few topics I want to touch:

• Reduce the noise
• Automate as much as possible
• Build actionable triggers
• Tune your monitoring constantly

After this talk, you’ll have concrete actions to make your engineers’ life easier when on-call.

krankheitsbedingt ein kurzfristiger Wechsel

Content Management Systeme, Web-Browser oder Betriebssystem: Viele der Produkte und Services die wir täglich nutzen werden mittlerweile als Open Source Projekte realisiert. Durch den hohen Einfluss, den die Open Source Entwicklung mittlerweile auf die digitale Welt hat, findet man allerdings auch viele unterschiedliche Aussagen über dieGefahren und Vorteile von Open Source Produkten. Vor allem wenn man sich selber noch nicht intensiv mit der Thematik auseinander setzen konnte ist es hierdurch schwer, fachlich korrekte Bewertungen zu Open Source Produkten treffen zu können.

Basierend auf der Mitarbeit an verschiedenen großen Projekten in der Eclipse Foundation und des Java Ökosystems werde ich in diesem Vortrag nicht nur die theoretische Definition von Open Source vorstellen, sondern auch zeigen, wie Open Source Projekte in der Praxis entstehen und weiterentwickelt werden. Wir werden uns auch anschauen, warumOrganisationen Software als Open Source veröffentlichen und welche neuen und interessanten Geschäftsmodelle sich hierbei ergeben. Hierbei werden auch die Themen wie Lizenzen, Security und Support von Open Source Produkten angesprochen, welche durch Beispiele wie OpenSSL und den 2014 veröffentlichten Heartbleed-Bug konkretisiert werden.

Das im Vortrag vermittelte Wissen soll helfen, Open Source Software besser verstehen und einschätzen zu können. Mit diesem Fachwissen können die verschiedenen Gefahren und Vorteile, die durch die Nutzung von Open Source Komponenten entstehen, in Zukunft besser beurteilt werden.

The idea of looking at your organization as a single coherent system is tempting, but is it realistic? If it isn't, what does that mean for software developers, and how can we make discoverable what we are developing? This talk looks at organizations as ecosystems rather than as systems, and asks what that difference means for software development. It all boils down to focusing on software as components implementing business capabilities, and how to best capture these capabilities and make them findable and useful as reusable components.

Target Audience: Developers, Architects, Project Leaders, API Strategists
Prerequisites: API Basics, Large-scale information systems
Level: Advanced

Oft wird Software immer schlechter wartbar, je länger Entwicklungsteams an ihr arbeiten. Dazu hat sich die Metapher “technische Schulden” etabliert. Aber es ist nicht immer sinnvoll, technische Schulden zu beseitigen und sie können auch “einfach so” entstehen. Darum geht es in diesem Vortrag - und über die Grundlagen der Metapher, wie sie bei der Kommunikation mit Managern hilft, warum die Metapher eigentlich nicht besonders gut gewählt ist und natürlich wie man mit technischen Schulden sinnvoll umgehen kann.

Zielpublikum: Technische Projektleiter:innen, Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlegendes Verständnis über Softwareentwickung
Schwierigkeitsgrad: Anfänger

Some codebases are nicer to work with than others. This is true for applications, services, libraries, frameworks, even programming languages themselves. Is this a purely personal choice or are there universal characteristics of software that can make code a joy to work with? Daniel has been thinking about this for a long time, especially since he poked a stick at the SOLID principles for fun a few years ago and people came after him with pitchforks.

Extended Abstract
His recent post about why he feels SOLID is outdated ended up on the front page of Hacker News! Now he has codified his thoughts into his own pithy five-letter acronym, CUPID: Composable, Unix philosophy, Predictable, Idiomatic, Domain-based. Why these characteristics, what do they mean, and why should you care? Can they improve your coding experience or is this just more programmer navel-gazing?

In den letzten 30 Jahren habe ich viel Software selbst oder mit Teams entwickelt und viele Softwaresysteme analysiert, um die darin angesammelten technischen Schulden zu analysieren und Lösungen zu erarbeiten. Dabei bin ich immer wieder ähnlichen Missverständnissen rund um das Thema Software-Architektur begegnet. Dieser Vortrag wird klären, welche Missverständnisse das sind und warum sie anders gedacht werden müssen, damit wir mit unseren Software-Architekturen kleine und große Probleme lösen können.

Zielpublikum: Software-Architekt:innen, Softwareentwickler:innen, Projektleiter:innen, Manager:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract

Als Missverständnisse werde ich ansprechen:

1) Microservices bilden eine SOA

2) Überall Events

3) Jedes Team wie es will

4) Wiederverwendung

5) Gegen Zyklen helfen Interfaces

6) Sourcecode = Dokumentation

7) Neubau ist besser als Refactoring

Dabei erkläre ich das Missverständnis und biete jeweils eine oder mehrere entgegengesetzte Sichtweisen an. Beispiele benutze ich, um die Argumentation zu verdeutlichen, und schließlich gebe ich jeweils meine Empfehlung dazu.

Im Web lauert eine Vielzahl von Sicherheitsgefahren. Deshalb sollten ein paar grundlegende Vorkehrungen getroffen werden: Angefangen bei der richtigen TLS-Konfiguration, über Schutzmaßnahmen wie dem Einrichten einer Content-Security-Policy und dem Überprüfen nachgeladener Ressourcen mittels Subresource Integrity, bis hin zur Absicherung von Cookies sowie dem Schicken oder Vermeiden bestimmter HTTP-Header. Welche grundlegenden Maßnahmen es zu beachten gilt und wie man diese umsetzt, erfahren Sie in diesem Vortrag.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Basiskenntnisse Web-Entwicklung
Schwierigkeitsgrad: Anfänger

Architektonische Konzepte in Code abzubilden, bleibt in Java-Applikationen meist eine Herausforderung, ebenso wie die Trennung von fachlichem Code und Applikationsframework. Der Vortrag gibt einen Überblick über das jMolecules API und zeigt, wie Entwickler:innen die bereitgestellten Abstraktionen nutzen können, um Architektur-Konzepte auszudrücken. Darüber hinaus wird konkrete Integration mit Technologien sowie die Generierung von Dokumentation am praktischen Beispiel beschrieben.

Zielpublikum: Software-Architekt:innen, Seniorentwickler:innen
Voraussetzungen: Grundlegende Java- und Software-Architekturkenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Java-Applikationen basieren gewöhnlicherweise auf einem Framework oder einer Entwicklungsplattform. Einige davon erlauben es, einige architektonische Konzepte auszudrücken. Diese jedoch direkt in Code abzubilden, bleibt meist eine Herausforderung, ebenso wie die Trennung von fachlichem Code und Applikationsframework.
jMolecules ist eine Framework-unabhängige Bibliothek, die es erlaubt, verbreitete, architektonische Konzepte direkt in Code abzubilden, zu überprüfen, ob Regeln bezüglich der Implementierung dieser Konzepte eingehalten werden, und sowohl die nötige technische Integration als auch entsprechende Dokumentation daraus abzuleiten.
Der Vortrag gibt einen Überblick über den grundsätzlich Ansatz und zeigt, wie Entwickler:innen die bereitgestellten Abstraktionen nutzen können. Darüber hinaus wird konkrete Integration mit Spring, Jackson und JPA sowie die Generierung von Dokumentation am praktischen Beispiel gezeigt.
 

In this talk, we will give an overview about all the different aspects that affect climate change from the software engineering perspective and discuss a number of concrete actions that every software engineer can take (and should keep in mind day-in day-out) to help fight climate change. During the talk, we will not only provide an overview of the landscape, but also cover topics in more depth and discuss the challenges that come with them.

Target Audience: Architects, Developers, Project Leads
Prerequisites: None
Level: Advanced

Extended Abstract
In this talk, we will give an overview about all the different aspects that affect climate change from the software engineering perspective and discuss a number of concrete actions that every software engineer can take (and should keep in mind day-in day-out) to help fight climate change, including:

• Energy consumption of software and what that means for software engineering
• Research studies about software running in data centers and the problem of zombies
• Work towards operating software in a carbon-aware way
• When and how far do renewable energies help
• How does carbon offsetting works and how to select the right projects
• And more...

In 2020, the three big cloud providers signed us all up for a revolution in the way we write and operate software. The deadline is 2030. Are you ready?

Target Audience: General techie. This works for all
Prerequisites: None
Level: Advanced

Extended Abstract
In 2020, Google Cloud, AWS, and Azure all committed to be carbon zero by 2030. It's the incredibly tough goal of zero emitted carbon as a result for operating our applications and services. They can't do it alone. AWS says "we optimize for sustainability of the cloud, while customers are responsible for sustainability in the cloud, meaning they must optimize their workloads and resource utilization." I don't think this is a request. They've signed up to be carbon zero by 2030. That means we have too. The clock is ticking.

Um nachhaltig erfolgreich zu sein, müssen Unternehmen schnell, robust und anpassungsfähig auf die steigende Dynamik im Markt reagieren.
Doch wie entsteht Dynamikrobustheit in Unternehmen und was bedeutet das für die Organisationsstrukturen und IT-Architektur?
In unserem Workshop möchten wir unsere Erfahrung aus der Begleitung zweier Großkonzerne mit euch teilen und anhand von praktischen Beispielen Konzepte von Conways Gesetz über den Tech-Radar bis hin zu Team-Topologien beleuchten. Dazwischen ist genug Zeit für Praxisfragen und Diskussion.

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

Extended Abstract
Schnell, robust und anpassungsfähig auf die ständig steigenden Marktanforderungen reagieren zu können - das ist das Ziel vieler Unternehmen. Während die meisten noch versuchen, mit agilen Prozessmethoden der wachsenden Dynamik und Komplexität Herr zu werden, setzen erfolgreiche Unternehmen auf weitgehend resilient organisierte Strukturen. Aber wie geht das?
Mit Scalamento begleiten wir seit 2016 verschiedene Unternehmen bei der Anpassung ihrer Organisations- und IT-Strukturen an ein komplexes Umfeld. In unserem Workshop teilen wir unsere Erfahrung, wie Dynamikrobustheit in Unternehmen entsteht und was das für Teamstrukturen und die IT-Architektur bedeutet. Was sind Erfolgsfaktoren für cross-funktionale Teams? Wie finde ich heraus, welche Kollaborations-Form und Software-Architektur sich für meine Herausforderungen eignet?
Am Beispiel zweier Großkonzerne berichten wir vom Umbau der Organisations- und IT-Strukturen in hierarchischen Organisationen. Gemeinsam mit den Teilnehmenden diskutieren wir dabei den Mehrwert von Konzepten wie Conway’s Law, dem Tech-Radar und Team-Topologien. Dazwischen ist genug Zeit für Praxisfragen und Anwendungsbeispiele der Teilnehmenden.

Jedes interessante Softwaresystem hat eine Architektur. Diese ist kunstvoll geplant oder zufällig entstanden, meist aber irgendwas dazwischen. In diesem Vortrag stelle ich vor, wann und vor allem wie Sie und Ihr Team Ihre Lösungsansätze reflektieren können.
Architekturbewertungen sichern Entscheidungen ab, zeigen Risiken auf und schaffen Transparenz. Richtig gemacht stellen sie ein exzellentes Kommunikationsmittel dar – und keinesfalls einen Pranger.
In Umfeld der Architektur-Reviews gibt es ein reiches Arsenal an Methoden und Werkzeugen. Sie reichen von qualitativen Ansätzen wie ATAM bis zum Auswerten von Metriken oder dem Messen von Antwortzeiten, Durchsatz oder ähnlichem.
Hier gebe ich Orientierung, ordne ein und zeige auf, was wo und wann welchen Nutzen stiftet. Was argumentative, Workshop-basierte Verfahren leisten thematisiere ich dabei ebenso wie welche Aspekte Eurer Architekturziele sich mit Messungen verknüpfen lassen.

Zielpublikum: Vor allem Menschen, die Architekturentscheidungen treffen und/oder verantworten. Insbesondere im Team. Entscheider können problemlos folgen.
Voraussetzungen: Erfahrung in Software-Entwicklungsvorhaben sind von Vorteil
Schwierigkeitsgrad: Anfänger

Auch Legacy-Systeme kann man mit Domain-driven Design (DDD) verbessern. Am Anfang sollte die Frage stehen, warum ein erfolgreiches Legacy-System überhaupt verbessert werden soll. Der Vortrag zeigt, wie man sich dazu an Änderungen des Geschäftsmodells orientieren kann. Technische Ansätze wie das Extrahieren von Bounded Contexts oder die Implementierung von Bubble Bounded Contexts verdeutlichen zudem, wie man ganz praktisch vorgehen kann. So kann DDD auch bei der Anpassung existierender Systeme an sich ständig ändernde Anforderungen helfen.

Zielpublikum: Technische Projektleiter:innen, Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlegendes Verständnis über Softwareentwickung
Schwierigkeitsgrad: Anfänger

In den letzten Jahren erfahren IT-Landschaften durch Digitalisierung einen großen Änderungsdruck. Für ältere IT-Landschaften bedeutet dies eine komplette strategische Neuausrichtung. In diesem Beitrag schlagen wir mit Domain Driven Transformation eine Methodik vor, in der DDD mit Methoden des EAMs (Enterprise Architecture Management) kombiniert wird. Im Kern liegt die Definition von Bounded Contexts und einer Context Map, die mit der IST-IT-Landschaft abgeglichen werden kann. Aus dem Abgleich entstehen Handlungsfelder, die priorisiert und in eine Roadmap aufgenommen werden.

Zielpublikum: IT-Architekt:innen, IT-Manager und Projektleiter:innen
Voraussetzungen: Grundsätzliches Verständnis von DDD und EAMs
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
In den letzten Jahren erfahren die IT-Landschaften von Unternehmen einen immer größeren Druck auf notwendige Veränderungen. Dies hat mehrere Gründe:
- Die Cloud verspricht viele Vorteile, aber die vorhandenen, veralteten Technologien verhindern eine Nutzung
- Die Digitalisierung des Business von Firmen führt zu einem Bedarf an schnellen und größeren Änderungen sowie Erweiterungen in der IT-Landschaft
- The 'war of talents' verlangt nach der Nutzung von modernen Technologien, um Talente im Unternehmen zu halten oder einstellen zu können
Für ältere IT-Landschaften bedeutet dies häufig eine komplette strategische Neuausrichtung mit dem Fokus, eine Zielarchitektur zu definieren und einen Plan für die Transformation der IT-Landschaft aufzustellen. Damit die Vorteile der modernen Technologien und Organisation (Cloud-Technologie, DevOps) schnell genutzt werden können, müssen Handlungsfelder priorisiert werden und die Umbauschritte mit dem Projektportfolio und dem EAM verzahnt werden. Ziel des Planungsprojekts ist die Definition einer Zielarchitektur, eine allgemeine Vorgehensweise sowie eine Roadmap, mit deren Hilfe die IT-Landschaft schrittweise in den nächsten Jahren umgebaut werden kann. Und dabei sollen möglichst schnell Benefits hinsichtlich der anfangs genannten Punkte erreicht werden.
In diesem Beitrag werden zunächst die Ausgangslage und die Ziele eines Planungsprojekts erläutert. Dazu schlagen wir eine an die DDD angelegte Methodik vor: Domain Driven Transformation, eine Methodik, in der DDD mit Methoden des EAMs und Projektmanagements kombiniert werden. Im Kern liegt die Definition von Bounded Contexts und einer Context Map, die zum Bedarf des Business passt und mit der derzeitigen IT-Landschaft abgeglichen werden kann. Aus dem Abgleich entstehen Handlungsfelder, die priorisiert und in eine Roadmap aufgenommen werden. Um überhaupt zu einem guten Aufsatzpunkt für DDD zu kommen, muss der Soll-Bedarf des Business definiert werden. Dazu werden capability maps, Prozesslandkarten und Business-Strategien analysiert und damit die gesamte zu betrachtende fachliche Welt aufgespannt. In diesem aufgespannten Feld dienen zunächst Orientierungsszenarien mit Hilfe von Domain Stories dazu, die fachliche Welt näher zu definieren.
In einem spiralförmigen Prozess aus business capabilities, Prozesslandkarte und Domain Stories wird das Feld tiefer erschlossen und Subdomänen werden erkannt. Die daraus definierten Bounded Contexts werden zusammen mit Make-or-buy-Entscheidungen zu einer Zielarchitektur zusammengefasst und mit der IT-Landschaft abgeglichen. Die Handlungsfelder umfassen Redesign-Vorhaben von Applikationen, Modernisierungen, Entrümpelung von nicht mehr benötigten System(teil)en sowie Abschaltung und Einführung von Kaufsoftware zusammen mit der notwendigen Integration.
Der Umbau der IT-Landschaft ist ein über mehrere Jahre andauernder Prozess, der im Sinne einer gesteuerten Evolution immer wieder vom Business-Bedarf über die Zielarchitektur bis zur Priorisierung angepasst werden muss. Die Dokumentation und das Handwerkszeug aus dem obigen Vorgehen eignen sich gut, die Zielarchitektur und die Priorisierungen auf dem Weg der Transformation anzupassen.

Klassisches EAM ist gut verstanden und hat in sich nur langsam oder voraussehbar verändernden Umgebungen erhebliche Verbesserungen bewirkt. Aufgrund steigender Komplexität und Dynamik nimmt die Verbreitung Agiler Methoden immer weiter zu. Außerdem werden im Zuge der digitalen Transformation Veränderungen auf der Business-Seite zunehmend zum wesentlichen Treiber strategischer Veränderungen in der IT. Darauf muss sich die IT insgesamt und die Unternehmens-Architektur im Besonderen mit ganz neuen Vorgehensweisen einstellen.

Zielpublikum: Unternehmensarchitekt:innen, IT-Manager, Architekt:innen, Projektleiter:innen, Change-Manager
Voraussetzungen: Grundkenntnisse EAM, Agile Methoden, Projekterfahrungen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Klassisches EAM ist gut verstanden und hat in sich nur langsam oder voraussehbar verändernden Umgebungen erhebliche Verbesserungen in der IT von Unternehmen bewirkt. Aufgrund steigender Komplexität und Dynamik nimmt die Verbreitung Agiler Methoden immer weiter zu. In der Folge sind Ansätze einer "Agilen Unternehmens-Architektur" in ersten Ansätzen erkennbar. In Zukunft wird in heterogenen Unternehmen allerdings die Herausforderung bestehen, dass innerhalb eines Unternehmens Organisationsbereiche mit ganz unterschiedlichen Umfeldern und Kulturen (tayloristisch, synergistisch und chaordisch) parallel zueinander existieren. Außerdem werden im Zuge der digitalen Transformation Veränderungen auf der Business-Seite zunehmend zum wesentlichen Treiber strategischer Veränderungen in der IT. Darauf muss sich die IT insgesamt und die Unternehmens-Architektur im Besonderen mit ganz neuen Vorgehensweisen einstellen. Klassische, auf die IT-beschränkte "Agile Transformationen" greifen dabei zu kurz.

Neue Ansätze, neue Technologien lösen Probleme – ja, nein, vielleicht?
Hinter den Neuigkeiten stecken oft alte Bekannte. Probleme, die wir lange kennen, sind selten ganz weg - aber immerhin gewandelt, geändert, besser beherrschbar. Neue Lösungen ändern die alten Probleme. Nur, mit steigendem Alter werden sie selbst zum Teil eines neuen Problems?
Das ist das Spannungsfeld für Architekten, die Systeme bauen, die lange leben sollen. Ihre Aufgabe ist nicht nur technologisch; sie sollen auch in alle Richtungen Vertrauen ausstrahlen, dass das Projekt und die Organisation auf dem richtigen Weg sind. Dazu gehört auch, die richtigen Probleme zu kennen und die richtigen Lösungen zu wählen.
Machen Sie mit: in dieser interaktiven Session reden wir darüber. Wir betrachten das Neue und das Mitgenommene, die Lösungen und die Nebenwirkungen, die Stakeholder und ihre Prioritäten.

Zielpublikum: Architekt:innen, und die mit ihnen arbeiten
Voraussetzungen: Rollenerfahrung
Schwierigkeitsgrad: Fortgeschritten

Autonome Teams sind etwas, das häufig als Fundament agiler Organisationen gesehen wird.
Der Vortrag beschäftigt sich mit Teamautonomie aus Perspektive von Organisationen und Software-Entwicklung entlang folgender Fragen:

• Was bedeutet Autonomie in einer Organisation?
• Kann es autonome Teams eigentlich geben?
• Warum passiert es, dass Teams nicht autonom sind?
• Warum ist die Illusion von Autonomie oft wertvoller als faktische Autonomie?
• Und warum ist die Abwesenheit von Autonomie wertvoll?

Zielpublikum: Architekt:innen, Projektleiter:innen, Manager, Entscheider, Scrum Master, Agile Coaches
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Der Vortrag bezieht sich auf moderne und uralte Erkenntnisse aus der Soziologie und Organisationstheorie.
Es wird gezeigt, warum mehr Autonomie in Organisationen zu mehr Kommunikation führen muss und damit eine paradoxe Situation entsteht:
Zumeist wird die Autonomie gefordert, weil es ein "Zu viel" an Kommunikation zu geben scheint. Die naive Lösung ist dann: Entkopplung, sowohl der Architektur als auch der Organisation.
Das klappt leider nicht, weil Autonomie etwas erfordert, das in der Organisationssoziologie "Entscheidungsprämissen" genannt wird. Grundsätze, anhand derer Entscheidungen "im Prinzip" getroffen werden.
Die sind notwendigerweise unspezifischer als konkrete Entscheidungen und benötigen genau deshalb häufig mehr Abstimmung im Vorfeld - und mehr Diskussion in ihrer Anwendung.
Im Vortrag erkläre ich diese Paradoxie und zeige, wie sie in Organisationen, die Software entwickeln, genauso passiert wie in der Architektur der entstandenen Software. Witzigerweise hat Conway nämlich sogar in diesem Fall recht.

Dokumentation hilft, Ideen zu kommunizieren und uns auch noch nach Wochen an Lösungskonzepte zu erinnern. Trotzdem wird sie häufig stiefmütterlich behandelt und wir treffen viel häufiger auf tolle Architekturen als auf tolle Architekturdokumentationen. In diesem Vortrag berichten wir von unseren Erfahrungen rund um Architekturdokumentation. Wir fassen 7 Anti-Patterns zusammen und geben Tipps, wie jede:r die Architekturdokumentation verbessern kann. Unsere Tipps sind unabhängig vom verwendeten Vorgehen und kombinierbar mit Templates wie arc42.

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

Extended Abstract
Zugegeben, kaum jemand fällt beim Thema Architektur-Dokumentation vor Begeisterung vom Stuhl, aber spätestens bei mittelgroßen Systemen geht es nicht mehr ohne. Jede:r kennt die Fragen: „Wie hatten wir uns da entschieden?“ oder „Warum wollten wir das so machen?“ Dokumentation hilft uns, Software-Architektur präziser zu machen, Ideen zu kommunizieren und uns auch noch nach Wochen an Lösungskonzepte zu erinnern.
Aber obwohl Architekturdokumentation eine so wichtige Rolle im Entwicklungsprozess einnimmt, wird sie ganz häufig eher stiefmütterlich behandelt. In unseren Projekten treffen wir viel häufiger auf tolle Architekturen als auf tolle Architekturdokumentationen. Dabei begegnen uns immer wieder die gleichen Defizite: Überbetonung von technischen Aspekten, keine oder nur unkonkrete Darstellung von Qualitätsattributen oder Vermischung von Lauf- und Entwicklungszeitaspekten sind nur einige Beispiele.
In diesem Vortrag berichten wir von unseren Erfahrungen rund um Architektur-Dokumentation von unterschiedlichsten Systemen und Branchen. Wir fassen 7 Anti-Patterns zusammen und geben Tipps wie jede:r durch einfache Mittel die Architektur-Dokumentation verbessern kann. Unsere Tipps sind unabhängig vom verwendeten Vorgehen und natürlich auch kombinierbar mit Templates wie arc42.

Der Beitrag diskutiert, wie man event-getriebene Architekturen als eine Form der reaktiven Architekturen in einer Beratungssoftware einsetzen kann. Warum wurde für diese Beratungssoftware der event-getriebene Ansatz gewählt? Es werden sowohl die geschäftlichen als auch die technischen Anforderungen diskutiert, die zur Wahl dieses Architektur-Ansatzes geführt haben. Der event-getriebene Ansatz erwies sich als der richtige, um eine Entkopplung der Systeme und ein gesamthaftes Bild der einzelnen Aktivitäten für den Benutzer sicherzustellen.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider
Voraussetzungen: Prinzipielles Verständnis von Software-Architektur
Schwierigkeitsgrad: Anfänger

Extended Abstract
1. Vorstellung Beratungssoftware
2. Vorstellung Beratungsprozess
3. Variante als steuernder Prozess (klassische Architektur)
4. Variante als event-getriebener Prozess (reaktive Architektur)
5. Vorstellung der technischen Architektur
6. Vor- und Nachteile des gewählten Ansatzes
7. Weitere Arbeiten

Detail:
Die Beratungssoftware der Allianz Gruppe wird in den Agenturen eingesetzt, um Kunden gezielt und individuell beraten zu können. Dabei ist es wichtig, dem Berater auf der einen Seite Hilfe und Richtung in den teilweisen komplizierten Produkten anzubieten und auf der anderen Seite die notwendige Flexibilität des Verkaufsprozesses nicht einzuschränken.
Technisch erlauben Events, die Informationen von sehr unterschiedlichen Systemen ohne eine enge Kopplung dem Agenten zur Verfügung zu stellen. Der Gesamtprozess muss nicht den Einzelsystemen bekannt sein, sondern wird vielmehr aus den verschiedenen Informationen erst gebildet.
Dadurch erreicht man eine hoch flexible und entkoppelte Architektur, ohne auf Gesamtüberblick und strukturierte Darstellungen verzichten zu müssen.

This talk describes how to build and run a successful product development organization that delivers business value, not just features. I will cover what makes effective product development teams, how to structure, loosely couple, align and choreograph them, especially in larger organisations with up to 100 teams. Methods I will talk about include OKRs and Kanban Flight Levels. In this context I will also show when and how decentralised product teams can benefit from centralised platforms.

Target Audience: CTO, Manager, Decision Makers
Prerequisites: Experience with software development at scale
Level: Advanced

In dieser Session zeige ich entlang echter Softwaresysteme, wie Sie und Ihr Team Ihre Architekturansätze auf geringem Raum verdichtet und zugleich überzeugend darstellen. Sie erfahren, welche Inhalte mindestens in einen Architekturüberblick hineingehören und welche Formen sich in welcher Situation bewährt haben. Das Vorgehen für bestehende Systeme kommt genauso zur Sprache wie das Anfertigen bei neuen Softwarelösungen. Der Vortrag ist reich gespickt mit Beispielen und Best Practices, insbesondere mit Tipps gegen das Veralten der Inhalte.

Zielpublikum: In erster Linie alle, die Software entwerfen und entwickeln. Entscheider können problemlos folgen
Voraussetzungen: Erfahrung in Software-Entwicklungsvorhaben sind von Vorteil
Schwierigkeitsgrad: Anfänger

Extended Abstract
Die Dokumentation Ihrer Software-Architektur veraltet schnell? Deswegen fertigen Sie gar keine an? In dieser Session zeige ich entlang echter Softwaresysteme, wie Sie und Ihr Team Ihre Architektur-Ansätze auf geringem Raum verdichtet und zugleich überzeugend darstellen. Für Neue im Team ebenso wie als Einstieg z. B. in ein Architektur-Review.
Statt sich in Word oder Wiki zu verlieren, versteht Ihre Zielgruppe einen solchen Überblick im Handumdrehen; bei Bedarf führen Sie Interessierte damit zielsicher in die nötigen Details. Der Überblick ist mit überschaubarem Aufwand angefertigt und aktuell gehalten. Und sieht im Idealfall auch noch richtig gut aus!
Ganz konkret erfahren Sie, welche Inhalte mindestens in einen Architektur-Überblick hineingehören und welche Formen sich in welcher Situation bewährt haben. Das Vorgehen für bestehende Systeme kommt genauso zur Sprache wie das Anfertigen bei neuen Softwarelösungen. Der Vortrag ist reich gespickt mit Beispielen und Best Practices, insbesondere mit Tipps gegen das Veralten der Inhalte. Begleitet wird er von mehreren kompletten Architektur-Überblicken jeweils in verschiedenen Formen -- vom kompakten Folienvortrag bis zum ausgedruckten Flyer im Treppenfalz.

10 Jahre nach CAP wurde das CALM-Theorem formuliert, das beweist, was wir immer alle geahnt haben: Im Fall von Netzwerkpartitionen sind Konsistenz UND Verfügbarkeit unter bestimmten Bedingungen möglich! Im Vortrag gehen wir auf eine Journey vom CAP-Theorem hin zum CALM-Theorem. Ich räume mit gängigen Mythen auf und zeige euch, wie ihr das CALM-Theorem praktisch anwenden könnt. Der Vortrag vereint neueste Forschungsergebnisse und Lessons Learned aus mehreren Studien mit konkreten Entwurfsmustern und Code-Beispielen für Architekt:innen.

Zielpublikum: Architekt:innen
Voraussetzungen: Fachkenntnisse verteilte Systeme, Basiswissen DDD, Entwurfsmuster, Java
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Zehn Jahre nach Eric Brewers CAP-Theorem formuliert Joseph Hellerstein das CALM-Theorem und beweist das, was wir schon immer geahnt haben: Im Fall von Netzwerkpartitionen sind Konsistenz UND Verfügbarkeit unter bestimmten Bedingungen möglich! Wie das geht, zeige ich euch in diesem Vortrag und nehme euch mit auf eine Journey vom CAP-Theorem hin zum CALM-Theorem. Ich räume mit gängigen Mythen auf und zeige euch, wie ihr das CALM-Theorem praktisch anwenden könnt. Basierend auf unseren empirischen Erfahrungen aus verschiedenen Studien (Case Studies und Action Research Studies) und unserer laufenden Forschung entwickeln wir Architektur-Empfehlungen und Entwurfsmuster für das Design von daten-intensiven, verteilten Anwendungen. Der Vortrag gibt konkrete Hilfestellungen für Architekt:innen, demonstriert Entwurfsmuster mit laufendem Code und teilt mit den Teilnehmern unsere frei verfügbaren, open access Architektur-Guidelines.

Vom Spotify-Modell über Inverse Conway zu Team Topologies: Die Ideen für die Organisation von Software-Entwicklung sind vielfältig. Bei einer Modernisierung konkurrieren die Bedürfnisse von alter und zukünftiger Architektur, das erschwert die Entscheidung für eine Struktur, die beide Seiten angemessen behandelt. Auf welche Probleme stoße ich hier, welche Möglichkeiten habe ich zur Gestaltung meiner Teams und welche Variante ist am wirksamsten? Ein Überblick über die aktuellen Ansätze, angereichert mit den Schmerzen aus der Praxis.

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

Extended Abstract
Wir sehen in der Praxis viele interessante Adaptionen von Teamstrukturen, die auf Ideen von DevOps/Team Topologies, den agilen Skalierungs-Frameworks oder dem Spotify-Modell beruhen, während im Hintergrund eine Modernisierung der Software stattfindet. Dort treten in Folge oft ähnliche Probleme, Hindernisse und Anti-Patterns auf, die bei einem Green-Field-Ansatz oder normaler Weiterentwicklung nicht vorgekommen wären — und auf die wenig Antworten zu finden sind. Wie geht man mit den Interferenzen der Koexistenz der alten und neuen Welt um? Oft weichen die informellen Strukturen und Boundaries deutlich von dem ab, was formell existiert, und Macht, Einfluss, Wissen und Schattenstrukturen sorgen nicht nur für Probleme, sondern stellen auch überlebenswichtige Prozesse in der Organisation bereit. Wie integriert man die Umverteilung von Domänenwissen und neues technisches Know-how bei der Modernisierung? Zu welchen Strukturen sind Organisation, Teams und Personen schon fähig, zu welchen noch nicht? Wie und wann muss und kann man Raum für Lernen und Adaption gehen?
Wir zeigen Lösungsansätze, Workarounds und die offengebliebenen Fragen.

The primary cause of technical debt in your organization is very likely your project managers – not your programmers nor your architects. In this keynote Scott Ambler explores the root causes of technical debt within organizations, many of which trace back to the project management (PM) mindset and the strategies that result from it. Scott works through how to make leadership aware of technical debt and its implications, how to evolve your management practices, and strategies to embed technical debt thinking and behaviors into your culture.

Target Audience: Developers, Architects, Leaders, Managers
Prerequisites: None
Level: Advanced

Extended Abstract
The primary cause of technical debt in your organization is very likely your project managers – not your programmers nor your architects. The management desire to be “on time and on budget”  often motivates deployment of poor-quality assets and rarely leaves room for investment in long-term quality. Although technical professionals may readily realize this problem managers often do not, or if they do they don’t view technical debt as a priority. It is time for a change.
In this keynote Scott Ambler explores the root causes of technical debt within organizations, many of which trace back to the project management (PM) mindset and the strategies that result from it. Just like the technical challenges of addressing technical debt must be addressed by technical solutions, the management challenges of technical debt must be addressed by management solutions. Scott works through how to make leadership aware of technical debt and its implications, how to evolve your management practices to avoid and address technical debt, and enterprise-level strategies to embed technical debt thinking and behaviors into your culture. Results from industry research will be shared throughout.
Learning objectives:
• Connect project management practices to their impact on technical debt
• Learn how to describe technical debt, its impact, and solutions to leadership
• Discover how to embed technical debt thinking and practices throughout your way of working (WoW)

Das Thema Quantencomputing (QC) ist in aller Munde. Doch was ist QC? Für welche Anwendungsdomänen ergeben sich Chancen? Wie integriert man Quantenalgorithmen in Software-Architekturen? Was ist der aktuelle Stand der Technik bzgl. Frameworks und Tools?
Dieser Vortrag vermittelt grundlegendes QC-Wissen und stellt ausgewählte Anwendungsfälle vor. Ein Hands-on-Beispiel veranschaulicht Vorgehen und Entwicklungswerkzeuge, um QC-Potenziale in der Anwendung zu identifizieren, effiziente Quantenalgorithmen zu integrieren und schlussendlich auszuführen.

Zielpublikum: Produktverantwortliche, Architekt:innen, Entwickler:innen
Voraussetzungen: Keine Vorkenntnisse zu Quantencomputing notwendig
Schwierigkeitsgrad: Anfänger

Extended Abstract
Der erste Teil des Vortrags vermittelt die Grundlagen von Quantencomputing und insbesondere die Unterschiede zu konventionellen Computer-Architekturen. Der Vortrag beginnt mit einer kurzen Vorstellung der grundlegenden Prinzipien von QC: Qubits, Superposition, Verschränkung und Manipulation von Qubits am Beispiel von Quantenschaltkreisen. Daraus werden jene Eigenschaften von QC abgeleitet, die QC von bekannten Computer-Architekturen abheben und Entwickler:innen vor völlig neue Herausforderungen stellen, zum Beispiel die fehlende Möglichkeit zu debuggen. Nach einer Übersicht über das derzeitige QC-Hardware-Ökosystem und die damit verbundene Programmierung von Quantenschaltkreisen folgt eine Diskussion aktueller Grenzen der gegenwärtigen QC-Systeme.

Der zweite Teil des Vortrags veranschaulicht die einzigartigen Vorteile von QC aus der Anwendungsperspektive und illustriert, welche Anwendungsdomänen davon potenziell profitieren können. Die Teilnehmenden können so die Auswirkungen von QC auf ihr eigenes Arbeitsumfeld einschätzen. Einige ausgewählte Anwendungsfälle werden detailliert betrachtet.

Im dritten Vortragsteil wird anhand eines Beispiels aufgezeigt, wie für eine spezielle Anwendung das Potenzial von QC erschlossen werden kann. Dies umfasst die Identifikation und Programmierung geeigneter Quantenalgorithmen, die entsprechende Integration der Quantensoftwarekomponenten in die Anwendungs-Architektur, sowie das Deployment zur Ausführung auf einem Cloud-Dienst. Im Rahmen des gewählten Beispiels werden verschiedene Abstraktionsebenen zur Programmierung von Quantenanwendungen sowie die zugehörigen Frameworks und Tools vorgestellt. Zusätzlich werden Simulatoren für Quantencomputer vorgestellt, mittels derer die Teilnehmenden im Nachgang mit der QC-Programmierung beginnen 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 den automatisierten Build-Prozess 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
Voraussetzungen: Grundlegende Kenntnisse von Architektur-Dokumentation und über automatisiertes Build-Management
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Im Gegensatz zu den klassischen Ansätzen (Textverarbeitung, Wiki, Netzlaufwerke, ...) verfolgt Docs-as-Code den Ansatz, die in Softwareprojekten relevante Dokumentation genau wie den Quelltext zu behandeln. Für die entwickelnden Team-Mitglieder entsteht somit kein Medienbruch. Sie können die gleichen Werkzeuge (Texteditor, IDE, Build-Tools, CI/CD-Pipeline) verwenden, um die Inhalte als leichtgewichtige Textformate neben dem Sourcecode in der Versionsverwaltung abzulegen, die Änderungen gemeinsam mit dem Quellen zu reviewen, als Release zu markieren und auszuliefern sowie die zielgruppenorientierte Zusammenstellung der Ergebnisse in den Build-Prozess einzubinden. Um Redundanzen zu vermeiden, können aus den vorhandenen Projektmodellen (Sourcecode, DB-, UML-Modell, ...) automatisiert textuelle Inhalte und Diagramme generiert werden.
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 Architektur-Regeln regelmäßig automatisiert zu testen. Die Zuhörer erfahren in diesem Vortrag, wie sie mit Documentation as Code starten können, welche typischen Fallstricke sie umschiffen sollten und welche konkreten Tools bekannt sein sollten.

In diesem interaktiven Workshop erarbeiten wir uns das Thema Wardley Maps und wie sich diese in der Weiterentwicklung von komplexen Softwaresystemen und Softwarelandschaften pragmatisch einsetzen lassen.
Wardley Maps sind evolvierende Strategielandkarten, welche ein kontextspezifisches Situationsbewusstsein für die eigenen Softwaresysteme (und mehr) schaffen. Sie bieten uns einen Ort, um komplexe Sachverhalte zu kommunizieren: Wie hängen Business und Systeme zusammen? Wo bauen wir etwas selbst und was holen wir von extern? Welche Entwicklungspraktiken und Vorgehen setzen wir dafür ein?
Mit Wardley Maps erstellen wir für diese Art von Fragen Landkarten, um unsere eigene Situation besser zu verstehen. Und mehr! Mit einer Karte können wir auch planen, wo die Reise hingehen soll. Wardley Mapping bietet uns hierfür einen reichen Fundus an Wegweisern zum Navigieren und Tipps zum Umgang mit Hindernissen.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheidende
Voraussetzungen: Interesse an visueller Kommunikation, keine Scheu vor praktischen Übungen in Miro
Schwierigkeitsgrad: Anfänger
 
Teilnehmendenbegrenzung: keine