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

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?

Wir teilen unsere Erfahrung, was Dynamikrobustheit in Unternehmen ist, wie sie entstehen kann und wie sie sich auf die IT-Architektur auswirkt. Am Beispiel zweier Großkonzerne berichten wir vom Umbau der Organisations- und IT-Strukturen in hierarchischen Organisationen. Wir beleuchten dabei Konzepte von Conways Gesetz über den Tech Radar bis hin zu Team Topologien. Dazwischen ist genug Zeit für Praxisfragen und Anwendungsbeispiele der Teilnehmenden.

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

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

Funktionale Architektur ist grundsätzlich anders als OO-Architektur:

• unveränderliche Daten
• Eingrenzung und Kontrolle von Effekten
• konsequente Abstraktion
• Einsatz von Mathematik bei der Modellierung

All dies reduziert Kopplung und führt generell zu mehr Flexibilität und Robustheit.  Der Vortrag gibt einen Kurzüberblick mit hoffentlich kritischen und provokativen Rückfragen - und den Antworten darauf.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: OO-Programmiererfahrung
Schwierigkeitsgrad: Advanced

In den letzten Jahren scheint 'Agilität' als alleinstehender Begriff aus der Mode gekommen zu sein. Neue Trends wie 'Enterprise Agility' oder 'Business Agility' sind in aller Munde. Reicht es jetzt also für Unternehmen nicht mehr, einfach nur agil zu sein? Muss es nun Business Agility sein? Und steckt hinter 'Business Agility'? 

Der Vortrag stellt 4 Dimensionen, die Business Agility ausmachen vor - und Agile Methoden sind darin nur ein Teil einer Dimension. Dafür nehmen Technologie und Kultur einen maßgeblichen Platz ein. 

Um die 4 Dimensionen anschaulich zu machen, bringen wir in den ersten 8 Minuten eine Liste von Beispielen für Ausprägungen aus der Praxis mit. In den zweiten 8 Minuten nehmen wir Fragen zu den Dimensionen entgegen oder stellen wahlweise ein Praxisprojekt vor.

Zielpublikum: Architekten, Führungskräfte, Agile Coaches
Voraussetzungen: Grundsätzliches Verständnis von Agilität
Schwierigkeitsgrad: Basic

Extended Abstract:

'Agil' und 'Agilität' sind seit mehr als 15 Jahren als Begriffe in Unternehmen immer prominenter geworden und mittlerweile nicht mehr wegzudenken. In den letzten Jahren scheint aber 'Agilität' als alleinstehender Begriff aus der Mode gekommen zu sein. Neue Trends wie 'Enterprise Agility' - zumeist jetzt als 'Business Agility' bezeichnet - sind in aller Munde. Reicht es jetzt also für Unternehmen nicht mehr, nur nach dem richtigen Maß an 'Agilität' zu streben? Muss es Business Agility sein? Und was ist dann eigentlich 'Business Agility'? 

Der Vortrag stellt 4 Dimensionen, die Business Agility ausmachen vor - und Agile Methoden sind darin nur ein Teil einer Dimension. Dafür nehmen Technologie und Kultur einen maßgeblichen Platz ein. Um die 4 Dimensionen anschaulich zu machen, bringen wir eine Liste von Beispielen für Ausprägungen aus der Praxis mit.

Die ersten 8 Minuten konzentrieren sich auf die Vermittlung des Modells. Die zweiten 8 Minuten geben die Möglichkeit für die Zuhörer relevante Fragen zu den 4 Dimensionen oder wahlweise ein aktuelles Praxisbeispiel aus einer Dimension kennenzulernen - Abstimmung dazu z.B. über Mentimeter.