Software Architektur im Stream

Daten-intensive Systeme arbeiten häufig mit Eventual Consistency. Dadurch ergeben sich neue Herausforderungen und jede Menge Komplexität wandert vom Infrastruktur-Layer in den Domain-Layer. Susanne Braun forscht zum Thema Eventual Consistency und stellt uns ihre ganz praktischen Regeln vor, wie man als Architekt man damit umgehen sollte.Link zum Projekt: https://github.com/EventuallyConsistentDDD

Stefan Zörner und Falk Sippach wollen in ihrem Vortrag auf der OOP Architektur-Reviews anhand der Corona-Warn-App vorstellen. Aber warum sind Architektur-Reviews wichtig und was zeichnet sie aus?

Auch Architektur-Entscheidungen müssen wirtschaftlichen Zielen unterordnen. Michael Mahlberg erläutert, warum das so ist - und wie bereits ein kleiner Werkzeug-Koffer dabei hilft, Architekturentscheidungen und -strategien bewertbarer zu machen. Material: https://bit.ly/oop2021-di24

Oft wird Software immer schlechter wartbar, je länger Entwicklungsteams an ihr arbeiten. Dazu hat sich die Metapher “technische Schulden” etabliert. Aber es ist nicht immer sinnvoll, technische Schulden zu beseitigen und sie können auch “einfach so” entstehen. Darüber sprechen wir - und über die Grundlagen der Metapher, wie sie bei der Kommunikation mit Managern hilf, warum die Metapher eigentlich nicht besonders gut gewählt ist und natürlich wie man mit technischen Schulden sinnvoll umgehen kann. Links Ward Cunningham über Technical Debt im c2 WikiWard Cunningham über Technical Debt bei YouTubeheise Podcast zu technische SchuldenBlog “Technische Schulden entstehen einfach so”Artikel über Qualitätsinvestitonen mit Felix Müller - ENArtikel über Qualitätsinvestitonen mit Felix Müller - DEArtikel Umgang mit technischen SchuldenSE Radio zu technical debt mit Sven Johann - ENArtikel Managing Technical Debt mit Sven Johann - ENTechnical Debt Conference

Simon Brown is the author of Software Architecture for Developers; a developer-friendly guide to software architecture, technical leadership and the balance with agility. He is also the creator of the C4 software architecture model and the founder of Structurizr, a collection of tooling to help software teams visualize, document and explore their software architecture. So naturally we will talk about software architecture - and how C4 and Structurizr help! Links: https://simonbrown.je/ https://c4model.com/ https://structurizr.com/

Eine der größten Herausforderungen, denen sich Software-Entwickler und Technical Leads stellen müssen, ist der Umgang mit Legacy und technischen Schulden. Diese Herausforderung wird immer schwieriger, da die Lebensdauer von Software mit dem Aufkommen neuer Technologien steigt und die Verweildauer in Unternehmen immer kürzer wird. Wie kann man diese Herausforderung angehen, ohne Software dauernd neu zu schreiben?

Patrick Kua was CTO and Chief Scientist at N26 in Berlin and is now an independent coach and mentor to CTOs and VPs Engineering. Patrick has written several books e.g. about how to talk to tech leads and he co-authored a book about evolutionary architecture. In this episode we will therefore discuss how software architecture can embrace change and support business goals in the long run. Patrick’s home page Patrick’s newsletter Command line tools for architecture decision records (ADRs) Architecture elevator (Gregor Hohpe)

