Konferenzprogramm

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

Thema: Software Architecture

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Montag
    29.01.
  • Dienstag
    30.01.
  • Mittwoch
    31.01.
  • Donnerstag
    01.02.
  • Freitag
    02.02.
, (Montag, 29.Januar 2024)
10:00 - 17:00
Mo 3
Domain-Driven Design 101
Domain-Driven Design 101

In the times of microservices, it becomes clear how important Domain-Driven Design (DDD) still is. Only with strategic design (i.e. DDD on a large scale) and the division of the domain into bounded contexts can a sensible cut be found for the microservices.
In this workshop we will take a day to take a closer look at DDD. The workshop consists of alternating lecture, discussion and exercises.

Target Audience: Architects, Developers, Project Leaders, Managers, Decision Makers, Domain Experts
Prerequisites: None
Level: Basic

Extended Abstract:
In the times of microservices, it becomes clear how important Domain-Driven Design (DDD) still is. Only with strategic design (i.e. DDD on a large scale) and the division of the domain into bounded contexts can a sensible cut be found for the microservices.
But also Tactical Design (i.e. DDD on a small scale) with the Ubiquitous Language and the “Building Blocks” Entities, Value Objects, Aggregates, Services and co. have lost nothing of their relevance.
In this workshop we will take a day to take a closer look at DDD. The workshop consists of alternating lecture, discussion and exercises.

The structure will be such that we first give an overview of DDD and then look at the individual topics in detail. In doing so, we will approach DDD from the outside in. Content structure:

  • introduction and overview
  • getting to know the domain
  • splitting up the domain
  • learning the domain language
  • model the domain
  • implement the domain model

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/henning.schwentner

English below

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« (Addison-Wesley, 2022) und dem www.LeasingNinja.io sowie Übersetzer von »Domain-Driven Design kompakt« (dpunkt, 2017).
----------
Henning Schwentner loves programming in high quality. He lives this passion as coder, coach, and consultant at WPS – Workplace Solutions. There he helps teams to restructure their monoliths or to build new systems from the beginning with a sustainable architecture. Henning is author of "Domain Storytelling" (Addison-Wesley, 2022), "Domain-Driven Transformation" (dpunkt, 2023), and the LeasingNinja.io.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/henning.schwentner

Henning Schwentner
Raum 13a
Henning Schwentner
Raum 13a

Vortrag Teilen

10:00 - 13:00
Mo 7
Qualitätsattribute systematisch integrieren
Qualitätsattribute systematisch integrieren

Bekanntermaßen haben Qualitätsattribute einen entscheidenden Einfluss auf die Software-Architektur. Deshalb bedürfen sie in einem Entwicklungsprojekt über alle Phasen hinweg einer systematischen Behandlung.
Das Tutorium bietet eine Rundfahrt mit verschiedenen Ausflügen zu wichtigen Teilthemen, um dadurch einen systematischen Ansatz für Qualitätsattribute zu entwickeln. Zur Veranschaulichung dienen kleine Anwendungsbeispiele. Die Teilnehmer haben dabei die Gelegenheit, das erworbene Wissen in Übungen zu vertiefen.

Zielpublikum: Software- und Systemarchitekt:innen
Voraussetzungen: Architektonische Grundlagen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Bekanntermaßen haben Qualitätsattribute einen entscheidenden Einfluss auf die Software-Architektur. Deshalb bedürfen sie in einem Entwicklungsprojekt einer systematischen Behandlung. Diese erstreckt sich vom Anforderungsmanagement über den Systementwurf bis hin zum Testen. Essenziell ist dabei ein grundlegendes Verständnis der architektonischen Anforderungen, nicht nur die Qualitätsattribute betreffend. Wie schon Cem Kener zu sagen pflegt: Garbage-in-Garbage-out.
Das Tutorium bietet eine Rundfahrt mit verschiedenen Ausflügen zu wichtigen Teilthemen. Dabei stehen die verschiedenen Projektphasen sowie Ansätze im Fokus, um in jeder Phase systematisch mit Qualitätsattributen umzugehen, was kleine Case Studies zusätzlich veranschaulichen. Die Teilnehmer haben dabei die Gelegenheit, das erworbene Wissen in Übungen zu vertiefen.
Die Lernziele des Tutoriums lauten:

  • Verständnis für die systematische Ableitung, Definition und Priorisierung von Qualitätsattributen
  • Einsicht in den konzeptionellen und systematischen Umgang mit Qualitätsattributen bei Entwurf und Test
  • Fähigkeit, das erworbene Wissen in eigenen Projekten anzuwenden

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/michael.stal

Michael Stal arbeitet bei der Siemens AG unter anderem an Software-Architekturen, verteilten Systemen und KI - sowohl in der Forschung als auch in Projekten. Zudem ist er als Professor an der Universität Groningen und als Chefredakteur von JavaSPEKTRUM tätig. Er verfügt über drei Jahrzehnte Erfahrung im Softwareengineering und hat Spaß daran, Wissen zu vermitteln.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/michael.stal

Michael Stal
Raum 13b
Michael Stal
Raum 13b

Vortrag Teilen

10:00 - 13:00
Mo 8
Was ist Event-Sourcing und wie steht es in Bezug zu CQRS und Event-Driven Architekturen?
Was ist Event-Sourcing und wie steht es in Bezug zu CQRS und Event-Driven Architekturen?

Mit der zunehmenden Popularität von Event-Sourcing, CQRS und EDA gibt es eine Menge Verwirrung zwischen diesen orthogonalen Konzepten.
Wir werden uns zunächst jedes dieser Konzepte einzeln ansehen und untersuchen, wie sie zusammen verwendet werden können.
Danach werden wir in einem praktischen Teil einige verschiedene Implementierungsmuster für Event-Sourced Aggregates kennenlernen. Die Teilnehmer werden verschiedene Versionen desselben Aggregate in Form von "Code Koans" implementieren.

Laptop wird benötigt. Eine Entwicklungsumgebung sollte installiert sein (z.B. Code Snippets (Githup-Repositories) in den Sprachen Java, Kotlin, C# und PHP)

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Basis-Wissen DDD: was ist ein Aggregate, Entity, Value Object, Command, Domain Event
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Mit der zunehmenden Popularität von Event-Sourcing, CQRS und EDA gibt es eine Menge Verwirrung zwischen diesen orthogonalen Konzepten, die sehr nützlich sind, aber sauber getrennt werden sollten.

1) Wir werden uns zunächst jedes dieser Konzepte einzeln ansehen und untersuchen, wie sie zusammen verwendet werden können.

2) Danach werden wir in einem praktischen Teil einige verschiedene Implementierungsmuster für Event-Sourced Aggregates kennenlernen. Die Teilnehmer werden verschiedene Versionen desselben Aggregate in Form von "Code Koans" implementieren. Für jede Variante wird es Testfälle und ein Skelett geben, das mit dem fehlenden Code gefüllt werden muss, damit die Tests grün sind.

Was es zu entdecken gibt:

  • Verschiedene Arten der Implementierung eines Aggregate
  • Wie ein konzeptionelles Aggregate implementiert werden kann, ohne ein großes "Objekt" zu haben
  • Die Grundlagen des Event-Sourcing
  • Eine leichte Form der Ensemble- (Mob-) Programming oder Pair Programming
  • Die Idee der "Code Koans"

Wir stellen Git-Repositories zur Verfügung, die Java-, Kotlin- und C#-Code enthalten:
https://github.com/MaibornWolff/aggregate-implementation-patterns-java
https://github.com/klimisa/aggregate-implementation-patterns-csharp
https://github.com/MaibornWolff/aggregate-implementation-patterns-kotlin
Die Teilnehmer benötigen einen Laptop mit einer IDE, die für eine der genannten Sprachen geeignet ist.
Idealerweise ziehen sie das Repo vor dem Workshop und installieren die Dependencies, so dass sie die Unit-Tests ausführen können!

3) Schließlich werden wir in den Q-Teil von CQRS eintauchen, indem wir mindestens eine "Projection" für eine Abfrage/ein Lesemodell/eine Ansicht implementieren, wobei es den Teilnehmern freisteht, ihre eigenen Ideen für ein interessantes Lesemodell einzubringen, das sie erstellen möchten.

4) Zeit für weitere Fragen und Antworten

Anton Stöckl arbeitet bei der MaibornWolff GmbH als Learning Designer in der internen Weiterbildung. Sein besonderes Interesse gilt dem Domain-Driven Design und dem Aufbau solider und lose gekoppelter Microservice-Architekturen.

Dagmar de Haan ist freiberufliche Software-Architektin und Entwicklerin. Ihr Schwerpunkt liegt in der Konzeption und Entwicklung von Backend-Systemen im Java-Umfeld.

Anton Stöckl, Dagmar de Haan
Raum 12
Anton Stöckl, Dagmar de Haan
Raum 12

Vortrag Teilen

, (Dienstag, 30.Januar 2024)
09:00 - 10:30
Di 1.1
Leading a Software-Architecture Revolution
Leading a Software-Architecture Revolution

Software-Architecture Revolution is the process of making profound, large-scale changes to the fundamental structures of software systems to improve its attributes, such as availability, scalability, and maintainability, or to enable new requirements that are incompatible with the current capabilities. Architectural revolution demands substantial effort from the organization and needs effective leadership to be successful. This talk draws from practical experiences (patterns) to improve the effectiveness of architectural revolution initiatives.

Target Audience: Architects, Managers, Project Leaders, Coaches, Developers, Product Owners, Decision Makers
Prerequisites: Leadership, Architecture, Project Management, Working with Teams, Agile mindset
Level: Advanced

Extended Abstract:
Pressure to adapt to and shape the market requires agile organizations to add new features, accommodate new interactions, and have new teams work on adapting the software. Sometimes a straightforward software architecture that starts out small when communication is easy can support guided, incremental architectural changes and can gradually evolve with its environment, remaining fit for its purposes. Other times it is not so simple: the initial software architecture can be poorly suited for supporting required changes, or the accumulation of suboptimal architectural decisions (also known as architectural technical debt) can be too severe; in either case, the architecture needs an extensive revision; especially for the organization to remain agile and adapt to the changing market.
Software architecture revolution can be defined as the process of making profound, large-scale changes to the fundamental structures of a software system to improve its attributes, such as availability, scalability, and maintainability, or to enable new requirements that are incompatible with the current capabilities. Architectural revolution usually demands substantial effort from the organization and thus depends on effective leadership to be successful. However, while there is plenty of research on the technical aspects of any architectural transformation, not much is available from the leadership perspective. The role of managers and other leaders include championing the revolution initiative, prioritizing activities, negotiating the allocation of people and resources, evaluating results, taking corrective actions, and reporting achievements. This talk draws from practical experiences to describe patterns to improve the effectiveness of architectural revolution initiatives.

Joseph (Joe) Yoder is a research collaborator at IME/USP, owner of The Refactory, and president of the Hillside Group which is dedicated to improving the quality of life of everyone who uses, builds, and encounters software systems. Joe is best known for the Big Ball of Mud pattern, which illuminates many fallacies in software architecture. Recently, the ACM recognized Joe as a Distinguished Member in the category of "Outstanding Engineering Contributions to Computing".

Joseph Yoder
Raum 01
Joseph Yoder
Raum 01

Vortrag Teilen

09:00 - 10:30
Di 2.1
Leichtgewichtige und fokussierte Software-Reviews
Leichtgewichtige und fokussierte Software-Reviews

Der Wert von Software-Reviews wird allgemein akzeptiert. Bei klassischen Methoden steht diesem gleichzeitig ein erheblicher Aufwand gegenüber. Das macht es Entwicklungsteams schwierig, ihre Vorhaben zum richtigen Zeitpunkt angemessen zu beleuchten, um Risiken aufzudecken und die Architektur abzusichern. In diesem Vortrag skizziere ich praktikable Ansätze, mit denen Sie und Ihr Team mit überschaubarem Aufwand und im Extremfall im Alleingang wertvolle Ergebnisse erzielen.

Zielpublikum: In erster Linie Architekt:innen und Entwickler:innen, ansonsten alle in Softwarevorhaben Beteiligte
Voraussetzungen: Erfahrung in Software-Entwicklungsvorhaben
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der Wert von Software-Reviews wird allgemein akzeptiert. Bei klassischen Methoden wie ATAM steht diesem gleichzeitig ein erheblicher Aufwand gegenüber. Das macht es Entwicklungsteams schwierig, ihre Vorhaben zum richtigen Zeitpunkt angemessen zu beleuchten, um Risiken aufzudecken und die Architektur abzusichern. In diesem Vortrag skizziere ich praktikable Ansätze, mit denen Sie und Ihr Team mit überschaubarem Aufwand und im Extremfall im Alleingang wertvolle Ergebnisse erzielen.
Zur Motivation: Es gibt einige "große" Methoden zur Architekturbewertung wie ATAM oder CBAM, oder sehr "flapsige", die nur Bauchgefühl haben. Da einen Mittelweg zu finden ist nicht leicht.
Aus der Praxis von 50+ Reviews konnten wir aber einen funktionierenden Kern ableiten, der fundiert und trotzdem schlank ist. Das Ergebnis stelle ich in dieser Session vor und gebe Orientierung, wie Sie das Schritt für Schritt auf Ihre eigenen Softwarelösungen anwenden.
Der Clou: Die gezeigte Methodik ist darauf getunt, durch Fokussierung bereits früh verwertbare und vorzeigbare Ergebnisse zu liefern. Weitere Schritte liefern wo nötig tiefere Erkenntnisse und mehr Sicherheit.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/stefan.zoerner

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“ (Hanser-Verlag).

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/stefan.zoerner

Stefan Zörner
Raum 13a
09:00 - 10:30
Di 6.1
How to reduce the footprint of Spring Boot applications
How to reduce the footprint of Spring Boot applications

In this session we will walk through various techniques to significantly reduce the resource consumption of regular Spring Boot applications, including using Spring AOT for regular Spring apps, compiling Spring Boot apps to native images (using GraalVM), and using CRaC for instant startup (for scale-to-zero scenarios). We will compare the different approaches, discuss pros and cons for each technology, and share concrete numbers from real-world applications to give the audience an idea of what can be achieved using these technologies.

Target Audience: Developers, Architects
Prerequisites: Basic Spring Boot knowledge required
Level: Advanced

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/martin.lippert

Martin Lippert is part of the Spring engineering team at VMware and leads the Spring tools engineering. In addition to that he focuses on sustainability and green software for several years now.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei:  https://www.sigs.de/autor/martin.lippert

The tragedy of user-centred design
The tragedy of user-centred design

User-centred design is one of the default modes of teams working with software, but the consequences are often unsustainable in a densely networked world as we privilege users over all other stakeholders and systems. How might teams approach building products, services and organisations from a more sustainable standpoint than 'user-centricity'? This talk looks at how the techniques of game design, community development, platform operations and security practices can support a practice focused on hyperobjects for multi-centric design.

Target Audience: Leaders, Builders, Architects, Designers, Community Members
Prerequisites: No previous knowledge, only enthusiasm for systems, building things and design
Level: Advanced

Extended Abstract:
The key feature of a 'tragedy' is when everybody does the right thing but it goes wrong anyway. The aim of this session will be to look at why user-centred design goes wrong even if everyone's intentions are pure. This talk (gently!) brings in ideas from feminism, design thinkers, political science and anthropology to focus on very practical, grounded approaches to sustainable design in software teams. We'll look at how building things and designing organisations that have increased levels of friction can improve users' experience and how 'seamless' design can lead to disempowerment. And we'll also draw on the speaker's practical experience of building products used by millions of citizens as part of the UK's digital transformation. By the end of the session we'll have a sense of what might replace the shallow seamlessness of 'user-centred' design — a multi-centric, transcendental design aimed at manufacturing enthusiastic consent.

Simon Edward Bostock is a product and design leader who's worked with software for 20+ years. His interests include how firms and brands incorporate new technologies, how work flows through organisations, EverythingOps and service topologies.

Martin Lippert
Raum 11
Simon Edward Bostock
Raum 11
Martin Lippert
Raum 11

Vortrag Teilen

Simon Edward Bostock
Raum 11

Vortrag Teilen

09:00 - 10:30
Di 7.1
Interaktionsdesign und Architektur
Interaktionsdesign und Architektur

Je mehr sich die Arbeit der Menschen vom Taktilen in Richtung digitaler Arbeit verschiebt, desto wichtiger wird das Design der Oberflächen für die Interaktion mit dem Digitalen. Wir haben uns in den vergangenen Jahren gefragt: Wie kann der Designprozess so in agile Software-Entwicklung integrieren, dass ein gut verwendbares System mit einer auf Dauer flexiblen und anpassbaren Software-Architektur entsteht? Wir haben auf verschiedenen Ebenen Antworten gefunden, die wir den Zuhörern in diesem Vortrag gerne vorstellen wollen.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen
Voraussetzungen: Erfahrung mit Software-Entwicklung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Je mehr sich die Arbeit der Menschen vom Taktilen in Richtung digitaler Arbeit verschiebt, desto wichtiger wird das Design der Oberflächen für die Interaktion mit dem Digitalen. Wir haben in den vergangenen Jahren in verschiedenen Anwendungsbereichen mit zwei Fragen gerungen: Wie lässt sich Arbeit in ein Interaktionsmodell überführen, bei dem die bisherigen Arbeitsabläufe wiedererkennbar sind, aber hilfreiche neue digitale Features eine echte Verbesserung darstellen? Wie kann der Designprozess für solche Interaktionsmodelle in agile Software-Entwicklung integriert werden, so dass ein gut verwendbares System mit einer auf Dauer flexiblen und anpassbaren Software-Architektur entsteht? Wir haben auf verschiedenen Ebenen Antworten gefunden, die wir den Zuhörern in diesem Vortrag gerne vorstellen wollen.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/carola.lilienthal

