Haben Sie schon einmal gesagt bekommen: Arbeite Dich mal in dieses Projekt ein - wir sollen es übernehmen?

Haben Sie dann Unmengen von Doku bekommen (aber nicht Unmengen von Zeit), um in ein paar Tagen ein Statement dazu abzugeben?

Die ganze Informatik-Ausbildung ist darauf ausgerichtet, Software zu schreiben.

In der Praxis angelangt, stellt man aber schnell fest, dass dies weniger als "die halbe Miete" ist.

Warum? Weil Entwickler:innen viel mehr Zeit damit verbringen, Software bzw. deren Dokumentation zu lesen, als neue zu schreiben.

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

Extended Abstract:
Haben Sie schon einmal gesagt bekommen: Arbeite Dich mal in dieses Projekt ein - wir sollen es übernehmen?

Haben Sie dann Unmengen von Doku bekommen (aber nicht Unmengen von Zeit), um in ein paar Tagen ein Statement dazu abzugeben?

Die ganze Informatik-Ausbildung ist darauf ausgerichtet, Software zu schreiben.

In der Praxis angelangt, stellt man aber schnell fest, dass dies weniger als "die halbe Miete" ist.

Warum? Weil Entwickler:innen viel mehr Zeit damit verbringen, Software bzw. deren Dokumentation zu lesen, als neue zu schreiben.

Dieser Talk zeigt Tipps und Best Practices, wie man effizient Dokumentation und Code lesen und erfassen kann.

Dabei liefert er auch einen Einblick in das, was dort nicht steht, bzw. Tipps, wie man genau diese Lücken füllen kann.

Er gibt Tipps zum schnellen Erfassen des Inhaltes bzw. zur zielgerichteten Analyse. Aus der Praxis - für die Praxis!

Lernen Sie die "Kunst des Unperfekten" kennen!

Die aktuellen "Best Practices" in der Software-Entwicklung, von TDD, Domain-Driven Design, Continous-Delivery, agiles Vorgehen usw., haben eine Gemeinsamkeit: Ihre Erfolgsversprechen basieren vor allem auf Anekdoten in Blogposts, Konferenzvorträgen und anderen Veröffentlichung von den Digitalchampions Google, Amazon, Facebook und anderen "Koryphäen". Warum ist das eigentlich so? Kann es auch anders sein? Diese und viele andere Fragen werden in diesem Vortrag diskutiert.

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

Extended Abstract:
Die aktuellen "Best Practices" in der Software-Entwicklung, von TDD, Domain-Driven Design, Continous-Delivery, agiles Vorgehen usw., haben eine Gemeinsamkeit: Ihre Erfolgsversprechen basieren vor allem auf Anekdoten: Blogposts, Konferenzvorträgen und andere Veröffentlichung von den Digitalchampions Google, Amazon, Facebook sowie den "Koryphäen" unseres Faches erzählen davon, wie sie verschiedene Probleme bei der Software-Entwicklung gelöst haben. Jedoch handelt es sich meistens um Einzelfälle in ganz spezifischen Kontexten. Und die Problemlösungen ändern sich rasend schnell. Systematische Untersuchungen, welches Vorgehen bei welchem Problem das richtige ist, haben dagegen Seltenheitswert. Arbeiten aus der akademischen Welt sind oft praxisfern. Bestenfalls münden sie in exotischen Programmiersprachen, deren Ideen vielleicht irgendwann mal in der Praxis landen. Warum ist das eigentlich so? Kann es auch anders sein? Diese und viele andere Fragen werden in diesem Vortrag diskutiert.

This talk will examine principles that assist with successfully evolving from a monolith to Microservices. Deciding what to decouple along with when and how to incrementally evolve a system are the main architectural challenges in this process. It is important to commit to "stop adding to the monolith" - all new code is added as microservices; the "Strangler Pattern". The new features are microservices, occasionally replacing part of the monolith. Also, when writing new microservices code, it is important to avoid dependencies to the monolith.

Target Audience: English, Developers, Architects, QAs, Testers
Prerequisites: Basic Understanding of architecture and microservices and familiarity with domain modeling
Level: Advanced

