OOP 2022 - Recap

Vergangene Woche war ich zum ersten Mal auf der OOP Digital 2022. Die Konferenz mit dem Titel "Software meets Business: Konferenz für Software-Architektur" fand dieses Jahr erneut online statt. Ein umfangreiches und spannendes 5-tägiges Programm hat mich schließlich zur Anmeldung gebracht. Bereits bei der Anmeldung mussten einige Vorträge/Workshops gebucht werden, da diese teilweise Teilnehmer*innen-Limitierungen hatten und die mehr als 1.300 Teilnehmer*innen irgendwie untergebracht werden mussten.

Nach der Anmeldung konnte ich zudem ein Profil ausfüllen und über den "Teilnehmer Match" Personen finden, welche das suchen, was ich anbiete oder das anbieten, was ich suche. Sehr praktisch. Zudem konnte man die ein oder andere Pause mit der kostenlosen Ausgabe von ITSpektrum füllen. Und dies waren einige der Talks/Workshops, die ich besucht habe...

Architektur effizient dokumentieren und kommunizieren mit Architecture Decision Records

Der Ganztags-Vortrag von Stephan war zweigeteilt und bestand aus einem Theorie- und einem Praxis-Block. Nach einem kurzen "aktuellen Stand" der Teilnehmer*innen wurde in die Theorie eingestiegen. Von zielgruppengerechter (Entwickler*innen oder Externe?) und qualitätsgetriebener (ISO 25010) Dokumentation mittels der ADRs wurde vermittelt, wie man Documentation-Code-Gap reduziert und nachhaltig Dokumentationen aufbaut. Dabei standen zum einen Veränderungen im Laufe des Projektes, als auch die parallele Arbeit an Architektur und Features im Vordergrund. Architektur MUSS irgendwie in den Prozess integriert werden. Sei es via separater Backlog-Items oder einem Quality Sprint. Technische Schulden in Form von Architektur und Dokumentation sollten abgebaut werden, um den Documentation-Code-Gap zu reduzieren.

ADR beschreibt dabei einen schmalen und schlanken Prozess, Entscheidungen für Entwickler*innen festzuhalten und dies z.B. in Form von AsciiDoc mit in der Versionskontrolle zu versionieren. Architektur-Entscheidungen können dabei auch in Code überführt werden und mittels CI Pipelines geprüft werden, um Vilotions zu verhindern. Beispiel für PHP sind https://github.com/ta-tikoma/phpunit-architecture-test oder https://github.com/carlosas/phpat

Im zweiten Teil haben wir uns daran gemacht eigene ADRs zu bauen und haben diese in der Gruppe diskutiert. Hier wurden die Beschreibungen fein geschliffen, weitere Details herausgearbeitet und über Dokumentation von Architektur diskutiert.

Wenn "Microservice Architektur" die Antwort ist, was war dann eigentlich die Frage?

Im Abendprogramm ging es dann um Microservices und die "Geschichte", dass nicht jede Lösung direkt alle Probleme löst. Mit der Metapher von drei Flugzeug-Ingenieuren wurde erläutert, wie in vielen Teams die Probleme eines schlecht integrierten Monolith (ACHTUNG: Die Integration ist schlecht, nicht der Monolith) Rückschlüsse darüber getroffen werden, dass der Monolith selbst schlecht ist und Microservice das Wundermittel für alle Probleme sind. Mit dieser falschen Kausalkette wird oft eine Microservices-Architektur eingeführt, was jedoch völlig neue und andere Probleme mit sich bringt und weitere Lösungen fordert, sodass schnell das Ziel - die fachliche Lösung - mit einem sehr umfangreichen Tech-Stack erschlagen wird.

Bei jedem Projekt sollten die Ziele im Blick behalten werden. Das Abschauen von Playern wie Netflix und Amazon macht meist wenig Sinn, da der Usecase nicht zu den eigenen Problemen passt.