Dr. Carola Lilienthal ist Software-Architektin und Geschäftsführerin bei der WPS – Workplace Solutions GmbH und entwickelt seit mehr als 10 Jahren mit ihren Teams Software-Architekturen nach den Prinzipien des Domain Driven Design. Sie ist Autorin des Buchs "Langlebige Softwarearchitekturen", hat das Buch "Domain-Driven Design Distilled" von Vaughn Vernon ins Deutsche übersetzt und 2023 ihr neues Buch "Domain-Driven Transformation" veröffentlicht.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/carola.lilienthal

Liefer keine Frameworks. Liefer Produkte!
Liefer keine Frameworks. Liefer Produkte!

In meinem Vortrag analysiere ich Statistiken zum Scheitern agiler Übergänge und enthülle dabei die entscheidenden Erfolgs- oder Misserfolgsfaktoren. Im Zentrum steht das Produkt-Management – der Schlüssel, um diese Transitionen zu meistern. Wir decken nicht nur Hindernisse auf, sondern präsentieren auch praxiserprobte Ansätze, um diese zu umgehen und den Weg zum Erfolg zu ebnen. Erleben Sie eine kompakte Reise durch die Welt der agilen Transitionen, die Ihnen wertvolle Erkenntnisse für die Zukunft bietet.

Zielpublikum: Leiter:innen, Product Owner:innen, Product Manager:innen, Agile Coaches, Entscheider:innen
Voraussetzungen: Projekt-, Produktmanagement-Erfahrung, Produkt-Owner-Erfahrung
Schwierigkeitsgrad: Experte

Benjamin Igna hat einen Abschluss in Wirtschaftsingenieurwesen. Während seines Studiums konnte er sich intensiv mit dem Toyota-Produktionssystem sowie der schlanken Denkweise in der Produktion auseinandersetzen. Nach seinem Studium beschäftigte er sich mit agilen Organisationsformen, insbesondere Scrum und Kanban. Seit 2015 ist er bei it-agile tätig. Dort unterstützt er Organisationen dabei, Strukturen zu finden, in denen zufriedene Mitarbeiter bessere Dienstleistungen und Produkte entwickeln können.

14:00 - 14:45
Di 1.2
These are not the architectures you’re looking for… What agile development needs from architecture
These are not the architectures you’re looking for… What agile development needs from architecture

This is not about what an "Agile Architecture" could be. It is about the view from the opposite direction:
How can architecture work look like in order to act as an enabler to work in the spirit of the Manifesto for Agile Software Development?
There are answers to questions like.
•    Why is architecture documentation so rarely read?
•    How much technology focus is helpful and why?
•    What knowledge needs to be built by yourself in the first place?
•    What does programming have to do with architecture?
And above all: what does it mean in practice?

Target Audience: (Senior) Software Developers, Architects, Knowledge-Managers
Prerequisites: Curiosity for why architecture work is still so difficult.
Level: Advanced

Extended Abstract:
This is not about the question "How does a good architecture emerge in an 'Agile environment'". Nor is it about whether hexagonal, clean or onion architectures are good for ‘agile projects’.
Rather, it is about the view from the opposite direction:
What should architecture work look like in practice to act as an enabler for working in the way of the Manifesto for Agile Software Development?
Covering (at least) these points:

  • Being read is more important than writing or: The worm must taste good to the fish, not to the angler.
  • Concepts are more important than technologies or: Kafka is not a business interface
  • Parnas and Dijksta are more important than reddit/r/docker or: "Have we reinvented the wheel yet this year?"
  • Software crafting is an architecture issue or: Riding a bike is only easy if you've learned how to do it

We look at what is actually meant by this in detail, and how we can arrive at "good practices" for the daily work.

English below

Heutzutage verbringt Michael die meiste Zeit in der Organisationsentwicklung und unterstützt Kunden bei ihrer Suche nach effektiveren Arbeitsmethoden. Oft durch die Anwendung von Lean- und Agile-Konzepten. Michael macht seit den 1990ern Zeugs, das heute Agil heißt (wie z.B. FDD und XP), hatte um 2005 eine intensivere Scrum Phase und ist seit 2008 mit der Kanban-Methode involviert. Unter anderem war er 2011 Co-Gründer der  Kölner "Limited WIP Society" (Kanban User Group) und ist regelmäßiger Sprecher auf diversen Konferenzen zum Thema. Obwohl –oder eigentlich gerade weil– er derzeit vor allem größere Organisationen übergreifend im Wandel begleitet, ist ihm der hilfreiche Einsatz von Methoden gerade auf persönlicher Ebene und auf Teamebene eine Herzensangelegenheit. Michaels Mantra: Accept Reality.
----------
These days, Michael Mahlberg spends most of his time in organizational development, helping clients find more effective ways of working. Often by applying concepts from Lean and Kanban. His strong commitment to software architecture makes him change hats every now and then and the collaboration with software architects from the last 20 years is the basis for this talk.

Michael Mahlberg
Raum 13a
Michael Mahlberg
Raum 13a

Vortrag Teilen

14:00 - 14:45
Di 2.2
From Legacy to Cloud – Mistakes You Don’t Want to Make Your Own
From Legacy to Cloud – Mistakes You Don’t Want to Make Your Own

Come and hear the story of a company that is on the journey from the old monolithic, on-premise, waterfall world to the new modular, agile, domain-driven, multi-tenant, cloud-based microservices world. The challenges come from different directions: both technical and organizational aspects have to be mastered. The domain has to be understood, so that the system can be structured right. The big bang has to be avoided.
In this talk we will look at how our “fictional” company has struggled with and finally overcome those challenges.

Target Audience: Architects, Developers, Project Leaders, Managers
Prerequisites: Programming Experience
Level: Advanced

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/henning.schwentner

English below

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« (Addison-Wesley, 2022) und dem www.LeasingNinja.io sowie Übersetzer von »Domain-Driven Design kompakt« (dpunkt, 2017).
----------
Henning Schwentner loves programming in high quality. He lives this passion as coder, coach, and consultant at WPS – Workplace Solutions. There he helps teams to restructure their monoliths or to build new systems from the beginning with a sustainable architecture. Henning is author of "Domain Storytelling" (Addison-Wesley, 2022), "Domain-Driven Transformation" (dpunkt, 2023), and the LeasingNinja.io.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/henning.schwentner

Henning Schwentner
Raum 01
14:00 - 14:45
Di 8.2
Live Hacking Cloud Architectures
Live Hacking Cloud Architectures

As more organizations are moving to the cloud, cloud architectures are getting more sophisticated by having a kind of technology diversity. This includes for example container orchestrators, database services, networking components & virtual machines.
When it comes to security, observability on this diversity is paramount. The main question here is, do you really perceive when your app landscape is under attack?
In this session, you'll have the opportunity to see various attack vectors & ways to mitigate them using different technologies.

Target Audience: Architects, Developers, Software Engineers
Prerequisites: Basic cloud & security knowledge
Level: Advanced

Extended Abstract:
Come and watch a live attack on a real-world based cloud architecture and see the attacker scan web applications and start lateral movement with the goal of exfiltrating data. Furthermore, become a part of the blue-team, defending and securing the architecture with modern open source tools.

Mirna Alaisami is a senior consultant at Novatec with focus on cloud technologies & platforms. She supports & advises customers on building cloud architectures & migrating to various cloud platforms. She also develops & delivers training topics related to microservice development & CI/CD. Prior to that, she worked as a software engineer. In addition to her role as a consultant, she actively blogs for Novatec, has been guest lecturer at different universities, and speaker at various meetups & conferences.

Thorsten Jakoby is a consultant for IT-architectures & cloud migrations at Novatec in Germany. He is currently a cloud security architect for highly regulated customers in Germany.
With a background of more than 10 years in distributed applications, he enables both customers building cloud architectures & students entering the IT world. Prior to his role at Novatec he led a company specialized in cloud-based startup projects.
Besides his role as consultant, he is also a trainer and public speaker.

Mirna Alaisami, Thorsten Jakoby
Raum 13b
Mirna Alaisami, Thorsten Jakoby
Raum 13b

Vortrag Teilen

16:15 - 17:15
Di 1.3
Architektur: Den menschlichen Faktor verbessern!
Architektur: Den menschlichen Faktor verbessern!

Gute Software-Architektur strukturiert komplexe Software-Systeme so übersichtlich, dass Menschen sie verstehen und weiterentwickeln können. Also geht es bei der Software-Architektur um den Faktor Mensch. Deswegen kann sich Architektur aber nicht auf Maßnahmen für die Strukturierung der Software begrenzen, sondern muss sich auch mit den Menschen beschäftigen. In diesem Vortrag geht es um einige konkrete Ansätze und Erfahrungen, die Entwicklung durch Maßnahmen in Bezug auf den Faktor Mensch zu verbessern.

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

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/eberhard.wolff

Eberhard Wolff ist Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Geschäft und Technologie. Er ist Autor zahlreicher Artikel und Bücher, trägt regelmäßig als Sprecher auf internationalen Konferenzen vor und streamt wöchentlich zum Thema Software-Architektur. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Domain-Driven Design und Microservices.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/eberhard.wolff

Eberhard Wolff
Raum 01
Eberhard Wolff
Raum 01

Vortrag Teilen

16:15 - 17:15
Di 2.3
Macro and Micro Frontend Architectures in Angular
Macro and Micro Frontend Architectures in Angular

Microfrontends are a popular concept for development in an enterprise project, where a large number of teams want to work independently.
But what is the cost achieving run-time integration and independent framework versions?
JS frameworks intended to build SPAs have solved many problems like deep-linking between pages without reloading the application.
This talk will give you some real life experience which challenges are to be considered using different integration patterns, using webcomponents, module federation and "classic" libraries.

Target Audience: Architects, Developers, Project Managers
Prerequisites: Basic knowledge of Angular or other JS SPA Frameworks
Level: Advanced

Extended Abstract:
How often do project managers wish for a microfrontend architecture? Contrary to microservices in the backend, microfrontends are not always the recommended future choice.
You might have to solve a lot of problems, that have already been solved in frameworks like Angular or React.
If we start separating UI elements in encapsulated webcomponents, we risk a lot of effort re-creating capabilities like deeplinking (routing) or event handling across components.
Or: we need to add additional frameworks that solve the challenges of navigation, context transfer and layouting.
The talk provides an overview, what default architecture patterns Angular provides and how to mitigate problems that might come with classical architectures or a monorepo.
The talk will mention use cases, when the usage of microfrontends is feasible and recommended. It will also provide workarounds if a microfrontend architecture is needed.

Cathrin Möller is a full stack developer, architect and UX and CSS enthusiast and working as a Principal Consultant at TNG Technology Consulting since 2014. She has a broad experience from multiple client projects ranging from mature enterprise projects as well as development from scratch. Therefore she knows common pitfalls and a lot of best practices that she likes sharing in talks.

Cathrin Möller
Raum 05
17:45 - 18:45
Di 1.4
Klonen nicht möglich – Wie man seine Architekturkompetenzen trotzdem schnell skaliert
Klonen nicht möglich – Wie man seine Architekturkompetenzen trotzdem schnell skaliert

Nach einer Fusion standen wir vor vielen Herausforderungen: Konsolidierung zweier großer IT-Landschaften auf eine, Integration und technologische Modernisierung. Dabei müssen wir Anforderungen aus Markt und Regulatorik weiter bedienen. Hierfür benötigen wir Architekturkompetenz.
Im Vortrag zeigen wir, wie wir unsere Architekturkompetenz durch Einführung einer neuen dezentralen Architekturrolle stark skaliert haben.
Wir stellen vor, wie wir die neue Rolle ins Architekturmanagement eingebettet haben und was die kritischen Erfolgsfaktoren waren.

Zielpublikum: Architekt:innen, Projektleiter:innen, Manager:innen, Entscheider:innen
Voraussetzungen: Grundlegende Kenntnisse im Architekturmanagement sind hilfreich
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Wir benötigten eine erheblich größere Anzahl von Architekturkompetenzen (ca. 25-30 Architekt:innen), als wir für die Bewältigung unserer Aufgaben hatten. Verstärkung durch externe Berater:innen ist eine Möglichkeit, aber kein Allheilmittel und auch nicht nachhaltig. Neue Kolleg:innen einzustellen ist in einem sehr engen Arbeitsmarkt nicht erfolgversprechend.
Unser Ansatz war daher, uns organisch aus der eigenen IT-Organisation heraus zu verstärken. Neben einer zentralen Architekturabteilung haben wir dezentral in den einzelnen IT-Teams eine neue Rolle etabliert, die des "Solution Architect".
In unserem Vortrag stellen wir vor, wie wir diese neue Rolle etabliert haben. Dabei betrachten wir organisatorische Aspekte, z.B. wie sich diese neue Rolle in bestehende Architekturmanagementprozesse einbettet und wie zentrale und dezentrale IT-Architektur zusammenarbeiten. Wir gehen darauf ein, welche Verantwortlichkeiten und Aufgaben diese Rolle mitbringt und wie wir Handlungsspielräume z.B. in Form unseres Technologiemanagements über Mikro- und Makroarchitekturentscheidungen managen.
Ein Schwerpunkt des Vortrags wird das Change-Management sein. Es beginnt damit, wie wir die Kolleg:innen identifiziert und von der Rolle überzeugt haben. Ohne richtige Ausbildung funktioniert die Übernahme einer solchen Rolle nicht. Daher zeigen wir, welche kurz- und mittelfristigen Maßnahmen wir für Schulung in IT-Architekturthemen unternommen haben. Dabei fußt unser Schulungskonzept auf drei Säulen: Methodik (eng angelehnt an ISAQB), Technologie und Leadership. Wir stellen dar, was wir darüber hinaus an spezifischer Ausbildung in unseren speziellen Themen durchführen und wie wir Mentoring und Coaching etablieren.
Kritische Erfolgsfaktoren (davon gibt es reichlich) und welche Stolpersteine und Skeptiker:innen uns auf dem Weg begegnet sind und wie wir im Rahmen des Change-Managements darauf reagiert haben, runden den Vortrag ab.

Steffen Fischer ist IT-Architekt im Architekturmanagement bei der Provinzial Versicherung AG. Er hat langjährige Erfahrung als Chefarchitekt in komplexen IT-Projekten bei Finanzdienstleistern.

Dr. Philipp Saalmann arbeitet als Unternehmensarchitekt im Architekturmanagement der Provinzial Versicherung AG mit Schwerpunkt EAM-Methodik und -Werkzeuge.

Dr. André Wickenhöfer leitet den Bereich „IT-Standards & zentrale Aufgaben“ bei der Provinzial Holding AG und hat dort als Unternehmensarchitekt das Architekturmanagement mit aufgebaut und weiterentwickelt.

Steffen Fischer, Philipp Saalmann, André Wickenhöfer
Raum 13b
Steffen Fischer, Philipp Saalmann, André Wickenhöfer
Raum 13b

Vortrag Teilen

17:45 - 18:45
Di 2.4
Die Rolle "Evolutionist": Software-Architekturarbeit im Bestand
Die Rolle "Evolutionist": Software-Architekturarbeit im Bestand

Ein großer Teil der Software-Entwicklung besteht aus Wartungsarbeit. In Ausbildung und Studium haben wir oft jedoch nur die Neuentwicklung kennengelernt. Überforderung droht, Frust baut sich auf und die Freude an der Software-Entwicklung geht verloren. Das muss nicht sein!
Wir stellen die Rolle "Evolutionist" vor, welche sich auf die qualitativ angemessene Weiterentwicklung bestehender Systeme fokussiert. Wir blicken auf das notwendige Skill- und Mindset sowie erste Praktiken, um mit großen und langlebigen Softwaresystemen zurechtzukommen.

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

Extended Abstract:
Es ist wahrscheinlich, dass ihr in euren aktuellen Projekten damit beschäftigt seid, ältere Systeme am Leben zu erhalten, zu erweitern und zu aktualisieren. Dies kann zu Unmut, Überforderung und Zweifeln an der Berufswahl führen, da wir in der Ausbildung oft nur das Entwickeln von Neuem gelernt haben.
Für den richtigen Umgang mit Legacy-Systemen ist zuallererst ein spezielles Mindset für uns als Software-Architekt:innen erforderlich: das eines Softwareevolutionisten. Wie bei der Flickschusterei und Archäologie, wo Reparaturen und Nachforschungen wichtig sind, um etwas Altes funktionsfähig zu erhalten oder wichtige Erkenntnisse aus der Vergangenheit zu gewinnen, benötigen wir ähnliche Herangehensweisen bei der Arbeit an Altsystemen. Wir geben euch ein paar Tipps aus der Praxis, um die dafür benötigte Zeit und Energie im stressigen Entwicklungsalltag zu finden.
Wir gehen kurz auf konkrete Praktiken ein, die uns bei dieser Weiterentwicklungsreise unterstützen, wie etwa die Mikado-Methode, bei der wir inkrementell Schritte zur Umstrukturierung von Software vornehmen. Um hier das Big Picture der Evolution nicht aus den Augen zu verlieren, werfen wir einen Blick auf Kommunikationsmethoden größerer Umbauvorhaben mit Quality Views. Mit der iterativen Prozessverbesserung mittels des Popcorn-Flows geben wir euch ein Werkzeug an die Hand, um iterativ passende Vorgehen für eure Verbesserung auszuwählen und aus alten Gewohnheiten auszubrechen.
Wir möchten euch mit diesem Vortrag motivieren, stolz auf eure Arbeit mit Legacy-Systemen zu sein, und euch eure Bedenken bei der Modernisierung eines Systems nehmen. Es gibt viel zu tun, also fangen wir an: Es könnte ja gut werden!

