Angular, React oder vielleicht doch Vue.js? Die erste Frage in vielen Projekten ist nicht, ob eine Single-Page Application (SPA) der richtige Architekturansatz ist, sondern nur noch, mit welchem Framework man sie umsetzt. Mit der blinden Entscheidung für eine SPA gehen wir unbewusst eine ganze Reihe von Kompromissen ein, die nicht immer im Sinne des Projekts oder der Endanwender sind. Wie sind wir an den Punkt gelangt, an dem wir andere Optionen gar nicht mehr in Betracht ziehen? Um diese Frage zu beantworten, werfen wir einen Blick zurück auf die Evolutionsschritte vom klassischen Server-Side Rendering (SSR) hin zum reinen Client-Side Rendering (CSR) einer Single-Page Application. Dabei betrachten wir die Vor- und Nachteile anderer Ansätze, die wir auf dieser Reise zurückgelassen haben, und wagen einen Blick in die Zukunft, in der die Grenzen zwischen SSR und CSR zunehmend verschwimmen.

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

Systeme leben häufig über viele Jahre oder gar Jahrzehnte, werden sorgsam gepflegt und immer wieder geflickt. Aber irgendwann wirkt das UI angestaubt, Änderungen brauchen ewig und man will von Möglichkeiten moderner Technologien profitieren.

Die Entscheidung, das System zu modernisieren, wird gefällt. Und dann kommt die einfachste Anforderung der Welt, die wir alle schon gehört haben: 'Das neue System muss aber das Gleiche können wie das alte!'. Dass wir diese Anforderung so häufig hören ist nicht verwunderlich: Sie ist einfach, man kann sie auch formulieren, wenn man das System nur oberflächlich kennt und scheint dabei präzise zu sein. Tatsächlich ist diese Anforderung ziemlich unsinnig.

In diesem Vortrag erklären wir, warum die einfachste Anforderung der Welt Unsinn ist und geben Erfahrungen, Hinweise und Best Practices für Modernisierungsvorhaben, in denen es darum geht, den Zielzustand zu gestalten und den Weg der Modernisierung zu planen.

Zielpublikum: Architekt:innen, Projektleiter:innen, Manager:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Basic

Wir streben alle nach möglichst hoher Qualität unseres Codes, wissen aber gleichzeitig dass eine gewisse Zahl an Qualitätsproblemen immer anwesend ist. Statt auf absolute Perfektion zu zielen, ist es oft viel sinnvoller zu schauen, ob man mit seinen Problemen im erwartbaren Bereich, oder deutlich darüber oder darunter liegt. Daraus lässt sich z.B. Handlungsbedarf ableiten und die Notwendigkeit zur Modernisierung argumentieren.

In unseren Audits haben wir über die Jahre eine Vielzahl an Systemen vermessen und bewertet. Die daraus resultierenden Ergebnisse erlauben es uns nun einen Benchmark zu präsentieren, der zeigt in welchem Bereich sich die Systeme hinsichtlich verschiedener Qualitätseigenschaften des Codes, wie z.B. der Struktur, Redundanz oder Kommentierung bewegen. Mit unserem Vortrag skizzieren wir demnach unter Berücksichtigung der Programmiersprache eine Erwartungshaltung, die jeder mitnehmen und mit seinem eigenen Code abgleichen kann.

Zielpublikum: Qualitätsverantwortliche, Architekten, Entwickler, Projektleiter
Voraussetzungen: Für diesen Vortrag sind keine besonderen Voraussetzungen notwendig.
Schwierigkeitsgrad: Basic

Extended Abstract:

Wir streben alle nach möglichst hoher Qualität unseres Codes, wissen aber gleichzeitig dass eine gewisse Zahl an Qualitätsproblemen immer anwesend ist. Es besteht zum Teil ein deutlicher Unterschied zwischen dem theoretischen Idealbild und der tatsächlichen Code-Qualität in der Praxis. Diese Diskrepanz macht es uns schwer zu erkennen wo relevante Erosion stattfindet und ggf. Gegenmaßnahmen erforderlich sind. Statt unseren Code also mit dem Idealbild zu vergleichen, ist es oft viel sinnvoller zu schauen, ob man mit seinen Problemen im erwartbaren Bereich, oder deutlich darüber oder darunter liegt. Daraus lässt sich z.B. Handlungsbedarf ableiten und die Notwendigkeit zur Modernisierung argumentieren.