Forschungsvorhaben SoftAWERE – Energieeffizienz von Software anwendungsnah messen und bewerten

In dem Talk (und auch in der Keynote im Anschluss) wurde das Thema Energieeffizienz aufgegriffen. Jede Software verbraucht Ressourcen und es gilt diese zu minimieren. Ein Großteil des Fußabdruckes geht auf den Betrieb der Infrastruktur zurück und weniger die Produktion, Lieferung oder EoL. Nicht nur die Computer selbst, sondern auch Datencenter und Netzwerke haben einen großen Anteil an dem Ressourcenverbrauch. In dem Forschungsvorhaben wurde der Verbrauch der Software anhand des Tests der Software gemessen. Wenn die Test-Abdeckung gut ist, dient die Ausführung der Tests als ein Indikator für den Strom-Verbrauch der Software. Interessante Links aus dem Talk sind:

- https://github.com/hubblo-org/scaphandre
- https://sdialliance.org/roadmap

Hilfe, wir syncen!

Mit einem "Offline first"-Ansatz und dem aktiven Speichern von Informationen lokal, kann es zu Problemen mit der Synchronisation geben, wenn Daten von mehreren Personen parallel bearbeitet werden. Eine konfliktfreie und datenverlustlose Synchronisation ist gewünscht. Dies bzgl. wurden die Grundlagen mathematisch betrachtet und schließlich das IT-Konzept der CRDTs vorgestellt. "Conflict free replicated data types" sind Datentypen, welche ohne Konflikte getrennt und zusammengeführt werden können. Da verteilte Systeme und Uhrzeit-Problematiken zusätzliche Komplexität in das System bringen, gibt es verschiedene Ausprägungen der CRDTs für verschiedene Anwendungsfälle. Immer wenn es eine "Schreibendende Offline-Funktionalität" gibt, sollte darauf zurückgegriffen werden.

Links zum Thema:
- CRDTs https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type
- Automerge Beispiel https://github.com/innoq/groceries

ARC42