Pattern für Software-Entwicklung gibt es schon seit mehr als 25 Jahren. Aber schon davor gab es Patterns für Dinge z.B. in der Gebäude-Architektur. Und mittlerweile sind auch Patterns für andere Bereiche entstanden. So erlauben sie den Zugriff auf Erfahrungen über den Umgang mit Code und Menschen. Sogar Refactorings sind eigentlich Patterns für den Umgang mit Code. Links Patterns Christopher Alexander: “The Timeless Way of Building”, 1979, Oxford University Press, ISBN 978-0-19-502402-9 Peter Gabriel: “Patterns of Software” Kevlin Henney, Frank Buschmann et al: “Pattern-Oriented-Software-Architecture 1-5” POSA 1-5 , besonders POSA 5 Gregor Hohpe, Bobby Woolf: “Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions”, 2003, Addison Wesley, ISBN 978-0-32-120068-6 Gerard Mezaros: “xUnit Test Patterns: Refactoring Test Code”, 2007, Addison Wesley, ISBN 978-0-13-149505-0 Refactoring Michael Hungers Studienarbeit zu Refactoring Refactoring 2nd Ed Vortrag beim JUG Saxony Day Martin Fowler: “Refactoring: : Improving the Design of Existing Code”, 2nd Edition, 2018, Addison Wesley, ISBN 978-0-13-475759-9 Martin Fowler: Refactoring 2nd Edition Web Version Joshua Kerievsky: “Refactoring to Patterns”, 2004, Addison Wesley, ISBN 978-0-32-121335-8 Kent Beck: “Implementation Patterns”, 2007, Addison Wesley, ISBN 978-0-32-141309-3 Pramod Sadalage: “Refactoring Databases: Evolutionary Database Design”, 2011, Addison Wesley, ISBN 978-0-32-177451-4 Steve Freeman, Nat Pryce: “Growing Object-Oriented Software, Guided by Tests”, 2009, Addison Wesley, ISBN 978-0-32-150362-6 Adam Tornhill: “Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs”, 2015, O’Reilly, ISBN 978-1-68-050038-7 Adam Tornhill: “Software Design X-Rays: Fix Technical Debt with Behavioral Code”, 2018, O’Reilly, ISBN 978-1-68-050272-5 , Software Design jQAssistant Michael Feathers: “Working Effectively with Legacy Code”, 2013, Addison Wesley, ISBN 978-0-13-117705-5 Leute Dave Hoover, Adewale Oshineye: “Apprenticeship Patterns: Guidance for the Aspiring Software”, 2009, O’Reilly, ISBN 978-0-59-651838-7 Philip Armour: “The Laws of Software Process”, 2003, Auerbach, ISBN 978-0-84-931489-6 Linda Rising: “Fearless Change: Patterns for Introducing New Ideas”, 2015, Addison Wesley, ISBN 978-0-13-439525-8

In dieser Ausgabe diskutieren Uwe Friedrichsen und Eberhard Wolff das Für und Wider von Microservices.

Inner Source nutzt Open-Source-Methoden für die Entwicklung von Software innerhalb eines Unternehmens. Auf den ersten Blick scheinen Entwickler:innen so nur einfach Code teilen zu können, aber es hat weitreichende Konsequenzen und kann dazu dienen, Silos in Unternehmen einzureißen und so die Organisation zu verbessern. Prof. Dirk Riehles forscht in diesem Bereich und wird berichten, wie Inner Source in der Praxis funktionieren kann. Links zu Inner SourceInner Source Commons: Eine Non-Profit zur Verbreitung von Inner SourceFallstudien zu Inner Source (Video)Einfacher Rat, um mit Inner Source zu beginnen (Short Post)Was Dirk so zu Inner Source zu sagen hatBücher zu Forschungsmethoden im Software EngineeringFelder & Travassos, Contemporary Empirical Methods in Software Engineering, Springer 2020.Runeson et al., Case study research in software engineering, Wiley 2012.Wohlin et al., Experimentation in Software Engineering, Springer 2012.Das von Eberhard gennante Buch:Laurent Bossavit: The Leprechauns of Software Engineering

Anja Kammer erklärt in dieser Folge, warum und wie man keine DevOps Engineers einstellt - und warum DevOps als Begriff leider immer noch missverstanden wird. Dabei geht es auch um Team Topologys, mit denen die Organisation von Teams und die Kommunikation zwischen Teams visualisiert und optimiert werden kann. Links: DevOps Topologies DevOps Handbook Team Topologies

In dieser Folge diskutiert Johannes Seitz sokratische Gespräche. Das ist ein Möglichkeit, um nicht nur Grundlagen wie Information Hiding zu vermitteln, sondern die sich auch sonst gut für Consulting und Training eignet. Johannes hat vor allem in Remote-Szenarios damit gute Erfahrungen gemacht. In dieser Folge erläutert Johannes, was sokratische Gespräche sind und wie man sie führen kann. Links: Johannes Artikel Justice Course

Der INNOQ Technology Day ist eine kostenlose Online-Konferenz am 2020-12-09. In diesem Video erläutert das Programm-Komitee die Idee der Konferenz und was den Technology Day besonders macht.

Lisa Moritz spricht mit Christoph Iserlohn über Sicherheit und was gerade Architekt:innen dazu wissen sollten und müssen. Dabei geht es um typische Angriffe und Security-Probleme wie die OWASP Top 10 - und natürlich auch darum, was man gegen sie tun kann. Links: Kostenloses Security Buch

