Konferenzprogramm

Die im Konferenzprogramm der OOP 2022 Digital angegebenen Uhrzeiten entsprechen der Central European Time (CET).

Per Klick auf "VORTRAG MERKEN" innerhalb der Vortragsbeschreibungen können Sie sich Ihren eigenen Zeitplan zusammenstellen. Sie können diesen über das Symbol in der rechten oberen Ecke jederzeit einsehen.

Unser Programm gibt es auch als praktische PDF-Datei >>Zum Download

Thema: Architecture

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Montag
    31.01.
  • Dienstag
    01.02.
  • Mittwoch
    02.02.
  • Donnerstag
    03.02.
  • Freitag
    04.02.
, (Montag, 31.Januar 2022)
10:00 - 17:00
Mo 1
Ausgebucht The Art of Software Reviews
The Art of Software Reviews

Auch in erfolgreichen Softwaresystemen lauern praktisch immer Probleme. Durch systematische Reviews können Sie diese Probleme zielgerichtet identifizieren – und damit eine robuste Grundlage für zukünftige Verbesserungen schaffen.

Der Workshop erklärt methodisches Vorgehen bei Software-Reviews, mit Fokus auf eine Breitensuche typischer Problemkategorien.

In interaktiven Sessions erarbeiten Sie unter Anleitung wesentliche Probleme Ihrer eigenen Systeme - und erhalten damit konkrete Hilfestellung für Ihr konkretes Arbeitsumfeld.

Maximale Teilnehmerzahl: 35

Zielpublikum: Architektur, Entwicklung, Management, POs -> alle, die mit SW-Entwicklung zu tun haben
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Getreu dem Bonmot „Besser geht immer“ leidet praktisch alle Software an Problemen kleiner oder großer Natur: Vielleicht läuft sie zu langsam, stürzt manchmal ab oder sieht weniger schön aus als das System der Konkurrenz. Häufig beschwert sich das „Business“ lautstark darüber, dass neue Features viel zu lange dauern – neudeutsch: die Time-to-Market ist zu schlecht. Abgesehen von hello-world, lässt sich überall noch so manches besser machen.

Falls Sie dieses Verbesserungspotenzial Ihres Systems heben möchten, sollten Sie auf jeden Fall zuerst ein explizites, konkretes und spezifisches Verständnis der vorhandenen Probleme erarbeiten.

Dabei können wir aus der Medizin lernen: Dort steht vor den Therapievorschlägen zuerst eine gründliche Diagnose („Untersuchung“). Ohne ein solches „Review“, wie die Untersuchung in der IT-Branche heißt, droht Verschlimmbesserung.

Der Workshop führt Sie in methodische Software-Reviews ein, mit den folgenden wesentlichen Schritten:

  • Klärung von Scope und Kontext
  • Klärung der wesentlichen Stakeholder
  • Identifikation wesentlicher Qualitätsprobleme („qualitative Analyse“)
  • Analyse wesentlicher struktureller und Code-Probleme
  • Identifikation von Problemen externer Schnittstellen
  • Analyse von Problemen bei Anwendungsdaten
  • Analyse technischer Probleme
  • Wirksame Aufarbeitung und Kommunikation von Review-Ergebnissen

Der Workshop enthält eine Reihe interaktiver Übungen, in deren Verlauf Sie eine Übersicht über die Probleme Ihres eigenen Systems bekommen (können).

Dr. Gernot Starke (INNOQ Fellow) ist Coach, Berater und Trainer für methodische Software-Architektur und Software-Engineering, (Mit-)Gründer von arc42.org, Gründer von aim42.org. Gernot Starke war an der Architektur und Implementierung mittlerer und großer Systeme für Organisationen in verschiedenen Geschäftsbereichen beteiligt, hauptsächlich im Finanzwesen, in der Automobilindustrie, in der Logistik und in der Telekommunikation, derzeit mit dem Schwerpunkt auf Entwicklung und Verbesserung von Legacy-Systemen sowie Software-Reviews. Er hat zahlreiche Bücher über Software-Architektur und verwandte Themen geschrieben, veröffentlicht regelmäßig Fachartikel und gibt seine Erfahrungen auf Konferenzen und in Trainings weiter. Gernot lebt in Köln.

Benjamin Wolf ist Entwickler und Architekt bei INNOQ. Er erträgt unsauberen Code nur schwer und scheut nicht vor umfangreichen Refactorings zurück. Seine Vorstellung von Softwarequalität und ordentlicher Softwareentwicklung gibt er als Sprecher bei Konferenzen und Meetups, als Trainer sowie als Consultant weiter. Dabei ist ihm wichtig, dass nicht nur Technologien, sondern vor allem die Einstellung eines Teams für eine gute Softwarequalität ausschlaggebend sind.

Gernot Starke, Benjamin Wolf
Gernot Starke, Benjamin Wolf
flag VORTRAG MERKEN

Vortrag Teilen

10:00 - 17:00
Mo 2
Ausgebucht Architekturen effizient dokumentieren und kommunizieren mit Architecture Decision Records
Architekturen effizient dokumentieren und kommunizieren mit Architecture Decision Records

Architekturentscheidungen werden häufig und zumeist implizit getroffen. Da eine Dokumentation dieser nur selten erfolgt, existiert Wissen über diese nur in den Köpfen der Entwickler und eine Weitergabe des Wissens ist schwer bis unmöglich. Ein Wildwuchs verschiedener Implementierungsstile und eine Erosion der Architektur ist der logische Schluss.

Am Beispiel wird gezeigt, wie die Arbeit mit Michael Nygards ADRs erfolgreich etabliert werden kann, um Entscheidungen zu dokumentieren, und welche Tools existieren, um deren Umsetzung automatisiert zu prüfen.

Zur Teilnahme benötigt wird ein Laptop mit Google Chrome oder Mozilla Firefox.

Maximale Teilnehmerzahl: 30

Zielpublikum: Softwareentwickler:innen sowie Architektinnen und Architekten mit Nähe zum Code
Voraussetzungen: Erfahrung im Umgang mit einer IDE
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Dieser Workshop möchte mit Michael Nygards "Architecture Decision Records" (ADRs) einen leichtgewichtigen Ansatz zur Dokumentation und Kommunikation von Architektur-Eentscheidungen aufzeigen. Am Beispiel soll erläutert werden, wie sich das Treffen und Kommunizieren von Entscheidungen mit ADRs effizient in den Entwicklungsprozess integrieren lassen. Das Hauptaugenmerk liegt dabei insbesondere in dem Nachvollziehbar-Machen der Entscheidungen für alle Entwickler. Es wird gezeigt, wie sich ADRs mit AsciiDoc versioniert und nachvollziehbar im Projekt integrieren lassen, diese zentral allen zur Verfügung gestellt werden können und wie die Einhaltung der Entscheidungen automatisiert geprüft werden kann. Der Workshop basiert auf den Erfahrungen bei verschiedenen Kunden, bei welchen die Dokumentation mittels Architecture Decision Records erfolgreich eingeführt wurde.