Markus Harrer arbeitet seit mehreren Jahren in der Softwareentwicklung und ist vor allem in konservativen Branchen tätig. Als Senior Consultant hilft er, Software nachhaltig und wirtschaftlich sinnvoll zu entwickeln und zu verbessern. Er ist aktiver Mitgestalter in Communities zu den Themen Software Analytics, Softwarearchitektur, Softwaresanierung und Wardley Maps. Zudem ist er akkreditierter Trainer für den iSAQB Foundation Level und dem Advanced-Level-Modul IMPROVE.

Benjamin Wolf ist Senior IT Consultant, Coach und Trainer für Software-Architektur, -qualität und -entwicklungsprozesse sowie Architekturdokumentation.

Markus Harrer, Benjamin Wolf
Raum 01
Markus Harrer, Benjamin Wolf
Raum 01

Vortrag Teilen

17:45 - 18:45
Di 3.4
Software Engineer's 2034 Playbook
Software Engineer's 2034 Playbook

Expanding Horizons, the motto of OOP 2024, invites exciting thoughts about the future of software engineering. What will a developer's working day look like in 2034? What environments, tools, and practices will they use to create, test, deploy, and operate software? What will our daily lives look like in a digitalized world in 2034? What types of software systems will be everywhere? What systems will we use at work? What architectures and technologies do these systems rely on? Frank and Kevlin look into the future.

Target Audience: Anyone curious about the future of software engineering
Prerequisites: Interest and sound knowledge in software engineering, architecture and development
Level: Advanced

Extended Abstract:
Expanding Horizons, the motto of OOP 2024, invites exciting thoughts about the future of software engineering. What will a developer's working day look like in 2034? What environments, tools, and practices will they use to create, test, deploy, and operate software? What will our daily lives look like in a digitalized world in 2034? What types of software systems will be everywhere? What systems will we use at work? What architectures and technologies do these systems rely on?
The view is not always clear, but we can look at past and present trends to ask questions and make some forecasts. How will AI affect the daily work of developers, but also everyone else's work? Digitalization is affecting everyone from government to individual — how far will it have taken us by 2034? The last couple of years have seen a lot of media around cryptocurrency, Web3 and the Metaverse, but to what extent will these hopes and hypes actually have affected software development and software usage? What new trends can we expect to see in software architecture, programming languages and workplace culture?
Join Frank and Kevlin as they look into the future, a decade from now.

Frank Buschmann is a Senior Principal Engineer at Siemens Technology in Munich. His interests are in modern Software-Architecture and development approaches for industrial digitization.

Kevlin Henney is an independent consultant, speaker, writer and trainer. His development interests are in programming, practice and people. He is co-author of two volumes in the "Pattern-Oriented Software Architecture" series, and editor and contributor for multiple books in the "97 Things" series. He lives in Bristol and online.

Frank Buschmann, Kevlin Henney
Raum 13a
Frank Buschmann, Kevlin Henney
Raum 13a
Vortrag: Di 3.4

Vortrag Teilen

, (Mittwoch, 31.Januar 2024)
09:00 - 10:30
Mi 1.1
Moderne Architekturarbeit: Vom Vorgabenmachen zum Enabling
Moderne Architekturarbeit: Vom Vorgabenmachen zum Enabling

Wir müssen Teams in die Lage versetzen, den größten Teil der architektonischen Arbeit selbst zu erledigen. An dieser Stelle kommen Team Topologies (M. Skelton und M. Pais) ins Spiel. Dort gibt es die Topologie des "Enabling Teams", welches knapp zusammengefasst, andere Teams mit Wissen und Methodik unterstützt. Dieser Vortrag gibt Ihnen einen Überblick sowie eine praktische Anleitung, wie Sie ein Architekturteam in ein Enabling Team umwandeln können, welches andere Teams unterstützt und befähigt. Der Vortrag enthält viele praktische Beispiele.

Zielpublikum: Architekt:innen, Manager:innen
Voraussetzungen: Eigentlich keine, aber ein paar Architektur-Basics schaden nicht.
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Viele große Unternehmen arbeiten immer noch mit zentralisierten architekturbezogenen Teams. Deren Aufgabe besteht häufig darin, anderen Teams architektonische Spezifikationen vorzugeben und dafür zu sorgen, dass diese Spezifikationen bei der Umsetzung eingehalten werden. Diese Teams werden oft als "Elfenbeinturm-Architektur"-Teams bezeichnet, die darauf abzielen, hochqualifizierte Architekt:innen zu bündeln. Diese Rolle ist auf dem Markt sicherlich nicht in Hülle und Fülle vorhanden.
Sie passen jedoch nicht in eine agile Umgebung, in der wir den Teams die Möglichkeit geben wollen, ihre eigenen Entscheidungen zu treffen. Bestimmte Leitplanken sind dennoch notwendig, um sicherzustellen, dass das Gesamtkonstrukt funktioniert. Darüber hinaus können gut gewählte Leitplanken auch den Abstimmungsbedarf zwischen den Teams drastisch reduzieren.
Wir müssen diese Teams in die Lage versetzen, den größten Teil der architektonischen Arbeit selbst zu erledigen, und gleichzeitig dafür sorgen, dass die einzelnen Teile zusammenpassen. An dieser Stelle kommen Team Topologies ins Spiel, eine von Matthew Skelton und Manuel Pais eingeführte Methode. Dort gibt es den Teamtyp des "Enabling Teams", welches knapp zusammengefasst, andere Teams mit Wissen und Methodik unterstützt.
Dieser Vortrag gibt Ihnen einen Überblick über diesen Wandel sowie eine praktische Anleitung, wie Sie ein zentralisiertes Architekturteam in ein Enabling Team umwandeln können, dessen Aufgabe es ist, die Architekturarbeit in anderen Teams zu verbessern. Sie werden lernen:
1.    Welche Stakeholder Sie in diesen Prozess einbeziehen sollten
2.    Warum das künftige Enabling-Team ebenfalls befähigt werden muss und wie man das macht
3.    Wo häufige Fallstricke auf dieser Reise liegen
4.    Warum diese Reise auf agile Weise mit kontinuierlichem Lernen und Retrospektiven durchgeführt werden muss
Dieser Vortrag wird auch viele Beispiele aus der Praxis enthalten, die eine solche Transformation begleiten.

Michael Plöd ist Fellow bei INNOQ. Seine aktuellen Beratungsschwerpunkte sind Domain-driven Design, Team Topologies, soziotechnische Architekturen und die Transformation von IT-Delivery-Organisationen in Richtung Kollaboration und lose gekoppelter Teams. Michael ist zudem Autor des Buchs „Hands-on Domain-driven Design - by example“ auf Leanpub sowie regelmäßiger Referent auf nationalen und internationalen Konferenzen.

Landkarte für den Plattform-Dschungel: Orientierung im Plattform-Begriffswirrwarr
Landkarte für den Plattform-Dschungel: Orientierung im Plattform-Begriffswirrwarr

Der Begriff „Plattform“ ist leider „überstrapaziert“. Wegen der Popularität großer Plattformen und Plattform-Unternehmen wird der Begriff inflationär gebraucht. Dadurch reden selbst Experten in der IT-Industrie kontinuierlich aneinander vorbei.
Der Vortrag präsentiert eine Landkarte mit Architektur-Big-Picture durch den Plattform-Dschungel, die dabei hilft, verschiedene Arten von Plattformen zielsicher zu erkennen und zu verstehen. Sie erlaubt Architekten, den Überblick zu behalten und alle anderen sicher durch den Dschungel zu führen.

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

Extended Abstract:
Der Begriff „Plattform“ existiert schon sehr lange und wird aktuell extrem viel und vielfältig verwendet, man muss leider schon sagen, er wird „überstrapaziert“.
Beispiele sind die Begriffe Cloud-Plattform, Plattformökonomie, iOS-Plattform, Platform Engineering oder Plattform-Industrie 4.0.
Wegen der Popularität großer Plattformen, dem Erfolg von Plattform-Unternehmen und den Verheißungen der Plattform-Ökonomie wird der Begriff mittlerweile inflationär gebraucht. Dadurch entsteht viel Verwirrung und selbst Experten in der IT-Industrie reden kontinuierlich aneinander vorbei.
Zeit, um etwas Ordnung zu schaffen und einen Überblick über verschiedene Arten von Plattformen und Verwendungen des Begriffs Plattform zu geben.
Der Vortrag hat zum Ziel, eine Landkarte durch den Plattform-Dschungel zu präsentieren, die es ermöglicht, verschiedene Arten von Plattformen zu erkennen und vor allem auch ihre unterschiedlichen Eigenschaften und Daseinsberechtigungen zu verstehen. Dadurch wird auch klar, wie große Unterschiede existieren und dass teilweise die einzige Gemeinsamkeit ist, dass Software im Spiel ist …
Die Zuhörer bekommen im Vortrag die Landkarte in die Hand, um sich nicht mehr zwischen Plattformbegriffen zu verirren. Der Vortrag ist nicht technisch motiviert oder orientiert, sondern soll eine bessere Kommunikation und Diskussion zwischen allen Professionen in der Digitalen Welt ermöglichen

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/matthias.naab , https://www.sigs.de/autor/dominik.rost

Matthias Naab engagiert sich seit Jahren dafür, Unternehmen digitale Ökosysteme und Plattformökonomie besser verständlich zu machen. Er ist Co-Founder von Full Flamingo mit dem Ziel, Plattformökonomie nicht nur zur Gewinnerzielung, sondern auch für Nachhaltigkeit zu nutzen.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/matthias.naab

Dominik Rost ist Software-Architekt und trägt mit Full Flamingo zur Rettung unseres Planeten bei. Als der Co-Founder für die Technik kümmert er sich um Systemdesign, Entwicklung und Technologie.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/dominik.rost

Michael Plöd
Raum 13a
Matthias Naab, Dominik Rost
Raum 13a
Michael Plöd
Raum 13a

Vortrag Teilen

Matthias Naab, Dominik Rost
Raum 13a

Vortrag Teilen

09:00 - 10:30
Mi 2.1
Verteilte autonome Microservices mit Event-driven Architecture
Verteilte autonome Microservices mit Event-driven Architecture

In den letzten Jahren kamen immer öfters Microservices zum Einsatz. Durch den Einsatz vieler kleinerer Services wurde der Einsatz der synchronen Kommunikation immer schwerer und komplexer. Wir können nicht mehr sicherstellen, dass zu jedem Zeitpunkt alle Systeme verfügbar sind und dass alle Änderungen zu jedem Zeitpunkt Konsistent sind. Denn die synchrone Kommunikation sorgt für eine enge Kopplung zwischen den einzelnen Diensten und kann dafür sorgen, dass beim Ausfall eines Dienstes zeitgleich eine Reihe weiterer ausfallen. Typische Resilience Patterns wie: Circuit-Breaker, Retries, Service Meshes, etc. erhöhen wiederum die Komplexität des Gesamtsystems und lösen auch nur teilweise das wirkliche Problem. 

In diesem Vortrag zeige ich, wie mit einem Event-first Mindset ganze Systeme ereignisgetrieben entworfen werden können. Wir werden mit Hilfe des CAP-Theorem analysieren, wie sich die Konsistenz in einem verteilten System ändert. Wie Transaktionssicherheit gewährleistet werden kann und wie Microservices zu autonomen Services werden, die komplett voneinander getrennt sind und nur über Events miteinander kommunizieren. Und wie sich Entwickler mit Hilfe von Serverless und FaaS auf das konzentrieren können, was wichtig ist: Business Value zu liefern.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider:innen
Voraussetzungen: Grundlegende Kenntnisse in Cloud (-Ressourcen), Grundlegendes Verständnis von Software-Architektur
Schwierigkeitsgrad: Anfänger

Florian Lenz ist Gründer der neocentric und entwickelt gemeinsam mit seinen Kunden strategische Konzepte für den Einsatz von Serverless Cloud-Lösungen und modernsten Technologien, um die Effizienz zu steigern, Kosten zu senken und die Wettbewerbsfähigkeit zu stärken.

Alle Wege führen in die Cloud - doch wie komme ich am besten dahin?
Alle Wege führen in die Cloud - doch wie komme ich am besten dahin?

Vielen Anwendungen steht der Schritt zu einer Cloud-native Entwicklung noch bevor.
Wie bei jeder guten Reise beginnt das mit den eigenen Anforderungen und vorhandenen Möglichkeiten.
Welche Optionen und Herausforderungen gibt es dabei zu beachten?
Für eine Java-Webanwendung wird in mehreren Szenarien gezeigt, wie man diese mit AWS-Diensten betreiben kann.
Dabei werden die Vor- und Nachteile der Replatforming- und Rearchitecture-Wege diskutiert und Fragen beantwortet.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen, Entscheider:innen
Voraussetzungen: Cloud Grundkenntnisse, Erfahrung mit Anwendungsmodernisierung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Um sich nicht naiv in die Cloud aufzumachen, lohnt es sich, erfahrene Begleiter mit an Bord zu holen und folgende Fragen zu klären. Die hier gezeigten Erfahrungen helfen, in Zukunft mehr cloud-native unterwegs zu sein.

  1. Welche Qualitätsziele können wie am besten erreicht werden?
  2. Wie müssen Prozesse angepasst werden, um sicher und effizient Anwendungen in der Cloud zu betreiben?
  3. Wie kann ich meine Daten am einfachsten mitnehmen?
  4. Was muss sich wo ändern, um das volle Potenzial der Cloud zu heben?

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/frank.pientka

Frank Pientka (@fpientka) besitzt mehrere Cloud-Zertifizierungen und berät seine Kunden als Cloud-Architekt bei ihrer Reise in der Cloud. Als Gründungsmitglied des iSAQB kümmert er sich um eine verbesserte Ausbildung und Zertifizierung von Architekten. Regelmäßig publiziert und referiert er zu aktuellen IT-Themen.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/frank.pientka

Florian Lenz
Raum 13b
Frank Pientka
Raum 13b
Frank Pientka
Raum 13b

Vortrag Teilen

09:00 - 10:30
Mi 5.1
Designing Agile Ecosystems with Org Topologies™
Designing Agile Ecosystems with Org Topologies™

In this session, two co-creators of Org Topologies™, Alexey Krivitsky and Roland Flemm, will share a method to design, assess and improve your organizational ecosystem.
They will do that by familiarizing you with a set of organizational archetypes that are easy to spot. Hopefully, you will have much better clarity on which organization ecosystem you want to build and which behaviors you expect it to exhibit.
You shall be able to take this tool home and use it as a map in your ongoing, never-ending transformation journey toward agility.

Target Audience: Decision Makers, Transformation Team Members, Coaches, Leadership
Prerequisites: Challenges with scaling agility
Level: Advanced

Extended Abstract:
The legacy of the original lightweight barely sufficient Agile ideas (namely XP and Scrum) has been impeded by the difficulties of applying them beyond a single team without losing the key principles and the promised gains.
Over the last decade, that challenge has led to a rose in heavy-weight methods, especially SAFe™, which has become a go-to place for "everything agile". It provides the user with a profound variety of specific tools and techniques for "scaling agile". Many enterprises are on the path of "rolling out" these ideas by the book with the help of trained coaches. But will we eventually get the promised gains of agility once we fulfill the requirements of the framework in our enterprise? Is such a prescriptive approach agile itself? And more importantly: will we own the change and know how to keep improving beyond the rule book?
In recent years, we have seen the emergence of other methods: framework-agnostic org design DIY toolboxes. In this family of modern ideas, Team Topologies™ and unFix™ stand out from the crowd. Their approach is to offer us a "lunch buffet" to pick structures and processes that suit our situation. It is a flexible approach with a lot of freedom of choice. It offers a fresh path for some of us trying to avoid the burden of frameworks. But the freedom of freely picking org elements implies that we possess a clear bigger picture and won't get lost in the night-gritty details of the puzzle pieces. As leaders, managers, and coaches, how fluent are we in org design, queuing theory, and systems thinking? How can we be confident that we won't lose the plot by trying to put together those puzzle pieces? And more importantly: will we get long-term gains, or will we inflict more unforeseen problems by focusing too much on the small building blocks rather than the whole system?
Difficult questions. Org Topologies™ doesn't have all of them answered for us. But being a framework-agnostic approach for designing agile ecosystems where business and technology would work as one, it can provide us with a solid basis on which all other decisions can be grounded. Essentially, Org Topologies™ moves us from the dualism of frameworks vs. DIY methods into the realm of ecosystems - a unity of interdependent organizational parts that together exhibit well-recognized behaviors.
In this session, two co-creators of Org Topologies™, Alexey Krivitsky and Roland Flemm, will share a method to design, assess and improve your organizational ecosystem. They will do that by familiarizing you with a set of organizational archetypes that are easy to spot in any organization. Hopefully, by the end of the talk, you will have much better clarity on which organization ecosystem you want to build and which behaviors you expect it to exhibit. Eventually, you shall be able to take this tool home and use it with your leadership group as a map in your ongoing, never-ending transformation journey toward agility.

Roland Flemm (PST) became a Scrum Master in 2009 closing his 20-year career as a developer and infrastructure specialist. Roland grew into international agile consulting with a focus on large scaled Scrum adoptions since 2015. He has been actively appearing in the Agile community as a conference speaker.
He started in 1984 as a Cobol and Ideal/Datacom developer. In 2001 he moved to the support and maintenance field and worked with mostly IBM Application Server products.
In 2009 he switched to a new career in Scrum and Agile. He is now a proud member of the 350 globally certified Professional Scrum Trainers for scrum.org. His main focus is Agile organization design coaching and he supports agile adoptions in various industries. The core of his approach is to put people first, learn by doing and innovate with common sense.