Schon in Folge 20 diskutierten Franziska Dessart, Joy Heron, Lucas Dohmen und Eberhard Wolff über Web-Architekturen. In dieser Folge geht es um die Architektur-Optionen für moderne Web Frontends. Wir geben einen Überblick über die Patterns, die wir uns begegnet sind. Wo implementiert man die Logik, wo liegen die Daten und wie findet die Integration statt: Das sind die wesentlichen Fragen, die wir gemeinsame diskutieren werden. Verschiedene Architektur-Optionen wie server-side Rendering, Single Page Apps werden wir wertungsneutral gegeneinander abwägen.

Frontends scheinen auf den ersten Blick einfach, aber auch der Entwurf dieser Systeme stellt Architekt:innen und Entwickler:innen vor Herausforderungen. In dieser Folge diskutieren Franziska Dessart, Joy Heron, Lucas Dohmen und Eberhard Wolff über verschiedene Ansätze für Frontend-Architekturen.

Nur mit Modularisierung kann man große Systeme entwickeln. Gerade durch Microservices gibt es wieder eine Diskussion zu diesem zentralen Konzept. In dieser Folge werden wir uns klassische Konzepte zur Modularisierung beispielsweise von Parnas anschauen und herausarbeiten, was man aus diesen Ansätzen für Architektur-Arbeit an modernen Systemen lernen kann. Parnas 1971: On the Criteria to be Used in Decomposing Systems into Modules Adrian Colyer zu dem Paper Blog: Meine Datenbank gehört mir! Parnas 1971: Information Distribution Aspects of Design Methodology Adrian Colyer zu dem Paper Brooks 1975, 1995: The Mythical Man Month Blog: Collective Code Ownership: Ein Anti-Pattern? Blog: Wasserfall-Modell? LOL!

Microservices sind verteilte Systeme. Damit ist die Konsistenz der Daten über die verschiedenen Microservices eine Herausforderung. Und Transaktionen in verteilten Systemen sind auch schwierig. In dieser Folge von Software Architektur im Stream geht es darum, wie man mit den Herausforderungen umgeht. Dabei geht es auch um Begriffe wie ACID, Two Phase Commit, Sagas, BASE und das CAP Theorem. Kyle Kingsbury über NoSQL-Datenbanken Leslie Lamports Preise

Diese Folge behandelt verschiedene Fragen aus der Community: Wie geht man beim Halten von Vorträgen vor?Architekt:innen- vs. Entwickler:innen-RolleLernen als Architekt:in

Ein Kunde hat eine besondere Anforderung an die Software, dann kommt der nächste Kunde mit seiner spezifischen Anforderung und am Ende sind die vielen verschiedenen Varianten kaum noch zu managen. In dieser Folge stellt Danilo Beuche dar, wie man mit dieser Herausforderung umgeht, wenn es wie bei Embedded Software sehr viele Varianten gibt und der Umgang damit entscheidend wird. Ein Stichwort ist dabei Product Line Engineering. ISO/IEC DIS 26580 Methods and tools for the feature-based approach to software and systems product line engineering Product Line Engineering Primer (High-Level Introduction) Danilo Beuche, Mark Dalgarno: Software Product Line Engineering with Feature Models

Auch Domain-driven Design (DDD) findet nur selten in Greenfield-Projekten statt. Eric Evans, der DDD-Erfinder, hat ein Paper geschrieben, das den Umgang mit Domain-driven Design in Legacy Systemen diskutiert und das im Mittelpunkt dieser Folge steht. 

Auch in Monolithen gibt es Module. In dieser Folge sprechen Oliver Drotbohm und Eberhard Wolff sprechen darüber, wie man auf dieser Basis Architekturen erstellen kann.

In dieser Folge geht es um den Aufbau einer fachlichen Architektur z.B. mit Bounded Contexts und warum dieser Architektur-Ansatz so wichtig ist.

Der iSAQB ist ein gemeinnütziger Verein. Er unterstützt die Ausbildung und Fortbildung von Software-Architekten. Diese Folge bespricht den Verein und die Zertifizierung von Software-Architekten.

Die Organisation beeinflusst nicht nur die Architektur, sondern man kann sie auch als Werkzeug für das Erstellen von Architekturen nutzen. Diese Folge geht der Idee auf den Grund und zeigt, wie Architekt:innen noch besser an Architekturen arbeiten kann.