Stephan Pirnbaum ist Consultant bei der BUSCHMAIS GbR. Er beschäftigt sich leidenschaftlich gern mit der Analyse und strukturellen Verbesserung von Softwaresystemen im Java-Umfeld. In Vorträgen und Workshops präsentiert er seine gesammelten Erfahrungen und genutzten Methodiken.
Stephan Pirnbaum
Stephan Pirnbaum
flag VORTRAG MERKEN

Vortrag Teilen

10:00 - 17:00
Mo 5
MLOps – Wie passen Machine Learning, IoT und Software-Architekturen zusammen?
MLOps – Wie passen Machine Learning, IoT und Software-Architekturen zusammen?

Die Themen KI und Maschinelles Lernen (ML) sind heute allgegenwärtig. Meistens geht es um technische Konzepte oder mathematische Modelle. Viel zu wenig findet Beachtung, wie sich KI im Allgemeinen und ML im Speziellen in den Entwicklungsprozess und in Software- & Systemarchitekturen integrieren lassen. Das Tutorium adressiert dieses Thema anhand von IoT-Systemen, da sich dadurch auch die Systemseite beleuchten lässt. Sein Inhalt umfasst den Einstieg in KI/ML, den MLOps-Zyklus und notwendige architektonische Maßnahmen.

Software: Edge Impulse, Teilnehmende können einen beschränkten Account anlegen.

Zielpublikum: Software-Architekt:innen, technologieinteressierte Entscheider:innen
Voraussetzungen: Tiefe Kenntnisse über Software-Architekturen und Software-Entwicklung
Schwierigkeitsgrad: Anfänger

Extended Abstract
Die Themen Künstliche Intelligenz (KI) und Maschinelles Lernen (ML) sind heute allgegenwärtig. Meistens geht es um technische Konzepte oder mathematische Modelle. Viel zu wenig findet Beachtung, wie sich KI im Allgemeinen und ML im Speziellen in den Entwicklungsprozess und in Software- & System-Architekturen integrieren lassen.

Hier stellen sich verschiedene Fragen:

  • Was bedeutet ML überhaupt und wozu ist es gut?
  • Wie sollten Entwicklungsprozess und Rollenverteilung aussehen?
  • Was ist MLOps und wie setze ich es um?
  • Lässt sich ML auch für IoT-Geräte nutzen und falls ja wie?
  • Welche Auswirkungen hat ML auf Software-Architekturen und welche Best/Bad Practices gibt es?

Das Tutorium adressiert dieses Thema anhand von IoT-Systemen, da sich dort auch die Systemseite beleuchten lässt. Angefangen vom Einstieg in ML über den MLOps-Zyklus bis hin zu architektonischen Maßnahmen erstreckt sich das abgedeckte Spektrum.

Zu den Lernzielen gehört unter anderem:

  • Grundlegendes Verständnis über KI und ML und ihrer Grenzen
  • Verstehen und abschätzen von MLOps
  • Einblick in Rollenverteilung und Integration von ML in den Entwicklungsprozess
  • Kennenlernen von Software-Architekturaspekten bei ML
Prof. Dr. Michael Stal forscht bei Siemens Technology an Themen rund um Software-Architektur und ist seit drei Jahrzehnten international als Experte auf diesem Gebiet renommiert.
Michael Stal
Michael Stal
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 17:00
Mo 18
The KISS Architecture Model
The KISS Architecture Model

There are several architecture models with prescribed views and notations. The Keep It Short & Simple architecture model is different. We create pieces of documentation iff they benefit stakeholders. We do so using drawing tools, not modeling tools. We say no to BDUF and yes to Important Design Up Front. We follow 7 tips for creating diagrams that are expressive, not ambiguous, and help you to successfully understand and evolve them, and build a system from them. We complement the design diagrams that describe structure and behavior with ADRs.

Target Audience: Developers and anyone else who plays the role of architect.
Prerequisites: If you've ever developed software, you're ready.
Level: Basic

Extended Abstract
Do you create or use architecture documentation? Have you ever been confused and wondered about the meaning of a box or arrow in a design diagram? Do you think architecture documentation is costly or time consuming? If your answer is yes to any of these questions, this tutorial has practical and valuable information for you. There are several proposed architecture models with prescribed views and notations. The Keep It Short and Simple architecture model is different. We create pieces of documentation if they benefit stakeholders. We do so primarily use drawing tools, not modelling tools. We say no to Big Design Up Front (BDUF) but say yes to Important Design Up Front (IDUF). We follow 7 guidelines for creating informal design diagrams that are expressive, not ambiguous, and effectively help you and others to successfully understand them, evolve them, and build a system from them. Finally, we complement the essential design diagrams that describe structure and behaviour with architecture decision records (ADRs) for the important design decisions.

In the tutorial we look at several example architectures from real world systems. Most are good examples, but we also turn a critical eye on known products' architecture diagrams with several opportunities for improvement. Participants can also share their experience throughout. The tutorial also includes a fun online game and a hands-on exercise.

Tutorial minutiae include: what is the minimum architecture documentation expected, what design decisions are important enough to deserve an ADR, examples of drawing tools, who should be responsible for architecture documentation, how to complement structural diagrams with behavior diagrams.

Paulo Merson has been programming in the small and in the large for over 30 years. He's a dev at the Brazilian Federal Court of Accounts, adjunct faculty in the Masters of Software Engineering program at Carnegie Mellon University, and faculty in the University of Brasilia masters program in Applied Computing. He often delivers professional training to fellow devs in the US and Europe. His speaking experience also includes talks at DDD Europe, OOP, XP Agile, JavaOne, SPLASH/OOPSLA, SATURN, and lectures to grad students in different universities. Paulo holds a BSc in CS from University of Brasilia and a Master of Software Engineering from Carnegie Mellon University.
Paulo Merson
Paulo Merson
Vortrag: Mo 18
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmo 1
Wenn "Microservice-Architektur" die Antwort ist, was war dann eigentlich die Frage?
Wenn "Microservice-Architektur" die Antwort ist, was war dann eigentlich die Frage?

Als Entwickler kann man ihnen fast nicht ausweichen – den Microservice-Architekturen. Die Entscheidung für deren Einsatz ist oft schon getroffen, bevor es die erste User-Story im Backlog und die erste Zeile Code im Repository gibt.
„Microservice“ lautet scheinbar die Antwort auf alle Fragen nach der besten Umsetzung heutiger Business-Probleme. Netflix und andere dienen als schillerndes Beispiel für den Erfolg dieser Architektur.
Aber sind sie wirklich der einzige Weg ins Ziel? Sind sie Fluch oder Segen? Dem wollen wir auf den Grund gehen.