Alexey Krivitsky has been a developer, scrum master, conference producer, and speaker. He has written several books and is the inventor of lego4scrum. He is a Certified Scrum Trainer (CST) and works as an organization agility coach.
Alexey is known in the industry because of the success of lego4scrum that he invented.
He has been using Scrum since 2005, he is probably the first Scrum master of Ukraine. In 2007, together with a group of 'interested', he acted as the inspirer of the Agile Ukraine community. So in Ukraine they began to talk about flexible development. It all started with a Google group. Then a dozen half-day free conferences throughout Ukraine. The wave went rolling.
Since 2008, he has been actively appearing in the arena of the Agile community as a conference producer and speaker. Since the same year - an independent agile consultant, perhaps also the first in Ukraine.

Roland Flemm, Alexey Krivitsky
Raum 04b
Roland Flemm, Alexey Krivitsky
Raum 04b

Vortrag Teilen

09:00 - 10:30
Mi 8.1
Domain-driven Design: Konzepte und Fallstricke
Domain-driven Design: Konzepte und Fallstricke

Domain-driven Design (DDD) steht für eine Vielzahl an Techniken wie strategisches DDD, taktisches DDD und kollaborative Modellierung. Dieser Vortrag gibt einen Überblick über das DDD-Universum. Dabei stellt er nicht nur die verschiedenen Konzept vor. Er zeigt außerdem auch die jeweiligen Vor- und Nachteile der Praktiken auf und weist auf die typischen Fallstricke hin - und wie man sie vermeiden kann.

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

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/eberhard.wolff

Eberhard Wolff ist Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Geschäft und Technologie. Er ist Autor zahlreicher Artikel und Bücher, trägt regelmäßig als Sprecher auf internationalen Konferenzen vor und streamt wöchentlich zum Thema Software-Architektur. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Domain-Driven Design und Microservices.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/eberhard.wolff

Eberhard Wolff
Raum 01
Eberhard Wolff
Raum 01

Vortrag Teilen

11:00 - 11:45
Mi 1.2
Mut zum Frontend ohne Framework – nativ, nicht naiv!
Mut zum Frontend ohne Framework – nativ, nicht naiv!

Für ein modernes Web-Frontend greift man am besten zu Angular, React & Co., oder? - Nicht unbedingt! Auch native Bordmittel, zusammen mit ein paar Libraries, können eine echte, leichtgewichtige Alternative sein. Und man kann sogar schrittweise dorthin migrieren. Basierend auf konkreter Projekterfahrung, möchte ich den Blick für diesen Ansatz schärfen, Vor- und Nachteile aufzeigen und das Ganze anhand von Codebeispielen illustrieren.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Wer schonmal etwas von JavaScript, HTML und Angular/React/... gehört hat, ist richtig
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
„Ein modernes Web-Frontend kann man nur mit Angular, React o. ä. bauen, weil die HTML- und JavaScript-Bordmittel bei Weitem nicht ausreichen. Da helfen auch ein paar kleine Libraries nicht.“
Dieser häufig anzutreffenden Ansicht möchte ich in diesem Vortrag widersprechen und dem reflexartigen Griff zu Angular & Co. eine Alternative gegenüberstellen: WebComponents ... also doch die nativen Bordmittel!
Mit WebComponents lässt sich eine Web-Applikation aus unabhängigen, wiederverwendbaren Komponenten entwickeln, ohne sich an ein schwergewichtiges Framework zu binden. Frameworks sind Gesamtpakete, die bequem sein können, aber auch Nachteile mit sich bringen. Zum Beispiel können sie durch ihren All-In-One-Charakter unflexibel sein und eine große Abhängigkeit auf sich einfordern, von der es sich zu lösen lohnen kann. Der vorgestellte Ansatz tut dies. Die üblicherweise vom Framework bereitgestellten Features und Tools werden dabei durch kleine Libraries ersetzt, die zu den individuellen Anforderungen des Projekts passen und jederzeit unabhängig voneinander aktualisiert/ersetzt werden können.
Basierend auf konkreter Projekterfahrung möchte ich aufzeigen, dass man auch ohne Framework ein voll- und hochwertiges Web-Frontend entwickeln kann. Sogar dass man Schritt für Schritt unter Beibehaltung der Lieferfähigkeit von einem Framework wegmigrieren kann, ganz im agilen Sinne. Ich bin auf jeden Fall glücklich damit, dass mein Team den Mut dazu aufgebracht hat, und dass wir dadurch bei einem besseren Frontend mit einer nachhaltigen Architektur herausgekommen sind.
Welche Vorteile bietet dieser Ansatz? Wie geht das denn konkret mit den WebComponents? Wie ersetzt man die „unverzichtbaren“ Vorteile eines Frameworks? Was genau verstehen wir hier eigentlich unter einem Framework? Wie schmerzhaft ist eine Migration weg von einem Framework, hin zu einer reinen WebComponent-Lösung? Geht eine solche Lösung nicht mit viel mehr Komplexität einher? Auf diese Fragen möchte ich eingehen, Live Coding inklusive.

Jan Müller arbeitet seit 6 Jahren als Agile Software Engineer bei andrena objects ag. Aktuell ist er als Full-Stack-Entwickler in einem Scrum-DevOps-Projekt mit Java und TypeScript tätig. Bei seiner täglichen Arbeit liegt sein Augenmerk auf Clean Code und der pragmatischen Nutzung agiler Arbeitsweisen.

Jan Müller
Raum 12a
Jan Müller
Raum 12a

Vortrag Teilen

11:00 - 11:45
Mi 2.2
Sechseckige Webseiten? Hexagonale Frontend-Architektur!
Sechseckige Webseiten? Hexagonale Frontend-Architektur!

Gefühlt stand das Akronym WWW lange Zeit eher für Wild Wild West. Architekturmuster und -Prinzipien waren im Frontend oft die Ausnahme. Erst mit der letzten großen Frameworkwelle und dem Siegeszug von SPAs begann ein längst notwendiges Umdenken.
Neuere Technologien führen aber nicht automatisch zu einer besseren Architektur. Es gilt, nach wie vor, Architekturmuster gezielt einzusetzen. Eines der bekanntesten Muster im Domain-Driven Design ist die Hexagonale Architektur. Wann lohnt sich der Einsatz und wie funktioniert das in der Praxis?

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Frontend-Erfahrung und TypeScript-Kentnisse sind hilfreich
Schwierigkeitsgrad: Fortgeschritten

Marco Emrich ist Architekt und Consultant bei codecentric und leidenschaftlicher Verfechter von Software-Craft und Codequalität. Er hält regelmäßig Vorträge auf bekannten Konferenzen, ist Autor mehrerer Fachbücher und twittert als @marcoemrich. Wenn er mal nicht tief im Code vergraben ist, zocken ihn seine Kinder in analogen Brettspielen ab.

English below

Sophia Cook ist Senior IT Consultant mit Schwerpunkt Softwareentwicklung. Ihre Abneigung gegen Frontend und insbesondere JavaScript wurde durch das Einsetzen von Hexagonal Architecture in einem Frontend-Projekt geheilt. Man könnte fast sagen das ihr Herz jetzt für Frontend brennt. Darüber hinaus setzt sich Sophia für mehr Frauen in der IT ein. Ihre neu gegründete Community Shevelopers bietet eine Bühne für Frauen von Frauen.
Twitter: https://twitter.com/Soisco
----------
Sophia Cook is a senior IT consultant with a focus on software development. Her aversion to frontend and especially JavaScript was cured by using Hexagonal Architecture in a frontend project. You could almost say that her heart is now burning for frontend. Sophia is also an advocate for more women in IT. Her newly founded munich based community Shevelopers provides a stage for women by women and all supporting allies.

Marco Emrich, Sophia Cook
Raum 11
Marco Emrich, Sophia Cook
Raum 11

Vortrag Teilen

11:00 - 11:45
Mi 7.2
Softwaresysteme wie Apfelbäume pflegen
Softwaresysteme wie Apfelbäume pflegen

Softwaresysteme sind oft große, verwachsene Strukturen, welche Softwareschaffende nach einiger Zeit wieder in Form bringen müssen. Es ist aber eine Herausforderung, einen Überblick über das wuchernde Konglomerat von Softwarekomponenten und Funktionalitäten zu gewinnen, ganz zu schweigen von der Entwicklung eines klaren Plans für das weitere Vorgehen. Im Vortrag verwende ich Analogien aus der Pflege von Apfelbäumen, um Softwaremodernisierenden zu zeigen, wie sie ihre Softwaresysteme mit einem wertorientierten Ansatz weiterentwickeln können.

Zielpublikum: Architekt:innen, Produktentwickler:innen, Softwareentwickler:innen, Softwaremodernisierer:innen
Voraussetzungen: Erfahrung mit optimierungsbedürftigen Softwaresystemen
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Beim Zurechtstutzen eines Apfelbaums haben wir mehrere Optionen, die wir nutzen können. Wir können Äste etwa zurechtstutzen, abschneiden oder einfach komplett ignorieren. Auch Softwaresysteme können wir zurechtstutzen, Teile des Systems abtrennen oder gewisse Bereiche einfach ignorieren. Aber wie schaffen wir es, fundiert über diese verschiedenen Optionen bei der Weiterentwicklung von Softwaresystemen zu reden? Wir brauchen dazu ein klares Bild unseres Softwaresystems genauso, wie wir vor einem Obstbaumschnitt ein klares Bild des Baums benötigen.
In diesem Vortrag zeige ich daher, wie sich ein ähnliches Bild wie bei einem Apfelbaum mit Hilfe der Wardley-Mapping-Technik für komplexe Softwaresysteme gewinnen lässt. Auf Basis dieses Bilds lassen sich dann verschiedenen Optionen des „Systemzurückschnitts“ unter Produktentwickelnde diskutieren und kleine, handlungsorientierte Pläne für die weitere Entwicklung eines Softwaresystems kommunizieren.

Markus Harrer arbeitet seit mehreren Jahren in der Softwareentwicklung und ist vor allem in konservativen Branchen tätig. Als Senior Consultant hilft er, Software nachhaltig und wirtschaftlich sinnvoll zu entwickeln und zu verbessern. Er ist aktiver Mitgestalter in Communities zu den Themen Software Analytics, Softwarearchitektur, Softwaresanierung und Wardley Maps. Zudem ist er akkreditierter Trainer für den iSAQB Foundation Level und dem Advanced-Level-Modul IMPROVE.

11:00 - 11:45
Mi 8.2
Domain Patterns – wie die Domäne sich auf die Architektur auswirkt
Domain Patterns – wie die Domäne sich auf die Architektur auswirkt

Beim Analysieren und Zerlegen von Legacy-Systemen nach DDD sind wir auf Domänen gestoßen, die einfach in Subdomänen aufgeteilt werden konnten, und auf Domänen, bei denen es deutlich schwieriger war. Auch das Alter und der Entwicklungsgrad einer Domäne haben Einfluss auf unsere Möglichkeiten, gute Subdomänen zu finden und die Legacy zu modularisieren. Inzwischen können wir diese Unterschiede beschreiben und haben verschiedene Domain Patterns gefunden und benannt. Ich freue mich auf Feedback und Diskussionen von den Zuhörer:innen.

Zielpublikum: Architekt:innen, Entwickler:innen, Business-Analyst:innen, Projektleiter:innen
Voraussetzungen: Projekterfahrung, Basiswissen in DDD
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In den letzten Jahren haben wie eine Reihe von Domänen mit Subdomänen gesehen und mit DDD zerlegt. Ziel war natürlich immer, ein oder mehrere Softwaresysteme auf die Subdomänen aufzuteilen und eine sinnvolle Zerlegung des Softwaresystems anhand des Domänenschnitts zu erreichen. Mit der Zeit haben wir den folgenden Eindruck gewonnen:

  1. Es gibt (Sub-)Domänen, die sich leichter in (Sub-)Subdomänen zerlegen lassen, und solche, bei denen es deutlich schwerer ist.
  2. Es gibt Umsetzungen in fachliche Kontexte, die es leichter oder schwerer machen, das Legacy-System zu zerlegen.
  3. Die Entwicklung der Domäne und der Software beeinflussen sich gegenseitig und die Legacy-Software ist je nach Entwicklungszustand anders zu zerlegen.

In diesem Talk werde ich unsere Überlegungen zu Domain Patterns und ihrer Umsetzung vorstellen und hoffe auf Diskussionen und Feedback.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/carola.lilienthal

Dr. Carola Lilienthal ist Software-Architektin und Geschäftsführerin bei der WPS – Workplace Solutions GmbH und entwickelt seit mehr als 10 Jahren mit ihren Teams Software-Architekturen nach den Prinzipien des Domain Driven Design. Sie ist Autorin des Buchs "Langlebige Softwarearchitekturen", hat das Buch "Domain-Driven Design Distilled" von Vaughn Vernon ins Deutsche übersetzt und 2023 ihr neues Buch "Domain-Driven Transformation" veröffentlicht.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/carola.lilienthal

Carola Lilienthal
Raum 01
Carola Lilienthal
Raum 01

Vortrag Teilen

11:00 - 11:45
Mi 9.2
Technical Neglect
Technical Neglect

Many developers evoke technical debt to explain the misfortunes and troubles of their codebase and delivery. While unmanaged technical debt weighs down an architecture and exerts drag on its schedule, it is more often an effect than a cause. In this talk, we will look at what is and is not meant by technical debt with a view to properly attributing the root and recurring cause as technical neglect than technical debt. Without seeing technical neglect for what it is, we will continue to misattribute our problems to an effect rather than a cause.

Target Audience: Developers, Architects, Technical Managers
Prerequisites: Responsibility for software development, whether implementing it, guiding it or managing it
Level: Advanced

Extended Abstract:
Many developers evoke the mischievous spirit and day-to-day burden of technical debt to explain the misfortunes and troubles of their codebase and delivery. While unmanaged technical debt weighs down an architecture and exerts drag on its schedule, it is more often an effect than a cause. In this talk, we will look at what is and is not meant by technical debt — and other metaphors — with a view to properly attributing the root and recurring cause as technical neglect than technical debt. Without seeing technical neglect for what it is, we will continue to misattribute our problems to an effect rather than a cause.

Kevlin Henney is an independent consultant, speaker, writer and trainer. His development interests are in programming, practice and people. He is co-author of two volumes in the "Pattern-Oriented Software Architecture" series, and editor and contributor for multiple books in the "97 Things" series. He lives in Bristol and online.

Kevlin Henney
Raum 13a
Kevlin Henney
Raum 13a

Vortrag Teilen

14:30 - 15:30
Mi 1.3
Von Microservices zu evolutionärer Systementwicklung in 60 Minuten
Von Microservices zu evolutionärer Systementwicklung in 60 Minuten

Auch wenn ihr Microservices bereits umgesetzt habt, hängt ein wirklich erfolgreiches Produkt von technisch weiterführenden, methodischen und organisatorischen Themen ab. Wie stark ist die vertikale Idee ausgeprägt? Gibt es eine “Thinnest Viable Platform” und einen Pfad des geringsten Widerstands? Wie gut sind empirische Prozesse ausgeprägt und wie dezentral sind eure Entscheidungswege? In diesem Talk geben wir die Möglichkeit zum Self-Assessment und liefern damit Impulse, Microservices besser zu leben.

Zielpublikum: Architekt:innen, Entwickler:innen und alle, die an vertikalen Architekturen beteiligt sind
Voraussetzungen: Erfahrungen mit Microservices
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Viele Microservices-Anwendungen sind in Betrieb oder werden dort bereits weiterentwickelt und verbessert. Ob ein Microservices-basiertes System wirklich erfolgreich ist, hängt allerdings nicht nur von der technischen Migration ab, die initial geleistet wird. Um Versprechen in Bezug auf kürzere Release-Zeiten, bessere Agilität, höhere Innovationskraft und verbesserte Flexibilität und Skalierbarkeit einzulösen, braucht es weiterführende Impulse. Entwicklungsvorhaben und Teams müssen sich technisch, methodisch und organisatorisch weiterentwickeln.
In dieser Session zeigen wir einige weiterführende Themen, die unserer Erfahrung nach stark mit dem langfristigen Erfolg eines Microservices-Produkts korrelieren. Wie stark ist die vertikale Idee ausgeprägt? Gibt es eine “Thinnest Viable Platform” und einen Pfad des geringsten Widerstands? Wie gut sind empirische Prozesse ausgeprägt und wie dezentral sind die Entscheidungswege? Wie direkt und feinmaschig ist Feedback für qualitative Zielerreichung verfügbar? Aus einem Katalog von Fragen stellen wir hier einige vor. Sie führen allesamt zu einer evolutionären Idee der System- und Architekturentwicklung.
Um zum Nachdenken anzuregen und den Transfer auf den eigenen Kontext zu verbessern, liefern wir nicht nur Theorie, sondern zeigen auch Prüfmöglichkeiten für das eigene System und Reflexionsfragen für die eigene Organisation. Ein kleines Self-Assessment zieht sich durch den Talk und kann offline weiter vertieft werden. Insgesamt ein Schritt in die Richtung Microservices besser umzusetzen und die evolutionäre Idee dahinter besser zu leben.

Stefan Toth ist Gründer der embarc GmbH und Autor zahlreicher Artikel sowie des Buchs "Vorgehensmuster für Softwarearchitektur" (Hanser). Als Berater begleitet er Start-ups, Mittelständler und Großkonzerne bei der organisatorischen, methodischen und technischen Neuausrichtung.

Alexander Kaserbacher ist Berater für Software-Architektur bei embarc. Mehrjährige Erfahrungen aus der agilen Software-Entwicklung helfen ihm dabei, den Mehrwert von Software-Architektur zu vermitteln und diese effektiv umzusetzen. Neben Cloud-Anwendungen, verteilten Systemen und evolutionärer Architektur umfasst seine Leidenschaft für Technologie auch die verschiedensten Auswirkungen von Software auf Unternehmen und gesellschaftliche Faktoren.