Extended Abstract:
Being Agile, with its attention to extensive testing, frequent integration, and focusing on important product features, has proven invaluable to many software teams. When building complex systems, focus on features provides a lot of value and starting with a monolith architecture can be advantageous. However, over time, although you might be committed to keeping the code clean, and having lots of tests — the architecture can become harder to evolve. Ultimately technical debt and design problems will creep in until it becomes muddy, making it hard to deliver new features quickly and reliably. Also, evolving the system quickly can become harder. If things are changing quickly with lots of teams, evolving using the microservices architectural style can have many possible benefits.

Many Microservices architectures start from the evolution of a Monolith system by gradually applying the microservices architectural style. There are considerations and principles that assist with successfully evolving from a monolith to Microservices. Deciding what to decouple along with when and how to incrementally evolve a system are the main architectural challenges in this process. There are good principles that help with this evolutionary process. For example, it is important to commit to "stop adding to the monolith" - all new code is added as microservices. This is the core of the "Strangler Pattern". The new features are microservices, occasionally replacing part of the monolith. Also, there might be important pieces of the monolith that are getting hard to maintain and you want to pull these out. When this happens, you find design seams within the monolith, refactoring these out to components, that can ultimately be replaced with microservices. Early on, it is ok to create macro services first and then evolve (refactor) them to microservices. Also, when writing new microservices code, it is important to avoid dependencies to the monolith. Finally, you can use DDD modeling to identify aggregates and bounded contexts to pull them out from the monolith. This talk will examine various patterns when evolving from the monolith to microservices specifically with variations of the Strangler Pattern.

Wenn ein Softwaresystem modernisiert werden soll, kommt oft reflexartig die Anforderung „Das neue System muss aber das Gleiche können wie das alte!” Was sich auf den ersten Blick sinnvoll anhören mag, ist es keineswegs. Warum das so ist, erklären wir vor dem Hintergrund häufiger Modernisierungsziele und typischer Systemhistorien. Damit sollten alle Zuhörenden in Zukunft argumentativ gerüstet sein, diesen Fehler nicht mehr zu begehen. Darüber hinaus zeigen wir Stolperfallen und Best Practices für die Planung einer erfolgreichen Modernisierung.

Zielpublikum: Architekt:innen, Projektleiter:innen; Management
Voraussetzungen: Erfahrung in Software-Projekten
Schwierigkeitsgrad: Anfänger

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

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

Über die Jahre entstehen bei zu modernisierenden Systemen fast immer Kompromisslösungen, nachträgliche Ergänzungen und technische Schulden. Diese wollen wir gerade nicht mit ins neue System nehmen, sondern die Chance der Modernisierung nutzen. Das Gleiche gilt für die Sicht der User Experience. Wenn man das System schon umbaut, bietet es sich an, das User Interface grundlegend zu überdenken. Außerdem zeigen viele Untersuchungen, dass ein Großteil der Features einer Software so gut wie nie verwendet wird und der Wert eigentlich nur durch einige wenige Funktionalitäten generiert wird. Bei einer Modernisierung haben wir also die Möglichkeit zu konsolidieren, unnötigen Ballast abzuwerfen und mit leichterem Gepäck in die Zukunft zu gehen.

In diesem Vortrag erklären wir im Detail, warum die einfachste Anforderung der Welt Unsinn ist, und geben Erfahrungen, Hinweise und Best Practices für die frühen Phasen eines Modernisierungsvorhabens, in denen es darum geht, den Zielzustand zu gestalten und den Weg der Modernisierung zu planen. Wir sprechen darüber, wie man entscheidet, welche Features tatsächlich übernommen werden sollten, wie man das Modernisierungsvorhaben im Unternehmen und in den Teams verankert und wie man die Tiefe und Umfang der Modernisierung plant. Unsere Erfahrung und Hinweise illustrieren wir anhand von konkreten Beispielen und Erfahrungen aus Projekten.

Automatisiertes Testen von Funktionalität ist heutzutage Standard und ermöglicht kurze Releasezyklen. Für die Software-Architektur ist die resultierende hohe Änderungshäufigkeit eine Herausforderung und führt in vielen Projekten zu Architektur Drift und Erosion.

In der Session behandeln wir das systematische Testen von Software-Architektur. Sie bekommen einen Überblick über gängige Methodik und Lösungen anhand von Beispielen aus realen Projekten. Im Praxisteil lernen Sie, wie Architektur einfach automatisiert getestet werden kann.

Zielpublikum: Software-Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Grundkenntnisse Software-Architektur und Testautomatisierung
Schwierigkeitsgrad: Fortgeschritten