Zielpublikum: Entwickler:innen, Architekt:innen, Entscheider mit technischem Background
Voraussetzungen: Kenntnisse in Java oder einer anderen objektorientierten Sprache, Grundkenntnisse in Software-Architektur
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Als Entwickler kann man ihnen fast nicht ausweichen – den Microservice-Architekturen. Egal ob Neuauflage einer Bestandsanwendung oder Green-Field-Projekt, der Architektur-Ansatz ist oft schon festgelegt, bevor es die erste User-Story im Backlog und die erste Zeile Code im Repository gibt.
„Microservice“ lautet scheinbar die Antwort auf alle Fragen nach der besten Umsetzung heutiger Business-Probleme. Unternehmen wie Netflix dienen als schillerndes Beispiel für den Erfolg dieser Architektur. Und alle wollen nacheifern. Mit modernen Tools, agilen Methoden und motivierten Entwicklern wird das schon zu schaffen sein.
Aber was waren eigentlich die Architektur-Zziele, die zur Entscheidung geführt haben? Und welche Alternativen hätte es gegeben? Was sind die Kernprobleme, die wir lösen müssen? Und sind Microservices wirklich der einzige Weg ins Ziel? Oder wieso wurden sie gewählt?
Wir haben uns angeschaut, warum Vergleiche mit Netflix hinken, warum Microservice-Architekturen sich oft zu mehr Fluch als Segen entwickeln und dass die Rolle der Entwickler bei diesem Scheitern oft unterschätzt wird.

Tilmann Glaser ist freiberuflicher Software Engineer. Als iSAQB zertifizierter Software-Architekt betreut er Entwicklungsprojekte und unterstützt Teams als Mentor für agile Software-Engineering-Methoden (ASE). Dabei ist ihm wichtig, selbst mit anzupacken und als Teil der Teams aktiv an der Software-Entwicklung teilzunehmen. Seine mehr als fünfzehn Jahre Erfahrung in verschiedenen Rollen in IT-Projekten bringt er gerne ein, um neue Blickwinkel aufzuzeigen. Seine Kernthemen sind agile Transition, Architektur in agilen und klassischen Umfeldern, Clean Code, Test-Driven Development (TDD) und Project Recovery.
Peter Fichtner ist seit 1995 bei Atruvia in Karlsruhe tätig. Nach über zehn Jahren in der Anwendungsentwicklung und weiteren 10 Jahren in der Architektur greift er auf breitgefächerte Erfahrungen im Java-Umfeld zurück. Aktuell fokussiert er die Themen Test-Driven-Development (TDD), Continuous Integration (CI), Clean Code (CC) sowie agile Entwicklungsmethoden. In seiner Rolle als Coach für agiles Softwareengineering (ASE) unterstützt Peter Fichtner seit acht Jahren agile und nicht-agile Teams bei Atruvia mit Schulungen und Coachings.
Tilmann Glaser, Peter Fichtner
Tilmann Glaser, Peter Fichtner
flag VORTRAG MERKEN

Vortrag Teilen

, (Dienstag, 01.Februar 2022)
09:00 - 10:45
Di 1.1
Jenseits Micro-Frontends: Der Frontend-Modulith
Jenseits Micro-Frontends: Der Frontend-Modulith

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

Manfred Steyer ist Trainer, Berater und programmierender Architekt mit Fokus auf Angular, Google Developer Expert (GDE) für Angular und Trusted Collaborator im Angular-Team. Erunterstützt Firmen im gesamten deutschen Sprachraum, schreibt für O'Reilly, Heise und das Java-Magazin, spricht regelmäßig auf Konferenzen.
Applications Instead of Libraries: Micro Frontends Implemented Through Module Federation
Applications Instead of Libraries: Micro Frontends Implemented Through Module Federation

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

Mario Fernandez develops software for a living, and then he goes home and continues thinking about software because he just can't get enough.
He is a full-stack engineer with infrastructure skills. He has led multiple agile delivery teams, being an individual contributor, driving architecture topics, and coaching and supporting other team members.
He believes in high-quality software and advocates for Continuous Delivery, Tes- Driven Development, and quick iteration. He writes and speaks about his experience regularly.
Manfred Steyer
Mario Fernandez
Manfred Steyer

Vortrag Teilen

Mario Fernandez
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:30
Di 5.1
Forschungsvorhaben SoftAWERE – Energieeffizienz von Software anwendungsnah messen und bewerten
Forschungsvorhaben SoftAWERE – Energieeffizienz von Software anwendungsnah messen und bewerten

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

Max Schulze ist Geschäftsführer der Sustainable Digital Infrastructure Alliance (SDIA). Als Software-Ingenieur und Cloud-Experte bringt Max seine Erfahrung in die Transformation der Digitalwirtschaft ein, um diese nachhaltig zu gestalten.
Max Schulze
Max Schulze
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:30
Di 6.1
Organizational Agility in a Post-Pandemic World
Organizational Agility in a Post-Pandemic World

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)

Eric Abelen is Enterprise Agile Coach at ING Netherlands with agile transformation lead experience in ING's Support functions, HR, and (IT driven) delivery organizations. Eric's professional profile is that of Agile Coach, Lean Consultant, Business Manager, Process Manager, and Program/Change Manager. Before joining ING, he helped the Customer Care and Logistics organizations of Hewlett-Packard to adopt global ways of working. Eric enjoys reflecting on enterprise agility health, see e.g. Supporting Agile Adoption Initiative | Agile Alliance.
Lieke Jansen is an Enterprise Agile Coach at ING Netherlands. After different roles in Account Management, Project Management and General Management, she became Agile Enterprise Coach in 2015. From the start of the Agile Transformation, she has been involved and has coached (leadership) teams at different stages of their ambition to become high performing. Cultural challenges, team dynamics and systemic transition management have her special interest.
Eric Abelen, Lieke Jansen
14:00 - 14:45
Di 1.2
Hilfe, wir syncen!
Hilfe, wir syncen!

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.

Lars Hupel ist Senior Consultant bei INNOQ in München und ist bekannt als einer der Gründer der Typelevel-Initiative, die sich der Entwicklung von typgetriebenen Scala-Bibliotheken in einer einsteigerfreundlichen Umgebung verschrieben hat. Er spricht oft auf Konferenzen und ist im Open-Source-Umfeld in Scala unterwegs. Außerdem programmiert und redet er gern über Haskell, Prolog und Rust.
Lucas Dohmen ist Senior Consultant bei INNOQ und beschäftigt sich mit der Architektur, Konzeption und Umsetzung von Web-Anwendungen in Front- und Backend. Er programmiert in Ruby und JavaScript und hilft bei der Entscheidung und Einführung verschiedener NoSQL-Lösungen. Lucas ist Autor des Buchs „The Rails 6 Way“. Seine Stimme ist regelmäßig im INNOQ Podcast zu hören. Außerhalb seiner Arbeit beschäftigt er sich mit Open-Source- und Community-Arbeit (wie die Organisation und das Coaching beim lokalen CoderDojo).
Lars Hupel, Lucas Dohmen
Lars Hupel, Lucas Dohmen
Vortrag: Di 1.2
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 3.2
Rust in a Polyglot World, from Client to Cloud
Rust in a Polyglot World, from Client to Cloud

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.