Stefan Toth, Alexander Kaserbacher
Raum 01
Stefan Toth, Alexander Kaserbacher
Raum 01

Vortrag Teilen

14:30 - 15:30
Mi 2.3
Schneller, höher, weiter! Aber wie?
Schneller, höher, weiter! Aber wie?

Effizienz/Performanz gehört neben Sicherheit zu den meistgefragten Qualitätsattributen. Doch was heißt überhaupt Performanz und wie sollten Software-Architekten damit konkret umgehen? Gibt es einen Unterschied zwischen Performanz und Skalierbarkeit? Gibt es Architekturkonzepte, die sich beim Umgang mit Performanzkriterien als nützlich erweisen? Und wie lässt sich die Performanz eines Systems testen? Diese und andere Fragen möchte der Vortrag beantworten.

Zielpublikum: Entwickler:innen, Architekt:innen, Tester:innen
Voraussetzungen: Software-Architekturkenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Effizienz/Performanz gehört neben Sicherheit zu den meistgefragten Qualitätsattributen. Doch was heißt überhaupt Performanz und wie sollten Software-Architekten damit umgehen? Gibt es einen Unterschied zwischen Performanz und Skalierbarkeit?
Gerade beim strategischen Design beziehungsweise Architekturentwurf ist der Umgang mit Performanzzielen schwierig. Zudem können Performanzziele mit anderen Qualitätsattributen in Konflikt stehen, etwa mit Sicherheit. Wie lassen sich aber solche Konflikte auflösen? Gibt es Architekturkonzepte, die sich beim Umgang mit Performanzkriterien als nützlich erweisen? Und wie lässt sich die Performanz eines Systems verifizieren bzw. testen? Diese und andere Fragen möchte der Vortrag beantworten.
Lernziele:

  1. Verständnis für die verschiedenen Facetten von Performanz
  2. Erlernen der systematischen Behandlung von Performanzzielen auch in Hinblick auf andere Qualitätsattribute
  3. Erlernen von Architekturkonzepten und Vorgehensweisen

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/michael.stal

Michael Stal arbeitet bei der Siemens AG unter anderem an Software-Architekturen, verteilten Systemen und KI - sowohl in der Forschung als auch in Projekten. Zudem ist er als Professor an der Universität Groningen und als Chefredakteur von JavaSPEKTRUM tätig. Er verfügt über drei Jahrzehnte Erfahrung im Softwareengineering und hat Spaß daran, Wissen zu vermitteln.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/michael.stal

Michael Stal
Raum 13a
Michael Stal
Raum 13a

Vortrag Teilen

14:30 - 15:30
Mi 8.3
Navigating sociotechnical complexity with DDD and friends
Navigating sociotechnical complexity with DDD and friends

Xin has lived and breathed DDD for more than a decade. Drawing on her experiences, Xin makes a case for DDD’s rising relevance in a post-modern world, where aging companies struggle with aging software, while adding new software and complexity to their IT portfolio. With good attractor effect DDD is evolving from a software-centric design discipline to a multi-dimensional toolbox. Join Xin to reflect together on, how DDD can help us sustain meaning and productivity in a reality of vast sociotechnical complexity and constant change.

Target Audience: Software Professionals, Architects, Leaders, Agile Practitioners, Change Agents, Facilitators
Prerequisites: Basic DDD understanding; Prior DDD experience is not a must but helps understand the deeper message
Level: Advanced

Extended Abstract:
What is the first thing that comes to mind when you hear the word DDD – Domain-Driven Design? The geeky technical patterns (Value object, Entity, Aggregate, etc.)? Walls decorated with colorful event storming stickies? A miracle cure to rescue change initiatives in large companies? Or are you thinking of a software development method born in the pre-cloud and pre-microservice era, which after 20 years is still struggling to gain traction?
Xin has lived and breathed DDD for more than a decade. In this talk, Xin makes a case for DDD’s rising relevance in a post-modern world, where aging companies struggle with aging software, while adding new software and complexity to their IT portfolio. The reflections will be grounded in solid DDD experiences and observations from the battlefield. With good attractor effect DDD can evolve from a software-centric design discipline to a multi-dimensional toolbox of thinking, modeling and collaboration techniques. You will be invited to explore DDD's value proposition and reflect upon how to leverage DDD’s strategic and tactical design approaches in your own context.
Globally, there is an increasing interest in DDD. Hope is evergreen for DDD to become a key ingredient in the magic potion for tackling the increasing complexity, not only at the heart of software, but also at the heart of sociotechnical organizations. How can DDD help us create meaning and productivity in a reality of multi-dimensional complexity and constant change? What’s in it for me? What’s in it for us?

Xin Yao is a sociotechnical architect, DDD evangelist and independent consultant. She believes that a product, domain and team-oriented architecture is the super glue to bind multiple agile teams navigating toward a common horizon. She’s spearheaded large-scale change initiatives in boundary-spanning architect roles, weaving together strategy, products, teams, systems, domains into coherent models to guide progress and reduce stress. She architects collective experiences in scale-ups and enterprises to unravel complexity and discover leverage points. In sociotechnical environments where a team’s cognitive capacity is under constant stress, she practices domain-driven design and facilitates collaborative modeling to help teams and organizations make sense, make decisions and make intuitive business software.

Xin Yao
Raum 05
Xin Yao
Raum 05

Vortrag Teilen

17:00 - 18:00
Mi 1.4
How Process Orchestration Increases Agility Without Harming Architecture
How Process Orchestration Increases Agility Without Harming Architecture

A main theme in modern architectures is around fine-grained, isolated, reactive components, that are managed by autonomous teams (think microservices). This is considered key to decoupling, which, in turn, leads to business agility. Unfortunately, this often goes wrong and people end up with more tightly coupled systems, that are hard to understand and change - the opposite of agility. In this talk, I will explore why this happens and provide my view on how process orchestration can improve the situation without harming any good architecture.

Target Audience: Architects, Lead Engineers, IT Decision Makers
Prerequisites: Basic knowledge in Microservice architecture
Level: Basic

Extended Abstract:
I will walk you through the challenges around event-driven systems and microservices, talking about orchestration and choreography, also showing you how to balance both architectural approaches.
I will further discuss the importance of looking at end-to-end processes before going into local automations, as local optimizations can actually harm the global result.
I will further compare different approaches to automate end-to-end processes, from batches over streaming to workflow engines. You will understand the impact on agility and get guidance on decision criteria, backed by examples collected in various real-life projects.
I will sketch what influence those architecture decisions have on the governance and enterprise architecture of organizations.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/bernd.ruecker

Bernd Rücker is a software developer at heart who has been innovating process automation deployed in highly scalable and agile environments of industry leaders such as T-Mobile, Lufthansa, ING, and Atlassian. He contributed to various open-source workflow engines for more than 15 years and is the Co-Founder and Chief Technologist of Camunda – an open-source software company reinventing process automation. He is the author of "Practical Process Automation" and co-author of "Real-Life BPMN". Additionally, he is a regular speaker at conferences around the world and a frequent contributor to several technology publications. He focuses on new process automation paradigms that fit into modern architectures around distributed systems, microservices, domain-driven design, event-driven architecture, and reactive systems.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/bernd.ruecker

Bernd Rücker
Raum 13b
Bernd Rücker
Raum 13b

Vortrag Teilen

17:00 - 18:00
Mi 2.4
Secure by Design – the Architect’s Guide to Security Design Principles
Secure by Design – the Architect’s Guide to Security Design Principles

Architecture work has to balance providing clear guidance for important decisions with empowering people to build their aspects of the system without interference. In this session we'll explore how security principles can help achieve this for application security. The talk explains how principles can guide design decisions without being too prescriptive and explains a set of ten proven principles for designing secure systems, distilled from security engineering practice but presented in accessible language for the working software architect.

Target Audience: Architects, Developers, Testers, Project Managers
Prerequisites: Some experience in developing large scale systems
Level: Advanced

Extended Abstract:
Security is an ever more important topic for system designers. As our world becomes digital, today’s safely-hidden back office system is tomorrow’s public API, open to anyone on the Internet with a hacking tool and time on their hands. So the days of hoping that security is someone else’s problem are over.
The security community has developed a well understood set of principles used to build systems that are secure (or at least securable) by design, but this topic often isn’t included in the training of software developers, assuming that it’s only relevant to security specialists. Then when principles are explained, they are often shrouded in the jargon of the security engineering community and so mainstream developers struggle to understand and apply them.
In this talk, we will introduce a set of ten key, proven, principles for designing secure systems, distilled from the wisdom of the security engineering community. We’ll explain each principle the context of mainstream system design, rather than in the specialised language of security engineering, explaining how it is applied in practice to improve security.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Eoin.Woods

Eoin Woods is the Chief Engineer at Endava (www.endava.com) where he is responsible for delivery capability and innovation. In previous professional lives he has developed databases, security software and way too many systems to move money around. He is interested in software architecture, software security, DevOps and software energy efficiency. He co-authored three books on software architecture and received the 2018 Linda Northrup Award for Software Architecture, from the SEI at CMU.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Eoin.Woods

Eoin Woods
Raum 01
17:00 - 18:00
Mi 8.4
Bounded Contexts mit Event Storming finden
Bounded Contexts mit Event Storming finden

Dass Event Storming eine Methode aus dem Domain-driven Design ist und man damit ein gemeinsames Verständnis der Fachlichkeit erreichen kann, ist vielen bekannt. Ich möchte in dieser Session darüber hinausgehen und euch zeigen, wie man Event Storming auch als eine Grundlage für einen guten Serviceschnitt nutzen kann.
In meinem Vortrag erläutere ich euch die Vorteile von Event Storming und verprobe die Methode anhand eines Praxisbeispiels. Das Ziel ist die Erstellung von Aggregaten, die die Basis für Bounded Contexts bilden.

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

Extended Abstract:
Beim Finden der Bounded Contexts gehe ich auch darauf ein, was bei deren Kommunikation untereinander beachtet werden muss und wie man die Kommunikation gestalten kann, um später unabhängige Services realisieren zu können.

Ina Einemann ist als Agile Coach bei der Open Knowledge GmbH in Oldenburg tätig. Ihr Tätigkeitsumfeld umfasst neben ihrer Arbeit als Scrum Master auch Aufgaben aus dem Bereich PO und Requirements Engineering. Sie beschäftigt sich mit agilen Methoden und Vorgehensmodellen und berät Teams bei der Umsetzung agiler Praktiken. Sie ist außerdem einer der Podcasts-Host.

Ina Einemann
Raum 11
Ina Einemann
Raum 11

Vortrag Teilen

17:00 - 18:00
Mi 9.4
Unabhängig von Microservices – wie geht man vor, um Code entlang von Domänen umzustrukturieren?
Unabhängig von Microservices – wie geht man vor, um Code entlang von Domänen umzustrukturieren?

Das eigene Software-System in Microservices transformieren? Unabhängig davon, wir Softwerker sollten auch bestehenden Code entlang von Fachlichkeiten besser trennen. Wie gehen wir vor? Strangler-Pattern? Ist keine praktische Anleitung. Den Code in Geschäftsdomänen konzeptionell aufteilen und dann neu zu strukturieren? Klingt nach Big-upfront-Design.
Im Vortrag zeigen wir, wie man die bestehende Datenbasis über Code hinaus nutzen kann. Wie man z.B. die Features (im Issue-Tracker) oder die Beiträge der einzelnen Entwickler dabei berücksichtigt.

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

Extended Abstract:
Das eigene Software-System in Microservices transformieren? Unabhängig davon, wir Softwerker sollten auch bestehenden Code entlang von Fachlichkeiten besser trennen. Wie gehen wir vor? Strangler-Pattern? Ist keine praktische Anleitung. Den Code in Geschäftsdomänen konzeptionell aufteilen und dann refactoren? Klingt nach Big-upfront-Design.
Im Vortrag zeigen wir, wie man die bestehende Datenbasis über Code hinaus nutzen kann. Wie man von Features (im Issue-Tracker) ausgeht, diese probeweise Domänen zuweist und deren Kopplungen (Überlappungen, Aufruf-Abhängigkeiten) im Code evaluiert. Damit dann den Refactoring-Bedarf lokalisieren und den Aufwand bewerten. Und wie automatisierte Refactoring-Vorschläge dabei eine Rolle spielen.
Die Herausforderungen sind die gleichen, wir müssen sie nur anders angehen.

Behandelte Problemstellungen:

  1. Wie trennt man bestehenden Code nach fachlichen Verantwortlichkeiten?
  2. Wie führt man das Ganze probeweise durch vor dem Refactoring/Coding?
  3. Wie nutzt man die Features des Issue-Trackers dafür?
  4. Wie nutzt man das Code-Repository dafür?
  5. Wie wird der Refactoring/Redesign-Bedarf lokalisiert?
  6. Wie bewertet man den Aufwand dafür?

Nutzen für den Teilnehmer:

  1. Teilnehmer lernen ein praktisches Vorgehen zur Trennung des Codes entlang fachlicher Verantwortlichkeiten
  2. Teilnehmer lernen mehr über architekturelle technische Schulden
  3. Teilnehmer wohnen einem unterhaltsamen Vortrag bei :-)

Egon Wuchner hat mehr als 18 Jahre bei der Siemens AG als Software Engineer, Architekt und Projektleiter zu den Themen Software-Architektur und Qualität gearbeitet. 2018 hat er Cape of Good Code gegründet.

Konstantin Sokolov hat für Siemens als Freelancer an den Themen mit Egon zusammengearbeitet. Zusammen haben sie Cape of Good Code mit dem Ziel gegründet, Software-Analysen anzubieten, auf die es ankommt.

Egon Wuchner, Konstantin Sokolov
Raum 12a
Egon Wuchner, Konstantin Sokolov
Raum 12a

Vortrag Teilen

18:30 - 20:00
Nmi 1
OO and FP Can’t Be Friends – Yet
OO and FP Can’t Be Friends – Yet

Henning (OO to the core) and Mike (ferociously FP) agree on all the fundamentals of software architecture, but when it comes to designing models, they can't seem to find common ground.
OO and FP folks like to congratulate themselves on how well they go together - and how OO languages are accreting one feature after another from the FP world.
Henning and Mike will highlight how OO and FP approaches to design differ, and offer possible approaches to unifying both for mutual gain and insight.

Target Audience: Architects, Developers
Prerequisites: Experience in OO or FP
Level: Advanced

Extended Abstract:
Much work remains to unify these two worlds:

  1. OO folks are weary of premature abstractions, whereas FP folks tend to abstract early.
  2. While both camps prefer operation-rich models, the approaches to designing these operations are incompatible. Specifically, the BDD and TDD approaches favored by the OO folks are incompatible with the design recipes approach preferred by the functional camp.
  3. Paradoxically, OO - which is supposed to be about objects - espouses BDD which is about functions, whereas FP has a rich tradition in data design, i.e. objects.
  4. In OO, objects populate the domain, and they are encapsulated and thus isolated, whereas in FP this encapsulation is an emergent (or not emergent) phenomenon.
  5. OO is inherently stateful, and FP is inherently stateless. This naturally leads to very different approaches to interface design, and more importantly, to the use of types.

Mehr Inhalte dieser Speaker? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/michael.sperberhttps://www.sigs.de/autor/henning.schwentner

English below

Dr. Michael Sperber ist Geschäftsführer der Active Group GmbH. Er ist international anerkannter Experte für funktionale Programmierung. Außerdem hat er zahlreiche Fachartikel und Bücher zum Thema verfasst. Michael Sperber ist Mitbegründer des Blogs funktionale-programmierung.de und Mitorganisator der Entwicklerkonferenz BOB. Außerdem ist er einer der primären Autoren des iSAQB-Advanced-Curriculums "Funktionale Software-Architektur".
----------
Dr. Michael Sperber is CEO of Active Group in Tübingen, Germany. Mike specializes in functional architecture, and has been an internationally recognized expert in the field. He has authored many papers on the subject as well as several books. Mike is also an accredited iSAQB trainer, curator of its FUNAR and DSL curricula, and a member of iSAQB's Foundation working group.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/michael.sperber

English below

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« (Addison-Wesley, 2022) und dem www.LeasingNinja.io sowie Übersetzer von »Domain-Driven Design kompakt« (dpunkt, 2017).
----------
Henning Schwentner loves programming in high quality. He lives this passion as coder, coach, and consultant at WPS – Workplace Solutions. There he helps teams to restructure their monoliths or to build new systems from the beginning with a sustainable architecture. Henning is author of "Domain Storytelling" (Addison-Wesley, 2022), "Domain-Driven Transformation" (dpunkt, 2023), and the LeasingNinja.io.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/henning.schwentner

Michael Sperber, Henning Schwentner
Raum 11
Michael Sperber, Henning Schwentner
Raum 11

Vortrag Teilen

18:30 - 20:00
Nmi 2
Expanding Horizons
Expanding Horizons

Expanding horizons has many facets. It means taking advantage of new opportunities that arise from technical progress, such as Large Language Models, or societal challenges like Sustainability. Expanding horizons also means taking responsibility. AI and data analytics have a direct impact on our future life, good and bad. Expanding horizons also means reflection on existing practice. We have perhaps forgotten the benefits of structured monoliths, or have sometimes overdone it with agility, which suggests a critical and learning retrospective.

Moderation: Frank Buschmann
Panelists: Isabel Bär, Zoe Lopez-Latorre, Carola Lilienthal, Xin Yao

Target Audience: Software Practitioners
Prerequisites: None
Level: Advanced

