"Just Enough Software Architecture" aus dem Jahr 2010
(georgefairbanks.com)- George Fairbanks’ Just Enough Software Architecture geht von der Einsicht aus, dass sich gute objektorientierte Systeme und Architekturen nicht allein mit Kenntnissen von Sprachsyntax oder UML entwerfen lassen
- Im Mittelpunkt steht risikobasiertes Architektieren: Wenn das Risiko gering ist, wird übermäßiges Design vermieden; bei Risiken, die den Erfolg bedrohen, kommen strengere Methoden zum Einsatz
- Architektur wird nicht als Domäne einiger weniger Expertinnen und Experten behandelt, sondern als Kompetenz, die alle Entwickler verstehen sollten; erklärt wird dabei auch, wie sich Einschränkungen und kleine Änderungen auf Systemeigenschaften auswirken
- Statt auf Entwicklungsprozesse oder Organisationsfragen konzentriert sich das Buch auf Engineering-Methoden und zeigt, wie sich mit Modellierung und Architekturanalyse Design-Trade-offs bei mittelgroßen bis großen Problemen behandeln lassen
- Der Aufbau besteht aus zwei Teilen zu risikobasierter Softwarearchitektur und Architekturmodellierung und behandelt Abstraktionen wie Domänenmodell, Designmodell und Codemodell, Kapselung sowie Komponenten und Konnektoren
Entwurfsfähigkeit braucht mehr als Sprach- und UML-Wissen
- Der Autor wollte das Buch schreiben, das er zu Beginn seiner Laufbahn in der Softwareentwicklung selbst gebraucht hätte
- Damals gab es zwar Bücher über Programmiersprachen und objektorientierte Programmierung, aber nur wenige über Design
- Gute objektorientierte Systeme lassen sich nicht allein entwerfen, weil man die Sprachmerkmale von C++ kennt; und gute Systemarchitekturen nicht allein, weil man UML kennt
Architektieren passend zum Risiko
- Der Kern des Buches ist risk-driven architecting
- Bei geringem Risiko ist kein detaillierter Entwurf nötig, und wenn Risiken den Erfolg bedrohen, reicht ein unsauberer Entwurf nicht aus
- Viele Agile-Befürworter sehen einen gewissen vorgelagerten Entwurf als hilfreich an; dieses Buch behandelt, wie man „gerade genug Architektur“ betreibt
- Es vermeidet einen „one size fits all“-Prozess und zeigt, wie sich Architektur- und Designaufwand an die tatsächlich vorliegenden Risiken anpassen lassen
- Die meisten Methoden lassen sich in ihrer Intensität von quick-and-dirty bis sehr streng skalieren
Architektur zur gemeinsamen Sprache aller Entwickler machen
- Das Buch verfolgt das Ziel, Architektur zu demokratisieren
- In einer Organisation kann es Softwarearchitektinnen und -architekten geben, und die Leserin oder der Leser kann selbst Architekt sein
- Viele Architekten möchten, dass alle Entwickler Architektur verstehen
- Wenn Entwickler die Gründe für Einschränkungen und die Auswirkungen kleiner Änderungen auf Systemeigenschaften nicht verstehen, kann ihre Entwurfsentscheidung unsicher werden
- Architektur ist kein Thema nur für Architekten, sondern für alle Softwareentwickler relevant
Prozedurales und deklaratives Wissen
- Das Buch konzentriert sich darauf, deklaratives Wissen aufzubauen
- Einen Tennisball schlagen zu können und zu wissen, warum man ihn schlagen kann, ist nicht dasselbe; darin zeigt sich der Unterschied zwischen prozeduralem und deklarativem Wissen
- Wer bereits Systeme professionell entwirft und baut, hat viele der Methoden des Buches möglicherweise schon angewendet
- Das Buch hilft dabei, das eigene bisherige Vorgehen bewusster wahrzunehmen und den Konzepten Namen zu geben
- Dieses deklarative Wissen hilft auch dabei, Junior-Entwickler besser zu coachen
Fokus auf Engineering statt auf Prozesse
- Wer Softwaresysteme entwirft und baut, muss zugleich mit Zeitplänen, Ressourcenzusagen, Stakeholder-Anforderungen und anderen Problemen umgehen
- Viele Bücher über Softwarearchitektur behandeln bereits Entwicklungsprozesse und Organisationsstrukturen
- Dieses Buch konzentriert sich stattdessen auf den technischen Teil der Softwareentwicklung und auf das Engineering, das ein System funktionsfähig macht
- Es zeigt, wie man Modelle erstellt und Architektur analysiert, um fundierte Design-Trade-offs zu treffen
- Es erklärt Techniken zum Durchdenken mittelgroßer bis großer Probleme und zeigt auch, wo sich spezialisierte Methoden vertiefen lassen
Praktisches Design über mehrere Abstraktionsebenen hinweg
- Das Buch behandelt Architektur als praktische Entwurfsaktivität
- Softwarearchitektur ist eine Form von Softwaredesign; Entwurfsentscheidungen beeinflussen die Architektur, und Architektur beeinflusst umgekehrt auch das Design
- Herausragende Entwickler analysieren Hindernisse im Detail, verstehen sie gründlich und verbinden deren Charakter anschließend mit der Gesamtarchitektur
- Entsprechend diesem Verhalten des drill-down/pop-up behandelt das Buch Modelle auf mehreren Abstraktionsebenen, von der Architektur bis zum Entwurf von Datenstrukturen
Aufbau und verfügbare Formate
- Das Buch besteht aus zwei Teilen
- Part I: Risk-Driven Software Architecture
- Part II: Architecture Modeling
- Einige Beispielkapitel lassen sich als einzelnes PDF herunterladen
- Das E-Book wird über Google Play verkauft, enthält die drei DRM-freien Formate ePub, Mobi und PDF und kostet $9.99
- Die Hardcover-Ausgabe ist bei Amazon erhältlich
- Google Books und Amazon Search Inside bieten volltextdurchsuchbare Versionen an
Was behandelt wird – und was nicht
- Das Buch konzentriert sich auf Softwarearchitektur im Zusammenhang mit der Erstellung von Software
- Es erklärt Techniken, mit denen Software technische Anforderungen erfüllt
- Da Engineering-Methoden selbst weitgehend prozessunabhängig sind, ist auch das Buch größtenteils nicht an einen bestimmten Prozess gebunden
- Ratschläge zu Management-Aktivitäten wie den folgenden werden nicht behandelt
- die politische Verantwortung von Architekten
- wann bestimmte Arten von Meetings stattfinden sollten
- wie Anforderungen von Stakeholdern erhoben werden
Part I: Risikobasierte Softwarearchitektur
- Softwarearchitektur exakt zu definieren ist schwierig, aber einige Merkmale sind klar
- Softwareentwickler lösen wie Ingenieure anderer Disziplinen große und komplexe Probleme mithilfe von Abstraktionen und Modellen
- Softwarearchitektur wirkt wie das Skelett eines Systems, beeinflusst Qualitätsmerkmale, steht orthogonal zur Funktionalität und wirkt über Einschränkungen auf Systemeigenschaften ein
- Architektur ist besonders wichtig in folgenden Situationen
- wenn der Lösungsraum klein ist
- wenn das Risiko des Scheiterns hoch ist
- wenn anspruchsvolle Anforderungen an Qualitätsmerkmale erfüllt werden müssen
- Als Designansatz kann zwischen architecture-indifferent design, architecture-focused design und architecture hoisting gewählt werden
- Das zentrale Vorgehen des risikobasierten Modells ist einfach
- Risiken identifizieren und priorisieren
- ein Set von Methoden auswählen und anwenden
- die Risikoreduktion bewerten
- Kapitel 4 zeigt die Anwendung des risikobasierten Modells am Beispiel eines Home Media Player-Systems
- Teamkommunikation
- Integration von COTS-Komponenten
- Sicherstellung der Metadatenkonsistenz
- Part I endet mit Hinweisen zum Einsatz von Modellen und Softwarearchitektur
- Modelle zur Problemlösung verwenden
- Einschränkungen sorgfältig hinzufügen
- auf Risiken fokussieren
- Architekturkompetenz im gesamten Team verteilen
Part II: Architekturmodellierung
- Part II konzentriert sich darauf, beim Leser ein konzeptionelles Modell von Softwarearchitektur aufzubauen
- Die grundlegende Modellstruktur besteht aus drei Arten
- Domänenmodell: entspricht Dingen der realen Welt
- Designmodell: repräsentiert den Entwurf der Software, die erstellt wird
- Codemodell: entspricht dem Quellcode
- Es können zusätzliche Modelle als Views erstellt werden, die ausgewählte Details zeigen; solche Views lassen sich zu einem Viewtype zusammenfassen
- Das Schaffen von Kapselungsgrenzen ist eine wichtige Technik der Softwarearchitektur
- Nutzer von Komponenten oder Modulen können deren internes Verhalten ignorieren und sich auf andere schwierige Probleme konzentrieren
- Autoren gekapselter Komponenten oder Module gewinnen die Freiheit, die Implementierung zu ändern, ohne ihre Nutzer zu beeinträchtigen
- Diese Freiheit ist nur möglich, wenn die Kapselung wirksam ist; das Buch behandelt daher Methoden, um das sicherzustellen
- Das Buch integriert Softwarearchitektur-Methoden aus verschiedenen Quellen
- Methoden mit Schwerpunkt auf Qualitätsmerkmalen
- Methoden mit Schwerpunkt auf Funktionalität
- praktische Verfahren zum Erstellen wirksamer Modelle
- Verfahren zum Debuggen von Modellen
- Part II behandelt zusammen mit Ratschlägen zur effektiven Nutzung von Modellen auch die Fallstricke, denen man bei diesen Techniken begegnen kann
- Das abschließende Ziel ist ein reichhaltiges konzeptionelles Modell von Abstraktionen und Beziehungen, mit dem sich Softwaresysteme ähnlich betrachten lassen, wie ein Coach ein Spiel beobachtet
1 Kommentare
Meinungen auf Hacker News
Es heißt zwar, man müsse unterscheiden zwischen Projektmanagement-Risiken wie „ein wichtiger Entwickler wird von einem Bus angefahren“ und Software-Engineering-Risiken wie „der Server skaliert möglicherweise nicht bis 1000 Nutzer“, aber meiner Erfahrung nach sind sie nicht so selten getrennt
Codequalität und Struktur, Tests und Dokumentation sowie der Einsatz standardmäßiger und gut bekannter Tools helfen bei beidem
Deshalb habe ich gegenüber Kollegen oder Vorgesetzten mehrfach das Szenario „Was, wenn du von einem Bus angefahren wirst?“ ins Spiel gebracht; es wurde zu einem Druckmittel, um reproduzierbare und verständliche Software zu bauen
Wenn man die negative Konnotation von Verletzung oder Tod vermeiden will, ist „Was, wenn du im Lotto gewinnst?“ besser
Der Kern von „vom Bus angefahren“ ist, dass man überhaupt keine Vorbereitungszeit hat, unabhängig vom Charakter; genau dadurch entsteht der Druck, Informationen heute zu teilen
Leider habe ich noch keine positive Formulierung mit derselben Implikation gefunden
Beide kamen nach etwa einer Woche zurück, also braucht es wohl ein anderes Standardbeispiel für Katastrophen
Wenn ich den Punkt vermitteln will, sage ich häufiger „die nächste Person“
Ein schlimmeres Szenario ist Burnout: Die Kopfzahl bleibt gleich, aber mental ist die Person bereits weg
Ich habe viele Unternehmen gesehen, die nicht einmal das aushalten, geschweige denn einen dauerhaften Weggang
Oder man kann, wie bei „den Bus-Faktor erhöhen“, den Fokus auf die Motivation legen, Single Points of Failure zu beseitigen
Wenn man eine Ursachenanalyse macht, sollte man nicht bei „Larry wurde von einem Bus angefahren / hat im Lotto gewonnen“ stehen bleiben; das ist nicht das eigentliche Problem
Architektur um der Architektur willen ist das Schlimmste, weil sie unnötig Komplexität erhöht
Das letztliche Ziel guter Architektur ist Kostensenkung
Wenn die Architektur dazu führt, dass Entwicklung und Wartung des Codes mehr Zeit kosten, ist diese Architektur gescheitert
Es ist immer eine Frage des Ausbalancierens
Daher gibt es nicht die eine richtige Architektur; die Wahl hängt vom Kontext ab und muss mitunter neu bewertet werden
Flexibilität ist besonders nützlich, weil sie erlaubt, die Architektur bei veränderten Umständen in gewissem Maß anzupassen und effizient zu bleiben
Kostensenkung kann eines davon sein
„Das risikogetriebene Modell führt Entwickler dazu, die minimale Menge an Architekturtechniken einzusetzen, um die dringendsten Risiken zu reduzieren. Es ist ein Prozess, in dem man hartnäckig fragt: ‚Was sind meine Risiken? Welche Technik ist die beste, um sie zu reduzieren? Ist das Risiko gemindert, und kann ich jetzt mit dem Coden beginnen oder weitermachen?‘ Das risikogetriebene Modell lässt sich in drei Schritte zusammenfassen: 1. Risiken identifizieren und priorisieren 2. ein Bündel von Techniken auswählen und anwenden 3. die Risikoreduktion bewerten“
Man will weder Zeit mit Techniken verschwenden, die wenig Wirkung haben, noch Risiken ignorieren, die das Projekt bedrohen
Um ein erfolgreiches System zu bauen, muss man den Weg wählen, der die Zeit am effektivsten nutzt; das bedeutet, Architektur- und Designtechniken nur dann einzusetzen, wenn Risiken der Anlass sind, und diese Risiken damit zu adressieren
Zu „Architektur“ gehört zum Beispiel auch, einen Client-Server-Stil zu verwenden, bei dem der Server nicht von sich aus handelt, sondern nur auf Client-Anfragen antwortet
Dieser Ansatz kann gut zum Problem passen – oder auch nicht
https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...
Hochbezahlte technische Architekten tun kaum etwas und zwingen Software Engineers dabei schreckliche Patterns auf, die diese unter unvernünftigen Einschränkungen wie Deadlines ausbaden müssen
Gute Architektur erlaubt es mehr Menschen, am Produkt mitzuwirken
Wenn es 2010 erschienen ist, frage ich mich, wie gut es seitdem überlebt hat.
„Design It“ gefällt mir, weil es gute Workshops und Aktivitäten für Techniker bietet, die mit Stakeholdern oder Kunden interagieren müssen.
Da ich in einer Beratungsrolle bin, ist es umso relevanter; außerdem gefällt mir, dass es sich nicht zu sehr auf bestimmte, häufig wechselnde technische Architekturstile stützt.
Ich meine das nicht im Hinblick auf Moden, sondern auf tatsächliche Prinzipien.
Der Autor verbringt viel Zeit mit Essays zur Denkweise und behandelt konkrete Technik nur leicht, liefert aber weiterführende Lektüre.
Es bringt Teams dazu, Architekturideen durch konkrete Aktivitäten zu bearbeiten, und macht am Ende sichtbar, worauf es ankommt.
Mein Buch versuchte, solche großen Ideen direkt anzugehen, aber es zeigte sich, dass das Thema so abstrakt ist, dass es didaktisch schwierig ist.
Welche Ideen haben seit 2010 überlebt? Manche Betriebssysteme sind Microkernel, manche sind monolithisch.
Manche Datenbanken sind relational, andere dokumentenorientiert.
Manche Anwendungen sind Client-Server, andere Peer-to-Peer.
Solche Unterscheidungen sind vermutlich dauerhaft; wenn man in 100 Jahren zurückkommt, sind Beispiele wie Windows, Oracle oder Salesforce vielleicht verschwunden, aber Systeme mit solchen Entwürfen wird man weiterhin sehen.
Und über Qualitäten wie Änderbarkeit oder Latenz werden wir ebenfalls weiterhin sprechen.
Im Feld der Softwarearchitektur geht es darum, solche dauerhaften Abstraktionen zu identifizieren.
In [2] gibt es eine knappe Erklärung.
„Abstract: Softwarearchitektur ist eine Sammlung von Abstraktionen, die uns helfen, über Software nachzudenken, die wir bauen wollen oder bereits gebaut haben. Unser Feld hatte schon lange kleine Abstraktionen, aber es dauerte Jahrzehnte, bis sich größere Abstraktionen wie Qualitätsattribute, Information Hiding, Komponenten und Konnektoren, mehrere Sichten und Architekturstile angesammelt hatten. Wenn wir Systeme entwerfen, verweben wir diese Abstraktionen, um eine Kette der Intentionalität zu bewahren und dafür zu sorgen, dass das entworfene System das Gewünschte tut. Vor 20 Jahren veröffentlichte Martin Fowler in diesem Magazin den einflussreichen Artikel ‘Who Needs an Architect?’. Jetzt ist es an der Zeit, dass Entwickler Softwarearchitektur erneut betrachten und sie als Sammlung von Abstraktionen sehen, die es ermöglichen, über Software nachzudenken.“
[1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/
[2] George Fairbanks, Software Architecture is a Set of Abstractions Jul 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...
John Ousterhouts A Philosophy of Software Design fand ich nützlich.
Es enthält viele solide, leicht verständliche Ratschläge und viele Beispiele.
Dieses Buch selbst kenne ich nicht, aber ich kenne die Texte des Autors zu Intellectual Control, und sie sind sehr aufschlussreich.
https://www.georgefairbanks.com/ieee-software-v37-n3-may-202...
https://johnwhiles.com/posts/programming-as-theory
In einer früheren Firma haben wir Simon Browns Buch Software Architecture for Developers herumgereicht: https://leanpub.com/b/software-architecture
Es steht bei mir noch auf der Leseliste, und ich bin inzwischen nicht mehr bei dieser Firma, aber es wurde mir wärmstens empfohlen.
Diese Firma dokumentierte ihre Architektur auch mit dem C4-Modell.
Ich frage mich, ob es hier jemand gelesen hat.
Seine Architekturvorträge [1] und Workshops sind besonders wirksam, und auch die C4-Architekturmodellierungssprache [2] gewinnt in der Praxis tatsächlich an Fahrt.
Ich habe zwar auch YouTube-Videos [3], aber sie sind nicht so wirksam.
[1] https://www.youtube.com/results?search_query=simon+brown+arc...
[2] https://c4model.com/
[3] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...
Für diese Methodik wäre der Name „risikoabhängig“ meiner Meinung nach viel besser gewesen.
Warum mögen Programmierer Ausdrücke wie „[X]-getrieben“ eigentlich so sehr?
Diese Welle treibt jenes Zahnrad an, und dieses Zahnrad treibt das Rad an, und so weiter.
Es ist eine Kurzform für „Was ist der stärkste Mechanismus in dieser komplexen Denkmaschine?“
Vor ein paar Jahren hatten wir in der Firma einen Lesezirkel zu diesem Buch, und ich fand es sehr repetitiv.
Ich frage mich, ob dieses Buch eine gute Ressource für jemanden ist, der ein nicht triviales Open-Source-Projekt startet.
Oder ob es für einen Solo-Gründer wertvoll ist; ich würde mich über Empfehlungen für Bücher oder andere Ressourcen freuen, die für Solo-Entwickler nützlich sind.
Softwarearchitektur ähnelt zwar der klassischen Architektur, aber in der Software gibt es noch keine Figur wie Isaac Newton; es ist, als gäbe es noch kein Bauingenieurwesen.
Die bislang nächstliegende Person ist meiner Ansicht nach Claude Shannon.
Denn es gibt nicht einmal Maßeinheiten.
Im Software Engineering befinden wir uns noch in der Phase „hoffentlich stürzt es nicht ein“.
Das hat tiefgreifende Auswirkungen auf selbstberichtete Produktivität.
Zum Beispiel kann sich ein Fahrrad schneller anfühlen, als mit hochgekurbelten Fenstern mit 30 Meilen pro Stunde über kleine Vorortstraßen mit vielen Stoppschildern zu fahren.
Aber normalerweise kommt der Autofahrer an einem 20 Blocks entfernten Ziel deutlich schneller an.
Ohne Maßeinheiten würden alle darüber streiten, dass das Fahrrad schneller sei.
Genau in diesem Zustand befindet sich das Software Engineering derzeit.
Software zu bauen ist überhaupt nicht dasselbe wie eine Brücke oder ein Hochhaus zu bauen; es ähnelt viel eher dem Entwerfen solcher Dinge.
Bei großen Bauprojekten wird zuerst entworfen und danach gebaut, und dieser Entwurf ist eine enorme Arbeit.
Man muss alles durchdenken, Simulationen laufen lassen, sich mit Stakeholdern abstimmen, Anforderungen und Einschränkungen erfassen sowie Materialkosten, Gewicht und Ähnliches berücksichtigen.
Bei großen Bauprojekten können allein für die Erstellung des Entwurfs Monate oder Jahre vergehen, und das Ergebnis ist ein sehr detaillierter Bauplan, der nahezu alle Aspekte der Konstruktion abdeckt.
Tatsächlich ist das der Softwareentwicklung ziemlich ähnlich.
Solche Entwurfsprojekte sind mit hoher Unsicherheit und hohem Risiko verbunden.
Trotzdem ist es besser, herauszufinden, dass alles falsch ist, bevor man beginnt, teure Ressourcen wie viele Arbeitskräfte, Beton und Stahl einzusetzen.
Aber hat man je gehört, dass ein Architekt zur Risikominderung einen Entwurf für den Entwurf erstellt? So etwas gibt es nicht.
Allenfalls gab es irgendwann eine Skizze oder eine Zeichnung auf einer Serviette.
SpaceX hat einige agile Elemente ins Engineering übernommen; das stammt aus der Softwareentwicklung.
In der Software ist der fertige Bauplan ausführbar.
Der Prozess, den Bauplan zu erstellen, ist Handarbeit, aber der Prozess, aus diesem Bauplan Software zu erzeugen, ist in der Regel durch Compiler und andere Tools automatisiert und sehr billig, weshalb Entwickler das ständig tun.
Natürlich war das früher nicht immer so.
Beim Erstellen eines ausführbaren Bauplans gibt es selbstverständlich viele Risiken, und unterwegs kann es Servietten- oder Whiteboard-Entwürfe geben.
Aber die Vorstellung, zuerst ein vollständiges Design und danach eine vollständige Implementierung zu machen — also das Wasserfallmodell — hat auch in der Software nie wirklich funktioniert.
Von einigen Ausnahmen abgesehen gibt es normalerweise keinen Bauplan für den Bauplan.
Wenn man Royces ursprünglichen Wasserfall-Aufsatz liest, kommt das Wort Wasserfall tatsächlich überhaupt nicht vor, und er deutet vage an, dass Iteration eine gute Idee sein könnte.
Sinngemäß: Macht es mindestens einmal mehr.
Er hatte vollkommen verstanden, dass der erste Entwurf mit hoher Wahrscheinlichkeit falsch sein würde.
Agile hat den Schritt mit geringem Wert, einen Entwurf für den Bauplan zu erstellen, wegoptimiert — etwas, das offensichtlich wird, wenn man viele Iterationen macht.
Außerhalb bestimmter Bereiche ignorieren wir sie jedoch größtenteils.
Wenn man sich zum Beispiel diese Zusammenfassung und das Inhaltsverzeichnis grob ansieht, scheint es kaum oder gar keine Erwähnung von Performance-Metriken zu geben.
Wozu ist Architektur gut, wenn sie nicht berücksichtigt, was der Computer tatsächlich tut?
Warum gibt es auch im Hinblick auf Entwicklerproduktivität oder Benutzeroberflächen kein mathematisches Modell, das den mentalen Stack beschreibt, der nötig ist, um Software zu entwickeln, zu ändern, zu erweitern und — wichtiger noch — zu benutzen?
Rechenressourcen, ob menschlich oder maschinell, haben reale und messbare Auswirkungen darauf, wie man als Entwickler oder Nutzer mit Software interagiert; warum werden sie also nur selten berücksichtigt?
Westminster Palace hat zum Beispiel eindeutig bauingenieurtechnische Elemente, doch entscheidende Merkmale wie die reichhaltige Textur, der ikonische Uhrturm und die Innenaufteilung werden größtenteils von funktionalen und ästhetischen Entscheidungen bestimmt.
Für viele Teile von Software gilt dasselbe.