Christopher Prohm is working as a Data Scientist for Volkswagen. His main focus is the application of machine learning and data analytics to problems in the area of technical development.
Christopher Prohm
Christopher Prohm
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 5.2
Software Meets Quality: Nachhaltige Qualitätssicherung in extern vergebenen Softwareprojekten
Software Meets Quality: Nachhaltige Qualitätssicherung in extern vergebenen Softwareprojekten

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

Robertino Solanas ist Trainer, Consultant und Architekt mit dem Schwerpunkt Cloud-Technologien. Als Referent für Softwarequalität und -design beim ITZBund berät er Ministerien und Länder zu IT-Vorhaben.
Dirk Mahler ist Senior-Consultant bei der BUSCHMAIS GbR. Die Schwerpunkte seiner Tätigkeit liegen im Bereich Architektur und Qualitätssicherung sowie der Entwicklung des QA-Werkzeugs jQAssistant.
Robertino Solanas, Dirk Mahler
Robertino Solanas, Dirk Mahler
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 6.2
Process-Tinder – Wenn ich mich nur nach den schönen Bildern entscheide …
Process-Tinder – Wenn ich mich nur nach den schönen Bildern entscheide …

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.

Michael Mahlberg ist methoden-agnostischer Methodenberater seit den 1980ern und betreibt sein eigenes Unternehmen für Methodenberatung in Köln, die TCG The Consulting Guild GmbH.
Er verwendet einen Großteil seiner Zeit dazu, Kunden bei ihrer Suche nach effektiverer Arbeit zu unterstützen – häufig durch die Anwendung von Konzepten aus den Bereichen Lean, Kanban, Agile und Organisationsentwicklung.
Falk Kühnel ist begeisterter Agilist auf der Suche nach Glück.
Er beschäftigt sich seit 1998 mit XP, Scrum und Co.
Er ist Dipl.-Inf., Certified Scrum Trainer, Developer Trainer, CS(T|D|M|PO), TKP und praktizierender Zyniker.
Michael Mahlberg, Falk Kühnel
Michael Mahlberg, Falk Kühnel
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 1.3
The Root of All Evil: Shared Mutable State and How to Get Rid of It
The Root of All Evil: Shared Mutable State and How to Get Rid of It

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.

Michael Sperber is CEO of Active Group in Tübingen, Germany. Mike specializes in functional programming and has been an internationally recognized expert in the field: He has spoken at the top conferences in programming languages, authored many papers on the subject as well as several books. Moreover, he is an expert on teaching programming.
Michael Sperber
Michael Sperber
Vortrag: Di 1.3
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 5.3
arc42, die Achte
arc42, die Achte

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.

Dr. Gernot Starke (INNOQ Fellow) ist Coach, Berater und Trainer für methodische Software-Architektur und Software-Engineering, (Mit-)Gründer von arc42.org, Gründer von aim42.org. Gernot Starke war an der Architektur und Implementierung mittlerer und großer Systeme für Organisationen in verschiedenen Geschäftsbereichen beteiligt, hauptsächlich im Finanzwesen, in der Automobilindustrie, in der Logistik und in der Telekommunikation, derzeit mit dem Schwerpunkt auf Entwicklung und Verbesserung von Legacy-Systemen sowie Software-Reviews. Er hat zahlreiche Bücher über Software-Architektur und verwandte Themen geschrieben, veröffentlicht regelmäßig Fachartikel und gibt seine Erfahrungen auf Konferenzen und in Trainings weiter. Gernot lebt in Köln.
Gernot Starke
Gernot Starke
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 6.3
Softwareplattformen und Product Ownership
Softwareplattformen und Product Ownership

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

Roman Pichler arbeitet als Produktmanagement-Experte mit Schwerpunkt agiles Produktmanagement. Er schult seit über 15 Jahren Produktmanager und Product Owner und hilft Unternehmen, ihr Produktmanagement zu verbessern. Roman ist der Autor dreier Produktmanagementbücher, schreibt einen Blog, bietet eine Reihe von kostenlosen Produktmanagement-Tools an, und macht seinen eigenen Podcast.

Stefan Roock (it-agile) hilft Unternehmen, Führungskräften und Teams dabei, ihre Potenziale zu entfalten - hin zu erfolgreichen Unternehmen, die ihre Kunden und Mitarbeiter begeistern. Er ist davon überzeugt, dass dazu strukturelle, personelle und interpersonelle Themen im Zusammenspiel adressiert werden müssen.

Stefan Roock hat seit 1999 agile Ansätze in Deutschland maßgeblich mit verbreitet und weiterentwickelt. Zunächst hat er als Entwickler in agilen Teams, später als Scrum Master/Agile Coach und Product Owner gearbeitet. Heute arbeitet er zusammen mit seinen Kollegen daran, dass Unternehmen langfristig mit agilen Denk- und Arbeitsweisen erfolgreich sind. Dabei fokussiert er auf agile Leadership.

Er ist regelmäßiger Sprecher zu agilen Themen auf Konferenzen, bei User Groups und in Unternehmen. Außerdem schreibt er Bücher und Artikel zu agilen Themen

Roman Pichler, Stefan Roock
Roman Pichler, Stefan Roock
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 7.3
Software-Architektur für Machine Learning
Software-Architektur für Machine Learning

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.

Stefan Toth ist Geschäftsführer und Mitgründer der embarc GmbH. Seine Beratungsschwerpunkte liegen in der Konzeption und der Bewertung mittlerer bis großer Softwarelösungen, der Weiterentwicklung von Systemlandschaften sowie der Verbindung dieser Themen zu agilen Vorgehen. Er ist Autor zahlreicher Artikel und des Buchs „Vorgehensmuster für Software-Architektur“.
Stefan Toth
Stefan Toth
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 1.4
Writing less code with Serverless on AWS
Writing less code with Serverless on AWS

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 

Vadym Kazulkin is Head of Development at ip.labs GmbH, a 100% subsidiary of the FUJIFLM Group, based in Bonn. ip.labs is the world's leading white label e-commerce software imaging company. Vadym has been involved with the Java ecosystem for over 20 years. His current focus and interests include the design and implementation of highly scalable and available solutions, Serverless and AWS Cloud. Vadym is the co-organizer of the Java User Group Bonn and Serverless Bonn Meetup, and a frequent speaker at various Meetups and conferences.
Vadym Kazulkin
Vadym Kazulkin
Vortrag: Di 1.4
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 5.4
Architektur-Bewertung mit dem MMI
Architektur-Bewertung mit dem MMI

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.

