book

Erleichterung der Software-Architektur

by Andrew Harmel-Law

March 2025

Intermediate to advanced

512 pages

18h 14m

German

O'Reilly Media, Inc.

Audio summary available

Read now

Unlock full access

Wer sollte dieses Buch lesen?Warum ich dieses Buch geschrieben habeNavigieren in diesem BuchIn diesem Buch verwendete KonventionenErgänzendes MaterialO'Reilly Online LearningWie du uns kontaktierstDanksagungen
Sowohl die Praxis als auch das Endergebnis der Softwarearchitektur sind entscheidend für den ErfolgWas sind die Praktiken der traditionellen Architektur?Elfenbeinturm ArchitektenArchitekten zum AnfassenWas ist falsch an den beiden traditionellen Ansätzen?Fünf Revolutionen haben die Macht der Software entfesseltDie Auswirkungen der fünf Revolutionen auf die ArchitekturpraxisDer Aufschwung der DezentralisierungDer Fall der zentralisierten ArchitekturbürosWas muss eine neue Praxis der Architektur bieten?Kein Ansatz kann vor den Mächten des Chaos schützenArchitekturen sollten Ungewissheit zulassenArchitekturen sollten das Entstehen ermöglichenFazit
Entscheidungen sind der Kern der Software-ArchitekturWas ist eine architektonische Entscheidung?StrukturFunktionsübergreifende MerkmaleAbhängigkeitenSchnittstellenKonstruktionstechnikenEinige Beispiele für architektonische und nicht-architektonische EntscheidungenWer trifft diese architektonischen Entscheidungen?Architektonisch bedeutsame EntscheidungenWas macht eine architektonische Entscheidung "bedeutsam"?Was sollte bei der architektonischen Bedeutung nicht beachtet werden?Architektonische Bedeutung in Bezug auf die eingesetzte SoftwareEinige Beispiele für wichtige architektonische EntscheidungenFazit
EntscheidungsprozesseStufe 1: Entscheidung erforderlichPhase 2: Der Akt des EntscheidensStufe 3: Entscheidung umgesetztWo liegt das Machtgleichgewicht in Entscheidungsprozessen?Traditionelle architektonische Ansätze bringen Teams nur unzureichend in die Phase der Optionsfindung im Entscheidungsprozess einEntscheidungsprozesse im MaßstabStandardansätze für Entscheidungen in großem MaßstabEntscheidungsprozesse in einer revolutionierten WeltFazit
Der Bedarf an einem schnelleren, dezentralen EntscheidungsprozessDer Prozess der Architekturberatung: Eine Regel, zwei beratende Gruppen und ein VertragDer Prozess der Architekturberatung ist schnellDer Prozess der Architekturberatung ist dezentralisiertDer Architekturberatungsprozess führt zu einem GesellschaftsvertragZwei Beispiele für den Architekturberatungsprozess in AktionGeschichte 1: Ein Entwicklungsteam entscheidet sich für Release TogglesGeschichte 2: Ein Architekt beschließt, ein Workflow-Problem zu lösenDie zentrale Rolle der BeratungRatschläge sind Richtungsempfehlungen plus ArgumenteBeratung stärkt Optionsmacher und EntscheidungsträgerWer Ratschläge gibt, ist nicht verantwortlich - Entscheidungen zu treffen schonDie Wichtigkeit von GesprächenDie Bedeutung von VertrauenFazit
Erste SchritteWenn du bereits Entscheidungsgewalt hastWenn dir derzeit die Entscheidungsgewalt fehltEgal, wo du anfängst, fang klein anHerausforderungen in der Anfangsphase überwindenErkläre allen Beteiligten den Prozess der ArchitekturberatungLass dich von den richtigen Leuten beratenFrag die richtigen Leute und finde das "Warum?" heraus.Erkläre, wer für jede Entscheidung verantwortlich istVertrauensfragen, die sich aus dem Architekturberatungsprozess ergebenMangelndes Vertrauen in die eigenen Entscheidungsfähigkeiten und die der anderenMangelndes Vertrauen bei der Suche nach und dem Anbieten von RatschlägenMangelnde Zuversicht, alles zu wissen, was passiertFazit
Einführung der architektonischen EntscheidungsprotokolleDie Struktur eines ADR-VerfahrensTitelMeta-ElementeEntscheidungKontextOptionenKonsequenzenBeratungEin ADR zur Unterstützung der Entscheidungsfindung verfassenSchritt 1: Erstelle dein leeres ADR und lege seine Metadaten festSchritt 2: Schreibe den KontextSchritt 3: Triff Optionen und sammle ihre KonsequenzenSchritt 4: Eine ausgewählte Option vorschlagenADRs zur Erleichterung des Beratungsprozesses nutzenWann und wie du dich beraten lassen solltestEinrichten des BeratungsbereichsRatschläge einholenAktualisierung des ADR, um die Beiträge anderer zu berücksichtigenDeine Entscheidung treffen und das ADR-Verfahren abschließenWähle die EntscheidungsoptionSchreibe deinen Entscheidungsabschnitt und aktualisiere deinen TitelÄndere den ADR-Status in AngenommenTeile die EntscheidungDer ADR-LebenszyklusStatus der Standards: Entwurf, Vorgeschlagen, Angenommen und ErsetztNicht-Standard ADR-StatusADRs verwaltenGrundlegende Aspekte der Verwaltung von ADRsADRs auf Wikis und Rich-Text-Dateien in der VersionsverwaltungADRs in Work-Ticketing-SystemenADRs kuratierenFazit