In unseren Audits haben wir über die Jahre eine Vielzahl an Systemen vermessen und bewertet. Die daraus resultierenden Ergebnisse erlauben es uns nun einen Benchmark zu präsentieren, der zeigt in welchem Bereich sich die Systeme hinsichtlich verschiedener Qualitätseigenschaften des Codes, wie z.B. der Struktur, Redundanz oder Kommentierung bewegen. Mit unserem Vortrag skizzieren wir demnach unter Berücksichtigung der Programmiersprache eine Erwartungshaltung, die jeder mitnehmen und mit seinem eigenen Code abgleichen kann. Im Vergleich zu vielen anderen Benchmarks die lediglich Open-Source-Systeme berücksichtigen, basiert unser Benchmark vorwiegend auf proprietärem Code.

Zusätzlich zu den konkreten Ergebnissen teilen wir unsere Erfahrungen beim Aufbau und Einsatz eines solchen Benchmarks. Hierbei diskutieren wir unter anderem was beim Vergleich von Systemen zu berücksichtigen ist. Hierzu zählt unter anderem der Umgang mit verschiedenen Arten von Code (z.B. handgeschrieben vs. generiert) und die manuelle Validierung der Messergebnisse. Wir sprechen auch darüber, welche Aussagen man aufgrund eines solchen Benchmarks treffen kann und welche nicht.

Nach unserem Vortrag kennen die Teilnehmer das grundlegende Vorgehen, aber auch die typischen Fallstricke, beim Vergleichen der Code-Qualität verschiedener Systeme. Der von uns präsentierte Benchmark zeigt was man als 'normal' in Bezug auf verschiedene Qualitätskriterien erwarten kann und wo Abweichungen auf Nachbesserungsbedarf hinweisen.

Beim Mob-Programming erledigen Teams Aufgaben gemeinsam. Zur selben Zeit, am selben Ort, am selben Computer. Wartezeit ('Verschwendung') wird minimiert, der 'Flow' von wertvollen Ergebnissen für unsere Kunden erhöht. Es werden nicht möglichst viele Aufgaben parallel angefangen, sondern die angefangene Aufgabe wird gemeinsam erfolgreich zu Ende gebracht - aus Einzelkämpfern werden Co-Autoren.

In den vergangenen 12 Monaten standen viele Teams aber vor einem Problem: Wie bringen wir unsere Vor-Ort-Zusammenarbeit in die Onlinewelt? In diesem Vortrag werde ich berichten, welche Erfahrungen wir mit Remote-Mob-Programming gesammelt haben, was für uns funktioniert und was eher nicht. Für Neueinsteiger ins Mob-Programming werde ich die allgemeinen Grundlagen vorstellen, den Fokus aber auf Remote-Tools und Remote-Arbeitsweisen legen.

Zielpublikum: Entwickler, Teamleiter, Entscheider, Manager
Voraussetzungen: Hilfreich: Softwareentwicklung im Team erlebt oder geleitet zu haben.
Schwierigkeitsgrad: Basic

Extended Abstract:

Beim Mob-Programming erledigen Teams Aufgaben gemeinsam. Zur selben Zeit, am selben Ort, am selben Computer. Wartezeit ('Verschwendung') wird minimiert, der 'Flow' von wertvollen Ergebnissen für unsere Kunden erhöht. Es werden nicht möglichst viele Aufgaben parallel angefangen, sondern die angefangene Aufgabe gemeinsam erfolgreich zu Ende gebracht - aus Einzelkämpfern werden Co-Autoren.

Mit dem Beginn der Corona-Krise und dem plötzlichen Wechsel ins Homeoffice standen viele Teams aber vor einem Problem: Wie bringen wir unsere erfolgreiche Vor-Ort-Zusammenarbeit in die Online-Welt? In diesem Vortrag werden ich davon berichten, welche Erfahrungen wir mit Remote-Mob-Programming gesammelt haben, was für uns funktioniert und was eher nicht. Für Neueinsteiger ins Mob-Programming werde ich die allgemeinen Grundlagen vorstellen, den Fokus aber auf Remote-Tools und Remote-Arbeitsweisen legen.