Dr. Carola Lilienthal ist Geschäftsführerin bei der WPS - Workplace Solutions GmbH und Mitglied der Geschäftsleitung. Seit 1998 entwickelt sie qualitativ hochwertige Softwaresysteme mit ihren Teams. Carola hält regelmäßig Vorträge auf Konferenzen, schreibt Artikel und hat ein Buch zum Thema „Langlebige Software-Architekturen“ veröffentlicht.
Carola Lilienthal
Carola Lilienthal
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 6.4
Adaptive Systems with Wardley Mapping, Domain-Driven Design, and Team Topologies
Adaptive Systems with Wardley Mapping, Domain-Driven Design, and Team Topologies

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.

Susanne Kaiser is an independent tech consultant supporting organizations to build and run software products from idea to production with a focus on socio-technical systems. Susanne was previously working as a startup CTO. She has a background in computer sciences and experience in software development and software architecture for more than 18 years. Susanne presents regularly at international tech conferences as a speaker.
, (Mittwoch, 02.Februar 2022)
09:00 - 10:30
Mi 1.1
Shared Data in verteilten Architekturen
Shared Data in verteilten Architekturen


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.

Lars Röwekamp, Gründer des IT-Beratungs- und Entwicklungsunternehmens OPEN KNOWLEDGE GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise- und Cloud-Computing, wobei neben Design- und Architektur-Fragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen.
Lars Röwekamp
Lars Röwekamp
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Mi 9.1
Humane On-Call: Alerting Doesn't Have to be Painful
Humane On-Call: Alerting Doesn't Have to be Painful

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.

Mario Fernandez develops software for a living, and then he goes home and continues thinking about software because he just can't get enough.
He is a full-stack engineer with infrastructure skills. He has led multiple agile delivery teams, being an individual contributor, driving architecture topics, and coaching and supporting other team members.
He believes in high-quality software and advocates for Continuous Delivery, Tes- Driven Development, and quick iteration. He writes and speaks about his experience regularly.
DevOps: the Secrets to Sustainable Innovation
DevOps: the Secrets to Sustainable Innovation

Our world accelerates, innovation cycles get shorter, causing innovation pressure for software companies to deliver their software faster and with high quality. DevOps shows us that delivery speed and quality are no trade-offs. You can have both!

In this talk, we will go on a journey from the beginnings of DevOps to today. We discuss findings of the famous DevOps study, detailed out in the Accelerate book. I make a case, why every company should measure the Four Key Metrics of DevOps and show you different ways to approach this.

Target Audience: Architects, Engineering Managers, Project Leaders, Developers
Prerequisites: You should have worked on at least one IT project or product.
Level: Advanced

Felix Müller is an independent technology and organization consultant, focussing on software architecture. He gained vast experience in distributed software architectures and agile product development by working in Berlin’s tech scene for over a decade. He thinks life is too short to argue endlessly about different architectural styles when you can measure and iterate on them. A bias for action and simplicity is what drives him.
Mario Fernandez
Felix Müller
Mario Fernandez

Vortrag Teilen

Felix Müller
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Mi 1.2
Development and Discovery in Large-Scale Organizations
Development and Discovery in Large-Scale Organizations

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

Erik Wilde works in the Axway Catalyst team and focuses on API strategy, API programs, and API platforms. His main goal is to make sure that organizations make the right decisions when it comes to using APIs as the foundation of their digital transformation initiatives. Erik has a Ph.D. from ETH Zurich, is the author of many articles, papers, and books, is a frequent speaker at global API events, and contributes to standardization activities to help improving the way how APIs are designed, managed, and used.
Erik Wilde
Erik Wilde
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 1.3
Technische Schulden: Software langfristig weiterentwickeln
Technische Schulden: Software langfristig weiterentwickeln

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

Eberhard Wolff ist Fellow bei INNOQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u. a. zu Continuous Delivery und Microservices, und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Continuous Delivery, DevOps und Microservices.
Eberhard Wolff
Eberhard Wolff
Vortrag: Mi 1.3
flag VORTRAG MERKEN

Vortrag Teilen

15:45 - 16:30
KeyMi 2
KEYNOTE: CUPID - for joyful coding
KEYNOTE: CUPID - for joyful coding

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?

Daniel Terhorst-North uses his deep technical and operational knowledge to help business and technology leaders to optimise digital product organisations. He puts people first and finds simple, pragmatic solutions to business and technical problems, often using lean and agile techniques. With thirty years of experience in IT, Daniel is a frequent speaker at technology and business conferences worldwide. The originator of Behaviour-Driven Development (BDD) and Deliberate Discovery, Daniel has published feature articles in numerous software and business publications, and contributed to “The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends” and “97 Things Every Programmer Should Know: Collective Wisdom from the Experts”. He occasionally blogs at https://dannorth.net/blog.
Daniel Terhorst-North
Daniel Terhorst-North
Track: Keynote
Vortrag: KeyMi 2
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 1.4
7 Missverständnisse zu Software- Architektur
7 Missverständnisse zu Software- Architektur

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.

Dr. Carola Lilienthal ist Geschäftsführerin bei der WPS - Workplace Solutions GmbH und Mitglied der Geschäftsleitung. Seit 1998 entwickelt sie qualitativ hochwertige Softwaresysteme mit ihren Teams. Carola hält regelmäßig Vorträge auf Konferenzen, schreibt Artikel und hat ein Buch zum Thema „Langlebige Software-Architekturen“ veröffentlicht.
Carola Lilienthal
Carola Lilienthal
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmi 1
Moderne Web-Architekturen erfordern moderne Sicherheitsmaßnahmen
Moderne Web-Architekturen erfordern moderne Sicherheitsmaßnahmen

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

Lisa Moritz ist Senior Consultant bei INNOQ. Ihre Schwerpunkte liegen in Web-Architekturen und der Programmierung mit Java sowie JavaScript. Sie ist sowohl im Backend als auch im Frontend unterwegs. Neben der Programmierung und Konzipierung von Architekturen engagiert sie sich im Bereich Sketchnotes und macht seit Juni 2020 regelmäßig Sketchnotes für den Podcast Software-Architektur im Stream. Dort steht sie auch gelegentlich als Gast oder Interviewer vor der Kamera.
Christoph Iserlohn ist Senior Consultant bei INNOQ. Er hat langjährige Erfahrung mit der Entwicklung und Architektur von verteilten Systemen. Sein Hauptaugenmerk liegt dabei auf den Themen Skalierbarkeit, Verfügbarkeit und Sicherheit.
Lisa Moritz, Christoph Iserlohn
Lisa Moritz, Christoph Iserlohn
Vortrag: Nmi 1
flag VORTRAG MERKEN

Vortrag Teilen

, (Donnerstag, 03.Februar 2022)
09:00 - 10:30
Do 1.1
Architekturexplizite Java-Applikationen mit jMolecules
Architekturexplizite Java-Applikationen mit jMolecules

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.
 