Verantwortung und Rechenschaftspflicht haben sich verschobenDie meisten traditionellen Governance-Praktiken werden obsoletDer Beratungsprozess ist mit bestehenden Unternehmensarchitekturen kompatibelExplizite ADR-Rechenschaftspflicht ist eine Kontrolle für die RücksichtslosenTeams sind nicht verpflichtet, sich zu entscheidenDer Raum des Architekturbüros öffnet sichRaum für eine Kultur des Lernens und des Vertrauens schaffenZwei Beispiele für Vertrauen (oder fehlendes Vertrauen) in AktionDu kannst nicht davon ausgehen, dass eine Kultur des Vertrauens und des Lernens entstehen wirdEine Kultur des Vertrauens und des Lernens muss sorgsam gepflegt werdenVerstehe die sich verändernde Dynamik bei verschiedenen OrganisationsgrößenVerabschiede unterstützende Elemente, um den Raum für Vertrauen zu schützenDen Raum der Architekturpraxis schützenEs gibt kein Standardrezept für die unterstützenden ElementeMach jedes unterstützende Element zu deinemÜberprüfe deine Motivation, bevor du irgendetwas hinzufügstNetflix: Ein Beispiel für das Flow-Finding MindsetHüte dich vor den Sirenengesängen der Gewissheit und VorhersehbarkeitExperimentiere, um den Fluss deines Unternehmens zu findenFazit
Das Architekturberatungsforum stellt sich vorEine einfache Stehende AgendaWie sich ein Beratungsforum von traditionellen Architekturversammlungen unterscheidetEin Architekturberatungsforum betreibenVor einem ArchitekturberatungsforumDie Agenda teilenEröffnung einer Sitzung des ArchitekturberatungsforumsEin ADR einführenAngebot und Annahme von RatschlägenAufzeichnung der BeratungSoziale Dynamik auf dem BeratungsforumArchitektonische Interaktionen sind standardmäßig kontraproduktiv und hierarchischKoaleszente Argumentation: Eine Alternative zur kontradiktorischen ArgumentationDer Architekturberatungsprozess und ADRs als koaleszenter Ansatz zur EntscheidungsfindungBeratungsforen katalysieren eine starke GruppendynamikDie Erfahrung für BeratungsanbieterDie Erfahrung für RatsuchendeDie Erfahrung für Lernende BeobachterGemeinsame Beteiligung an konkreter KreativitätArchitekturberatungsforen fördern konzeptionelle Integrität und sozialen ZusammenhaltDezentralisierung der Ausführung bei zentraler KoordinierungTiefes Fachwissen: Wenn Zentralisierung am besten funktioniertTransparenz für sozialen Zusammenhalt und VertrauenDas Stärkungsritual der KadenzDen Beratungsprozess mit einem Beratungsforum einleitenAufgabenbereichWenn du das Beratungsforum nutzt, um den Beratungsprozess einzuleitenWer beruft das erste Beratungsforum ein?Wie sich das erste Beratungsforum von den folgenden unterscheiden wirdFazit
Die Wichtigkeit der organisatorischen AusrichtungAngleichung ist keine Garantie für EffektivitätErkennen einer unzureichenden organisatorischen AusrichtungVier Mittel zur AnpassungDu bist ausgerichtet, wenn du nicht überrascht bistMinimum Viable AgreementFunktionsübergreifende AnforderungenTechnologie-StrategieAuf dem Weg zur Minimalvereinbarung für deine OrganisationFazit
Architektonische Grundsätze von allen Beteiligten übernehmenBeispiele für architektonische PrinzipienMerkmale guter architektonischer PrinzipienMerkmale von schlechten architektonischen GrundsätzenPrinzipien können verdeckte funktionsübergreifende Anforderungen seinArchitektonische Grundsätze ergänzen einen Beratungsprozess und ADRsErfasse deine architektonischen Prinzipien mit einem Prinzipien-WorkshopVorbereitung der Inputs für deinen Prinzipien-WorkshopWorkshop zum Aufbau deiner PrinzipienWorkshop zu deinen PrinzipienDeine Prinzipien einsatzbereit präsentierenPrinzipien nützlich haltenRückmeldungen aus Entscheidungen sollten architektonische Prinzipien beeinflussenAktualisierung und Pflege von GrundsätzenRückmeldungen aus Entscheidungen können die technische Strategie beeinflussenFazit
Sense Tech Trends und ErfassungsrichtlinienTechnologie-Radare sammeln und teilen kontinuierlich HinweiseWie das Thoughtworks Technologie-Radar funktioniertDein internes Technologie-Radar wird anders strukturiert seinDer Platz deines Radars in einem BeratungsprozessDein Technologie-Radar erstellenBlip-SammelnBlip-Sortierung und ValidierungBlip-FokussierungBlip PositionierungBlip DokumentierenRadar VerlagAktualisieren deiner BlipsRegelmäßige ResweepsAd-hoc-Aktualisierungen auf der Grundlage gemeinsamer ErfahrungenErfassen früherer Ausbrüche und ihrer GeschichteFazit
Die Bedeutung der weicheren SeiteDen Kontext einrahmenAusschluss ist genauso wichtig wie EinschlussFragen, die das Urteilsvermögen rund um das Framing verbessernBeziehe die richtigen Stakeholder einUnterscheidung der Optionen und ihrer KonsequenzenLass dich nicht durch den Rahmen in deiner Kreativität einschränkenInspiration suchenKontext und Optionen mit Beratung schärfenEntwickle deine MetakognitionÜbung 1: Teile deine Gründe mitÜbung 2: Reagierst du oder reagierst du?Übung 3: Suche absichtlich nach Ratschlägen, die dich herausfordernDer Umgang mit unkooperativen PersonenAuswählen einer EntscheidungsoptionAngst überwindenVorurteile überwindenDie Entscheidung treffenWenn du die Entscheidung triffstWenn andere die Entscheidung treffenFazit
Die Auswirkung der Variabilität auf die Praxis der ArchitekturVariabilität macht die Entwicklung von Systemen schwierigVariabilität ist das Lebenselixier der SoftwareentwicklungEffektiv mit architektonischer Variabilität arbeitenVariabilität durch schnelles Treffen und Testen von Entscheidungen bewältigenTeste Entscheidungen gründlich anhand ihres funktionalen KontextsNutze Walking Skeletons, um deine frühesten Entscheidungen in ihrem funktionalen Kontext zu testenVariabilität mit kleineren Entscheidungen bekämpfenDie Auswirkungen architektonischer Entscheidungen auf den zukünftigen FlussGute technische Infrastruktur ermöglicht kleine EntscheidungenEine gute soziotechnische Infrastruktur ermöglicht auch kleine EntscheidungenNutze den Beratungsprozess, um Entscheidungen für den Fluss zu entkoppelnVariabilität nutzen, um Risiken zu bekämpfen und Werte zu entdeckenSchnell und falsch ist besser als langsam und richtigBeobachte die AusreißerOrdne die wertvollsten Entscheidungen zuerst anFazit
Einen Weg durch die Variabilität findenWir stellen vor: SpikesSpikes können die architektonische Variabilität kostengünstiger bewältigenWo sitzen Spikes in einem Entscheidungsprozess?Spike ADRsSpiked ADRs folgen immer noch dem BeratungsprozessUntersuchung der Verflechtung von EntscheidungenEntscheidungen sind eine SerieEntscheidungen sind eine umgekehrte HierarchieEntscheidungen sind atomarEntscheidungen sind zweiseitige UnterhaltungenZusammenhängende Entscheidungen sind gesellschaftlich kompliziertFazit
Machtübergänge sind nie einfachDer Übergang für diejenigen, die Macht erlangenGlaubt jeder, dass er die Macht hat, zu entscheiden?Sind sich alle über ihre Verantwortlichkeiten im Klaren?Warum nehmen die Menschen die ihnen zur Verfügung stehende Macht nicht wahr?Die Wichtigkeit der SicherheitDer Übergang für diejenigen, die ihre Macht teilen müssenDie Angst derer, die die Macht weggegeben habenDas Verhalten derjenigen, denen es nicht gefällt, dass die Macht geteilt wurdeÜbergänge sind unbehaglichFazit
Missverständnisse über FührungIrrglaube 1: Führung ist angeborenIrrglaube 2: Führung ist an Hierarchie gebundenIrrglaube 3: Führung ist unidirektionalIrrglaube 4: Führung ist ManagementWas Führung istDeming's 14 PunkteDienende FührungAdaptive FührungFührer-Führer-FührungHerausforderungen bei der Umstellung auf Leader-Leader LeadershipDer Bedarf an kontinuierlicher moralischer FührungAuf moralische Herausforderungen reagierenSei sensibel für - aber nicht verschlossen gegenüber - all deinen derzeitigen KulturenEs gibt keine "ständigen Anführer"Fazit
Die Subkultur der SoftwareentwicklungGrund 1: Die Software-Entwicklung folgt nicht den üblichen mentalen Modellen für die ErstellungGrund 2: Die Veränderungsrate in IT-Abteilungen ist weitaus höher als anderswoGrund 3: Die Berührungspunkte zwischen Softwareentwicklung und dem Rest der Organisation sind gering und unterschiedlichGrund 4: Die kulturelle Kluft zwischen Softwareentwicklung und dem Rest der Organisation ist bereits akzeptiertBeratung ProzessblasenBlasen sind nur für diejenigen sichtbar, die nach ihnen suchenBlasen ordnen sich selbstBlasen sind durchlässigExterne Erwartungen an diejenigen innerhalb der BlaseSelbstverständliche ErwartungenWeniger eindeutige ErwartungenSprechblasen bieten eine von der Implementierung unabhängige SchnittstelleDer Schnittstellenvertrag der BlaseErkläre die wertvolle ÜbersetzungsarbeitWachsende BlasenInkrementelles Wachstum, Team für TeamSicherstellen, dass du die Kernziele deines Architekturbüros schütztBlasen aufteilen, wenn sie zu groß werdenNichts kann ewig wachsenTeile eine Blase, wenn die Kernziele deines Architekturbüros bedroht sindWie du deine Blase aufteilstÜber Blasen hinweg ausgerichtet bleibenSchutz und Förderung von Unterschieden zwischen BlasenFazit