Das Erlernen solcher Zusammenarbeitsweisen lohnt sich: Während manche Softwareentwicklungsteams sich schnell und vollkommen problemlos von der Arbeit vor Ort auf reine Remote-Arbeit umstellen konnten, taten sich andere Teams extrem schwer damit. Das lag zum Einen sicherlich an der technischen Ausstattung. Zum Anderen war aber eine starke soziale Komponente entscheidend. Und die kann man mit (Remote-)Mob-Programming gezielt fördern. Die Teams waren resilienter gegenüber Unerwartetem. Und das brauchen wir auch in Zukunft.

In der Softwareentwicklung werden die Anforderungen an ein Produkt häufig von Stakeholdern oder Product Owner in einem Lastenheft definiert und dann im agilen Prozess in User Stories überführt. Die Anforderungen der Nutzer werden dabei oft außer Acht gelassen, was dazu führt, dass das fertige Produkt keine Akzeptanz findet. Es geht auch anders. Der Vortrag beleuchtet, wie eine Idee für ein Produkt nutzerzentriert entsteht und methodisch gestützt mit einfachen Mitteln in ein Product Backlog überführt wird. Ein konkreter Use Case inklusive praktischen Übungen in Miro zeigt, wie die Theorie umgesetzt wird und wie die einzelnen Schritte aufeinander aufbauen.

Zielpublikum: Product Owner, Business Analysten, Requirements Engineer, Projektleiter, Manager und alle, die agil ein Produkt entwickeln wollen
Voraussetzungen: Grundlegendes Verständnis zu Agilität z.B. Verständnis darüber, was ein Product Backlog ist
Optional: grundlegende Erfahrung in Miro für die Übungen
Schwierigkeitsgrad: Basic

Extended Abstract:

In der Softwareentwicklung werden die Anforderungen an ein Produkt häufig von Stakeholdern oder Product Owner in einem Lastenheft definiert und dann im agilen Prozess in User Stories überführt. Die Anforderungen der Nutzer werden dabei oft außer Acht gelassen, was dazu führt, dass das fertige Produkt keine Akzeptanz findet. Es geht auch anders. Der Vortrag beleuchtet, wie eine Idee für ein Produkt nutzerzentriert entsteht und methodisch gestützt mit einfachen Mitteln in ein Product Backlog überführt wird. Ein konkreter Use Case inklusive praktischen Übungen in Miro zeigt, wie die Theorie umgesetzt wird und wie die einzelnen Schritte aufeinander aufbauen.

Praxisrelevanz und Anwendbarkeit:

Das im Vortrag vorgestellte Vorgehen wurde bereits bei mehreren Kunden in verschiedenen Branchen erfolgreich angewendet.

Vermittlungsart:

Die Teilnehmer bekommen neben wertvollen Praxistipps die Möglichkeit, das vermittelte Wissen schon während des Vortrags gerne auch anhand von eigenen Use Cases zu testen.

Expertise:

Die beiden Vortragenden gestalten und halten Schulungen zu Scrum, RE sowie weiteren methodischen Vorgehensweisen und verfügen über langjährige Beratungsexpertise in der agilen Softwareentwicklung. 

Wie strukturiert man ein Programm richtig? Dies ist seit Beginn der Software-Entwicklung eine zentrale Frage. Schichten sind ein Anfang, aber nicht genug. Modernere Stile sind Hexagonal, Onion und Clean Architecture. Auch Tactical Design und Pattern Languages helfen. Großartiges Systemdesign wird nicht nur mit einer dieser Zutaten erreicht. Nur wenn wir alle zusammenfügen, können wir den Architektur-Hamburger bauen - die Kombination, die qualitativ hochwertige Software möglich macht.

Zielpublikum: Architekten, Entwickler, Projektleiter
Voraussetzungen: Erfahrung in mittleren bis großen Softwareprojekten
Schwierigkeitsgrad: Advanced

