PROGRAMM

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

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

Track: Design Erosion & Learning from Failure

Nach Tracks filtern
Alle ausklappen
  • Mittwoch
    10.02.
  • Donnerstag
    11.02.
09:00 - 10:45
Mi 7.1
If you can read my mind - Dokumentation und Code lesen und verstehen
If you can read my mind - Dokumentation und Code lesen und verstehen

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!

Thomas Ronzon arbeitet seit 2000 als Projektleiter und Senior Software-Entwickler bei der w3logistics AG in Dortmund. Dabei beschäftigt er sich vor allem mit der Modernisierung von unternehmenskritischen Logistikanwendungen.

In der Zeitschrift JavaSPEKTRUM berichtet er regelmäßig über neue 'Tools' für Architekten ('The Tool Talk'). Darüber hinaus veröffentlicht er regelmäßig Fachartikel und spricht auf Konferenzen. Thomas taucht leidenschaftlich gerne und tief in technische Aspekte ein, verliert dabei jedoch nie den Bezug für die Fachlichkeit. Mit viel Empathie, Erfahrung und konkreten Lösungsvorschlägen schlägt er damit immer wieder die Brücke zwischen Business und IT.

Evidenz ist nicht die Mehrzahl von Anekdote
Evidenz ist nicht die Mehrzahl von Anekdote

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.

Christoph Iserlohn ist Senior Consultant bei INNOQ. Er hat langjährige Erfahrung mit der Entwicklung und Architektur von verteilten Systemen. Sein Hauptaugenmerk liegt dabei auf den Themen Skalierbarkeit, Verfügbarkeit und Sicherheit.
Thomas Ronzon
Christoph Iserlohn
Thomas Ronzon
Vortrag: Mi 7.1-1
Christoph Iserlohn
Vortrag: Mi 7.1-2
flag VORTRAG MERKEN
11:00 - 11:45
Mi 7.2
Evolving Monoliths to Microservices
Evolving Monoliths to Microservices

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.

Joseph (Joe) Yoder is president of the Hillside Group and principle of The Refactory. He is best known as an author of the Big Ball of Mud pattern, illuminating fallacies in software architecture. Joe teaches and mentors developers on agile and lean practices, architecture, flexible systems, clean design, patterns, refactoring, and testing. Joe has presented many tutorials and talks, arranged workshops, given keynotes, and help organized leading international agile and technical conferences.
Joe Yoder
Joe Yoder
flag VORTRAG MERKEN
14:30 - 15:30
Mi 7.3
“Das neue System muss aber das Gleiche können wie das alte!” “NEIN!” - Systeme richtig modernisieren
“Das neue System muss aber das Gleiche können wie das alte!” “NEIN!” - Systeme richtig modernisieren

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.

Matthias Naab und Dominik Rost sind Software-Architekten in leitender Rolle am Fraunhofer IESE. Sie unterstützen Kunden verschiedener Branchen bei Design, Bewertung und Modernisierung ihrer Systeme.
Marcus Trapp leitet die Abteilung "UX & RE " am Fraunhofer IESE. Er unterstützt Unternehmen bei der kreativen Ideenfindung zum Aufbau oder der Modernisierung von Software-intensiven Systemen.
Matthias Naab, Marcus Trapp
Matthias Naab, Marcus Trapp
flag VORTRAG MERKEN
17:00 - 18:00
Mi 7.4
Testen Sie Ihre Software-Architektur – Lebe lang und sei erfolgreich!
Testen Sie Ihre Software-Architektur – Lebe lang und sei erfolgreich!

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

Matthias Herbort arbeitet als Principal Key Expert für Software-Architektur bei der Siemens AG. Er hat mehr als 15 Jahre Erfahrung in der Modernisierung und Sanierung von mittleren und großen unternehmenskritischen Software-Systemen. Dabei arbeitet er oft an der Schnittstelle zwischen Architektur und Business.
Matthias Herbort
Matthias Herbort
flag VORTRAG MERKEN
09:00 - 10:30
Do 7.1
7-mal daneben: Warum Continuous Delivery manchmal scheitert
7-mal daneben: Warum Continuous Delivery manchmal scheitert