Extended Abstract:
The motto of OOP 2024 has many facets. Expanding horizons means understanding and taking advantage of new opportunities that arise from technological progress or societal challenges. For example, on Large Language Models, Sustainability, and the Metaverse. Expanding horizons also means taking responsibility and not blindly applying new technologies. For example, AI and data analytics have a direct impact on our future life and social interaction. With all the consequences, good and bad. But broadening horizons also means reflecting on existing technologies and practices. In the course of the euphoria about microservices, for example, we have perhaps forgotten the advantages of the structured monolith too much, or have sometimes overdone it with agility. A critical and learning retrospective seems appropriate.
In this panel, we will examine the various aspects of the motto of OOP 2024 to give us all meaningful guiding thoughts for the exciting journey to expanding our horizons.

Frank Buschmann is a Senior Principal Engineer at Siemens Technology in Munich. His interests are in modern Software-Architecture and development approaches for industrial digitization.

Isabel Bär is a skilled professional with a Master's degree in Data Engineering from the Hasso-Plattner-Institute. She has made contributions in the field of AI software, focusing on areas like MLOps and Responsible AI. Beyond being a regular speaker at various conferences, she has also taken on the role of organizing conferences on Data and AI, showcasing her commitment to knowledge sharing and community building. Currently, she is working as a consultant in a German IT consulting company.

Dr. Carola Lilienthal ist Software-Architektin und Geschäftsführerin bei der WPS – Workplace Solutions GmbH und entwickelt seit mehr als 10 Jahren mit ihren Teams Software-Architekturen nach den Prinzipien des Domain Driven Design. Sie ist Autorin des Buchs "Langlebige Softwarearchitekturen", hat das Buch "Domain-Driven Design Distilled" von Vaughn Vernon ins Deutsche übersetzt und 2023 ihr neues Buch "Domain-Driven Transformation" veröffentlicht.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/carola.lilienthal

Zoe is a digital sustainability and web performance engineer with 3 years of experience in the field. They have published user research and actionable advice for brands and advertisers, and they are currently running web performance and web energy consumption correlation research studies. Zoe is also a member of the Sustainable Web W3C Community Group, focused on web digital sustainability measurement and standards to offer actionable advice to developers. They are a contributor to the Web Sustainability Guidelines 1.0 Draft.

Zoe is passionate about using their skills to help businesses reduce their digital environmental impact. They believe that digital sustainability is an important issue that everyone should be aware of, and they are committed to raising awareness and sharing their knowledge with others.

Xin Yao is a sociotechnical architect, DDD evangelist and independent consultant. She believes that a product, domain and team-oriented architecture is the super glue to bind multiple agile teams navigating toward a common horizon. She’s spearheaded large-scale change initiatives in boundary-spanning architect roles, weaving together strategy, products, teams, systems, domains into coherent models to guide progress and reduce stress. She architects collective experiences in scale-ups and enterprises to unravel complexity and discover leverage points. In sociotechnical environments where a team’s cognitive capacity is under constant stress, she practices domain-driven design and facilitates collaborative modeling to help teams and organizations make sense, make decisions and make intuitive business software.

Frank Buschmann, Isabel Bär, Carola Lilienthal, Zoe Lopez-Latorre, Xin Yao
Raum 05
Frank Buschmann, Isabel Bär, Carola Lilienthal, Zoe Lopez-Latorre, Xin Yao
Raum 05

Vortrag Teilen

18:30 - 20:00
Nmi 3
Diät für Eure Architekturdokumentation – Unser Ernährungsplan
Diät für Eure Architekturdokumentation – Unser Ernährungsplan

In Projekten treffen wir oft auf zwei Arten von Architekturdokumentation:
Gar keine oder veraltet in gigantischem Umfang. Der Effekt ist der gleiche – es wird nichts mehr dokumentiert, begründet mit "Keine Zeit" oder "Das findet niemand mehr".
Wir stellen Euch den Architecture Communication Canvas (ACC) vor, mit welchem Ihr in kurzer Zeit die wichtigsten Aspekte Eurer Architektur dokumentieren und kommunizieren könnt. Mit Praxisbezug zeigen wir Euch, dass Dokumentation sparsam und dabei nützlich für Stakeholder sein kann – und Spaß macht!

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Grundwissen in Software-Architektur/Architekturdokumentation
Schwierigkeitsgrad: Anfänger

Extended Abstract:
In den meisten Projekten treffen wir auf folgende Arten von Architekturdokumentation:
Entweder gibt es gar keine Dokumentation, oder es existiert veraltete Dokumentation in gigantischem Umfang. Unabhängig davon ist der Effekt jedoch der gleiche – es wird nichts Neues mehr dokumentiert. Begründet wird dies meist mit "Das liest doch niemand", "Dafür haben wir keine Zeit" oder "Das findet ja niemand mehr". Kommt Euch bekannt vor? Dann ist dieser Vortrag genau das Richtige für Euch.
Wir stellen Euch heute den Architecture Communication Canvas (ACC) vor, mit welchem Ihr in kurzer Zeit die wichtigsten Aspekte Eurer Architektur dokumentieren und kommunizieren könnt. Der Canvas ist kompatibel zum arc42-Template, jedoch wesentlich kompakter. Mit Beispielen aus der Praxis sowie praktischen Tipps zeigen wir Euch, dass Dokumentation zugleich sparsam erstellt werden und dabei nützlich für Stakeholder sein kann – und das Ganze auch noch Spaß macht!

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/gernot.starke

Benjamin Wolf ist Senior IT Consultant, Coach und Trainer für Software-Architektur, -qualität und -entwicklungsprozesse sowie Architekturdokumentation.