Seit dem Beginn der Chaos-Engineering-Initiative beim Vertrieb der Deutschen Bahn sind inzwischen mehr als zwei Jahre vergangen. Nach gut 90 Game Days, etlichen produktionsrelevanten Findings und Überzeugungsarbeit in einem stark skalierten agilen Umfeld wissen wir, wie man sich selbst einfach mit Chaos Engineering in den Fuß schießen kann. In diesem Vortrag sprechen wir darüber, was unsere Zuhörenden tun können, um auf keinen Fall mit Chaos Engineering Erfolg zu haben.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Tester:innen
Voraussetzungen: Projekterfahrung, Testing
Schwierigkeitsgrad: Advanced

Extended Abstract:

Seit dem Beginn der Chaos-Engineering-Initiative beim Vertrieb der Deutschen Bahn sind inzwischen mehr als zwei Jahre vergangen. Nach gut 90 Game Days, etlichen produktionsrelevanten Findings und Überzeugungsarbeit in einem stark skalierten agilen Umfeld wissen wir, wie man sich selbst einfach mit Chaos Engineering in den Fuß schießen kann. In diesem Vortrag sprechen wir darüber, was unsere Zuhörenden tun können, um auf keinen Fall mit Chaos Engineering Erfolg zu haben. Das Cynefin-Framework, die sieben Network Fallacies, ein Game Day mit Beispielagenda und Scaled-Agile-Herangehensweisen sind nur einige gute Kandidaten, die viel Potential bieten, die eigene Chaos-Engineering-Initiative zu einem grandiosen Misserfolg zu machen. Nach unserer Erkundungsreise aus dem Projektalltag wissen unsere Zuhörenden, was sie selbst tun können, um zu scheitern.

Leuchtturmprojekt, Kostengrab, Hoffnungsträger und wichtiger Baustein in der Pandemiebekämpfung - das deutsche Corona-Warn-App-System (kurz CWA) besteht nicht nur aus den recht prominenten iOS- und Android-Apps. Zur Umsetzung von Use Cases wie der persönlichen Risikoermitttlung oder dem Melden von (positiven) Testergebnissen, gehört auch eine vielteilige Server-Lösung. Sie basiert auf einem zeitgemäßen Architekturstil und einem aktuellen Technologie-Stack. Und wurde unter hohem Zeitdruck federführend von SAP und Deutscher Telekom realisiert. 

Das öffentliche Interesse an diesem Projekt ist hoch, die Transparenz bei der Entwicklung erfreulicherweise ebenfalls. Der Quellcode ist Open Source und auch die Dokumentation offen zugänglich. Wir diskutieren die prägenden architekturrelevanten Anforderungen und die getroffenen Entscheidungen. Zum Abschluss bewerten wir die gewählten Lösungsansätze und arbeiten Stärken, Hindernisse und Kompromisse heraus.

Zielpublikum: Architekten, Entwickler, Entscheider
Voraussetzungen: keine speziellen, Kenntnisse moderner Softwarearchitekturen sind hilfreich
Schwierigkeitsgrad: Basic

Spendiert man jedem Microservice seine eigene Datenbank (Database-per-Service-Pattern), hat man irgendwann unweigerlich das Problem verteilter Businesstransaktionen. Die gute alte DB-Transaktion fällt per Definition aus dem Rennen. Lässt sich also aus fachlicher Sicht ganz auf Transaktionen verzichten? In vielen Fällen ist das durchaus möglich. Als Alternative zur Sicherstellung Service-übergreifender Datenkonsistenz bietet sich u. a. eine Realisierung auf Basis mehrerer lokaler technischer Transaktionen an, auch Saga-Pattern genannt. Die Session führt in die Theorie des Saga-Patterns ein und zeigt seine praktische Verwendung an verschiedenen Beispielen.

Zielpublikum: Architekten, Entwickler
Voraussetzungen: Kenntnisse zu Microservices
Schwierigkeitsgrad: Basic