Kontinuierliches Liefern (Continuous Delivery) und Infrastructure as Code sind Mainstream, oder? Zumindest behaupten viele, es zu tun. Wer es nicht macht, ist draußen (neudeutsch „out“) - oder zumindest ganz weit drin im Zimmer. Konsequent zu Ende betrachtet, müssten wir also eine enorme Verbesserung der Liefergeschwindigkeit in unserer IT-Welt sehen – und zwar nicht nur bei kleinen Unternehmen und Projekten. In dieser Session werfen wir einen Blick auf Kontinuierliche Lieferpipelines und zeigen 7 Dinge, über die jemand schon mal gestolpert ist.

Zielpublikum:
Architekt:innen, Entwickler:innen, Automatisierer und DevOps-Interessierte
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Bernd Rederlechner arbeitet als T-Systems Lead Architekt mit den Schwerpunkten DevOps und Cloud. Vom kleinen Innovationsprojekt bis zum strategischen Großprojekt hat er die Architektur vieler Kundenvorhaben bis zum produktiven Einsatz verantwortet. Diese Erfahrung gepaart mit modernen Ideen zur Agilisierung von Organisationen nutzt er jetzt, um Kunden Wege zur effizienten Umsetzung ihrer digitalen Geschäftsideen mit cross-funktionalen Teams in schnellen Lieferzyklen zu zeigen.
Bernd Rederlechner
Bernd Rederlechner
flag VORTRAG MERKEN
11:00 - 11:45
Do 7.2
Komplexität, Design-Erosion, Entscheidungen - wie bringt man Licht ins Chaos, wenn etwas schiefgeht?
Komplexität, Design-Erosion, Entscheidungen - wie bringt man Licht ins Chaos, wenn etwas schiefgeht?

Ist es die Komplexität der Aufgabe, die sich ergebende Design-Erosion oder sind es falsche Entscheidungen, die zu Problemen führen? Der Vortrag zeigt auf, wie man von üblichen Failures/Symptomen zu möglichen Faults/Ursachen und Gegenmaßnahmen kommt. Dabei kann man Failures messen, mögliche Faults bestimmen und Maßnahmen überprüfen, sodass ein Lernprozess etabliert wird. Zum Beispiel kann eine hohe Fehlerdichte auf schlechte Code-Dokumentation, diffuse Verantwortlichkeit oder hohe Featurekopplung gewisser Codemodule zurückgeführt werden.

Zielpublikum:
Architekt:innen, Projektleiter:innen, Key Developer, Management, Entscheidungsträger
Voraussetzungen: Architekt:innen, Projektleiter:innen, Key Developer, Management, Entscheidungsträger
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Ist es die Komplexität der Aufgabe, die sich ergebende Design-Erosion oder sind es falsche Entscheidungen, die zu Problemen führen? Führt die Komplexität zu früher Design-Erosion? Oder war die Diagnose falsch, die dazu geführt hat, dass trotz Gegenmaßnahmen zur Design-Verbesserung die Implementierung neuer Features sich weiterhin schwierig gestaltet? Der Vortrag zeigt auf, dass es zu üblichen Failures (als Symptome) mehrere mögliche Faults (d.h. Ursachen) geben kann. Failures und mögliche Faults müssen als Metriken gemessen werden, um daraus auf eine gute Diagnose und die richtigen Gegenmaßnahmen zu schließen.

Wir gehen im Vortrag auf einige Failure/Faults/Maßnahmen-Ketten ein und zeigen für Manager:innen und Entwickler:innen ein Vorgehen auf, was und wie zu messen wäre, um einen Lernprozess zu etablieren. Statt Vollständigkeit wollen wir Beispiele (anhand konkreter Projekte) liefern:

- wie z.B. für eine hohe Fehlerdichte mit vielen follow-up Bugs (Failure) mehrere potenzielle Ursachen (Faults) infrage kommen können: schlechte Code-Dokumentation, diffuse Verantwortlichkeit der Entwickler oder hohe Featurekopplung der entsprechenden Code-Module. Und wie man anhand von Messungen zu einer Diagnose und möglichen Gegenmaßnahmen kommt, deren Effekt auf Faults und Fehlerdichte wiederum gemessen werden kann.