Oliver Drotbohm ist Senior Principal Software Engineer bei VMware. Seit über 15 Jahren widmet er sich dem Entwickeln von Java-Enterprise-Applikationen, Open-Source-Projekten und ist Mitglied der JPA Expert Group. Seine Arbeitsschwerpunkte liegen im Bereich Software-Architektur, Domain-Driven Design, REST, Spring und Persistenztechnologien. Er ist regelmäßiger Sprecher auf deutschen und internationalen Konferenzen sowie Autor von Fachartikeln. Das neue Buch "Modulithic Applications with Spring" erscheint im Herbst 2021.
Stephan Pirnbaum ist Consultant bei der BUSCHMAIS GbR. Er beschäftigt sich leidenschaftlich gern mit der Analyse und strukturellen Verbesserung von Softwaresystemen im Java-Umfeld. In Vorträgen und Workshops präsentiert er seine gesammelten Erfahrungen und genutzten Methodiken.
Oliver Drotbohm, Stephan Pirnbaum
Oliver Drotbohm, Stephan Pirnbaum
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Do 5.1
Sustainability in Software Engineering - or how to fight climate change as a software engineer
Sustainability in Software Engineering - or how to fight climate change as a software engineer

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...
Martin leads the work on development environments for Spring and Spring Boot and is Sustainability Ambassador at VMware.
It's Coming! The Revolutionary Effect Of Climate on Architecture
It's Coming! The Revolutionary Effect Of Climate on Architecture

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.

Anne Currie has been in the tech industry for nearly 30 years. In the 90's she worked on high performance backend infrastructure. In the 00's on ecommerce, and in the 10's on cutting edge ops. The 20's is all about climate.
Martin Lippert
Anne Currie
Anne Currie
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:30
Do 6.1
Workshop: Resiliente Organisation trifft resiliente IT-Architektur
Workshop: Resiliente Organisation trifft resiliente IT-Architektur

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.

Alex Hoitz ist Wirtschaftspsychologin und Organisationsentwicklerin bei Scalamento. Ihr Purpose: Potenziale von Individuen und Organisationen entfalten. Ihre Superkraft: Für Alex ist kein Problem zu komplex.
Anne Herwanger ist Agile Coach und Organisationsentwicklerin bei Scalamento. Ihr Purpose: Organisationen human-friendly gestalten. Ihre Superkraft: Anne vereint Zug zum Ziel mit jeder Menge Improvisationstalent.
Alexandra Hoitz, Anne Herwanger
Alexandra Hoitz, Anne Herwanger
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:30
Do 7.1
Kommunikation und Bewertung – zwei unterschätzte Software-Architektur-Barrieren
Kommunikation und Bewertung – zwei unterschätzte Software-Architektur-Barrieren

Der Architekt erklärt die Software-Architektur, aber einige verstehen nur Bahnhof - wer kennt das nicht? Schlechte Kommunikation hat leider viele negativen Folgen. Entwickler verstehen die Architektur nicht und implementieren ihre eigene, Tester übersehen wichtige Aspekte, Manager können Architektur und Geschäftsziele nicht aufeinander abbilden. Daher spielen Kommunikation und kontinuierliches Review der Architektur eine wichtige, aber unterschätzte Rolle. Der Vortrag gibt sachdienliche Hinweise auf Best Practices und Fallstricke.

Zielpublikum: Entscheidungsträger, Architekt:innen
Voraussetzungen: Fortgeschrittene Kenntnisse in Software-Engineering und Software-Architektur
Schwierigkeitsgrad: Experte

Extended Abstract
Der Architekt erklärt die Software-Architektur, aber einige verstehen nur Bahnhof. Das kennt jeder, der schon schwierige Entwicklungsprojekte überlebt hat. Schlechte Kommunikation hat leider viele negativen Folgen. Entwickler verstehen die Architektur nicht und implementieren stattdessen ihre eigene, Tester übersehen wichtige Aspekte bei ihrer Teststrategie, Manager können Architektur und Geschäftsziele nicht aufeinander abbilden, Projektmanager den Stand der Dinge nicht vernünftig erfassen. Daher spielen Kommunikation und das kontinuierliche Review der Architektur eine wichtige, aber unterschätzte Rolle. Das betrifft nicht nur die zu erstellenden Artefakte, sondern auch andere relevante Aspekte wie Teammotivation und Soft Skills. Der Vortrag gibt sachdienliche Hinweise auf essenzielle Best Practices und Fallstricke, die in den Werkzeugkoffer von Software-Architekten gehören.

Prof. Dr. Michael Stal forscht bei Siemens Technology an Themen rund um Software-Architektur und ist seit drei Jahrzehnten international als Experte auf diesem Gebiet renommiert.
Michael Stal
Michael Stal
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Do 8.1
Domain-Driven Design für Legacy-Systeme
Domain-Driven Design für Legacy-Systeme

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

Eberhard Wolff ist Fellow bei INNOQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u. a. zu Continuous Delivery und Microservices, und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Continuous Delivery, DevOps und Microservices.
Domain Driven Transformation – über den Umbau von IT-Landschaften mit DDD
Domain Driven Transformation – über den Umbau von IT-Landschaften mit DDD

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.

Dr. Sönke J. Magnussen begann seine Karriere nach Studium und Promotion der Informatik bei der Deutschen Lufthansa als ABAP & Java-Entwickler sowie als Software-Architekt. Als Manager verantwortete er mehrere Teams für den Betrieb und die Weiterentwicklung von IT-Landschaften. Im Rahmen dieser Führungsfunktionen leitete er mehrere Digitalisierungsvorhaben sowie Redesign- und Einführungsprojekte für die Neuausrichtung von IT-Landschaften auf Digitalisierungs- und Cloud-Strategien. Als IT-Architekt und Consultant bei der WPS – Workplace Solutions hilft er jetzt Teams, IT-Landschaften auf die Zukunft auszurichten.
Henning liebt Programmieren in hoher Qualität. Diese Leidenschaft lebt er als Coder, Coach und Consultant bei der WPS - Workplace Solutions aus. Dort hilft er Teams dabei, Ihre gewachsenen Monolithen zu strukturieren oder neue Systeme von Anfang an mit einer tragfähigen Architektur zu errichten. Häufig kommen dann Microservices oder Self-Contained Systems heraus. Henning ist Autor von »Domain Storytelling« und dem www.LeasingNinja.io sowie Übersetzer von »Domain-Driven Design kompakt«.
Eberhard Wolff
Sönke Magnussen, Henning Schwentner
Sönke Magnussen, Henning Schwentner
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 1.2
EAM is Dead; Long live Agile. Agile is Dead; Long live Digital Transformation
EAM is Dead; Long live Agile. Agile is Dead; Long live Digital Transformation

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.