Die IT-Produktentwicklung ist in den meisten Unternehmen überlastet, und das Hinzufügen weiterer Entwickler oder Teams führt häufig zu Verlangsamung und Chaos. Wie ein Auto, das absäuft, wenn man das Gaspedal tritt. Es gibt jedoch seltene Beispiele, in denen Teams zusammenarbeiten, regelmäßig neue Funktionen erstellen und die Produktionsmaschine anfängt, rund zu laufen. Dies kann erreicht werden, indem die Organisation radikal umstrukturiert, die Zusammenarbeit mit dem Management sichergestellt und die inhaltlichen und technischen Verantwortlichkeiten an Experten verteilt werden. Kurzum: indem die gesamte Produktionsstraße in der Organisation neu aufgebaut wird.

Zielpublikum: Entscheider, Verhinderer, Passivisten und Leidende
Voraussetzungen: Schmerzen haben
Schwierigkeitsgrad: Advanced

Häufig wird die Architekturdokumentation eines Projekts / Produkts im stillen Architekt:innenkämmerlein entworfen. Dabei gibt es im Umfeld der kollaborativen Modellierungsansätze, die in der Domain-driven Design Community sehr beliebt sind, zahlreiche Ansätze und Methoden, wie man zusammen mit Stakeholdern Teile des architektonischen Entwurfs und somit auch der Dokumentation erarbeiten kann. An dieser Stelle setzt der Vortrag an und vermittelt basierend auf dem arc42-Template folgende Inhalte:

• Wie kommt man mit EventStorming zu einer guten fachlichen Kontextabgrenzung
• Wie kann man im EventStorming mit Hilfe von Pivotal Events, Swimlanes und zeitlichen Grenzen erste Modulkandidaten identifizieren
• Beschreibung von Bausteinen der Bausteinsicht mit Hilfe der Bounded Context Canvas
• Nutzung von Quality Storming für die Identifkation von Qualitätsszenarien

Zielpublikum: Entwickler:innen und Architekt:innen
Voraussetzungen: Einfache Grundkenntnisse im Bereich der Software Dokumentation
Schwierigkeitsgrad: Basic

Der Klimawandel ist eine globale Bedrohung. Um den Klimawandel zu stoppen, ist jeder einzelne Schritt wichtig und nötig. In diesem Vortrag zeige ich auf, welchen Einfluss wir als Software-Entwickler auf den Klimawandel nehmen können. Dabei gebe ich zunächst einen umfassenden Überblick über die verschiedenen Bereiche, mit denen wir als Software-Entwickler in Berührung kommen, und zeige, welchen enormen Einfluss Software auf die globalen Treibhausgasemissionen haben kann. Daran anschließend diskutiere ich eine Auswahl an Maßnahmen detaillierter, mit denen Software-Entwickler den Ausstoß von Treibhausgasen reduzieren können und welchen Fallen und Schwierigkeiten sie dabei begegnen werden.

Zielpublikum: Entwickler, Manager, DevOps
Voraussetzungen: keine
Schwierigkeitsgrad: Basic

Extended Abstract:

Im Laufe des Vortrags betrachte ich diverse Aspekte der Software-Entwicklung und zeige, welchen Einfluss diese Aspekte auf den Klimawandel und speziell die Treibhausgasemissionen haben. Ich betrachte dabei unter anderem:

• Energie-Verbrauch von Software und was das für die Entwicklung bedeutet
• Studien zur Auslastung von Rechenzentren, das Problem der Zombie-Prozesse/Anwendungen/Machinen, und Software in der Cloud (bezogen auf den Energie-Verbrauch, wie 'grün' sind die Public-Clouds), inkl. Forschungsansätze, um Software automatisch anhand von CO2-Emissions-Daten zu steuern und zu verteilen
• Das Jevox-Paradoxon heute - Worauf muss ich achten?
• Wie weit komme ich mit regenerativen Energien und Carbon-Offsetting?Video-Konferenzen vs. Face-to-Face-Meetings und Online-Konferenzen - Wann lohnt sich was aus Sicht des Klimaschutzes?
• und weitere... :-)