Content preview from Erleichterung der Software-Architektur

Über den Autor

Andrew Harmel-Law ist Tech Principal bei Thoughtworks und spezialisiert auf Domain-Driven Design, Org-Design, Software- und Systemarchitektur, Agile Delivery, Build-Tools und Automatisierung. Seine Erfahrung erstreckt sich über den gesamten Lebenszyklus der Softwareentwicklung und viele Branchen.

Andrew ist auch Autor und Trainer für O'Reilly. Er hat nicht nur dieses Buch über die Vereinfachung der Softwarearchitektur geschrieben, sondern auch ein Kapitel über die Umsetzung der vier Accelerate/DORA-Schlüsselmetriken. Andrew führt außerdem regelmäßig Online-Schulungen wie "Domain-Drive Design (First Steps)" und "Architecture Decision Making by Example" durch. Was Andrew motiviert, ist die menschenwürdige Bereitstellung und nachhaltige Entwicklung von großen Softwarelösungen, die komplexe Nutzerbedürfnisse erfüllen. Andrew weiß, dass Menschen, Architektur, Prozesse und Werkzeuge dabei eine wichtige Rolle spielen. Andrew hat eine große Leidenschaft für Open Source Software und ihre Gemeinschaften. Andrew ist seit Beginn seiner Karriere mehr oder weniger stark in OSS involviert, sei es als Nutzer, Mitwirkender, Mitglied einer Expertengruppe oder bezahlter Fürsprecher - vor allem als einer der Gründer von Jenkins JobDSL.

Andrew teilt seine Erfahrungen gerne so weit wie möglich. Dies geschieht nicht nur durch formelle Beratertätigkeiten, sondern auch informell durch Mentoring, Blogbeiträge, Konferenzen (Keynotes, Vorträge und Organisation) und Open-Sourcing ihres Codes. ...