- wie man die Schwierigkeit messen kann, neue Features hinzufügen (Failure) und trotz gelegentlichem Refactoring den mangelnden Effekt auf noch nicht ausreichendes oder Refactoring der falschen Codestellen (Faults) zurückführen kann. Und wie man Aufwände und die Effektivität von Verbesserungsmaßnahmen verfolgen kann.

- oder wenn man angesichts eines aufwendigen Releases mit vielen neuen Features, aber unzufriedenen Kunden wohl trotz agiler Entwicklung am Bedarf vorbei entwickelt hat. Und welche möglichen Ursachen infrage kommen und daraus Empfehlungen ableiten kann, sei es konzeptioneller Art zur besseren Erfassung des Benefits eines Features bis zu technischen Mitteln zur Messung der Nutzung der Features.

Egon Wuchner hat mehr als 18 Jahre bei der Siemens Corporate Technology als Software-Engineer, Architekt und Projektleiter zu Software-Architektur-Themen wie Qualitätsattribute und Software-Wartbarkeit gearbeitet.
Konstantin Sokolov hat teilweise für Siemens als Freelancer an den Themen mit Egon zusammengearbeitet. Zusammen haben sie Cape of Good Code gegründet mit dem Ziel, Software-Analysen anzubieten, auf die es ankommt.
Egon Wuchner, Konstantin Sokolov
Egon Wuchner, Konstantin Sokolov
flag VORTRAG MERKEN
14:30 - 15:30
Do 7.3
Design-Erosion - Hege und Pflege von Software-Architekturen
Design-Erosion - Hege und Pflege von Software-Architekturen

Software-Architekturen sind lebendige Organismen, die einer gründlichen Pflege bedürfen. Vernachlässigt man sie, so führt dies zu Verwachsungen, Wucherungen und weiteren Schäden. Der Vortrag adressiert zum einen, wie sich eine Pflege von Software-Architekturen durchführen lässt. Und zum anderen stellt er vor, wie Architekt:innen Probleme in den Griff bekommen können. Anhand von Beispielen erkennen Teilnehmende, warum dabei Lernen aus Fehlern ein wichtiges Werkzeug darstellt.

Zielpublikum:
Architekt:innen, Entwickler:innen
Voraussetzungen: Praxiskenntnisse Software-Architekturen
Schwierigkeitsgrad: Fortgeschritten

Michael Stal beschäftigt sich bei der Siemens AG mit Software-Architekturen, verteilten Systemen und KI. Er ist Professor für Software-Engineering und Chefredakteur von JavaSPEKTRUM.
Michael Stal
Michael Stal
flag VORTRAG MERKEN
17:00 - 18:00
Do 7.4
Gute Legacy? Schlechte Legacy?
Gute Legacy? Schlechte Legacy?

Seit über sechzig Jahren bauen wir Software, die immer größer und komplexer wird. Inzwischen haben wir nicht nur Mainframe-Altsysteme, sondern auch die Systeme in objektorientierten Programmiersprachen sind in den letzten zwanzig Jahren so schnell und immer wieder unkontrolliert gewachsen, dass sie zu einem großen Knäul geworden sind. All dieser Legacy-Code treibt die Entwicklungskosten in die Höhe und führt dazu, dass wir diese alten Softwaresysteme nicht mehr gerne anfassen. Ist das unvermeidbar? Oder gibt es auch gute Legacy?

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

Dr. Carola Lilienthal ist Geschäftsführerin bei der WPS Workplace Solutions GmbH. Sie hat an der Universität Hamburg studiert und dort zum Thema "Komplexität von Software-Architekturen" promoviert. Seit 2003 analysiert sie im Auftrag ihrer Kunden in ganz Deutschland regelmäßig die Zukunftsfähigkeit von Software-Architekturen und spricht auf Konferenzen über dieses Thema.
Carola Lilienthal
Carola Lilienthal
flag VORTRAG MERKEN

Zurück