Technische und fachliche Herausforderungen in hochkomplexen Umgebungen bergen große Risiken. Eine agile Herangehensweise bietet Chancen für ein nachhaltiges Risikomanagement: Kurze Feedbackzyklen, interdisziplinäre Kollaboration sowie kleines und inkrementelles Deployen reduzieren Risiken deutlich. Jedoch bringt jedes neue Feature wiederum neue unvorhersehbare Risiken mit sich. Wie geht man mit diesen Gefahren um, wenn man trotzdem eine kurze Time-to-Market einhalten möchte

Carsten Lill (Projektleiter), Jan-Torben Evers (Data Scientist) und Nils Hyoma (Agile Coach) berichten aus unterschiedlichen Sichtweisen, wie sie dieses Problem in den Griff bekommen haben. 

Sie haben gemeinsam auf der grünen Wiese eine neue Lösung mit ihren eng vernetzten Teams entwickelt.Parallel zu der Entwicklung der Dispositionssoftware haben wir eine Self-Service-Business-Intelligence-Lösung konzipiert und implementiert.

Zielpublikum: Product Owner, Projektleiter, Manager, Entscheider, Agile Coaches, Scrum Master, Architekten
Voraussetzungen: Grundlagen Scrum
Schwierigkeitsgrad: Advanced

Extended Abstract:

Risky business? Bessere Softwareentwicklung mit überschaubaren Risiken durch Feature Toggles und Self-Service BI

Technische und fachliche Herausforderungen in hochkomplexen Umgebungen bergen große Risiken. Eine agile Herangehensweise bietet Chancen für ein nachhaltiges Risikomanagement: Kurze Feedbackzyklen, interdisziplinäre Kollaboration sowie kleines und inkrementelles Deployen reduzieren Risiken deutlich. Jedoch bringt jedes neue Feature wiederum neue unvorhersehbare Risiken mit sich. Wie geht man mit diesen Gefahren um, wenn man trotzdem eine kurze Time-to-Market einhalten möchte?

Der deutsche Luftraum ist so eine komplexe Umgebung. Eine an die europäische Luftraumüberwachung (Eurocontrol) angebundene Dispositionssoftware, welche automatisch kritische Entscheidungen trifft, muss zeitnah realistische Zeitinformationen übermitteln. Werden diese Vorhersagen nicht eingehalten, droht der Verlust von begehrten Slots im Luftraum, was zu negativen Kettenreaktionen führen kann. Im schlimmsten Fall können hunderte Passagiere nicht am selben Tag zu ihrem Reiseziel gelangen. Dabei können hohe Folgekosten entstehen.

Carsten Lill (Projektleiter), Jan-Torben Evers (Data Scientist) und Nils Hyoma (Agile Coach) berichten aus unterschiedlichen Sichtweisen, wie sie dieses Problem in den Griff bekommen haben. Sie haben gemeinsam auf der grünen Wiese eine neue Lösung mit ihren eng vernetzten Teams entwickelt.

Neben gründlichen Tests der Systeme hilft die Auswertung von operativen Daten. Hierbei sind nicht etwa Logdateien, sondern die Überprüfung vorher definierter Metriken gemeint. Eine starre Data-Warehouse-Lösung oder Standard-Reports bieten hierbei jedoch nicht die notwendige Flexibilität, um ad-hoc reagieren zu können.

Parallel zu der Entwicklung der Dispositionssoftware haben wir eine Self-Service-Business-Intelligence-Lösung konzipiert und implementiert. Dabei hat das Team die Zeit zwischen den einzelnen Releases durch das verringerte Risiko sogar verkürzen können. Alle Entwickler:innen, wichtige Stakeholder, die Geschäftsführung und der Product Owner konnten jederzeit auf die Ergebnisse der Datenanalyse zugreifen und mit diesen arbeiten. Mit den Feature Toggles war es dem Scrum Team möglich, Änderungen ohne Deployment jederzeit zu aktivieren und auch wieder zu deaktivieren. In der Software vorhandene anpassbare Parameter erlauben es, die gewonnenen Erkenntnisse zur Optimierung sofort umzusetzen.

Der Entwicklungsfortschritt der jeweiligen Produktziele war durch Transparenz in Zielsetzung und Daten jederzeit überprüfbar.