Nach dem Studium der Betriebswirtschaftslehre mit den Schwerpunkten Unternehmensführung und Informatik in Köln hat Michael Kunz fast 25 Jahre als Projektleiter, (Unternehmens-)Architekt, (Transformations-)Berater und Manager in der IT-Industrie gearbeitet. Dabei war er sowohl für Anwenderunternehmen als auch für Beratungs- und Produkthäuser tätig. In den letzten 10 Jahren hatte er die Verantwortung für die Sanierung einer ganzen Reihe von Großprojekten. In den letzten Jahren hat er Unternehmen in verschiedenen Branchen bei ihrer Digitalen Transformation auf Fach- und IT-Seite unterstützt - u. a. beim Aufbau Digitaler Geschäftsmodelle.
Michael Kunz
Michael Kunz
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 3.2
Hinter dem Hype
Hinter dem Hype

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

Klaus Marquardt ist Platform System Architect und gestaltet das technische Kernsystem von vernetzten Therapiegeräten. Er beschäftigt sich mit einfachen, skalierbaren und wiederverwendbaren Lösungen, und den Zusammenhängen zwischen Projekten, Personen, Organisationen und Prozessen.
Klaus Marquardt
Klaus Marquardt
Vortrag: Do 3.2
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 6.2
Mythos Teamautonomie – Warum sie eine Illusion ist und wir sie trotzdem brauchen
Mythos Teamautonomie – Warum sie eine Illusion ist und wir sie trotzdem brauchen

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.

Gerrit Beine ist Trainer und Berater bei INNOQ. Er ist seit 1998 in der IT unterwegs, seit 2001 mit agilen Methoden. Er war viele Jahre lang Software-Architekt in großen Projekten. Nach 10 Jahren agile Coaching baut er zwischen Organisationsstrukturen und langlebigen Software-Architekturen.
Gerrit hat Informatik studiert, ist Autor zahlreicher Fachartikel und regelmäßig als Sprecher auf Konferenzen zu den Themen Software-Architektur und Agile zu treffen.

Gerrit Beine
11:00 - 11:45
Do 7.2
Meisterwerk oder Groschenroman? 7 Anti-Patterns und Tipps für gute Architektur-Dokumentationen
Meisterwerk oder Groschenroman? 7 Anti-Patterns und Tipps für gute Architektur-Dokumentationen

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.

Matthias Naab ist Softwarearchitekt am Fraunhofer IESE und leitet seit 2020 die Hauptabteilung Information Systems. Seit 2010 verantwortet er die Weiterentwicklung von Architekturmethoden und die Beratung von Kunden aus der Wirtschaft. Er hat in zahlreichen Projekten in unterschiedlichsten Branchen Architekturen bewertet, Systeme verbessert und innovative Systeme mitgestaltet. Matthias Naab hält regelmäßig Vorträge zu Softwarearchitektur und Digitalen Ökosystemen.
Dominik Rost ist seit 2009 Softwarearchitekt am Fraunhofer IESE und leitet dort seit 2020 die Abteilung »Architecture-Centric Engineering (ACE)«. Er berät Kunden aller Branchen dabei, die Architektur ihrer Produkte zu entwickeln, zu evaluieren und zu dokumentieren, und die Skills im Bereich Softwarearchitektur zu verbessern. Über seine Erfahrungen spricht er regelmäßig bei Konferenzen. Darüber hinaus leitet er das Seminar »Softwarearchitektur« der Fraunhofer Academy.
Matthias Naab, Dominik Rost
Matthias Naab, Dominik Rost
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 1.3
Events@Allianz
Events@Allianz

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.

Annegret Junker ist Lead Architect bei Allianz Deutschland. Sie arbeitet seit mehr als 30 Jahren in der Software-Entwicklung in unterschiedlichen Rollen und unterschiedlichen Domänen wie Automotive, Versicherungen und Finanzdienstleistungen. Besonders interessiert sie sich für DDD, Microservices und alles, was damit zusammenhängt. Derzeit arbeitet sie in einem großen Versicherungs-Projekt als übergreifende Architektin.
Annegret Junker
Annegret Junker
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 5.3
Monolith To Microservices
Monolith To Microservices

Big Bang rebuilds of systems are so 20th century. With our users expecting new functionality to be shipped more frequently than ever before, we no longer have the luxury of a complete system rebuild. In fact, a big bang migration of a monolithic architecture into a microservice architecture can be especially problematic, as we’ll explore in this talk.

We want to ship features, but we also want to improve our architecture, and for many of us this means breaking down existing systems into microservices. But how do you do this while still regularly releasing new features?

In this talk, I’ll share with you some key principles and a number of patterns which you can use to incrementally decompose an existing system into microservices. I’ll also cover off patterns that can work to migrate functionality out of systems you can’t change, which are useful when working with very old systems or vendor products. We'll look at the use of strangler patterns, change data capture, database decomposition and more.

Coming out of this talk you’ll have a better understanding of the importance of evolving an architecture, along with some concrete patterns to help you do that on your own projects.

Target Audience: Developers, architects, operations, testers and anyone actively involved in software delivery
Prerequisites: Basic knowledge about microservices and software delivery
Level: Advanced

Sam is a technologist and consultant who focuses in the areas of cloud, continuous delivery and microservices. As well as helping companies all over the world get software into production, Sam is also an experienced conference speaker and writer. He is author of Building Microservices, 1st Edition (O’Reilly, 2015), Monolith To Microservices (O’Reilly, 2019), and Building Microservices, 2nd Edition (O’Reilly, 2021).
Sam Newman
Sam Newman
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 6.3
The CTO Guide on How to Build a Successful Product Development Organization
The CTO Guide on How to Build a Successful Product Development Organization

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

Matthias Patzak is a Principal Advisor at Amazon Web Services. Before joining Amazon Web Services, Matthias was Vice President IT at AutoScout24 and Chief Digital Officer at Home Shopping Europe. In both companies he introduced lean-agile operational models at scale and lead successful cloud transformations resulting in shorter delivery times and increased business value.
14:30 - 15:30
Do 7.3
Der Architekturüberblick. Lösungsansätze prägnant und nachvollziehbar darstellen
Der Architekturüberblick. Lösungsansätze prägnant und nachvollziehbar darstellen

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.

Stefan Zörner ist Software-Architekt bei embarc in Hamburg. Er wirkt bei Entwurfs- und Umsetzungsfragen mit, unterstützt beim Festhalten von Architektur und beleuchtet Lösungsansätze in Bewertungen. Sein Wissen und seine Erfahrung teilt er regelmäßig in Vorträgen, Artikeln und Workshops. Stefan ist aktives Board-Mitglied im iSAQB und Autor des Buchs „Software-Architekturen dokumentieren und kommunizieren“.
Stefan Zörner
Stefan Zörner
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Do 1.4
Keeping CALM – Konsistenz in verteilten Systemen leichtgemacht
Keeping CALM – Konsistenz in verteilten Systemen leichtgemacht

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.