Dr. Gernot Starke, INNOQ-Fellow, arbeitet als Coach und Berater für Software-Entwicklung und -Architektur. Er ist Mitbegründer und Betreuer der Open-Source-Projekte arc42 (https://arc42.de) und aim42 (https://aim42.github.io), Buchautor und gelegentlicher Konferenzsprecher.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/gernot.starke

Benjamin Wolf, Gernot Starke
Raum 13b
Benjamin Wolf, Gernot Starke
Raum 13b

Vortrag Teilen

, (Donnerstag, 01.Februar 2024)
09:00 - 10:30
Do 1.1
Where do we go from here? – mastering the changed needs of architectural work
Where do we go from here? – mastering the changed needs of architectural work

Designing good applications has become more demanding than ever: Extremely flexibility. Super-fast to change. Never down. Increasing user demands. Sustainability. Fewer developers. More AI. The list appears to be endless.
Many demands have not existed 10 or 15 years ago. Some have changed dramatically. Still, the discussions regarding architecture barely reflect that. In this session, we will take a look at how the architectural demands have changed and how to tackle the challenges of today best.

Target Audience: Architects, Senior Developers, Decision Makers
Prerequisites: Sound architectural knowledge makes the ideas presented easier to grasp
Level: Advanced

Extended Abstract:
Designing good applications has become more demanding than ever: Extremely flexibility. Super-fast to change. Never down. Demand-based scaling. Increasing user demands. Sustainability. APIs as first class citizens. Secure like a fortress. Fewer developers. More AI. The list appears to be endless.
Many of today's architecture demands have not existed 10 or 15 years ago. Some have changed dramatically. Still, most discussions regarding architecture seem to be stuck in the early 2000s.
In this session, we will take a look at how our application design demands have changed, what it means today to design good applications and how to tackle the challenges best.
Let us catch up together and learn what architectural work today means!

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/uwe.friedrichsen

Uwe Friedrichsen ist langjähriger Reisender in der Welt der IT, Dot-Connector, Kartograph von Neuland, Bewahrer zeitloser Weisheiten sowie Übersetzer zwischen den Etagen bei Themen wie Systementwurf, Widerstandsfähigkeit und Nachhaltigkeit. Uwe verabscheut lange Biografien und versucht, die IT (ein bisschen) besser zu machen.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/uwe.friedrichsen

Effective Practices for Continuous Software Architecture
Effective Practices for Continuous Software Architecture

Continuous Software Architecture is an approach to software architecture that tries to move architecture from a set of up-front blueprints to a continually developed set of architectural knowledge and decisions. While a simple idea, actually putting it into practice can be difficult. In this talk we will briefly recap the idea of Continuous Software Architecture and then explore the key practices that are usually needed to achieve it, as well as the common problems and how to address them.

Target Audience: Architects, Developers, Technical Project Managers
Prerequisites: Some familiarity with agile development and modern architecture practice
Level: Advanced

Extended Abstract:
Continuous Software Architecture is a philosophy and approach to software architecture that embraces the fact that doing most of the design before the implementation does not work very well, and perhaps never did. The approach tries to move architecture to a continually developed set of architectural knowledge and decisions, stressing collective ownership of the resulting architecture. This talk will provide attendees with practical and actionable advice on implementing the five key practices of Continuous Architecture: Technical Leadership, Achieving Quality Attributes, Driving Design Decisions, Managing Technical Debt and Implementing Feedback Loops.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Eoin.Woods

Eoin Woods is the Chief Engineer at Endava (www.endava.com) where he is responsible for delivery capability and innovation. In previous professional lives he has developed databases, security software and way too many systems to move money around. He is interested in software architecture, software security, DevOps and software energy efficiency. He co-authored three books on software architecture and received the 2018 Linda Northrup Award for Software Architecture, from the SEI at CMU.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Eoin.Woods

Uwe Friedrichsen
Raum 05
Eoin Woods
Raum 05
Uwe Friedrichsen
Raum 05

Vortrag Teilen

Eoin Woods
Raum 05

Vortrag Teilen

09:00 - 09:45
Do 2.1
Quality Metrics Unleashed: Softwarequalität im Griff mit Visualisierung und Alerting
Quality Metrics Unleashed: Softwarequalität im Griff mit Visualisierung und Alerting

Das Sicherstellen der Softwarequalität in Microservice-Architekturen ist eine echte Herausforderung: Unsere bewährten Ansätze skalieren nicht mehr für komplexe Systeme mit zahlreichen Komponenten.
Wir präsentieren unseren Ansatz, der die Softwarequalität in komplexen Microservice-Architekturen beherrschbar macht. Wir sammeln und visualisieren verschiedene Metriken an zentraler Stelle, setzen auf Alerting bei Anomalien und unterstützen damit unsere Teams, frühzeitig zu erkennen, wohin wir unsere Aufmerksamkeit gezielt lenken müssen.

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

Extended Abstract:
Mit einer geschickten Kombination von Open-Source-Tools haben wir unser Problem gelöst, den Überblick über zahlreiche verteilte Repos und Komponenten zu behalten.
Wir betrachten dabei verschiedene Metriken: sowohl die Codequalität, als auch fachliche und technische Schulden, die Einhaltung von Architekturvorgaben und viele weitere.

Sonja Wegner ist Lead Software Architect und Business Unit Director bei der QAware. Ihre aktuellen Schwerpunkte liegen im Design und der Implementierung komplexer Systeme und Software-Architekturen.
Seit einiger Zeit beschäftigt sie sich besonders mit Softwarequalität und deren Messung, APIs und deren Architektur-Aspekten und Teststrategien. Sie teilt ihre Erfahrungen hierzu gerne und regelmäßig bei verschiedenen Konferenzen.

Als Senior Software Engineer bei der QAware hat sich Ildikó Tárkányi auf den Aufbau und das Testen komplexer Softwaresysteme spezialisiert. Durch ihre Leidenschaft für Technologie und ihr Engagement für hohe Qualitätsstandards meistert sie anspruchsvolle Probleme. Sie ist eine begeisterte Befürworterin des Wissenstransfers und nimmt an fachlichen Diskussionen und Austausch gerne teil.

Sonja Wegner, Ildikó Tárkányi
Raum 13a
09:00 - 10:30
Do 3.1
Performant Component through Customization
Performant Component through Customization

Most current UI libraries provide great user experience with a vast of components. But when it comes to heavy customization and non-standard scenarios, especially for E-Commerce, they become hard to manage, scale or even slow down performance. How to create a UI library that provides users the most possible freedom in customizing components, while keeping our performance and scalability to the fullest? How much customization freedom is enough? That's what my talk is about.

Target Audience: Developers, Architects, Project Leader
Prerequisites: JavaScript
Level: Advanced

Maya Shavin is Senior Software-Engineer in Microsoft, working extensively with JavaScript and frontend frameworks and based in Israel. She founded and is currently the organizer of the VueJS Israel Meetup Community, helping to create a strong playground for Vue.js lovers and like-minded developers. Maya is also a published author, international speaker and an open-source library maintainer of frontend and web projects. As a core maintainer of StorefrontUI framework for e-commerce, she focuses on delivering performant components and best practices to the community while believing a strong Vanilla JavaScript knowledge is necessary for being a good web developer.

Latest Developments in Open Source
Latest Developments in Open Source

Last year in open source, we saw the compliance threat shift from license violation to contract violation, we saw the rise of the bill of material as a purchasing requirement, and we saw the continued growth of source-available licenses. If you don't know what I'm talking about, you really need to attend, because your business is at risk if you don't understand these changes. In this annual talk, I will review the last year and speculate about what the future may bring.

Target Audience: Product Leaders, Engineering Leaders, Architects, Developers, Enthusiasts
Prerequisites: Basic understanding of open-source software development
Level: Advanced

Dirk Riehle is a professor of computer science at University of Erlangen. He is also the CEO of Bayave GmbH, a consulting firm, and chief scientist of EDITIVE, one of the startups out of his research. His work helps companies succeed in and through software, with a specialization in open source, inner source, and product strategy. Before joining academia, Prof. Riehle led the open source research group at SAP Labs in Palo Alto, California.

Maya Shavin
Raum 04b
Dirk Riehle
Raum 04b
Maya Shavin
Raum 04b

Vortrag Teilen

Dirk Riehle
Raum 04b

Vortrag Teilen

09:00 - 10:30
Do 7.1
Loosely or lousily coupled? Understanding communication patterns in microservices architectures
Loosely or lousily coupled? Understanding communication patterns in microservices architectures

In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. Now there are so many questions around this communication (synchronous vs asynchronous, event-driven? what is the influence on the coupling of your services? ...?). This talk will help you answer these questions for your project. You will better understand not only the architectural implications but also the effect on the productivity of your teams.

Target Audience: Architects, Engineers, Developers
Prerequisites: Basic experience with distributed systems
Level: Basic

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

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

This talk will help you answer these questions for your project. You will better understand not only the architectural implications but also the effect on the productivity of your teams.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/bernd.ruecker

Bernd Rücker is a software developer at heart who has been innovating process automation deployed in highly scalable and agile environments of industry leaders such as T-Mobile, Lufthansa, ING, and Atlassian. He contributed to various open-source workflow engines for more than 15 years and is the Co-Founder and Chief Technologist of Camunda – an open-source software company reinventing process automation. He is the author of "Practical Process Automation" and co-author of "Real-Life BPMN". Additionally, he is a regular speaker at conferences around the world and a frequent contributor to several technology publications. He focuses on new process automation paradigms that fit into modern architectures around distributed systems, microservices, domain-driven design, event-driven architecture, and reactive systems.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/bernd.ruecker

Bernd Rücker
Raum 13b
Bernd Rücker
Raum 13b

Vortrag Teilen

09:00 - 10:30
Do 8.1
Best Practices, um Architekturdokumentation aktuell zu halten
Best Practices, um Architekturdokumentation aktuell zu halten

Eine explizite Softwarearchitektur ist der Garant für erfolgreiche Softwareprojekte. Zur Unterstützung der Kommunikation braucht es eine inhaltlich hinreichende und aktuelle Dokumentation. Der Docs-as-Code-Ansatz unterstützt, indem die Dokumentation in Form leichtgewichtiger Text- und Grafikformate näher an den Quellcode gebracht, in der Versionsverwaltung abgelegt, mit leichtgewichtigen Entwicklerwerkzeugen (IDE/Texteditor, Build-Tools, CI/CD-Pipelines) bearbeitet und in die Softwareentwicklungsprozesse integriert wird.

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

Extended Abstract:
Der Vortrag stellt leichtgewichtige Methoden, Vorlagen und Tools vor, die zum Erstellen einer hochwertigen, sich selbst validierenden Softwaredokumentation eingesetzt werden. Wir schauen uns Ansätze wie Docs-as-Code, leichtgewichtige Textformate, Ablage in der Versionsverwaltung und die Einbettung in die Build- und Review-Prozesse an. Das Sichtbarmachen von Software-Architekturkonzepten im Code und das Einbinden von Software-Analyse-Werkzeugen ermöglichen den kontinuierlichen Abgleich der Soll- und Ist-Strukturen und machen die Architekturdokumentation lebendiger.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Falk.Sippach

Falk Sippach ist bei der embarc Software Consulting GmbH als Softwarearchitekt, Berater und Trainer stets auf der Suche nach dem Funken Leidenschaft, den er bei seinen Teilnehmern, Kunden und Kollegen entfachen kann. Bereits seit über 15 Jahren unterstützt er in meist agilen Softwareentwicklungsprojekten im Java-Umfeld. Als aktiver Bestandteil der Community (Mitorganisator der JUG Darmstadt; Konferenzleitung JavaLand) teilt er zudem sein Wissen gern in Artikeln, Blog-Beiträgen sowie bei Vorträgen auf Konferenzen oder User-Group-Treffen und unterstützt bei der Organisation diverser Fachveranstaltungen.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Falk.Sippach

Falk Sippach
Raum 02
Falk Sippach
Raum 02

Vortrag Teilen

09:00 - 10:30
Do 9.1
ZUKUNFTschaffen – eine nachhaltige Zukunft braucht kreative Köpfe
ZUKUNFTschaffen – eine nachhaltige Zukunft braucht kreative Köpfe

In der leidigen Diskussion um Technologieoffenheit wird übersehen, dass für zukunftsfähige Organisationen Denkoffenheit zentral ist. Unser Bildungssystem schafft es nicht, diese bei jungen Menschen zu fördern. Daher wurde im April '23 ehrenamtlich die Initiative ZUKUNFTschaffen gegründet, die jungen Menschen Kreativität anhand Projektarbeit an den 17 SDGs* vermittelt.
In der interaktiven Session wird ein Win-Win-Win präsentiert, bei dem Nachhaltigkeit, Unternehmen & deren Mitarbeitende durch ZUKUNFTschaffen-Projekte in Organisationen profitieren.
*SDGs = UN Sustainable Development Goals

Zielpublikum: Menschen, die an Nachhaltigkeit interessiert sind
Voraussetzungen: Interesse, Neugier, Reflexion
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Mit den 17 UN-Zielen zur nachhaltigen Entwicklung (SDGs) zu mehr Kreativität in der Welt
ZUKUNFTschaffen adressiert die Lücke zwischen akademischem Grundlagenwissen, welches das deutsche Bildungssystem mehr schlecht als recht vermittelt, und den Kompetenzen, die in unserer heutigen Arbeits- und Lebenswelt erforderlich sind.
Wie könnte man diese Chance, etwas für Individuen zu tun, das gleichzeitig positive gesellschaftliche Auswirkungen hat, nun für Unternehmen gewinnbringend weiterdenken? Das Durchlaufen des ZUKUNFTschaffen-Programms in der betrieblichen Ausbildung oder z.B. kurz nach dem Berufseinstieg bietet Unternehmen die Möglichkeit, die Zukunfts-Kompetenzen ihrer Mitarbeitenden oder „Neuzugänge“ zu stärken. Über die Vernetzung in den Projektteams und ins Unternehmen hinein stärkt bzw. beschleunigt es ihre Integration und Unternehmensbindung. Gleichzeitig schärft das Programm den Blick der Menschen für Themen rund um Nachhaltigkeit. Durch die inhaltliche Arbeit an den 17 SDGs werden gesellschaftlich relevante Probleme, vorzugsweise auch mit Unternehmensbezug, adressiert und idealerweise gelöst oder zumindest abgemildert.
In diesem Vortrag wird in einem Mix aus Case Study und wissenschaftlichen Hintergrundinformationen vorgestellt, wie das Programm ZUKUNFTschaffen entsprechend konzipiert wurde.
Die Teilnehmer:innen werden in dem Vortrag

  1. Ein pragmatisches und praxisorientiertes Konzept kennenlernen, um Nachhaltigkeit mit der Förderung von Zukunftskompetenzen zu verknüpfen
  2. Denkanstöße bekommen, wie sie Menschen in ihrer Organisation zur Nachhaltigkeit befähigen können
  3. Argumentationshilfen erhalten, um in ihren Organisationen für Nachhaltigkeitsprojekte zu „werben“
  4. Inspiriert werden, von den Projektergebnissen junger Menschen zu den 17 UN-Zielen der nachhaltigen Entwicklung.

Für Maren Baermann(sie/ihr) ist der Schlüssel zu nachhaltigem Wachstum die Fähigkeit, neu & lösungsorientiert zu denken. April `23 hat sie „ZUKUNFTschaffen - mit SDG-Projekten zu mehr Kreativität“ gegründet.

Aus Blau wird Grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Aus Blau wird Grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster

Die Cloud hat bereits heute einen größeren CO2-Fußabdruck als die Luftfahrtindustrie, mit steigender Digitalisierung und Cloudifizierung wird sich dieser Trend fortsetzen, wenn wir nichts dagegen unternehmen. Viele Kubernetes-basierte Installationen sind gemessen am eigentlich benötigten Ressourcen-Bedarf stark überdimensioniert und tragen so unnötig zur globalen Erwärmung bei. Wie sieht die Energiebilanz Ihres Clusters und Workloads aus?

Zielpublikum: Architekt:innen, Platform Engineers, Entwickler:innen, #CloudNativeNerds
Voraussetzungen: Grundlegende Kenntnisse von Public Clouds und Kubernetes
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In diesem Vortrag zeigen wir Ansätze und Technologien, die dabei helfen, K8s-Cluster grün(er) zu machen. Zunächst braucht es Transparenz: Wie sieht die Energiebilanz des Clusters und seiner Workloads aus? Erst danach lassen sich diese gezielt auf ihre Energiesparsamkeit hin optimieren. Und das ist gar nicht so schwer, also packen wir es an!

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Mario_Leander_Reimer

Mario-Leander Reimer ist passionierter Software Entwickler und Architekt, stolzer Vater und #CloudNativeNerd. Er ist Managing Director und CTO bei der QAware GmbH und beschäftigt sich intensiv mit den Innovationen und Technologien rund um den Cloud Native Stack und deren Einsatzmöglichkeiten im Unternehmensumfeld. Außerdem unterrichtet er Software-Qualitätssicherung an der TH Rosenheim.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Mario_Leander_Reimer

Sascha Böhme ist ein erfahrener Software-Engineer und Architekt, und er leitet die Nachhaltigkeits- und Green Software Engineering Gilde in der QAware.

Maren Baermann
Raum 04a
Mario-Leander Reimer, Sascha Böhme
Raum 04a
Maren Baermann
Raum 04a

Vortrag Teilen

Mario-Leander Reimer, Sascha Böhme
Raum 04a

Vortrag Teilen

11:00 - 11:45
Do 1.2
The Bright Side of Software-Architecture Communication – Erfahrungen aus drei Jahrzehnten
The Bright Side of Software-Architecture Communication – Erfahrungen aus drei Jahrzehnten

Projekte unterschätzen des Öfteren die Rolle der Software-Architektur als Kommunikationsmittel zwischen den Beteiligten. Eine Architektur hat allerdings unmittelbar Einfluss auf Usability, Habitability, also sowohl beim Nutzen der Architektur als auch beim Nutzen der Implementierung. Um dem gerecht zu werden, müssen diese Qualitäten schon bei der Architekturerstellung Berücksichtigung finden.
Der Vortrag zeigt auf, wie sich dieses Problem durch einen systematischen Ansatz vermeiden lässt.

Zielpublikum: Software-Architekt:innen
Voraussetzungen: Architekturgrundlagen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Projekte unterschätzen des Öfteren die Rolle der Software-Architektur als Kommunikationsmittel zwischen den Beteiligten. Die Architektur hat allerdings unmittelbar Einfluss auf Usability, Habitability, also sowohl beim Nutzen der Architektur als auch beim Nutzen der Implementierung. Um dem gerecht zu werden, müssen diese Qualitäten schon bei der Architekturerstellung Berücksichtigung finden. Ein weiteres Problem besteht darin, dass sich Architekten zu stark auf aktuelle Technologietrends wie Containerisierung, Microservices, KI/ML oder Cloud-Computing stützen, wo sie eher auf Qualitätsaspekte achten sollten. Das führt zu Systemen, die schwer verständlich, kommunizierbar, wartbar und erweiterbar sind.
Der Vortrag zeigt auf, wie sich dieses Problem durch einen systematischen Ansatz vermeiden lässt, in dem Software-Architektur seine Rolle als Kommunikationsmedium und Fundament für Usability-/Habitability-Aspekte erfüllen kann. Die Sicht der Beteiligten/Betroffenen auf die Architektur spielt dabei eine essenzielle Rolle.
Lernziele:

  1. Die Rolle von Software-Architektur als Kommunikationsmittel und Hilfsmittel für alle Projektbeteiligten und Betroffenen (zum Beispiel Nutzern) verstehen
  2. Einen systematischen Weg der Architekturerstellung kennenlernen, bei dem Usability und Habitability Beachtung finden
  3. Technologien gezielt einsetzen, ohne in die Technologiefalle zu tappen.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/michael.stal

Michael Stal arbeitet bei der Siemens AG unter anderem an Software-Architekturen, verteilten Systemen und KI - sowohl in der Forschung als auch in Projekten. Zudem ist er als Professor an der Universität Groningen und als Chefredakteur von JavaSPEKTRUM tätig. Er verfügt über drei Jahrzehnte Erfahrung im Softwareengineering und hat Spaß daran, Wissen zu vermitteln.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/michael.stal

Michael Stal
Raum 13b
Michael Stal
Raum 13b

Vortrag Teilen

11:00 - 11:45
Do 2.2
Qualityland of Confusion
Qualityland of Confusion

Are you lost when folks talk about "quality" in the context of software? Just when you thought "high quality" means "good" and "QA" means "assure it's good", somebody hits you over the head with ISO 25010, where "quality" is just a neutral property of a software system. It's all a big happy pile of terminology quicksand where you sink faster the more you struggle for unambiguous and clear definitions. But we're here to help you out. We'll be looking at what's relevant about quality from a software architecture perspective.

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

Extended Abstract:
Among the prominent confusions is "quality requirements" vs. "functional requirements" - someone is sure to tell you that the first one is something not entirely unlike “non-functional” requirements. But if that distinction even is a thing, what's that "functional suitability" category of the ISO 25010 quality model? And where exactly do requirements even enter the picture? Once they do, how do we tell whether they are satisfied or not? And if they're not, how does all this terminology help with devising tactics for making things better? We'll separate out the taxonomy from the metrology, the metrology from the requirements, the functional from the non-functional (as far as this makes sense) and everything in between. We'll survey different ways of looking at quality and identify the murky areas where you need to be explicit about what you mean.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/michael.sperber

English below

Dr. Michael Sperber ist Geschäftsführer der Active Group GmbH. Er ist international anerkannter Experte für funktionale Programmierung. Außerdem hat er zahlreiche Fachartikel und Bücher zum Thema verfasst. Michael Sperber ist Mitbegründer des Blogs funktionale-programmierung.de und Mitorganisator der Entwicklerkonferenz BOB. Außerdem ist er einer der primären Autoren des iSAQB-Advanced-Curriculums "Funktionale Software-Architektur".
----------
Dr. Michael Sperber is CEO of Active Group in Tübingen, Germany. Mike specializes in functional architecture, and has been an internationally recognized expert in the field. He has authored many papers on the subject as well as several books. Mike is also an accredited iSAQB trainer, curator of its FUNAR and DSL curricula, and a member of iSAQB's Foundation working group.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/michael.sperber

Alexander Lorz is a member of the iSAQB Foundation Level Working Group, head of the WG Train-the-Trainer, and author of the CPSA-F reference training material for international training providers.

Michael Sperber, Alexander Lorz
Raum 04a
Michael Sperber, Alexander Lorz
Raum 04a

Vortrag Teilen

11:00 - 11:45
Do 7.2
No-code does not mean no-model
No-code does not mean no-model

**TL, DR;** Embrace no-code to explore more models and throw most of those models away. You will quickly discover what works, and what matters, in the business process that you are automating. If it matters enough, you can extract it into a high-fidelity design in code.

Target Audience: Everyone with a stake in the software production process
Prerequisites: None
Level: Basic

Extended Abstract:
Many software projects still consume considerable resources, and take a long time before anything material is put in the hands of the end-user. At a smaller scale this happens with teams that have the ambition to adopt Domain-Driven Design principles but that lack the expertise and experience in how to approach the design process. There is a spectrum of mistakes. On one hand there is the lack of producing a meaningful and shared model that is able to unify the conflicts and handle the complexity that the messy world will serve the system. On the other end of that spectrum there is analysis paralysis: a model that never sees the light of day, because there is always a new case it cannot handle. If the team doesn't produce a meaningful model, or if it fails to put that model in front of experts early on, then the team robs itself of precious feedback. "Judge models by their usefulness" is a mantra that is difficult to live by, if the model isn't being used...
Despite warnings, teams design big architectures early on, to support even bigger ambitions of the organization they work for, but they forget that it's not the architecture that the end-user cares about. With every bit of structure that is added early on, the team reduces the degrees of freedom to evolve the system at a later point in time. In order to support long-lasting design that is attuned to the environment, teams should set architectural principles that allow for a helpful structure to emerge, regardless of the platform.
> **No code** has entered the chat...
For a while now, no-code vendors have been telling organizations that they shouldn't be limited by expensive software engineers to build systems that are useful. No-code aims to commoditize the software production process. Commodification of technology leads to value if it removes a limitation, but successful adoption only works if the rules and policies that initially helped us overcome the limitation are replaced as well. Practices such as DevOps have to be adopted in order to reap the benefits of the commodification of compute and storage in the cloud. In order to benefit from serverless, system components need to be decoupled through message-driven designs. In order to benefit from no-code, people have to organize around the software production process in a different way.
Within software engineering communities no-code has been dismissed as a fad, saying the need for writing code will never go away because the needs of most software systems are too complex to capture in a visual design environment. This viewpoint ignores the argument that software engineers act as a gatekeeper, a limitation for the stakeholder to get what they want. It is reductionist to say that no-code means no-code. No-code is as much about no-code, as wireless is about the absence of wires, or serverless is about the absence of servers. No-code means less boilerplate. And no-code does NOT mean no-model.
The inability to deliver meaningful results in a reasonable amount of time is never out of bad intent, it's the consequence of rigidity in the system of work. If there is no room for experiments, for error, for trying again, then we shouldn't be surprised if people attempt moonshots. But if we can reduce the cost of experiments, then we should be able to iterate more, learn faster, and as a consequence produce more value.
Let's explore how no-code is able to remove the time to market of our ideas to explore new models. Join this session to uncover which rules, policies, and practices around modeling and design need to be replaced in order to reap the benefits that no-code has to offer.

Marijn Huizendveld works as an independent software consultant for (corporate) startups and scale-ups within Europe. He studied business school (boring though useful) and moonlighted as a freelance software engineer (limited impact, lots of fun).
After getting stung by the start-up bug he founded a SaaS business in which he was involved for the next 6 years (lots of impact, limited private life). This experience provided him with a realistic perspective on business and firm roots in software architecture. He was at the frontier of event-sourced domain models in PHP and has been actively involved in the DDD community since its revival around 2012.
These days he helps his customers to apply the lessons he picked up along the way, in order to make software that propels organizations forward. To support his clients he develops tools (such as Chameleon) that augment the software delivery process which makes teams more effective. He also laughs at his own jokes, for reasons unknown cause they typically aren’t funny. Join the workshop to see if you agree.

Marijn Huizendveld
Raum 11
Marijn Huizendveld
Raum 11

Vortrag Teilen

14:30 - 15:30
Do 1.3
Zero Trust – Erfahrungsbericht
Zero Trust – Erfahrungsbericht

Zero Trust ist anfangs ein Schlagwort, das von jedem Unternehmen individuell interpretiert werden muss. Während Slogans wie "Never trust, always verify" allgemeine Zustimmung finden, gibt es schnell kontroverse Diskussionen, wenn man ins Detail geht. Steht das Netzwerk, die Identität, die Daten oder die Geräte im Vordergrund, oder geht es letztendlich um die Systeme?
In diesem Vortrag möchte ich unsere Erfahrungen mit Dir teilen, die wir bei der Implementierung von Zero Trust in der Deutschen Telekom gesammelt haben.

Zielpublikum: Architekt:innen, DevOps, technische Verantwortliche
Voraussetzungen: Basis-Verständnis von IT-Architektur
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Dieser Konferenzvortrag bietet einen Erfahrungsbericht zur Implementierung einer Zero-Trust-Sicherheitsarchitektur im organisatorischen Kontext. Die Teilnehmer erhalten Einblicke in die praktischen Aspekte, Herausforderungen und Vorteile der Übernahme von Zero-Trust-Prinzipien.
Die Sitzung beginnt mit einer Einführung in Zero Trust, wobei die Notwendigkeit eines Paradigmenwechsels in Sicherheitspraktiken betont wird. Der Redner teilt seine Erfahrungen aus der realen Welt und behandelt wichtige Komponenten wie Identität, Netzwerk, Clients, Daten und insbesondere Systeme. Es werden Herausforderungen während der Implementierung angesprochen, einschließlich organisatorischem Widerstand und Ressourcenzuweisung.
Die Teilnehmer gewinnen praktisches Wissen und handlungsorientierte Einblicke aus dieser aus erster Hand stammenden Implementierungserfahrung.
Während das Konzept für Zero Trust je nach Unternehmen stark variieren mag, bleiben doch stets dieselben Fragestellungen bestehen, denen wir begegnen müssen.

Waldemar Schäfer ist als Senior Enterprise Architect bei der Deutschen Telekom tätig und hat seinen aktuellen Schwerpunkt auf dem Thema "Security by Design". In den letzten 15 Jahren lag sein Fokus hauptsächlich auf der Entwicklung skalierbarer Frontend-Architekturen.

Waldemar Schäfer
Raum 13b
Waldemar Schäfer
Raum 13b

Vortrag Teilen

14:30 - 15:30
Do 2.3
Neue Qualitäten braucht das Land
Neue Qualitäten braucht das Land

Heutzutage erfordern Systeme eine hohe Bandbreite an Qualitäten: immer online, schnell, robust, elastisch, skalierbar und sicher, oder was auch immer Ihre Interessenvertreter unter Qualität verstehen.
Ich erkläre, was Software-Entwicklungsprojekte brauchen: spezifische, konkrete und überprüfbare Qualitätsanforderungen, und warum bestehende Normen (wie ISO) in dieser Hinsicht nicht ausreichen.
Abschließend zeige ich einen pragmatischen, leichtgewichtigen (Open-Source-) Ansatz, der zu spezifischen und umsetzbaren Qualitätsanforderungen führt.

Zielpublikum: Entwicklungsteams
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Heutzutage erfordern Systeme eine beeindruckende Bandbreite an Qualitäten: immer online, schnell, robust, elastisch, skalierbar und sicher, oder was auch immer Ihre Interessenvertreter unter Qualität verstehen.
Und genau hier beginnt das Problem: Die Stakeholder wissen oft nicht genau, was ihre Qualitätsanforderungen sind. Und wenn sie es doch wissen, bleiben diese Anforderungen oft implizit.
Ich erkläre, was Software-Entwicklungsprojekte brauchen: spezifische, konkrete und überprüfbare Qualitätsanforderungen, und warum bestehende Normen (wie ISO) in dieser Hinsicht nicht ausreichen.
Abschließend zeige ich einen pragmatischen, leichtgewichtigen Ansatz, der zu spezifischen und umsetzbaren Qualitätsanforderungen führt.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/gernot.starke

Dr. Gernot Starke, INNOQ-Fellow, arbeitet als Coach und Berater für Software-Entwicklung und -Architektur. Er ist Mitbegründer und Betreuer der Open-Source-Projekte arc42 (https://arc42.de) und aim42 (https://aim42.github.io), Buchautor und gelegentlicher Konferenzsprecher.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/gernot.starke

Gernot Starke
Raum 05
14:30 - 15:30
Do 7.3
Misserfolge und Lehren bei der Anwendung von DDD: Beispiele aus der realen Welt
Misserfolge und Lehren bei der Anwendung von DDD: Beispiele aus der realen Welt

DDD ist momentan extrem populär, was zu falschen oder überzogenen Erwartungshaltungen führen kann. Diese werden in meinem Vortrag angesprochen. Ich stelle Ihnen anhand zahlreicher konkreter Beispiele aus der Praxis vor, wie man die meisten Probleme mit DDD vermeiden oder wie man mit DDD erfolgreich arbeiten kann. Dabei werden Facetten aus verschiedensten Blickwinkeln aufgegriffen: Entwicklung, Strategie, Fachmodellierung, Organisation und Agilität.
Der Vortrag soll ein Gespür für den Einsatz von DDD im Kontext Ihrer Organisation vermitteln.

Zielpublikum: Architekt:innen, Entwickler:innen, Manager:innen
Voraussetzungen: Grundverständnis von DDD
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Domain-Driven Design ist kein Patentrezept und löst kein Problem auf magische Weise. Die Herausforderungen und die Komplexität, die wir mit DDD zu bewältigen versuchen, sind schwierig und es gibt keinen einfachen Lösungsansatz. Nichtsdestotrotz gibt es eine wachsende Popularität und Wertschätzung für das Thema auf dem Markt, was zu überhöhten Erwartungen und schließlich zu Enttäuschungen führen kann.
Der Referent dieses Vortrags arbeitet seit 17 Jahren mit Domain-Driven Design an vielen Softwaresystemen und dieser Vortrag handelt von meinen Erfahrungen mit dem Scheitern. Glauben Sie mir: Ich bin oft gescheitert, aber es gibt immer eine Gelegenheit, etwas daraus zu lernen. Der Vortrag zielt darauf ab, Ihnen die Möglichkeit zu geben, aus den Fehlern von mir als Berater und den Teams/Organisationen, mit denen ich gearbeitet habe, zu lernen.
Der Vortrag behandelt Themen wie:

  1. Domain-Driven Design im Wasserfall
  2. Ignoranz für Code (aka nur Fokus auf strategisches Design)
  3. Übermäßiger Gebrauch von Mustern um ihrer selbst willen
  4. Kulturelle Implikationen
  5. Cargo-Kult
  6. Developer Experience
  7. Eingeschränkte Verfügbarkeit von Fachexperten
  8. Umgang mit etablierten Modellierungstechniken/Methoden
  9. Unkenntnis über die Definitionen/Bedeutung von Heuristiken und Mustern

Dieser Vortrag zielt darauf ab, Ihnen eine Sensibilität für potenzielle Gefahren zu vermitteln, wenn Sie versuchen, DDD für Ihr Team und Ihre Organisation einzuführen, und wird nur reale Situationen beschreiben, die tatsächlich passiert sind. Jeder beschriebene Misserfolg wird mit einer Erkenntnis darüber einhergehen, wie man es besser machen kann.
Es handelt sich um einen interaktiven Vortrag, bei dem Ihnen, dem Publikum, Fragen und Umfragen (über ein Online-Tool) gestellt werden. Sie werden sich beteiligen können.

Michael Plöd ist Fellow bei INNOQ. Seine aktuellen Beratungsschwerpunkte sind Domain-driven Design, Team Topologies, soziotechnische Architekturen und die Transformation von IT-Delivery-Organisationen in Richtung Kollaboration und lose gekoppelter Teams. Michael ist zudem Autor des Buchs „Hands-on Domain-driven Design - by example“ auf Leanpub sowie regelmäßiger Referent auf nationalen und internationalen Konferenzen.

Michael Plöd
Raum 11
Michael Plöd
Raum 11

Vortrag Teilen

17:00 - 18:00
Do 1.4
Wie fit ist deine Architektur? Automatisierte Architekturtests & statische Codeanalyse mit ArchUnit
Wie fit ist deine Architektur? Automatisierte Architekturtests & statische Codeanalyse mit ArchUnit

Im Architektur-Entwurf treffen wir ständig Architekturentscheidungen, die im besten Fall explizit, dokumentiert und verstanden sind. Aber wie praktisch wäre es, wenn man kontinuierlich prüfen könnte, ob diese Richtlinien auch eingehalten werden? Hier helfen Architecture Fitness Functions. Wir zeigen, wie man mit ArchUnit solche Fitness Functions schreibt, die die Struktur unseres Codes überprüfen, und wie man diese in den Entwicklungsprozess integriert. Außerdem zeigen wir, wie man mit der API von ArchUnit statische Codeanalysen durchführt.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Basis-Kenntnisse Java
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Architekturentscheidungen zu treffen und zu dokumentieren, ist aufwändig und mühsam, mit der Folge, dass Entscheidungen oft nur implizit getroffen werden und dann in Vergessenheit geraten, geschweige denn im Lauf der ständigen Weiterentwicklung eingehalten werden.
Architecture Fitness Functions dienen dazu, Architekturentscheidungen im besten Fall automatisiert zu überprüfen. So bekommt das Entwicklungsteam jederzeit Feedback, ob die Architektur noch den festgelegten Regeln entspricht.
Manche Entscheidungen wie Namenskonventionen lassen sich schon lange über altbekannte Tools wie Checkstyle abtesten. Komplexere Entscheidungen aber lassen sich nicht immer einfach prüfen – oder sie erfordern ein komplexes Metamodell, das aufwändig zu erstellen und zu pflegen ist. Hier kommt ArchUnit ins Spiel.
In unserem Talk stellen wir anhand konkreter Fragestellungen vor, wie man mit ArchUnit automatisiert Architekturentscheidungen überprüft und in einen Standard-Testzyklus einbindet. Dazu bringt ArchUnit von Haus aus eine ganze Reihe von Standard-Hilfsmitteln mit. Besser noch: Eigene Architekturregeln lassen sich leicht in Form von Tests definieren und so im automatisierten Build überprüfen. Zugleich sind die Architekturregeln über die Tests dokumentiert.
Beispiele: Sind Abhängigkeiten zwischen Komponenten richtig definiert? Sind Strukturen innerhalb einer Komponente richtig modelliert, z.B. als Onion-Architektur?
Dieselbe API von ArchUnit kann man aber auch für statische Codeanalyse einsetzen, deren Output nicht in einem Test, sondern als Input in weitere Tools eingeht. Damit lassen sich einfach kleine Helferlein schreiben, um gezielt über statische Code-Analyse Handlungsbedarf identifizieren und analysieren zu können.
ArchUnit lässt sich demnach für kleine, mittlere und komplexe Fragestellungen einsetzen. Das skaliert gut und ermöglicht eine leichtgewichtige und automatisierte Absicherung von Architekturentscheidungen.
Wir zeigen zahlreiche Beispiele direkt im Code und geben damit einen ausführlichen Überblick über die Benutzung der ArchUnit-API.

Dr. Kristine Schaal ist als Software-Architektin seit fast 25 Jahren in der Software-Entwicklung tätig. In der Individualentwicklung arbeitet sie für Kunden verschiedener Branchen, überwiegend im Java-Umfeld.

Kristine Schaal
Raum 13b
Kristine Schaal
Raum 13b

Vortrag Teilen

17:00 - 18:00
Do 2.4
Enterprise Serverless Monoliths – Or Stay On-Premise
Enterprise Serverless Monoliths – Or Stay On-Premise

High traffic during business hours, no traffic at night, weekends and vacations, multiple teams, and several staging environments - these characteristics of a typical enterprise application. Pay-as-you-go, "scale-to-zero" and managed services make serverless architectures appealing for enterprise applications.
On-premise, on the other hand, you get the maximum flexibility and full access to machines with less automation and so more plumbing.
I will compare both approaches with focus on architecture and answer your questions in real time.

Target Audience: Developers, Architects
Prerequisites: Basic Cloud and Java Knowledge
Level: Advanced

Adam Bien is Developer (Architect), Consultant, Trainer (https://airhacks.io), AWS Hero, podcaster (https://airhacks.fm), Java enthusiast (and Java Champion). Adam (https://adambien.blog) uses Java since JDK 1.0 and JavaScript since LiveScript and still enjoys writing code.
Adam regularly organizes Java / Web / Cloud / Architectures online live workshops https://airhacks.live and monthly Q&A live streaming show: https://airhacks.tv.

17:00 - 18:00
Do 6.4
ENTFÄLLT: Architecting MLOps: The Journey from Identifying ML Use Cases to the ML Platform Architecture
ENTFÄLLT: Architecting MLOps: The Journey from Identifying ML Use Cases to the ML Platform Architecture

Great engineers often use back-of-the-envelope calculations to estimate resources and costs. This practice is equally beneficial in Machine Learning Engineering, aiding in confirming the feasibility and value of an ML project. In my talk, I'll introduce a collaborative design toolkit for ML projects. It includes Machine Learning Canvas and MLOps Stack Canvas to identify ML use cases and perform initial prototyping, thus ensuring a business problem can be effectively solved within reasonable cost and resource parameters.

Target Audience: Architects, Developers, Project Leader, Data Scientist
Prerequisites: Basic knowledge in machine learning
Level: Advanced

Dr. Larysa Visengeriyeva received her Augmented Data Quality Management doctorate at TU Berlin. She is the Head of Data and AI at INNOQ. She focuses on Machine Learning Operations (MLOps), Data Architectures like Data Mesh, and Domain-Driven Design. Larysa initiated the Women+ in Data and AI Summer Festival.

Larysa Visengeriyeva
Raum 02
17:00 - 18:00
Do 7.4
Wie man so ziemlich alles versteht – Domänenanalyse für Praktiker
Wie man so ziemlich alles versteht – Domänenanalyse für Praktiker

Bei Software steht oft komplexe Fachlichkeit im Mittelpunkt: Medikamentenstudien, Steuerberechnung, Teleskopsteuerung. Idealerweise wollen wir Softwerker ein Tool entwickeln, mit dem Fachexperten selbstständig Studien, Steuerberechnungen oder astronomische Beobachtungen beschreiben können, sodass sie direkt von Software ausführbar sind. Herauszufinden, wie man die Domäne vollständig und präzise beschreibt, ist dabei extrem wichtig. Der Vortrag liefert dafür konkrete Practices, die sich über Jahre bewährt haben, plus Anekdoten aus dem Projektalltag.

Zielpublikum: Product Owner:innen, Requirements Engineers, Architekt:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Ich beginne, indem ich nochmal 5 Minuten motiviere, warum man Tools bauen möchte, mit denen Fachler direkt programmieren/spezifizieren/modellieren wollen. Dann beschreibe ich kurz die drei Aspekte der Domänenanalyse: Sammeln, Denken und Validieren. Klingt trivial, ist es irgendwie auch, aber viele der konkreten Practices sind es nicht. Hier sind einige Stichworte, die ich betrachten werde:
Sammeln: Die (Nicht-)Rolle von schriftlichem Material, verborgene Sprachen finden, mit den richtigen Leuten reden, konsistente Terminologie, Workshops richtig durchführen, aktives Zuhören, Umgang mit Ungewissheit, Ergebnisse festhalten.
Denken: Abgrenzung und Tiefe der Domäne, Beseitigung von "historischem Müll", Test-Unterstützung, Plattformen, Hochs und Tiefs, das Wissen verbreiten
Validieren: Spiel-Implementierung der Domäne, Benutzer experimentieren lassen, Konzeptuelle Überprüfung, Umgang mit Feedback, Tolle Demos
Der Vortrag basiert auf dem Buch "How to Understand Almost Anything", das ich im letzten Jahr geschrieben habe.

Markus Völter arbeitet als freiberuflicher Berater für Software-Architektur, domänenspezifische Sprachen und Modellierungswerkzeuge. Die letzten 15 Jahre hat er damit verbracht, die verschiedensten Domänen zu verstehen und deren Fachlichkeit in endbenutzerfreundliche Werkzeuge zu gießen, darunter Medizin, Finanzen und Maschinenbau. Neben der Projektarbeit schreibt Markus über seine Themen in Papers und in Büchern. Er hat Physikalische Technik studiert und hat ein PhD in Informatik.

Markus Völter
Raum 13a
Markus Völter
Raum 13a

Vortrag Teilen

, (Freitag, 02.Februar 2024)
09:00 - 16:00
Fr 2
Ausgebucht DDD infused Wardley Mapping
DDD infused Wardley Mapping

**TL,DR**; In this course you will learn to map your business and technological landscape in such a way that a common language emerges to discuss strategic thinking and decision-making.
Max. number of participants: 13

Target Audience: Architects, Developers, Project Leaders, Decision Makers
Prerequisites: Basic theoretical knowledge of DDD
Level: Advanced

Extended Abstract:
Organizations face more and more complexity these days as a result of a mesh of products, services, technology and the people that work to build, operate and maintain them.
Domain-Driven Design helps us with solving problems the right way. But what helps us solve the right problem? How can we continuously validate our progress with people in "non-tech" roles? And what should we do when the world around us changes, which it always ends up doing? Is the plan we had still valid?

Imagine...
- Imagine having a map that helps you understand the ecosystem your organization is embedded in. A map that makes sense from both a technical and business perspective. With patterns that provide guidance about effective actions regardless of the specific domain you are working in. Wardley Mapping is that: it is a ubiquitous language around strategy and execution that helps you solve the right problem.

The course
- In this course you will learn to map your business and technological landscape in such a way that a common language emerges to discuss strategic thinking and decision making. It allows for scenario building, it teaches about bias and assumptions, and it comes packaged with a long list of ideas that may help in your situation.
The map can hint us what practices from DDD are beneficial in our situation. And it can serve as a context map too, except this one has meaning to businesspeople as well.
Using visualizations, strategies can be challenged and implementation options debated and weighed. As such, mapping is about the act and not merely the artifact. That is why this training is hands-on from the very start.

What to expect
- This class will emphasize practice over theory. Mapping with imperfect knowledge today is better than mapping with perfect knowledge next year. The course will teach you the basics and provides hooks into the theoretical aspects behind exercises.

Who should attend
- Anyone that wants to challenge the status quo of decision making under uncertainty in technology and business. No prior knowledge is required and your open attitude to learn new things will be an asset during the workshop.

Marijn Huizendveld works as an independent software consultant for (corporate) startups and scale-ups within Europe. He studied business school (boring though useful) and moonlighted as a freelance software engineer (limited impact, lots of fun).
After getting stung by the start-up bug he founded a SaaS business in which he was involved for the next 6 years (lots of impact, limited private life). This experience provided him with a realistic perspective on business and firm roots in software architecture. He was at the frontier of event-sourced domain models in PHP and has been actively involved in the DDD community since its revival around 2012.
These days he helps his customers to apply the lessons he picked up along the way, in order to make software that propels organizations forward. To support his clients he develops tools (such as Chameleon) that augment the software delivery process which makes teams more effective. He also laughs at his own jokes, for reasons unknown cause they typically aren’t funny. Join the workshop to see if you agree.

Marijn Huizendveld
Raum: Xaver
Marijn Huizendveld
Raum: Xaver

Vortrag Teilen

09:00 - 16:00
Fr 5
Limitiert Fachliche Komponenten in Java Applikationen mit Spring Modulith
Fachliche Komponenten in Java Applikationen mit Spring Modulith

Fachliche Komponenten in Code auszudrücken ist und bleibt eine fundamentale Herausforderung in Softwareprojekten. Der Workshop zeigt, wie mithilfe von Spring Modulith Java-Applikationen strukturiert werden können und diese Struktur kontinuierlich validiert werden kann. Des Weiteren werden verschiedene Formen der Interaktion zwischen Anwendungsmodulen diskutiert, insbesondere die Kompromisse einzelner Varianten, und wie Module isoliert und in Zusammenarbeit getestet werden können.

Max. Teilnehmendenzahl: 30

Zielpublikum: Architekt:innen
Voraussetzungen: Java, Spring (Boot)
Schwierigkeitsgrad: Experte

Extended Abstract:
1 – Grundlagen

  • Applikationsmodule und deren Design
  • Architekturevidenter Code
  • Module und Hexagonale-, Onion und Clean Architecture
  • Modulstrukturverifikation
  • Modulares Design

2 – Modulinteraktion

  • Interaktionsvarianten und -muster
  • Konsistenz
  • Synchrone und asynchrone Interaktion
  • Eventbasierte Interaktion
  • Die Event Publication Registry

3 – Testen

  • Grundlagen des modularen Integrationstestens
  • Das PublishedEvents API
  • Das Scenario API

4 – Observability & Dokumentation

  • Entwicklerdokumentation aus Code extrahieren
  • Dokumentation anpassen
  • Observability von Applikationsmodulen
  • IDE- und Deploymentplattformintegration

Oliver Drotbohm ist Teil des Spring Engineering Teams bei VMware. Seine Arbeitsschwerpunkte liegen im Bereich Software-Architektur, Domain-Driven Design, REST, Spring und Persistenztechnologien. Sein neues Buch "Modulithic Applications with Spring" erscheint 2023.

Oliver Drotbohm
Raum: Leopold
Oliver Drotbohm
Raum: Leopold

Vortrag Teilen

Zurück