Nach kurzen technischen Problemen mit der Plattform hat der Talk 20 Minuten später begonnen. Gernot höchstpersönlich (https://www.arc42.de/about) hat einen Einblick in den neuen Release Version 8 der Arc42 Dokumentation gegeben. In dieser wurden zahlreiche Beispiele in der Dokumentation zu Arc42 ergänzt, Lizenz-problematiken gelöst und zahlreiche Rückfragen geklärt. Zudem ist bei mir die Aussage "Mehr Konzepte, weniger Sichten" hängen geblieben. Zusätzlich gab es bei den Infrastruktur-Entscheidungen auch die ADRs (s.o.) erneut als eine mögliche Art der Dokumentation bzw. als Tipp.

Mehr Informationen unter https://www.arc42.de/

Building a culture of chaos

Steve hat in seinem Vortrag diese Art & Weise der Qualitätssicherung vorgestellt. Der Ansatz, welcher auch von Netflix geprägt wurde, gehört zum Chaos Engineering und orientiert sich an den "Principles of chaos". Im Grunde geht es darum in komplexen verteilten Systemen, unter einem guten Monitoring, einzelne Services zu terminieren und zu prüfen, wie sich das Gesamtsystem verhält. Das Tool "Chaos Monkey" unterstützt einen bei dem Vorgehen, die "Single Points of Failure" in dem System aufzuspüren und die harte Kopplung zwischen den Services zu identifizieren und zu lösen. Motto: No plan survives first contact with the enemy. Das Vorgehen "von Fehlern lernen" erinnerte mich ein wenig an die erste "HDNET FuckUp Night", welche vor kurzem bei uns veranstaltet wurde.

Links:
- https://principlesofchaos.org/
- https://github.com/Netflix/chaosmonkey

Interne Komponenten-Library - Ein Erfahrungsbericht

In dem Vortrag gab es einen Einblick in die interne Komponenten-Bibliothek der Firma Zeiss. Diese besteht aus ~5.000 Komponenten, welche in 18 Projekten verwendet werden und von einem eigenen Team weiterentwickelt wird. Die Bibliothek namens "ZUi" (ZEISS User Interface) hat den folgenden Techstack: von Figma nach Web Component Standard, Lit Element, Storybook, Playwright, TypeScript, Rollup. Dabei enthält die Bibliothek voll funktionsfähige Web-Komponenten (inkl. verschiedener Zustände), aber auch viele kleine "Bausteine" aus denen projektbezogen individuelle "Feature-Komponenten" gebaut werden können.

Im Anschluss an die Basisdaten wurden verschiedene Probleme und Herausforderungen angesprochen, welche mit der Komponenten-Library einhergehen. Problematisch war die steigende Anzahl an Frontend Anwendungen, die Gratwanderung zwischen "einfach und fertig" und "Flexibilität" ("Dumme Komponenten" bauen, keine Angst vor Sub-Komponenten), das Community Management um die Entwickler*innen abzuholen und das Designsystem skalierbar zu gestalten. Cooler Einblick in die Praxis.

Stories from a High Performing Team or How to master the Developer Experience

In diesem Talk wurden Einblicke in die Forming-Phase eines Remote Teams auf dem Weg zu High Performance gegeben. Es wurden über verschiedene Aspekte von High Performing Teams gesprochen. Die Wichtigkeit von Diversität, Reduzierung von Fluktuation, eine offene Feedbackkultur (Team Huddle etc.), der hohe Stellenwert von "Trust im Team" und die Lösungen das Homeoffice besser zu gestalten. Im letzten Punkt wurde die "Wall of Feelings" und auch Remote Aktivitäten wie "Virtual City Tours" angesprochen. Schließlich ging es noch darum, was es bedeutet Verantwortung für etwas zu übernehmen und wie der Truck-Faktor durch "Pairing für Ownership" wiederum reduziert wird, um das Team handlungsfähig zu gestalten. Trotz aller Ideen und Maßnahmen sollte das Individuum weiter im Mittelpunkt der Tätigkeit stehen.

Links, die ich mitgenommen habe:
- Left-shift security - https://www.aquasec.com/cloud-native-academy/devsecops/shift-left-devops/

Keynote: Don't Look Down:
Wie wir #Open Source wirklich entwickeln

Im Talk hat Christian Grobmeier darüber gesprochen, was ihn an der Open Source Arbeit motiviert (Kein Geld und somit keine Abhängigkeit => Freiheiten viel zu lernen, neue Freunde finden, neue Jobs, neue Dinge ausprobieren) und was das Problem ist (Keine Geld, viel zu lernen, manchmal nicht so nette Personen, nervige Recruiter-Anfragen, viel Neues). Wie ihr seht: Es ist Segen und Fluch zugleich. Er engagiert sich seit über einem Jahrzehnt in der Apache Software Foundation. Im Talk hat Christian die Struktur der Foundation erläutert und wie die einzelnen Projekte darin eingegliedert werden (Incubator programm). Alles sehr schlüssig und gute Werbung für Open Source. Zudem ist er auch auf die Log4j Lücke Ende letzten Jahres eingegangen und den, auch aus meiner Sicht, falschen Umgang mit Open Source. In der Diskussion wurde auch nochmals aufgezeigt, dass viele Unternehmen nur Konsumenten von Open Source sind, ohne diese zu unterstützen (finanziell oder via Kontribution). Danke Christian für den Vortrag!

Links, welche ich hier mitgenommen habe:
- Log4j - https://de.wikipedia.org/wiki/Log4j
- Apache Software Foundation https://www.apache.org/
- Apache Incubator programm https://incubator.apache.org/

Technische Schulden: Software langfristig weiterentwickeln

Im Vortrag ging es um die unterschiedlichen Qualitäten von Software. Die externe Qualität (Was Benutzer sehen: Performance, Verfügbarkeit etc.) und die interne Qualität (Was Developer sehen: Code Qualität, Tests, Code Struktur etc.) und wie die beiden zusammen hängen. Technical Dept nehmen somit nicht nur Entwickler*innen wahr, sondern es spiegelt sich auch in z.B. Wartungskosten wider. Wie Wikipedia es beschreibt "cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer" (Quelle: https://en.wikipedia.org/wiki/Technical_debt) ist die "Schuld" wie "finanzielle Schulden" zu verstehen, da man diese zurückzahlen kann.

Im "Technical Dept Quadrats" von Martin Fowler
(Quelle: https://martinfowler.com/blik/TechnicalDebtQuadrant.html) wurden die Arten von technischen Schulden erläutert und somit auch, wie man diese vermeiden bzw. reduzieren kann. Der Abbau sollte nur am Code passieren, welcher auch oft modifiziert wird, weil die "Schuld" im Code, der sich nicht ändert, irrelevant ist. Dabei geht es NICHT um Ästhetik, sondern um Architektur, die durch Business Entscheidungen getragen wird. In Summe ist technische Schuld ein "Dangerous game". Denn wird zu stark an der Qualitätsschraube gedreht, kann es im Projekt zum Stillstand kommen.

Unterschiedliche Arten von Qualitäts-Investments sollen und können die Schulden abbauen:
- Refactoring (pair-/mob programming, code retreats)
- Rewrite / Rearchitekt
- Increment Investment

KEYNOTE: CUPID - for joyful coding

In dem Vortrag von Daniel Terhorst-North ging es um die Evolution von dem SOLID Prinzip und dem Add-On mit dem Namen CUPID. Es wurden die einzelnen Facetten des Pattern erläutert und erklärt, warum diese wichtig sind. Das Akronym steht dabei für:

- Composable – plays well with others
- Unix philosophy – does one thing well
- Predictable – does what you expect
- Idiomatic – feels natural
- Domain-based – in language and structure

Gute Erläuterung und eine schöne Evolution. Als Link-Info habe ich diese Seite für euch:
https://www.bbv.ch/cupid/

Missverständnisse zu Software-Architektur

Carola hat einige Missverständnisse zu Software-Architektur aufgezählt und erläutert. Dabei ging es um folgende Aspekte (Anmerkungen in Klammern):

- Microservices bilden eine serviceorientierte Architektur (am Beispiel eines Kinos)
- Überall Events (Verlust von Kontrolle, Abhängigkeiten werden unsichtbar) - Besser Self Contained System (hohe Kohäsion)
- Jedes Team nimmt die Technologie, die es möchte
- Wiederverwendung (negativ: große Domainenklassen)
- gegen Zyklen helfen Interfaces
- Sourcecode reicht als Doku (besser Arc42 inkl. ADRs)
- Neubau ist besser als Refactoring

Link zu Ihrem Buch https://sustainable-software-architecture.com/

Sustainability in Software Engineering - or how to fight climate change as a software engineer

Vortrag zu nachhaltiger Softwareentwicklung. Der Klimawandel ist allgegenwärtig und eine große Herausforderung unserer Zeit. Software ist zudem überall und hat somit großes Potenzial weniger und effizienter zu werden, um weniger Energie zu verbrauchen. Dabei ist das Spektrum, wo bei der Softwareentwicklung Energie verbraucht wird, sehr groß. Das Warten auf eine 100%ige grüne Energy Produktion ist keine Alternative und das Kaufen von Klimazertifikaten verhindert den Verbrauch der Energie nicht. Es wurde aufgezeigt, dass man nur die Software laufen lassen sollte, welche auch im Gebrauch ist. Statistiken von Rechenzentren zeigen, dass es eine hohe Quote von "Zombies" gibt. Im Anschluss lief auch noch "It's Coming! The Revolutionary Effect of Climate on Architecture" im "Signature-Track", was auch auf grüne Software einzahlt. Cloud Hoster wie AWS sind verantwortlich für die Cloud selbst, der Kunde ist jedoch für den Inhalt verantwortlich. Dies fordert mehr Verantwortung im Umgang mit der Cloud und ein Hinterfragen der Ziele einer bestimmten Software (z.B.: Muss eine Webseite von einem kleinen Bäcker hochverfügbar sein?).

Links, die dazu passen:
- https://purpose-economy.org/
- https://www.blauer-engel.de/de/produktwelt/ressourcen-und-energieeffiziente-softwareprodukte

Mythos Teamautonomie – Warum sie eine Illusion ist und wir sie trotzdem brauchen

In dem Vortrag ging es um die Illusion von Autonomie in Teams. Dies wurde fundiert erklärt und hergeleitet. Begonnen mit einer Definition, was Autonomie ist und auszeichnet (keine Gedanken über Voraussetzungen oder Folgen machen), dem Grund, warum wir Organisationen brauchen (Konstrukt, um Dinge zu leisten, welche alleine nicht möglich sind, bestehend aus der Kommunikation zwischen den Menschen, um Ziele erreichen) und dem Zwiespalt, dass eine Organisation per Definition Autonomie verhindern und Standards schaffen sollte. Im Anschluss wurde "Zweck" (Notwendigkeit) von "Ziel" (Willensbekundung) differenziert und auf den Mehrwert von Teams eingegangen: Orientierung, Fokussierung, Effizienz, Handlungsfähigkeit und reduzierte Komplexität.

Den Autonomie-Spielraum legen in der Organisation die Entscheidungsprämissen fest. Diese können explizit, aber auch impliziert (u.a. Werte & Kultur) getroffen werden. Diese Entscheidungsprämissen brauchen mehr Zeit als Entscheidungen selbst und sind gerade auf Organisations-Level schwer zu treffen. Wie und ob die Autonomie der Teams funktioniert, lässt sich dann am Alignment im Unternehmen sehen. Dies beschreibt die Übereinstimmung der Entscheidung der Personen/Teams mit den Entscheidungsprämissen der Organisation. Viele Buzz-Words, aber ein sehr spannendes Thema.

Teamstrukturen für Softwaremodernisierung

In dem Talk wurde zunächst auf die Softwaremodernisierung mit ihren verschiedenen Facetten eingegangen. Von Refactoring über Dokumentation, Bugs, Features und Sicherheit. Ebenfalls spielen Personalentscheidungen wie Fluktuation ("Brain Drain") in den Prozess der Teamstruktur mit ein. Es wurde auf die unterschiedlichen Arten von Team-Strukturen und Organigrammen eingegangen und schließlich "Team Topologies" als Lösung vorgestellt. Die Ausrichtung anhand von "Kognitiver Last" (Mental Load), gerade bei organisatorischen Umstellungen, wurde genau angesprochen sowie die Skill-Beschreibungen nach "Shu Ha Ri".

Links:
- https://teamtopologies.com

Hands-On-Einstieg in Wardley Mapping

Im letzten Workshop der Woche gab es einen Einstieg in Wardley Mapping. Der interaktive Vortrag bestand aus regelmäßigen Umfragen in der Gruppe, theoretischen Abschnitten und Break-Out-Sessions für die Arbeit in kleinen Gruppen. Dabei wurde die Wardley Map als Denk- und Kommunikationswerkzeug für Strategien vorgestellt (Make vs. Buy, Open-Source-Strategien, Zusammenhänge zwischen Technologie). Es wurde sowohl auf die Visualisierung (Position, Kontext, Orientierung, Bewegung) als auch auf Komponenten (u.a. Aktivitäten, Praktiken, Daten, Wissen) eingegangen. Die Karte soll im Anschluss Orientierung geben und anhand der Nutzerbedürfnisse nachhaltig Entscheidungen möglich machen.

Links:
- https://medium.com/wardleymaps
- https://thecanvasrevolution.com/product/wardley-mapping-canvas