Susanne Braun ist Entwicklerin, Software-Architektin und Forscherin am Fraunhofer IESE. Sie hat mehr als 10 Jahre professionelle Erfahrung und war lange Zeit für Capgmeini sd&m und die Accso GmbH tätig, bevor sie zu Fraunhofer wechselte. In ihrer PhD erforscht sie, wie man zu besseren Software-Architektur-Konzepten für verteilte Systeme kommt, die mit Eventual Consistency klarkommen müssen. Sie spricht regelmäßig auf Konferenzen, ist aktives Mitglied der Java User Group Community, Mitglied im Programm-Komitee der JavaLand und Co-Organisatorin der CyberLand Online-Events.
Susanne Braun
Susanne Braun
Vortrag: Do 1.4
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Do 6.4
Teamstrukturen für Softwaremodernisierung
Teamstrukturen für Softwaremodernisierung

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.

Mick Hohmann hat 15 Jahre Projektmanagementerfahrung und ist seit 2015 als Agile Coach für Mayflower in Projekten tätig. Micks Leidenschaft ist es, Menschen & Teams zu inspirieren und für ihre Aufgabe zu begeistern, damit sie fokussierter und motivierter wertschöpfende Produkte erzeugen können.
Johann-Peter Hartmann programmiert seit 1984 und verdient seit 1992 sein Geld mit Software. Er ist ein Hacker gone Management mit viel Erfahrung als CTO, Founder, Advisor und Investor, mit Spaß an Architektur, Leadership, Agile, DevOps und natürlich Security.
Mick Hohmann, Johann-Peter Hartmann
Mick Hohmann, Johann-Peter Hartmann
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Do 7.4
Technical Debt: A Management Problem That Requires a Management Solution
Technical Debt: A Management Problem That Requires a Management Solution

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)

Scott Ambler is the Vice President, Chief Scientist of Disciplined Agile at Project Management Institute. Scott leads the evolution of the Disciplined Agile (DA) tool kit and is an international keynote speaker. Scott is the (co)-creator of the Disciplined Agile (DA) tool kit as well as the Agile Modeling (AM) and Agile Data (AD) methodologies.
Scott W. Ambler
Scott W. Ambler
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Ndo 1
Quantencomputing in der Anwendung – State-of-the-Art und Future Roadmap
Quantencomputing in der Anwendung – State-of-the-Art und Future Roadmap

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.

Oliver Denninger leitet den Forschungsbereich Software Engineering am FZI Forschungszentrum Informatik. Seit zehn Jahren beschäftigt er sich mit Qualitätssicherung und -vorhersage zur Entwurfszeit.
Dr. Christian Tutschku ist theoretischer Festkörperphysiker mit Fokus auf Quantencomputing. Am Fraunhofer IAO entwickelt er anwendungsnahe Quantenalgorithmen für das IBM Q System One in Ehningen.
Oliver Denninger, Christian Tutschku
Oliver Denninger, Christian Tutschku
Vortrag: Ndo 1
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Ndo 4
Documentation-as-Code – Dokumentation kontinuierlich und automatisiert erstellen
Documentation-as-Code – Dokumentation kontinuierlich und automatisiert erstellen

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.

Falk Sippach arbeitet bei der embarc Software Consulting GmbH als Software-Architekt, Berater und Trainer. Bereits seit über 15 Jahren unterstützt er in meist agilen Software-Entwicklungsprojekten im Java-Umfeld. Als aktiver Bestandteil der Community (JUG Darmstadt) teilt er zudem sein Wissen gern in Artikeln sowie bei Vorträgen und unterstützt bei der Organisation diverser Fachveranstaltungen.
Falk Sippach
Falk Sippach
flag VORTRAG MERKEN

Vortrag Teilen

, (Freitag, 04.Februar 2022)
09:00 - 16:00
Fr 5
Domain-Driven Design-Tutorial: DDD intensiv
Domain-Driven Design-Tutorial: DDD intensiv

In den Zeiten von Microservices wird klar, wie wichtig Domain-Driven Design nach wie vor ist. Denn nur mit Strategischem Design und dem Aufteilen der Domäne in Bounded Contexts kann ein sinnvoller (nämlich fachlicher) Schnitt für die Microservices gefunden werden.

Aber auch Taktisches Design mit der Ubiquitous Language und den Building Blocks haben nichts an Aktualität verloren.

In diesem Workshop nehmen wir uns einen Tag Zeit, um DDD näher anzuschauen. Der Workshop besteht aus abwechselnd Vortrag, Diskussion und Übungen.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider, POs, Fachexpert:innen
Voraussetzungen: Erfahrung in mittleren bis großen Projekten
Schwierigkeitsgrad: Anfänger

Extended Abstract
In den Zeiten von Microservices wird klar, wie wichtig Domain-Driven Design (DDD) nach wie vor ist. Denn nur mit Strategischem Design (also DDD im Großen) und dem Aufteilen der Domäne in Bounded Contexts kann ein sinnvoller (nämlich fachlicher) Schnitt für die Microservices gefunden werden.

Aber auch Taktisches Design (also DDD im Kleinen) mit der Ubiquitous Language und den "Building Blocks" Entities, Value Objects, Aggregates, Services und Co. haben nichts an Aktualität verloren.

In diesem Workshop nehmen wir uns einen Tag Zeit, um DDD näher anzuschauen. Der Workshop besteht aus abwechselnd Vortrag, Diskussion und Übungen.

Der Aufbau wird so sein, dass wir zunächst einen Überblick über DDD geben und uns dann die einzelnen Themen detailliert betrachten. Dabei nähern wir uns DDD gewissermaßen von außen nach innen. Inhaltlicher Aufbau:

  1. Einführung und Überblick
  2. Domäne kennenlernen
  3. Domäne aufteilen
  4. Sprache lernen und bauen
  5. Domäne modellieren
  6. Modell implementieren
Henning liebt Programmieren in hoher Qualität. Diese Leidenschaft lebt er als Coder, Coach und Consultant bei der WPS - Workplace Solutions aus. Dort hilft er Teams dabei, Ihre gewachsenen Monolithen zu strukturieren oder neue Systeme von Anfang an mit einer tragfähigen Architektur zu errichten. Häufig kommen dann Microservices oder Self-Contained Systems heraus. Henning ist Autor von »Domain Storytelling« und dem www.LeasingNinja.io sowie Übersetzer von »Domain-Driven Design kompakt«.
Henning Schwentner
Henning Schwentner
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 16:00
Fr 6
Hands-On-Einstieg in Wardley Mapping
Hands-On-Einstieg in Wardley Mapping

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

Markus Harrer arbeitet seit über zwölf Jahren in der Software-Entwicklung. Seine Spezialgebiete sind Clean Code, Softwaresanierung, Performance-Optimierung und Software Analytics. Als Berater bei INNOQ hilft er, Software nachhaltig und strategisch sinnvoll zu verbessern.
Markus Harrer
Markus Harrer
flag VORTRAG MERKEN

Vortrag Teilen

Zurück