Handbuch moderner Softwarearchitektur E-Book

Mark Richards

• Herausgeber: O'Reilly
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2020

Seitenzahl: 533

Beschreibung

Softwarearchitektur zeitgemäß und pragmatisch geplant

• Architektonische Muster: Das technische Fundament für viele architektonische Entscheidungen
• Komponenten: Identifizierung, Kopplung, Kohäsion, Partitionierung und Granularität
• Architekturstile wie Microkernel, SOA, Microservices u.v.m. und ihre architektonischen Eigenschaften
• Softwarearchitektur als Engineering-Disziplin: mit wiederhol- und messbaren Ergebnissen zu stabilen Architekturen

Mark Richards und Neal Ford — Praktiker mit Erfahrung aus erster Hand, die seit Jahren das Thema Softwarearchitektur unterrichten —, betrachten Softwarearchitektur vor dem Hintergrund der Entwicklungen, Innovationen und Herausforderungen des letzten Jahrzehnts. Sie konzentrieren sich auf Architekturprinzipien, die für alle Technologie-Stacks gelten.
Angehende und erfahrene Architekten finden in diesem Buch umfassende Informationen zu architektonischen Merkmalen und Architekturstilen, zur Bestimmung von Komponenten, zur Diagrammerstellung und Präsentation, zu evolutionärer Architektur und vielen weiteren Themen.
Die Autoren verstehen Softwarearchitektur als Engineering-Disziplin: mit wiederhol- und messbaren Ergebnissen und konkreten Kennzahlen für stabile Softwarearchitekturen.

Leseprobe

Lob für »Handbuch moderner Softwarearchitektur«

Neal und Mark sind nicht nur herausragende Softwarearchitekten, sondern auch außergewöhnliche Lehrer. Mit »Handbuch moderner Softwarearchitektur« haben sie es geschafft, das weite Thema der Architektur zu einem umfassenden Werk zu kondensieren, das eine jahrzehntelange Erfahrung widerspiegelt. Unabhängig davon, ob Sie neu in der Rolle sind oder bereits viele Jahre als Architekt arbeiten – dieses Buch wird Ihnen helfen, Ihren Job noch besser zu machen. Ich hätte nur gehofft, dieses Buch wäre früher in meiner Laufbahn geschrieben worden.

– Nathaniel Schutta, Architect as a Service, ntschutta.io

Mark und Neal haben sich aufgemacht, ein großes Ziel zu erreichen – die vielschichtigen Grundlagen zu erklären, die nötig sind, um überragende Ergebnisse in der Softwarearchitektur zu erreichen –, und sie haben ihre Aufgabe gemeistert. Das Feld der Softwarearchitektur entwickelt sich ständig weiter, und die Rolle erfordert eine Unmenge an Wissen und Fähigkeiten. Dieses Buch wird über Jahre vielen, die auf dem Weg sind, die Softwarearchitektur zu meistern, als Richtschnur dienen.

– Rebecca J. Parsons, CTO, ThoughtWorks

Mark und Neal ist es gelungen, Ratschläge aus der echten Welt zusammenzutragen, die Technologen zu Spitzenleistungen in der Architektur anspornen. Das gelingt ihnen, indem sie die wichtigsten Vor- und Nachteile von Architekturen identifizieren, die für den Erfolg nötig sind.

– Cassie Shum, Technical Director, ThoughtWorks

Zu diesem Buch – sowie zu vielen weiteren O’Reilly-Büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei oreilly.plus+:

www.oreilly.plus

Handbuch modernerSoftwarearchitektur

Architekturstile, Patterns und Best Practices

Mark Richards und Neal Ford

Deutsche Übersetzung vonJørgen W. Lang

Mark Richards und Neal Ford

Lektorat: Ariane Hesse

Übersetzung: Jørgen W. Lang

Fachliche Unterstützung: Benjamin Schmid, Oliver Starke

Korrektorat: Claudia Lötschert, www.richtiger-text.de

Satz: III-satz, www.drei-satz.de

Herstellung: Stefanie Weidner

Umschlaggestaltung: Michael Oréal, www.oreal.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print   978-3-96009-149-3

PDF    978-3-96010-429-2

ePub   978-3-96010-430-8

mobi   978-3-96010-431-5

1. Auflage 2021

Translation Copyright © 2021 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Authorized German translation of the English edition of Fundamentals of Software Architecture ISBN 9781492043454 © 2020 Mark Richards, Neal Ford. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

Dieses Buch erscheint in Kooperation mit O’Reilly Media, Inc. unter dem Imprint »O’REILLY«. O’REILLY ist ein Markenzeichen und eine eingetragene Marke von O’Reilly Media, Inc. und wird mit Einwilligung des Eigentümers verwendet.

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Die Informationen in diesem Buch wurden mit größter Sorgfalt erarbeitet. Dennoch können Fehler nicht vollständig ausgeschlossen werden. Verlag, Autoren und Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für eventuell verbliebene Fehler und deren Folgen.

5 4 3 2 1 0

Inhalt

Vorwort: Axiome infrage stellen

1Einleitung

Softwarearchitektur definieren

Erwartungen an Architekten

Architekturentscheidungen treffen

Kontinuierliche Analyse der Architektur

Bei aktuellen Trends auf dem Laufenden bleiben

Sicherstellen, dass Entscheidungen eingehalten werden

Vielfältige Kenntnisse und Erfahrungen

Wissen in der Fachdomäne des Problems

Fähigkeiten im zwischenmenschlichen Umgang

Politik verstehen und sich in dieser Sqhäre bewegen können

Überschneidungen von Architektur und …

Engineering-Praktiken

Technischer Betrieb/DevOps

Prozess

Daten

Gesetze der Softwarearchitektur

Teil IGrundlagen

2Architektonisches Denken

Architektur und Design im Vergleich

Technische Breite

Vor- und Nachteile analysieren

Geschäftliche Faktoren verstehen

Die Balance zwischen Architektur und tatsächlichem Programmieren

3Modularität

Definition

Modularität messen

Kohäsion

Kopplung

Abstraktheit, Instabilität und Entfernung von der Hauptsequenz

Entfernung von der Hauptsequenz

Konnaszenz

Kopplungs- und Konnaszenzmetriken vereinheitlichen

Von Modulen zu Komponenten

4Definition architektonischer Eigenschaften

Architektonische Eigenschaften, eine (unvollständige) Liste

Betriebsrelevante architektonische Eigenschaften

Strukturelle architektonische Eigenschaften

Bereichsübergreifende architektonische Eigenschaften

Kompromisse und am wenigsten schlechte Architektur

5Architektonische Eigenschaften ermitteln

Architektonische Eigenschaften aus domänenspezifischen Anforderungen ableiten

Architektonische Eigenschaften aus funktionalen Anforderungen ableiten

Fallstudie: Silicon Sandwiches

Explizite Eigenschaften

Implizite Eigenschaften

6Messung und Governance von architektonischen Eigenschaften

Architektonische Eigenschaften messen

Betriebsrelevante Metriken

Strukturelle Metriken

Prozessbasierte Metriken

Governance und Fitnessfunktionen

Governance für architektonische Eigenschaften

Fitnessfunktionen

7Anwendungsbereich architektonischer Eigenschaften

Kopplung und Konnaszenz

Architektonische Quanten und Granularität

Fallstudie: Going, Going, Gone (»Zum Ersten, zum Zweiten und zum Dritten«)

8Komponentenbasiertes Denken

Anwendungsbereiche für Komponenten

Die Rolle des Architekten

Architektonische Partitionierung

Fallstudie: Partitionierung für Silicon Sandwiches

Die Rolle des Entwicklers

Arbeitsablauf zur Ermittlung der Komponenten

Anfängliche Komponenten ermitteln

Anforderungen auf Komponenten abbilden

Rollen und Verantwortlichkeiten analysieren

Architektonische Eigenschaften analysieren

Komponenten restrukturieren

Komponentengranularität

Komponentendesign

Sinnvolle Komponentenaufteilung ermitteln

Fallstudie: Going, Going, Gone: Komponenten ermitteln

Rückblick auf das architektonische Quantum: Die Wahl zwischen monolithischen und verteilten Architekturen

Teil IIArchitekturstile

9Architekturstile

Grundmuster

Big Ball of Mud (Der »große Matschklumpen«)

Eingliedrige Architektur

Client/Server

Monolithische und verteilte Architekturen

Irrtum Nr. 1: Das Netzwerk ist verlässlich

Irrtum Nr. 2: Die Latenz ist gleich null

Irrtum Nr. 3: Die Bandbreite ist unendlich

Irrtum Nr. 4: Das Netzwerk ist sicher

Irrtum Nr. 5: Die Topologie ändert sich nie

Irrtum Nr. 6: Es gibt nur einen Administrator

Irrtum Nr. 7: Die Transportkosten sind gleich null

Irrtum Nr. 8: Das Netzwerk ist homogen

Weitere Überlegungen zum verteilten Rechnen

10Der schichtbasierte Architekturstil

Topologie

Voneinander isolierte Schichten

Schichten hinzufügen

Zusätzliche Überlegungen

Gründe für den schichtbasierten Architekturstil

Bewertung der architektonischen Eigenschaften

11Pipeline-Architekturstil

Topologie

Pipes

Filter

Beispiel

Bewertung der architektonischen Eigenschaften

12Microkernel-Architekturstil

Topologie

Kernsystem

Plug-in-Komponenten

Registry

Kontrakte

Beispiele und Anwendungsfälle

Bewertung der architektonischen Eigenschaften

13Servicebasierter Architekturstil

Topologie

Topologische Varianten

Servicedesign und Granularität

Datenbank-Partitionierung

Beispielarchitektur

Bewertung der architektonischen Eigenschaften

Wann man diesen Architekturstil verwenden sollte

14Eventbasierter Architekturstil

Topologie

Broker-Topologie

Mediator-Topologie

Asynchrone Fähigkeiten

Fehlerbehandlung

Datenverlust verhindern

Broadcast-Fähigkeiten

Request-Reply

Request- oder eventbasiert?

Hybride eventbasierte Architekturen

Bewertung der architektonischen Eigenschaften

15»Space-based«-Architekturstil

Allgemeine Topologie

Verarbeitungseinheit

Virtualisierte Middleware

Data Pumps

Data Writer

Data Reader

Datenkollisionen

Cloudbasierte und On-Premises-Implementierungen im Vergleich

Repliziertes Caching im Vergleich mit verteiltem Caching

Überlegungen zu Near-Cache

Implementierungsbeispiele

System zum Verkauf von Veranstaltungstickets

Online-Auktionssysteme

Bewertung der architektonischen Eigenschaften

16Orchestrierter serviceorientierter Architekturstil (SOA)

Geschichte und Philosophie

Topologie

Taxonomie

Dienste für die Geschäftslogik

Unternehmensdienste

Applikationsdienste

Infrastrukturdienste

Orchestrierungs-Engine

Nachrichtenfluss

Wiederverwendbarkeit und Kopplung

Bewertung der architektonische Eigenschaften

17Microservices-Architekturstil

Geschichte

Topologie

Verteilt

Bounded Context

Granularität

Datenisolation

API-Schicht

Betriebliche Wiederverwendung (Operational Reuse)

Frontends

Kommunikation

Choreografie und Orchestrierung

Transaktionen und Sagas

Bewertung der architektonischen Eigenschaften

Weiterführende Referenzen

18Den richtigen Architekturstil auswählen

Architekturstile als »Modeerscheinungen«

Entscheidungskriterien

Monolith-Fallstudie: Silicon Sandwiches

Modularer Monolith

Microkernel

Verteilte Architektur, Fallstudie: Going, Going, Gone

Teil IIITechniken und Soft Skills

19Architekturentscheidungen

Antipatterns für Architekturentscheidungen

Antipattern: Covering your Assets

Antipattern: Groundhog Day

Antipattern: Email-Driven Architecture

Architektonisch wichtig

Architecture Decision Records (ADR)

Grundstruktur

ADRs speichern

ADRs als Dokumentation

ADRs für Standards verwenden

Beispiel

20Architektonische Risiken analysieren

Matrix zur Risikobewertung

Risikobewertung

Risk Storming

Identifizierung

Konsens

Risikoanalyse von Agile Stories

Risk-Storming-Beispiele

Verfügbarkeit

Elastizität

Sicherheit

21Architektur in Diagrammen und Präsentationen visualisieren

Diagramme

Werkzeuge

Standards für Diagramme: UML, C4 und ArchiMate

Richtlinien für die Erstellung von Diagrammen

Präsentieren

Zeit manipulieren

Inkrementeller Aufbau

Infodecks im Vergleich mit Präsentationen

Folien sind nur die Hälfte des Vortrags

Unsichtbarkeit

22Effektive Teams schaffen

Teams den richtigen Rahmen vorgeben

Architekten-Persönlichkeiten

Der Kontrollfreak

Der Sofa-Architekt

Der effektive Architekt

Wie viel Kontrolle?

Warnsignale des Teams

Checklisten einsetzen

Entwickler-Checkliste für die Codefertigstellung

Checkliste für Unit- und funktionales Testing

Software-Release-Checkliste

Orientierung bieten

Zusammenfassung

23Verhandlungsgeschick und Führungsqualitäten

Verhandlung und Moderation

Mit geschäftlichen Entscheidungsträgern verhandeln

Mit anderen Architekten verhandeln

Mit Enwicklern verhandeln

Der Softwarearchitekt als Führungskraft

Die vier Ks der Architektur

Seien Sie pragmatisch, aber visionär

Teams mit gutem Beispiel vorangehen

Abstimmung mit dem Entwicklungsteam

Zusammenfassung

24Eine berufliche Laufbahn entwickeln

Die 20-Minuten-Regel

Ein persönliches Radar entwickeln

Das ThoughtWorks Technology Radar

Open-Source-Visualisierungen

Soziale Medien verwenden

Rat zum Abschied

AFragen zur Selbstbeurteilung

Index

Vorwort: Axiome infrage stellen

Axiom

Eine Aussage oder Behauptung, die als etabliert, akzeptiert und allgemein zutreffend gilt.

Axiome sind die Grundlage für mathematische Theorien. Axiome sind Annahmen über Dinge, die unzweifelhaft wahr sind. Softwarearchitekten erstellen ihre Theorien ebenfalls anhand von Axiomen. Dabei ist die Welt der Software allerdings weicher als die Mathematik: Grundsätze ändern sich mit atemberaubender Geschwindigkeit, inklusive der Axiome, auf denen unsere Theorien basieren.

Das Ökosystem der Sofwareentwicklung befindet sich in einem beständigen dynamischen Gleichgewicht: Betrachtet man es zu einem bestimmten Zeitpunkt, befindet es sich in einem ausbalancierten Zustand; auf lange Sicht zeigt es jedoch ein dynamisches Verhalten. Ein gutes und aktuelles Beispiel für dieses Verhalten ist der Aufstieg der Containerisierung und die damit einhergehenden Veränderungen: Werkzeuge wie Kubernetes (https://kubernetes.io) gab es vor einem Jahrzehnt noch nicht, dennoch werden heute ganze Softwarekonferenze dazu abgehalten. Das Softwareökosystem verändert sich chaotisch: Eine kleine Veränderung bewirkt weitere kleinere Änderungen. Wiederholt man das einige Hundert Mal, entsteht ein neues Ökosystem.

Architekten haben die wichtige Verantwortung, die Annahmen und Axiome vergangener »Zeitalter« infrage zu stellen. Viele Bücher über die Softwarearchitektur wurden in einer Zeit geschrieben, die der heutigen Welt kaum noch ähnelt. Tatsächlich sind die Autoren der Meinung, dass grundsätzliche Axiome regelmäßig infrage gestellt werden müssen, um auf verbesserte Entwicklungspraktiken, betriebliche Ökosysteme und Softwareentwicklungsprosse – alles, was dieses unordentliche dynamische Gleichgewicht ausmacht, in dem Architekten und Entwickler arbeiten – einzugehen.

Betrachtet man die Softwarearchitektur im Laufe der Zeit, kann man eine Evolution der Eigenschaften feststellen. Innovationen wie das Extreme Programming (http://www.extremeprogramming.org), gefolgt von Continuous Delivery, der DevOps-Revolution, Microservices, Containerisierung und den aktuellen Cloud-basierten Ressourcen, haben zu neuen Möglichkeiten, aber auch zu neuen Schwierigkeiten geführt. Durch die veränderten Möglichkeiten änderte sich auch die Sichtweise der Architekten auf die Branche. Für viele Jahre wurde Softwarearchitektur augenzwinkernd als »das Zeug, was später nur schwer zu ändern ist« bezeichnet. Später traten Microservices auf den Plan, bei denen Veränderung eine der wichtigsten Designentscheidungen ist.

Jedes neue Zeitalter erfordert neue Vorgehensweisen, Werkzeuge, Messgrößen, Muster und eine Vielzahl weiterer Änderungen. Dieses Buch betrachtet die Softwarearchitektur in einem modernen Licht und geht dabei auf all die Innovationen des vergangenen Jahrzehnts sowie einige neue Kennzahlen und Messgrößen ein, die zu den heutigen Strukturen und Perspektiven passen.

Entwickler wünschen sich schon lange, dass sich die Sofwareentwicklung von einem künstlerischen Ansatz, bei dem geschickte Künstler einmalige Werke schaffen, zu einer Ingenieursdisziplin wandelt, die von Wiederholbarkeit, Strenge und effektiver Analyse bestimmt wird. Gegenüber der Softwareentwicklung haben andere Ingenieursdisziplinen immer einen um mehrere Größenordnungen weiten Vorsprung (wobei man nicht vergessen sollte, dass die Softwareentwicklung gegenüber anderen Ingenieursdisziplinen noch sehr jung ist). Dennoch haben die Architekten sehr große Verbesserungen erreicht, über die wir hier sprechen werden. Insbesondere haben die agilen Entwicklungspraktiken einen großen Fortschritt ermöglicht, wenn es um die von Architekten erstellten Systemtypen geht.

Außerdem gehen wir auf den besonders wichtigen Punkt der Kompromissanalyse (»Trade-Off analysis«) ein. Als Softwareentwickler legt man sich leicht auf eine bestimmte Technologie oder einen Ansatz fest. Architekten müssen die Vor- und Nachteile jeder Wahl dagegen sehr nüchtern gegeneinander abwägen. In der Realität hat man fast nie die Wahl zwischen schwarz und weiß. Alles ist ein Kompromiss. Aufgrund dieser pragmatischen Sichtweise versuchen wir, Werturteile über Technologien auszuschalten und uns stattdessen auf die Analyse möglicher Kompromisse zu konzentrieren, um unseren Lesern einen analytischen Blick auf die möglichen Technologieentscheidungen zu bieten.

Dieses Buch macht Sie nicht über Nacht zu einem Sofwarearchitekten, denn dieses vielschichtige Spielfeld besitzt viele Facetten. Existierenden und angehenden Architekten wollen wir einen guten und modernen Überblick über die Softwarearchitektur und ihre vielen Aspekte von der Struktur bis hin zu den nötigen Soft Skills bieten. Auch wenn Sie in diesem Buch bekannte Muster finden, verwenden wir hier einen neuen Ansatz. Dieser basiert auf unseren eigenen Erfahrungen, Werkzeugen, Entwicklungspraktiken und weiteren Quellen. Wir betrachten die vielen existierenden Axiome der Softwarearchitektur und denken sie im Licht des aktuellen Ökosystems und der gegenwärtigen Design-Architekturen neu.

Hinweis des Übersetzers

In diesem Buch kommen oft Formulierungen wie »der Architekt« vor. Diese Schreibweise ist selbstverständlich unabhängig vom Geschlecht der jeweiligen Leser/innen, also grundsätzlich als »m/w/d« gemeint.

Konventionen in diesem Buch

Die folgenden typografischen Konventionen werden in diesem Buch genutzt:

Kursiv

Für neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen.

Nichtproportionalschrift

Für Programmlistings, aber auch für Codefragmente in Absätzen, wie zum Beispiel Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter.

Nichtproportionalschrift fett

Zeigt Befehle oder anderen Text an, der genauso vom Benutzer eingegeben werden muss.

Nichtproportionalschrift kursiv

Zeigt Programmcode an, der durch Benutzereingaben oder durch kontextabhängige Werte ersetzt werden soll.

Dieses Zeichen steht für einen Tipp oder eine Empfehlung.

Codebeispiele verwenden

Ergänzungsmaterialien (Codebeispiele, Übungen usw.) stehen zum Download unter https://fundamentalsofsoftwarearchitecture.com bereit.

Dieses Buch soll Ihnen bei Ihrer täglichen Arbeit helfen. Falls Beispielcode zum Buch angeboten wird, dürfen Sie ihn im Allgemeinen in Ihren Programmen und für Dokumentationen verwenden. Sie müssen uns nicht um Erlaubnis bitten, es sei denn, Sie kopieren einen erheblichen Teil des Codes. Wenn Sie zum Beispiel ein Programm schreiben, das einige Codeblöcke aus diesem Buch verwendet, benötigen Sie keine Erlaubnis. Wenn Sie Beispiele aus O’Reilly-Büchern verkaufen oder vertreiben, benötigen Sie eine Erlaubnis. Wenn Sie eine Frage beantworten und dabei dieses Buch oder Beispielcode aus diesem Buch zitieren, brauchen Sie wiederum keine Erlaubnis. Möchten Sie allerdings erhebliche Teile des Beispielcodes aus diesem Buch in die Dokumentation Ihres Produkts einfließen lassen, ist eine Erlaubnis einzuholen.

Wir schätzen eine Quellenangabe, verlangen sie aber nicht. Eine Quellenangabe umfasst in der Regel Titel, Autor, Verlag und ISBN, zum Beispiel: »Handbuch moderner Softwarearchitektur. Architekturstile, Patterns und Best Practices« von Mark Richards und Neal Ford (O’Reilly). 978-3-96009-149-3.«

Wenn Sie der Meinung sind, dass Sie die Codebeispiele in einer Weise verwenden, die über die oben erteilte Erlaubnis hinausgeht, kontaktieren Sie uns bitte unter [email protected].

Danksagungen

Mark und Neal möchten sich bei allen Menschen bedanken, die unsere Kurse, Workshops, Konferenz-Sessions und Usergroup-Treffen besucht haben, sowie bei allen Leuten, die sich verschiedene Versionen dieses Materials angehört und Rückmeldungen von unschätzbarem Wert gegeben haben. Außerdem möchten wir uns beim gesamten O’Reilly-Team bedanken, das das Schreiben dieses Buchs so schmerzfrei wie nur möglich gestaltet hat. Wir möchten uns außerdem bei Jay Zimmerman, dem Direktor von No Stuff Just Fluff dafür bedanken, dass er eine Konferenzreihe gschaffen hat, die es guten technischen Inhalten ermöglicht, zu wachsen und sich zu verbreiten, sowie bei den anderen Sprechern, deren Feedback und tränendurchweichte Schultern wir sehr zu schätzen wissen. Außerdem bedanken wir uns bei verschiedenen Gruppen, die uns dabei halfen, unsere geistige Gesundheit zu bewahren und neue Ideen zu finden. Diese Zufallsoasen tragen Namen wie Pasty Geeks und das Hacker B&B.

Danksagungen von Mark Richards

Zusätzlich zu den oben genannten Danksagungen möchte ich mich bei meiner geliebten Frau Rebecca bedanken. Du hast zu Hause alles andere übernommen und dabei die Gelegenheit geopfert, Dein eigenes Buch zu schreiben, damit ich mehr Beratungstermine wahrnehmen, auf mehr Konferenzen und Trainings sprechen konnte, um so das Material für dieses Buch zu üben und zu verfeinern. Du bist die Beste.

Danksagungen von Neal Ford

Neal möchte sich bei seiner erweiterten Familie bedanken, ThoughtWorks als Kollektiv und Rebecca Parsonsn sowie Martin Fowler als einzelne Teile davon. ThoughtWorks ist eine außergewöhnliche Gruppe, die es schafft, Wert für ihre Kunden zu schaffen, ohne dabei aus den Augen zu verlieren, warum Dinge funktionieren und wie sie verbessert werden können. ThoughtWorks hat dieses Buch auf vielerlei Weise unterstützt und bildet auch weiterhin ThoughtWorker aus, die täglich aufs Neue herausfordern und inspirieren. Neal möchte sich außerdem bei unserem Nachbarschafts-Cocktail-Club für regelmäßige Auszeiten von der Routine bedanken. Abschließend dankt Neal seiner Frau Candy, deren Toleranz für Dinge wie das Schreiben von Büchern und das Sprechen auf Konferenzen scheinbar grenzenlos ist. Seit Jahrzehnten hält sie mich auf dem Boden und gesund genug, um weiter zu funktionieren. Ich hoffe, dass sie auch für weitere Jahrzehnte die Liebe meines Lebens bleiben wird.

Danksagungen von Jørgen W. Lang

Ich möchte mich bei den Autoren bedanken, die mir in kürzester Zeit alle Fragen freundlich und professionell beantwortet und für Klarheit gesorgt haben. Mein größtes Dankschön gilt jedoch meiner Familie, Armelle und Mathis, ohne die ich jetzt vermutlich etwas ganz anderes machen würde.

KAPITEL 1

Einleitung

Die Berufsbezeichnung »Softwarearchitekt« steht auf vielen Listen der besten Jobs auf der ganzen Welt ganz oben. Für die anderen Berufe auf der Liste (zum Beispiel Krankenpfleger oder Finanzmanager) gibt es einen klaren Karrierepfad. Warum gibt es keinen Karrierepfad für Softwarearchitekten?

Zunächst einmal hat die Branche selbst keine gute Definition von Softwarearchitektur. Wenn wir Grundlagenkurse unterrichten, fragen die Studenten oft nach einer klaren Definition für das, was ein Softwarearchitekt tut. Bisher haben wir ihnen diese Antwort hartnäckig verweigert. Und damit sind wir nicht alleine. In seinem berühmten Whitepaper »Who Needs an Architect?« (https://oreil.ly/-Dbzs) weigerte sich Martin Fowler bekanntlich, auch nur zu versuchen, den Begriff »Softwarearchitekt« zu definieren. Stattdessen wich er auf das folgende berühmte Zitat aus:

Bei der Softwarearchitektur geht es um wichtige Dinge … welche auch immer das sind.

– Ralph Johnson

Erst unter Druck haben wir die in Abbildung 1-1 gezeigte Mindmap erstellt. Sie ist hoffnungslos unvollständig, zeigt aber, wie groß das Feld der Softwarearchitektur tatsächlich ist. In Kürze werden wir Ihnen unsere eigene Definition der Softwarearchitektur vorstellen.

Außerdem zeigt die Mindmap, dass die Rolle des Softwarearchitekten sehr viele Verantwortungsbereiche umfasst, die immer weiter wachsen. Noch vor zehn Jahren haben sich Softwarearchitekten nur mit den rein technischen Aspekten der Architektur befasst, wie Modularität, Komponenten und Patterns. Durch neue Architekturstile, die zusätzliche Möglichkeiten (zum Beispiel Microservices) nutzen, hat sich auch die Rolle des Softwarearchitekten erweitert. Die vielen Überschneidungen zwischen der Architektur und dem Rest des Unternehmens betrachten wir in »Überschneidungen von Architektur und …« auf Seite 13.

Durch die fortschreitende Evolution der Softwareentwicklung ist auch die Softwarearchitektur ständig in Bewegung. Jede heute gültige Definition wird schon in ein paar Jahren hoffnungslos veraltet sein. Die Wikipedia-Definition der Softwarearchitektur (https://de.wikipedia.org/wiki/Softwarearchitektur) gibt hier einen guten Überblick.

Abbildung 1-1: Die Verantwortlichkeit eines Softwarearchitekten umfasst technische Fähigkeiten, Soft Skills, Unternehmensbewusstsein und eine Reihe weiterer Aspekte.

Viele Aussagen sind aber auch jetzt schon veraltet – zum Beispiel: »Es ist Aufgabe der Softwarearchitektur, grundlegende strukturelle Entscheidungen zu treffen, deren spätere Änderung sehr kostspielig wären.« Mittlerweile gibt es moderne architektonische Stile, zum Beispiel Microservices, die die Idee der Inkrementierung bereits enthalten. Strukturelle Änderungen in Microservices sind nicht länger teuer. Natürlich hat eine solche Möglichkeit auch Nachteile, zum Beispiel bei der Kopplung. Viele Bücher über Softwarearchitektur behandeln das als statisches Problem. Ist es einmal gelöst, kann man es sicher ignorieren. In diesem Buch vertreten wir dagegen die Meinung, dass Softwarearchitektur grundsätzlich etwas Dynamisches ist – inklusive ihrer Definition.

Darüber hinaus hat ein Großteil der Materialien über Softwarearchitektur nur noch historische Bedeutung. Leser der Wikipediaseite werden die verwirrendende Ansammlung von Akronymen und Querverweisen zu einem ganzen Wissensuniversum bemerkt haben. Allerdings stehen viele dieser Akronyme für veraltete oder fehlgeschlagene Versuche. Selbst Lösungen, die vor einigen Jahren noch absolut gültig waren, können heute nicht mehr funktionieren, weil sich der Kontext verändert hat. Die Geschichte der Softwarearchitektur ist voll von gescheiterten Versuchen von Softwarearchitekten, die abgebrochen wurden, nachdem die schlechten Nebenwirkungen sichtbar wurden. Viele dieser Lehren werden wir in diesem Buch behandeln.

Warum haben wir ausgerechnet jetzt ein Buch über Grundlagen der Softwarearchitektur geschrieben? Die Softwarearchitektur ist schließlich nicht der einzige Bereich der Softwareentwicklung, der andauernden Änderungen unterworfen ist. Ständig gibt es neue Technologien, Techniken, Fähigkeiten … Es ist tatsächlich leichter, die Dinge aufzulisten, die sich in den letzten zehn Jahren nicht verändert haben. Innerhalb dieses hochdynamischen Ökosystems müssen Softwarearchitekten in der Lage sein, Entscheidungen zu treffen. Da alles – inklusive der Grundlagen, auf deren Basis wir Entscheidungen treffen – ständig in Bewegung ist, sollten Architekten die grundlegenden Axiome früherer Publikationen immer wieder überprüfen und infrage stellen. DevOps spielten in früheren Büchern über Softwarearchitektur keine Rolle, weil es sie beim Schreiben dieser Bücher einfach noch nicht gab.

Beim Studium der Softwarearchitektur sollten die Leser sich darüber klar sein, dass sie – wie die Kunst – nur im richtigen Kontext verstanden werden kann. Viele der Entscheidungen von Softwarearchitekten wurden auf Basis der Realitäten getroffen, in denen sie sich gerade befanden. Eines der Hauptziele der Architektur des ausgehenden 20. Jahrhunderts war beispielsweise eine möglichst kosteneffiziente Nutzung verteilter Ressourcen. Damals war die gesamte Infrastruktur sehr teuer und kommerziell: Betriebssysteme, Application Server, Datenbankserver und so weiter. Stellen Sie sich vor, Sie betreten im Jahr 2002 ein Rechenzentrum und sagen dem Betriebsleiter: »Hey, ich habe eine tolle Idee für einen revolutionären Architekturstil. Dabei läuft jeder Dienst inklusive seiner eigenen Datenbank auf einem eigenen isolierten Rechner (was wir heute als Microservices kennen). Das würde bedeuten, wir bräuchten 50 Windows-Lizenzen, weitere 30 Lizenzen für Application Server und mindestens 50 Lizenzen für Datenbankserver.« Der Versuch, eine Architektur wie Microservices zu schaffen, wäre 2002 unermesslich teuer geworden. Durch das Aufkommen von Open-Source-Lösungen zusammen mit neuen Entwicklungspraktiken wie der DevOps-Revolution sind wir inzwischen jedoch in der Lage, eine Architektur wie die beschriebene zu erstellen. Die Leser sollten daher nicht vergessen, dass alle Architekturen ein Produkt ihres Kontexts sind.

Softwarearchitektur definieren

Die gesamte Branche hat sich bisher damit schwergetan, eine präzise Definition für den Begriff »Softwarearchitektur« zu finden. Einige Architekten verstehen darunter den Bauplan eines Systems, während andere sie als Roadmap für die Entwicklung eines Systems definieren. Das Problem mit diesen verbreiteten Definitionen besteht darin, dass man nicht weiß, was der Bauplan oder die Roadmap tatsächlich enthält. Was genau wird beispielsweise analysiert, wenn ein Architekt eine Architektur analysiert?

Abbildung 1-2 zeigt eine Möglichkeit, sich die Softwarearchitektur vorzustellen. In dieser Definition besteht sie aus der Struktur des Systems (dargestellt durch die dicken schwarzen Linien, die die Architektur stützen), kombiniert mit den architektonischen Eigenschaften (bzw. Fähigkeiten, engl. »-ilities«), die das System unterstützen muss, den architektonischen Entscheidungen und schließlich den Designprinzipien.

Abbildung 1-2: Architektur besteht aus Struktur, den architektonischen Eigenschaften (Fähigkeiten), architektonischen Entscheidungen und Designprinzipien

Die in Abbildung 1-3 gezeigte Struktur des Systems bezieht sich auf den Architekturstil (oder die Stile), in dem das System implementiert ist (zum Beispiel als Microservices, schichtbasiertes Modell oder Microkernel). Die Struktur allein reicht aber nicht, um eine Architektur zu beschreiben. Angenommen, ein Architekt soll eine Architektur beschreiben und seine Antwort lautet: »Es ist eine Microservices-Architektur.« In diesem Fall spricht der Architekt nur von der Struktur des Systems, aber nicht von seiner Architektur. Das Wissen um die architektonischen Eigenschaften, Entscheidungen und Designprinzipien ist genauso wichtig, um die Architektur eines Systems vollständig zu verstehen.

Die architektonischen Eigenschaften bilden eine weitere Dimension in der Definition einer Softwarearchitektur (siehe Abbildung 1-4). Die architektonischen Eigenschaften definieren die Erfolgskriterien eines Systems. Sie stehen üblicherweise senkrecht zur Systemfunktionalität. Beachten Sie, dass für sämtliche aufgelisteten Eigenschaften kein Wissen über die Systemfunktionalität notwendig ist. Dennoch werden sie gebraucht, damit das System korrekt funktioniert. Die architektonischen Eigenschaften sind so wichtig, dass wir ihrer Definition und ihrem Verständnis mehrere Kapitel dieses Buchs gewidmet haben.

Abbildung 1-3: Die Struktur zeigt, welcher Typ des architektonischen Stils im System verwendet wird.

Abbildung 1-4: Architektonische Eigenschaften beziehen sich auf die Fähigkeiten, die das System unterstützen muss.

Der nächste Faktor, der eine Softwarearchitektur definiert, sind die Architekturentscheidungen. Architektonische Entscheidungen definieren die Regeln, nach denen ein System konstruiert wird. So könnte ein Architekt beispielsweise die Entscheidung treffen, dass nur die Business- und Service-Schichten innerhalb einer schichtbasierten Architektur auf die Datenbank zugreifen können (siehe Abbildung 1-5). Damit soll zum Beispiel verhindert werden, dass die Präsentationsschicht direkte Datenbankaufrufe durchführt. Architektonische Entscheidungen definieren die Beschränkungen eines Systems, dienen als Rahmen für die Entwicklungsteams und zeigen ihnen an, welche Dinge erlaubt sind und welche nicht.

Abbildung 1-5: Architektonische Entscheidungen sind Regeln für die Konstruktion eines Systems.

Kann eine architektonische Entscheidung aufgrund bestimmter Bedingungen oder Beschränkungen in einem Systemsteil nicht umgesetzt werden, kann diese Entscheidung (oder Regel) durch die sogenannte Varianz gebrochen werden. In den meisten Unternehmen gibt es Varianzmodelle, die von einem Architektur-Prüfungsgremium (Architecture Review Board, ARB) oder einem Chefarchitekten eingesetzt werden können. Eine Ausnahme für eine bestimmte Architekturentscheidung wird vom ARB (oder dem Chefarchitekten, falls es kein ARB gibt) analysiert und basierend auf den Begründungen und möglichen Vor- und Nachteilen entweder genehmigt oder abgelehnt.

Der letzte Faktor bei der Definition einer Architektur sind die Designprinzipien. Der Unterschied zwischen einem Designprinzip und einer Architekturentscheidung besteht darin, dass ein Designprinzip eher eine Richtlinie als eine strenge und unverrückbare Regel darstellt. Das in Abbildung 1-6 gezeigte Designprinzip besagt beispielsweise, dass die Entwicklungsteams möglichst asynchrones Messaging für die Kommunikation zwischen den Diensten verwenden sollen, um die Performance zu steigern. Eine architektonische Entscheidung (Regel) könnte niemals alle Bedingungen und Optionen für die Kommunikation zwischen den Diensten abdecken. Hier kann ein Designprinzip helfen, um Richtlinien für die bevorzugte Methode (hier das asynchrone Messaging) aufzustellen. Auf diese Weise können Entwickler ggf. ein passenderes Kommunikationsprotokoll (zum Beispiel REST oder gRPC) wählen.

Abbildung 1-6: Designprinzipien sind Richtlinien für die Konstruktion von Systemen.

Erwartungen an Architekten

Die Definition der Rolle eines Softwarearchitekten gestaltet sich genauso schwierig wie die Definition der Softwarearchitektur selbst. Dabei kann es sich um einen erfahrenen Programmierer handeln oder um eine Person, die die strategisch-technische Richtung eines Unternehmens definiert. Anstatt mit der Definition der Rolle Zeit zu verschwenden, empfehlen wir Ihnen, sich auf die Erwartungen an einen Architekten zu konzentrieren.

Unabhängig von einer bestimmten Rolle, einem Titel oder einer Jobbeschreibung gibt es acht grundsätzliche Erwartungen an einen Softwarearchitekten:

Architekturentscheidungen treffen

Beständige Analyse der Architektur

Bei den neuesten Trends auf dem Laufenden bleiben

Sicherstellen, dass Entscheidungen eingehalten werden

Vielfältige Kenntnisse und Erfahrungen besitzen

Erfahrung im geschäftlichen Umfeld haben

Fähigkeiten im zwischenmenschlichen Umgang besitzen

Politik verstehen und sich in dieser Sqhäre bewegen können

Der Schlüssel zu Effektivität und Erfolg in der Rolle eines Softwarearchitekten hängt davon ab, alle diese Erwartungen zu verstehen und zu erfüllen.

Architekturentscheidungen treffen

Von einem Architekten wird erwartet, die architektonischen Entscheidungen und Designprinzipien festzulegen, die als Leitfaden (engl. »guide«) für die technologischen Entscheidungen innerhalb des Teams, der Abteilung oder im gesamten Unternehmen dienen.

Das Vorgeben einer Richtung spielt für die erste Erwartung die wichtigste Rolle. Ein Architekt sollte Technologieentscheidungen anleiten, anstatt sie zu bestimmen. Ein Architekt könnte beispielsweise entscheiden, React.js für die Frontend-Entwicklung einzusetzen. Statt einer Architekturentscheidung oder eines Designprinzips, das dem Entwicklungsteam für seine Auswahl eine Richtung vorgibt, trifft der Architekt hier eine technologische Entscheidung. In diesem Fall ist es besser, wenn der Architekt dem Entwicklungsteam vorgibt, ein auf reaktiven Prinzipien basierendes Framework für die Entwicklung von Web-Frontends zu verwenden. Dadurch gibt der Architekt dem Entwicklungsteam die Möglichkeit, selbst zu entscheiden, ob nun Angular, Elm, React, Vue oder ein anderes »reaktives« Web-Framework verwendet werden soll.

Die Vorgabe einer Richtung für technologische Wahlmöglichkeiten anhand architektonischer Entscheidungen und Designprinzipien ist schwierig. Damit das effektiv funktioniert, muss man sich fragen, ob die Architekturentscheidung dabei hilft, den Teams eine Richtung vorzugeben, die sie dabei unterstützt, die richtige technische Wahl zu treffen, oder ob die architektonische Entscheidung diese Wahl trifft. Manchmal ist es trotztdem nötig, dass ein Architekt klare technologische Vorgaben macht, um bestimmte architektonische Eigenschaften wie Skalierbarkeit, Performance oder Verfügbarkeit sicherzustellen. In diesem Fall würde man trotzdem von einer Architekturentscheidung sprechen, obwohl eine bestimmte Technologie vorgegeben wird. Es ist für Architekten nicht immer einfach, die richtige Grenze zu finden, daher geht es in Kapitel 19 nicht ausschließlich um Architekturentscheidungen.

Kontinuierliche Analyse der Architektur

Von Architekten wird erwartet, dass sie die Architektur und die Architekturentscheidungen Umgebung laufend analysieren und Lösungen für ihre Verbesserung anbieten.

Diese Erwartung an Architekten bezieht sich auf die Architekturvitalität. Dabei wird auf Basis der geschäftlichen und technologischen Veränderungen überprüft, wie gültig eine vor drei oder mehr Jahren definierte Architektur heute noch ist. Unserer Erfahrung nach konzentrieren zuwenige Architekten ihre Energie auf die beständige Analyse bereits vorhandener Architekturen. Bei den meisten Architekturen führt das zu strukturellem Verfall. Dieser tritt auf, wenn Entwickler Änderungen an Code oder Design vornehmen, die sich auf die nötigen architektonischen Eigenschaften wie Performance, Verfügbarkeit und Skalierbarkeit auswirken.

Andere Aspekte dieser Erwartung, die Architekten oft vergessen, sind Testing und Release-Umgebungen. Agilität hat für Änderungen am Code offensichtliche Vorteile. Wenn Teams allerdings Wochen zum Testen und Monate für ein Release benötigen, dann können Architekten in der Gesamtarchitektur keine Agilität erreichen.

Architekten brauchen eine ganzheitliche Denkweise. Sie müssen Veränderungen in Technologie und Problembereichen analysieren, um die Stabilität der Architektur zu ermitteln. Diese Anforderungen sieht man in Stellenangeboten jedoch nur selten. Dennoch müssen Architekten diese Erwartung erfüllen, damit ihre Bewerbung relevant bleibt.

Bei aktuellen Trends auf dem Laufenden bleiben

Von Architekten wird erwartet, dass sie die aktuellsten technologischen und Branchentrends im Auge behalten.

Entwickler müssen bei den neuesten Technologien, die sie täglich benutzen, stets auf dem neuesten Stand sein, um relevant zu bleiben (und ihren Job zu behalten!) Für Architekten ist es noch wichtiger, die aktuellen technischen Fortschritte und Entwicklungen ihrer Branche im Auge zu behalten. Schließlich haben die Entscheidungen von Architekten meist langfristige Auswirkungen und sind nachträglich schwer zu ändern. Das Verständnis und Verfolgen von Schlüsseltrends hilft Architekten, sich auf die Zukunft vorzubereiten und die richtigen Entscheidungen zu treffen.

Dabei ist es nicht einfach, diese Trends immer im Auge zu behalten, besonders für Softwarearchitekten. Daher besprechen wir in Kapitel 24 verschiedene Techniken und Möglichkeiten, dies zu tun.

Sicherstellen, dass Entscheidungen eingehalten werden

Von Architekten wird erwartet, sicherzustellen, dass architektonische Entscheidungen und Designprinzipien eingehalten werden (Compliance).

Das Sicherstellen der Compliance bedeutet, dass Architekten beständig überprüfen müssen, ob die Entwicklungsteams den von ihnen getroffenen, dokumentierten und kommunizierten architektonischen Entscheidungen und Designprinzipien folgen. Angenommen, ein Architekt entscheidet, in einer schichtbasierten Architektur den Datenbankzugriff nur für die Business- und Serviceschicht zu erlauben (aber nicht für die Präsentationsschicht). Das heißt, die Präsentationsschicht muss alle Schichten der Architektur durchlaufen, um selbst die einfachsten Datenbankaufrufe durchzuführen. Ein UI-Entwickler könnte diese Entscheidung missbilligen und aus Performance-Gründen versuchen, trotzdem direkt auf die Datenbank (oder die Persistenzschicht) zuzugreifen. Der Architekt hat die Entscheidung aber aus einem bestimmten Grund getroffen: um Änderungen kontrollieren zu können. Durch die Isolierung der einzelnen Schichten können Änderungern an der Datenbank vorgenommen werden, ohne dabei die Präsentationsschicht zu beeinflussen. Wird nicht auf die Einhaltung dieser Architekturentscheidungen geachtet, können Verstöße wie dieser auftreten. Das führt dazu, dass die Architektur nicht die erforderlichen architektonischen Eigenschaften (Fähigkeiten) erfüllt, wodurch die Architektur oder das System nicht wie erwartet funktioniert.

In Kapitel 6 sprechen wir darüber, wie die Compliance mithilfe automatischer Fitnessfunktionen und anderer Werkzeuge überprüft werden kann.

Vielfältige Kenntnisse und Erfahrungen

Von Architekten wird erwartet, dass sie Kenntnisse und Erfahrungen mit vielfältigen und verschiedenen Technologien, Frameworks, Plattformen und Umgebungen besitzen.

Diese Erwartung bedeutet nicht, dass Architekten Experten für jedes Framework, jede Plattform oder Sprache sein müssen. Dennoch sollten sie mit einer Reihe verschiedener Technologien vertraut sein. Die meisten Umgebungen sind heutzutage heterogen. Daher sollten Architekten zumindest wissen, wie auf verschiedene Systeme und Dienste unabhängig von Sprache, Plattform und Technologie zugegriffen werden kann.

Einer der besten Wege, diese Erwartung zu meistern, besteht darin, dass Architekten ihre Komfortzone erweitern. Die Konzentration auf nur eine bestimmte Technologie bietet nur vermeintliche Sicherheit. Effektive Softwarearchitekten sollten offensiv nach Gelegenheiten suchen, Erfahrungen mit verschiedenen Sprachen, Plattformen und Technologien zu sammeln. Dabei bietet es sich an, sich auf technische Breite (»technical breadth«) anstelle von technischer Tiefe (»technical depth«) zu konzentrieren. Zu technischer Breite gehören Dinge, zu denen sie etwas wissen, ohne jedes Detail zu kennen. Für Architekten ist es beispielsweise viel wertvoller, die Vor- und Nachteile von 10 verschiedenen Caching-Lösungen zu kennen, als für jede dieser Lösungen ein Experte zu sein.

Wissen in der Fachdomäne des Problems

Von Architekten wird erwartet, dass sie über ein gewisses Maß an Fachwissen im geschäftlichen Umfeld verfügen.

Effektive Softwarearchitekten verstehen nicht nur die Technologie, sondern auch den geschäftlichen Teil eines Problemraums. Ohne geschäftliches Wissen ist es nicht einfach, die geschäftlichen Probleme, Ziele und Anforderungen zu verstehen. Das erschwert es, eine effektive Architektur zu entwerfen, die auch die Businessanforderungen erfüllt. Stellen Sie sich vor, Sie sind Architekt für eine Großbank, ohne zu wissen, was gängige Fachbegriffe wie der durchschnittliche Richtungsindex (»average directional index«, ADX), aleatorische Verträge, Kursrallye oder auch nicht vorrangige Schulden (»nonpriority debt«) bedeuten. Ohne dieses Wissen kann ein Architekt nicht mit Entscheidungsträgern und geschäftlichen Nutzern kommunizieren, und er verliert schnell seine Glaubwürdigkeit.

Die erfolgreichsten Architekten, die wir kennen, haben ein breites technisches Wissen und Erfahrungen aus erster Hand, gekoppelt mit einem tiefen Verständnis für eine bestimmte Domäne. Diese Softwarearchitekten können effektiv mit Führungskräften und geschäftlichen Nutzern kommunizieren, indem sie ihr geschäftliches Wissen einsetzen und die gleiche Sprache sprechen wie diese Stakeholder. Das schafft wiederum ein großes Vertrauen in die Fähigkeiten der Architekten und vermittelt den Eindruck, dass sie wissen, was sie tun, und kompetent genug sind, eine effektive und korrekte Architektur zu schaffen.

Fähigkeiten im zwischenmenschlichen Umgang

Von Architekten wird erwartet, dass sie über außergewöhnliche Fähigkeiten im Umgang mit Menschen verfügen, inklusive Teamwork, Moderation und Führung.

Für die meisten Entwickler und Architekten ist der Besitz außergewöhnlicher Führungs- und zwischenmenschlicher Fähigkeiten eine schwierige Erwartung. Schließlich wollen Technologen, Entwickler und Architekten technische Probleme lösen und keine menschlichen. Aber, wie Gerald Weinberg (https://oreil.ly/wyDB8) einmal gesagt hat: »Egal, was sie euch erzählen, es ist immer ein menschliches Problem.« Ein Architekt muss nicht nur das Team technisch anleiten, sondern auch die Entwicklungsteams durch die Implementierung der Architektur führen. Führungskompetenz macht mindestens die Hälfte dessen aus, was effektive Softwarearchitekten ausmacht – unabhängig von deren Rolle oder ihrer Berufsbezeichnung.

Die Branche ist überflutet mit Softwarearchitekten, die um eine begrenzte Anzahl von Architektur-Arbeitsplätzen konkurrieren. Gute Führungsqualitäten und zwischenmenschliche Fähigkeiten sind ein guter Weg, sich von anderen Architekten zu unterscheiden und von der Masse abzuheben. Wir kannten viele Softwarearchitekten, die ausgezeichnete Technologen, aber ineffiziente Architekten waren, weil ihnen die Fähigkeit fehlte, Teams zu leiten, Entwickler zu fördern und anzuleiten, oder weil sie nicht in der Lage waren, Ideen, Architekturentscheidungen und Grundsätze effektiv zu kommunizieren. Es verwundert nicht, dass diese Architekten es nicht leicht hatten, ihren Job zu behalten.

Politik verstehen und sich in dieser Sqhäre bewegen können

Von Architekten wird erwartet, dass sie das politische Klima im Unternehmen verstehen und in der Lage sind, sich darin zu bewegen.

Es mag seltsam erscheinen, in einem Buch über Softwarearchitektur über das Verhandeln und den Umgang mit der Geschäftspolitik zu schreiben. Um zu illustrieren, wie wichtig und nötig Verhandlungsgeschick sein kann, stellen Sie sich ein Szenario vor, in dem ein Entwickler entscheidet, das Strategie-Entwurfsmuster (https://de.wikipedia.org/wiki/Strategie_(Entwurfsmuster)) einzusetzen, um die zyklomatische Gesamtkomplexität eines bestimmten Codeteils zu verringern. Wen kümmert das? Man könnte den Entwickler für den Einsatz eines solches Musters loben, aber in den meisten Fällen braucht der Entwickler für eine solche Entscheidung keine Erlaubnis einzuholen.

Und jetzt stellen Sie sich ein Szenario vor, in dem ein Architekt für ein großes Kundenmanagementsystem zuständig ist. Es kommt zu Problemen beim Datenbankzugriff von anderen Systemen, beim Sichern bestimmter Kundendaten und beim Anpassen von Datenbank-Schemata, weil zu viele andere Systeme die CRM-Datenbank ebenfalls verwenden. Also entscheidet der Architekt, sogenannte Application Silos einzusetzen, wobei jede Applikationsdatenbank nur für die Applikation zugänglich ist, der die Datenbank gehört. Durch diese Entscheidung erhält der Architekt bessere Kontrolle über die Kundendaten, die Sicherheit und das Änderungsmanagement. Im Gegensatz zum vorigen Entwicklerszenario wird diese Entscheidung von fast allen Beteiligten im Unternehmen infrage gestellt (mit der möglichen Ausnahme des CRM-Applikationsteams, versteht sich). Andere Applikationen müssen ebenfalls auf die Kundendaten zugreifen können. Ist das nicht mehr auf direktem Wege möglich, müssen die Daten beim CRM-System angefordert werden. Dafür sind entfernte Aufrufe über REST, SOAP oder ein anderes Protokoll für entfernte Zugriff nötig.

Die Hauptaussage hierbei ist, dass fast alle Entscheidungen des Architekten infrage gestellt werden. Product Owner, Projektmanager und andere Stakeholder des Unternehmens werden Architekturentscheidungen aufgrund erhöhter Kosten und eines größeren Aufwands (Zeit) zumindest kritisch hinterfragen. In beiden Fällen muss sich der Architekt innerhalb der Firmenpolitik bewegen und grundsätzliches Verhandlungsgeschick einsetzen können, um seine Entscheidungen genehmigt zu bekommen. Das kann für Softwarearchitekten sehr frustrierend sein, zumal die meisten Entscheidungen eines Entwicklers keine Genehmigung und manchmal nicht einmal eine Überprüfung benötigen. Programmieraspekte wie die Codestruktur, das Klassendesign, die Wahl der Entwurfsmuster und manchmal sogar die Wahl der Programmiersprache selbst sind Teil der Kunst der Programmierung. Trotzdem muss ein Architekt, der jetzt in der Lage ist, weitreichende und wichtige Entscheidungen zu treffen, fast jede dieser Entscheidungen rechtfertigen und sie verteidigen. Verhandlungsgeschick und Führungsqualitäten sind so wichtig, dass wir ihnen ein komplettes eigenes Kapitel gewidmet haben (siehe Kapitel 23).

Überschneidungen von Architektur und …

Der Bereich der Softwarearchitektur ist in den vergangenen zehn Jahren stetig gewachsen und bedarf heutzutage mehr Verantwortung und Voraussicht denn je. Noch vor einem Jahrzehnt war die Beziehung zwischen Architektur und Geschäft stark formalisiert und von einer Menge Bürokratie geprägt. Die meisten Unternehmen versuchten, die Komplexität selbst gehosteter Dienste zu vermeiden. Der technische Betrieb wurde dabei häufig an externe Dienstleister ausgelagert. Bezogen auf die Dienste musste dieser sich an vertragliche Verpflichtungen zu Uptime, Skalierung, Antwortzeiten und einer Menge anderer architektonischer Merkmale halten. Heutzutage lassen sich diese rein operativen Dinge durch Architekturstile wie etwa Microservices frei umsetzen. So war Elastic Scale früher auf schmerzhafte Weise in Architekturen integriert (siehe Kapitel 15), während Microservices diese Aufgabe durch eine Verbindung zwischen Architekten und DevOps mit deutlich weniger Aufwand lösten.

Geschichte: Pets.com Warum wir elastische Skalierung verwenden

Die Geschichte der Softwareentwicklung ist voll von Lektionen – guten wie schlechten. Wir gehen davon aus, dass die heutigen Fähigkeiten (zum Beispiel Elastic Scale) einfach irgendwann aufgetaucht sind, weil irgendein schlauer Entwickler eine Idee hatte. Tatsächlich ging vielen dieser Ideen oft eine harte Lektion voraus. Pets.com war hierfür ein frühes Beispiel. Das Unternehmen entstand in der Frühzeit des Web und hoffte darauf, das Amazon.com für Tierbedarf zu werden. Zum Glück hatte Pets.com eine ausgezeichnete Marketingabteilung, die ein unwiderstehliches Maskottchen erfand: eine Handpuppe mit einem Mikrofon, die respektlose Dinge sagte. Dieses Maskottchen wurde ein Superstar und hatte öffentliche Auftritte bei Paraden und landesweiten Sportveranstaltungen.

Leider hat das Management von Pets.com das ganze Geld für das Maskottchen ausgegeben und nicht für die Infrastruktur. Sie waren nicht vorbereitet, als die Bestellungen reinkamen. Die Website war langsam, Transaktionen gingen verloren, Lieferungen waren verzögert und so weiter … so ziemlich das Schlimmste, was passieren konnte. Es war sogar so schlimm, dass das Unternehmen kurz nach einem katastrophalen Ansturm durch das Weihnachtsgeschäft schließen musste. Der einzige verbleibende Vermögenswert (das Maskottchen) wurde an einen Konkurrenten verkauft.

Elastic Scaling hätte dem Unternehmen helfen können, also die Fähigkeit, bei Bedarf zusätzliche Instanzen einer Ressource hochzufahren. Inzwischen kann man diese Fähigkeit bei Cloud-Anbietern standardmäßig zubuchen. In den frühen Tagen des Web mussten Unternehmen jedoch ihre eigene Infrastruktur bereitstellen. Dabei fiel eine große Zahl einem bis dahin unbekannten Phänomen zum Opfer: Erfolg kann das Geschäft zerstören. Pets.com und andere Horrorgeschichten brachten Ingenieure dazu, die Frameworks zu entwickeln, die Architekten heute einsetzen.

In den folgenden Abschnitten beschäftigen wir uns mit einigen der neueren Überschneidungen von der Rolle des Architekten und anderen Geschäftsbereichen. Dabei gehen wir besonders auf neue Anforderungen und Verantwortungsbereiche für Architekten ein.

Engineering-Praktiken

Ursprünglich waren Softwarearchitektur und der Entwicklungsprozess voneinander getrennt. Es gibt Dutzende beliebter Methoden, Software zu erstellen. Hierzu gehören Dinge wie Waterfall, verschiedene Agile-Geschmacksrichtungen (inklusive Scrum, Extreme Programming, Lean und Crystal), die aber nur selten einen Einfluss auf die Softwarearchitektur haben.

In den vergangenen Jahren haben Fortschritte in der Entwicklungspraxis aber dazu geführt, dass Softwarearchitekten sich auch mit Aspekten der Vorgehensweise in der Entwicklung beschäftigen müssen. Dabei ist es sinnvoll, den Prozess der Softwareentwicklung von den Entwicklungspraktiken zu trennen. Mit »Prozess« meinen wir, wie Teams zusammgestellt und geführt werden, wie Meetings durchzuführen sind und wie der Workflow organisiert wird. Es geht darum, wie sich Menschen organisieren und wie sie interagieren. Praktiken der Softwareentwicklung sind dagegen Vorgehensweisen ohne Bezug zum Prozess, die nachvollziehbare Vorteile gezeigt haben. Ein Beispiel hierfür ist die beständige Integration (Continuous Integration), für die kein bestimmter Prozess benötigt wird.

Der Weg vom Extreme Programming zu Continuous Delivery

Der Unterschied zwischen Prozess und Entwicklung lässt sich gut am Beispiel des Extreme Programming (XP) (http://www.extremeprogramming.org) illustrieren. Anfang der 1990er-Jahre begann eine Gruppe erfahrener Entwickler unter Führung von Kent Beck, die Vielzahl der damals gängigen Entwicklungspraktiken infrage zu stellen. Ihrer Erfahrung nach gab es keine Methode, die zuverlässig wiederholbare gute Ergebnisse brachte. Einer der XP-Gründer sagte, die Wahl eines der gängigen Prozesse hätte »so viel Erfolgsgarantie wie das Werfen einer Münze«. Sie entschieden sich, die Softwareentwicklung neu zu überdenken, und begannen im März 1996 das XP-Projekt. Dabei missachteten sie alle üblichen Erfahrungen und gründeten ihren Prozess stattdessen auf die Praktiken, die zu Projekterfolgen geführt hatten, und trieben diese ins Extreme. Ihre Überlegungen basierten auf der Beobachtung, dass sich bei früheren Projekten gezeigt hatte, dass es offenbar eine Beziehung zwischen mehr Tests und einer höheren Qualität gab. Daher trieb der XP-Ansatz dieses Vorgehen ins Extreme: Man verwendete eine »Test-First«-Entwicklungspraxis, bei der sämtlicher Code getestet werden muss, bevor er in die Codebasis integriert wird.

Schnell fand XP Eingang in andere beliebte agile Prozesse mit ähnlichen Perspektiven. Dennoch war es eine der wenigen Vorgehensweisen, die Entwicklungspraktiken wie Automatisierung, Testen, kontinuierliche Integration und weitere konkrete erfahrungsbasierte Techniken miteinander verband. Die Fortschritte in der Softwareentwicklung gingen weiter mit dem Buch Continuous Delivery (Addison-Wesley Professional) – eine aktualisierte Version voller XP-Praktiken –, das besonders in der DevOps-Bewegung sehr beliebt war. Auf vielerlei Weise entstand die DevOps-Revolution als Abteilung für den technischen Betrieb, die sich Entwicklungspraktiken aneignete, die ursprünglich aus der XP-Welt stammten: Automation, Testing, deklarative Single Source of Truth und anderes.

Wir befürworten diese Fortschritte ausdrücklich. Sie bilden aufeinanderfolgende Schritte, die die Softwareentwicklung nach und nach in eine echte Ingenieursdisziplin verwandeln.

Die Konzentration auf die Aspekte des Ingenieurswesens ist wichtig. Erstens fehlen der Softwareentwicklung viele Merkmale der reiferen Ingenieurdisziplinen. So können Bauingenieure strukturelle Änderungen mit deutlich größerer Genauigkeit vorhersagen als es bei ähnlich wichtigen Aspekten der Softwarestruktur der Fall ist. Zweitens: Die Achillesferse der Softwareentwicklung sind Schätzungen: Wie viel Zeit, wie viele Ressourcen, wie viel Geld? Ein Teil dieser Schwierigkeiten liegt in antiquierten Buchhaltungsmethoden, die die explorative Natur der Softwareentwicklung nicht berücksichtigen. Ein weiterer Grund für unsere oft ungenauen Schätzungen sind die unbekannten Unbekannten.

… wie wir wissen, gibt es bekannte Bekannte; Dinge, von denen wir wissen, dass wir sie wissen. Wir wissen auch, dass es bekannte Unbekannte gibt; das heißt, wir wissen, es gibt einige Dinge, die wir nicht wissen. Aber es gibt auch unbekannte Unbekannte – Dinge von denen wir nicht wissen, dass wir sie nicht wissen.

– Donald Rumsfeld, ehemaliger US-Verteidigungsminister

Unbekannte Unbekannte sind der Erzfeind von Softwaresystemen. Viele Projekte beginnen mit einer Liste bekannter Unbekannter: Dinge, die Entwickler sich neu entwickelnder Bereiche und Technologien erst noch aneignen müssen. Oft fallen Projekte aber den unbekannten Unbekannten zum Opfer: Probleme, von denen niemand erwartet hat, dass sie auftreten. Genau hier liegt der Grund, warum alle Softwareprojekte, bei denen große Designentscheidungen ganz am Anfang getroffen werden, Probleme haben: Architekten können nicht für unbekannte Unbekannte vorausplanen. Um Mark (einen der Autoren dieses Buchs) zu zitieren:

Alle Architekturen werden aufgrund unbekannter Unbekannter iterativ. Agile Entwicklung erkennt das an und iteriert einfach früher.

Das heißt, obwohl der Prozess größtenteils von der Architektur unabhängig ist, passt ein iterativer Prozess besser zur Softwarearchitektur. Teams versuchen, moderne Systeme wie Microservices anhand veralteter Prozesse wie Waterfall zu erstellen. Durch einen veralteten Prozess, der die Realität bei der Erstellung von Software ignoriert, entsteht allerdings viel Reibung.

Oftmals sind Architekten auch technische Projektleiter und legen fest, welche Entwicklungspraktiken das Team verwendet. Architekten müssen also nicht nur den Problembereich (engl. problem domain) genau analysieren, sondern auch sicherstellen, dass der Architekturstil und die ingenieurtechnischen Aspekte sich symbiotisch ergänzen. Microservices-Architekturen verwenden beispielsweise eine automatische Verteilung von Rechnerressourcen, automatische Tests, automatisches Deployment sowie eine Vielzahl weiterer Annahmen. Der Versuch, diese Architekturen mithilfe veralteter, für den technischen Betrieb zuständiger Gruppen (»operations group«), manueller Prozesse und weniger Tests umzusetzen, erzeugt eine enorme Reibung und bedeutet ein großes Risiko für den Erfolg. So wie bestimmte Architekturstile für verschiedene Problembereiche besser geeignet sind, haben bestimmte ingenieurstechnische Ansätze die gleiche Art symbiotischer Beziehung.

Die Evolution der Denkweise, die vom Extreme Programming zu Continuous Delivery geführt hat, hat kein Ende. Aktuelle Fortschritte bei den Entwicklungspraktiken ermöglichen neue architektonische Fähigkeiten. Neals aktuelles Buch, Building Evolutionary Architectures (O’Reilly), untersucht neue Wege, über die Schnittmenge zwischen Ingenieurspraktiken und Architektur nachzudenken, die eine bessere Automatisierung der architektonischen Leitung ermöglichen können. Auch wenn wir hier nicht weiter auf dieses Buch eingehen, zeigt es doch eine wichtige neue Sprech- und Denkweise über architektonische Eigenschaften, die einen großen Teil dieses Buchs beeinflusst.

Neals Buch behandelt Techniken zur Schaffung von Architekturen, die sich ohne große Reibungsverluste an zukünftige Entwicklungen anpassen können. In Kapitel 4 beschreiben wir Architektur als die Kombination aus Anforderungen und zusätzlichen Bedürfnissen, wie in Abbildung 1-7 gezeigt.

Abbildung 1-7: Die Architektur eines Softwaresystems besteht aus den Anforderungen und allen weiteren architektonischen Eigenschaften.

Wie alle Erfahrungen in der Welt der Softwareentwicklung zeigen, wird auch hier deutlich, dass nichts unveränderlich ist. Daher sollten Architekten ein System entwickeln, das bestimmte Anforderungen erfüllt, wobei das Design aber sowohl die Implementierung (wie können Architekten sicherstellen, dass ihr Design korrekt implementiert ist) als auch die unvermeidlichen Änderungen im Ökosystem der Softwareentwicklung überlebt.

Building Evolutionary Architectures stellt das Konzept der »Fitnessfunktionen« vor, um architektonische Eigenschaften zu schützen (und zu regulieren), die sich im Laufe der Zeit ändern. Das Konzept stammt aus dem »evolutionary computing«. Bei der Entwicklung genetischer Algorithmen stehen Entwicklern verschiedene Techniken zur Verfügung, eine Lösung zu mutieren, wodurch iterativ neue Lösungen entstehen können. Wird ein solcher Algorithmus für ein bestimmtes Ziel entwickelt, müssen Entwickler das Ergebnis messen können, um zu überprüfen, ob es sich einer optimalen Lösung annähert oder von ihr entfernt. Diese Messgröße ist die Fitnessfunktion. Erstellen Entwickler beispielsweise einen genetischen Algorithmus zur Lösung des »travelling salesman«-Problems (mit dem die kürzeste Route zwischen mehreren Orten gefunden werden soll), würde die Fitnessfunktion die Wegstrecke überprüfen.

Building Evolutionary Architectures greift diese Idee auf, um architektonische Fitnessfunktionen zu entwickeln, die als objektive Integritätsüberprüfung verschiedener architektonischer Merkmale dienen. Diese Überprüfung kann eine Vielzahl von Vorgehensweisen enthalten, wie Kennzahlen, Unit Tests, Monitoring und Chaos Engineering. Es kann beispielsweise sein, dass ein Architekt die Seitenladezeit als wichtige Eigenschaft einer Architektur identifiziert. Damit das System sich ändern kann, ohne dass die Performance darunter leidet, enthält die Architektur eine Fitnessfunktion als Test, der die Ladezeit für die einzelnen Seiten ermittelt und diesen Test als Teil der kontinuierlichen Integration des Projekts ausführt. Dadurch kennen Architekten immer den Status der kritischen Teile einer Architektur, denn sie haben einen Verfizierungsmechanismus in Form der Fitnessfunktionen für die einzelnen Bestandteile.

Wir werden die Fitnessfunktionen hier nicht im Detail behandeln. Allerdings werden wir bei Bedarf auf Beispiele für ihren Einsatz hinweisen. Beachten Sie die Beziehung zwischen der Häufigkeit, mit der Fitnessfunktionen ausgeführt werden, und den Rückmeldungen, die sie zur Verfügung stellen. Sie werden bemerken, dass agile Entwicklungspraktiken wie die kontinuierliche Integration, automatische Bereitstellung von Rechnerressourcen und ähnliche Praktiken die Erstellung robuster Architekturen erleichtern. Es zeigt außerdem, wie stark die Architektur inzwischen mit den Entwicklungspraktiken verflochten ist.

Technischer Betrieb/DevOps

Die deutlichste Überschneidung zwischen der Architektur und verwandten Bereichen ergab sich mit dem Aufkommen von DevOps, wofür einige architektonische Axiome neu gedacht werden mussten. Viele Jahre betrachteten Unternehmen den technischen Betrieb als eigenständige Funktion der Softwareentwicklung. Um Kosten zu sparen, wurde der Betrieb an externe Unternehmen ausgelagert. Viele in den 1990er- und 2000er-Jahren entwickelte Architekturen gingen davon aus, dass Architekten keinen Einfluss auf den Betrieb hätten, und wurden daher defensiv um diese Beschränkung herum entwickelt (ein gutes Beispiel hierfür ist die »Space-based«-Architektur, siehe Kapitel 15).

Wenige Jahre später begannen viele Unternehmen, mit neuen Architekturformen zu experimentieren, die viele Aspekte des technischen Betriebs mit der Architektur kombinierten. In älteren Systemen wie etwa dem ESB-basierten SOA war die Architektur so gestaltet, dass sie Dinge wie elastische Skalierung übernahm, wodurch die Architektur selbst deutlich komplexer wurde. Im Prinzip waren die Architekten gezwungen, defensiv um die Einschränkungen herum zu entwickeln, die durch die vermeintlich kostensparenden Outsourcing-Maßnahmen entstanden waren. Also entwickelten sie Architekturen, die Skalierung, Performance, Elastizität und eine Vielzahl anderer Fähigkeiten intern handhaben konnten. Die Nebenwirkung eines solches Design war, dass die Architekturen dadurch äußerst komplex wurden.

Die Erfinder der Microservices-Architektur stellten fest, dass betriebliche Aspekte besser von der Abteilung für den technischen IT-Betrieb (IT-Operations) übernommen werden. Durch die Verbindung zwischen Architektur und technischem Betrieb konnten die Architekten das Design vereinfachen, während IT-Operations ihrerseits für die Dinge zuständig war, die sie am besten konnte. Das Erkennen der Fehleinschätzung von Ressourcen führte zu ungewollter Komplexität. Daher entwickelten Architekten und technische Betriebsabteilungen gemeinsam die Microservices, deren Details wir in Kapitel 17 behandeln.

Prozess

Ein weiteres Axiom besagt, dass die Softwarearchitektur sich weitgehend orthogonal zum Prozess der Softwareentwicklung verhält. Die Art, wie Software erstellt wird (der Prozess) hat nur wenig Auswirkungen auf die Softwarearchitektur (Struktur). Während der von einem Team verwendete Softwareentwicklungsprozess Auswirkungen auf die Softwarearchitektur hat (besonders bei den Entwicklungspraktiken), wurden beide Bereiche in der Vergangenheit als größtenteils separat angesehen. Die meisten Bücher zur Softwarearchitektur ignorieren den Entwicklungsprozess und treffen nur oberflächliche Annahmen zu Dingen wie Vorhersagbarkeit. Trotzdem hat der Prozess, den Teams für die Softwareentwicklung einsetzen, einen Einfluss auf viele Bereiche der Softwarearchitektur. So haben viele Unternehmen aufgrund der Natur der Software im Laufe der letzten Jahrzehnte agile Entwicklungsmethoden eingeführt. Architekten in agilen Projekten können von einer iterativen Entwicklung ausgehen und damit von schnelleren Rückmeldungen zu ihren Entscheidungen. Dadurch können die Architekten wiederum aggressiver mit Experimenten und anderem Wissen umgehen, das für das Feedback benötigt wird.

Wie das oben genannte Zitat von Mark feststellt, wird jede Architektur irgendwann iterativ – es ist nur eine Frage der Zeit. So gesehen gehen wir in diesem Buch grundsätzlich von agilen Methoden aus und weisen bei Bedarf auf die Ausnahmen hin. So ist es bei vielen monolithen Architekturen aufgrund ihres Alters, von Politik und anderen einschränkenden Faktoren, die nichts mit Software zu tun haben, immer noch üblich, ältere Prozesse zu verwenden.

Agile Methoden funktionieren in der Architektur besonders gut, wenn es um Restrukturierung geht. Oft müssen Teams ihre Architektur von einem Muster zu einem neuen migrieren. So ist es möglich, dass ein Team mit einer monolithischen Architektur begonnen hat, weil diese leicht und schnell umzusetzen war. Jetzt wird aber eine moderne Architektur gebraucht. Agile Methoden unterstützen Veränderungen dieser Art besser als planungslastige Prozesse durch eine enge Feedbackschleife und Förderung durch Techniken wie das Strangler-Muster (https://oreil.ly/ZRpCc) und Feature Toggles (https://trunkbaseddevelopment.com).

Daten

Bei den meisten ernsthaften Applikationen geht es auch um die Speicherung externer Daten, oft in Form von relationalen Datenbanken (oder immer häufiger auch NoSQL-Datenbanken). Dennoch behandeln viele Bücher über Softwarearchitektur diesen wichtigen architektonischen Aspekt nur am Rande. Code und Daten haben eine symbiotische Beziehung zueinander: Das eine ist ohne das andere nutzlos.

Datenbankadministratoren arbeiten oft gemeinsam mit Architekten an der Erstellung von Datenarchitekturen für komplexe Daten. Dabei wird analysiert, wie Beziehungen und Wiederverwendung ein Portfolio von Applikationen beeinflussen. Zwar werden wir in diesem Buch nicht jedes Detail behandeln können, wir wollen die Existenz und Abhängigkeit von externer Speicherung aber auch nicht ignorieren. Insbesondere wenn wir uns mit den Aspekten des technischen Betriebs der Architektur und den architektonischen Quanten (siehe Kapitel 3) beschäftigen, werden wir auch auf wichtige externe Punkte, wie zum Beispiel Datenbanken, eingehen.

Gesetze der Softwarearchitektur

Obwohl das Feld der Softwarearchitektur unglaublich vielfältig ist, gibt es auch Gemeinsamkeiten. Das Erste Gesetz der Softwarearchitektur haben die Autoren vor allem dadurch gelernt, dass es ihnen immer wieder begegnet ist:

Alles in der Softwarearchitektur ist ein Kompromiss.

– Erstes Gesetz der Softwarearchitektur

Für Softwarearchitekten gibt es keine klar definierten Schubladen. Für jede Entscheidung muss eine Vielzahl sich widersprechender Vor- und Nachteile berücksichtigt werden.

Wenn Architekten meinen, sie hätten etwas entdeckt, das kein Kompromiss ist, haben sie sehr wahrscheinlich noch nicht erkannt, worin der Kompromiss besteht.

– Folgerung 1

Wir definieren Softwarearchitektur als das Erstellen einer Grundstruktur, unter Beachtung bestimmter Prinzipien, Eigenschaftern und so weiter. Architektur ist aber mehr als nur die Kombination struktureller Elemente, was sich im zweiten Gesetz der Softwarearchitektur ausdrückt.

Das Warum ist wichtiger als das Wie.

– Zweites Gesetz der Softwarearchitektur

Die Wichtigkeit dieser Sichtweise ist uns klar geworden, als wir versuchten, die Ergebnisse einer Übung festzuhalten, zu denen Studenten während eines unserer Workshops zur Erstellung architektonischer Lösungen kamen. Da die Übungen zeitlich begrenzt waren, haben wir nur die Diagramme behalten, die die Topologie wiedergaben. In anderen Worten, wir haben festgehalten, wie sie das Problem lösten, aber nicht, warum das Team eine bestimmte Wahl getroffen hat. Ein Architekt kann sich beispielsweise ein bestimmtes System ansehen, ohne es genau zu kennen, und trotzdem die Struktur und die Funktionsweise der Architektur erkennen. Er wird aber nur schwer erklären können, warum bestimmte Entscheidungen getroffen wurden.

Im Laufe dieses Buchs werden wir zeigen, warum Architekten bestimmte Entscheidungen getroffen haben und welche Kompromisse dafür eingegangen werden mussten. In »Architecture Decision Records (ADR)« auf Seite 289 zeigen wir Ihnen außerdem einige gute Techniken, um die wichtigen Entscheidungen zu dokumentieren.

TEIL I

Grundlagen

Um die wichtigen Kompromisse in der Softwarearchitektur zu verstehen, müssen Entwickler einige Grundkonzepte und Fachbegriffe zu Komponenten, Modularität, Kopplung und Konnaszenz (»connascence«) verstehen.

KAPITEL 2

Architektonisches Denken

So ähnlich wie ein Meteorologe Wolken auf andere Weise betrachtet als ein Künstler, hat ein Architekt eine andere Sichtweise auf die Dinge als ein Entwickler. Das nennt man architektonisches Denken. Leider glauben zu viele Architekten, dass architektonisches Denken einfach bedeutet, »über Architektur nachzudenken«, wie in Abbildung 2-1 gezeigt.

Abbildung 2-1: Architektonisches Denken (iStockPhoto)

Tatsächlich ist architektonisches Denken viel mehr als das. Es geht darum, sich einen architektonischen »Blickwinkel« anzueignen. Für diese Denkweise gibt es vier Aspekte. Beim ersten geht es darum, den Unterschied zwischen Architektur und Design zu verstehen und zu wissen, wie man mit Entwicklungsteams zusammenarbeitet, damit die Architektur funktioniert. Zweitens müssen das technologische Wissen und Verständnis eher breit als tief sein. Eine gewisse Tiefe ist nötig, um Lösungen und Möglichkeiten zu erkennen, die andere vielleicht nicht sehen. Drittens geht es darum, die Vor- und Nachteile der verschiedenen Lösungen und Technologien zu verstehen, zu analysieren und miteinander in Einklang zu bringen. Und schließlich muss man viertens die Wichtigkeit der geschäftlichen Aspekte verstehen und wissen, wie sie in architektonische Belange übersetzt werden können.

In diesem Kapitel erforschen wir zum einen diese vier Aspekte der architektonischen Denkweise und zum anderen das Schärfen der architektonischen Sichtweise.

Architektur und Design im Vergleich

Der Unterschied zwischen Architektur und Design kann oft verwirrend sein. Wo endet Architektur, und wo fängt Design an? Welche Verantwortung trägt ein Architekt, und wofür sind Entwickler zuständig? Wie ein Architekt zu denken, heißt, den Unterschied zwischen Architektur und Design zu verstehen und zu erkennen, wie eng beides miteinander verwoben ist, um Lösungen für geschäftliche und technische Probleme zu finden.

Sehen wir uns hierzu Abbildung 2-2 an. Hier sehen Sie die traditionellen Verantwortlichkeiten eines Architekten im Vergleich zu denen eines Entwicklers. Im Diagramm ist zu sehen, dass ein Architekt beispielsweise für die Analyse der geschäftlichen Anforderungen zuständig ist, um daraus die architektonischen Eigenschaften (Fähigkeiten) abzuleiten. Dazu gehören die Auswahl der für die Problemlösung sinnvollen architektonischen Patterns und Stile und die Erstellung der Komponenten (der Grundbausteine des Systems). Die daraus resultierenden Artefakte werden an das Entwicklungsteam übergeben, das für die Erstellung von Klassendiagrammen für die einzelnen Komponenten, die Erstellung von Benutzerschnittstellen und für die Entwicklung und das Testen des Quellcodes zuständig ist.

Abbildung 2-2: Traditionelle Sichtweise des Vergleichs zwischen Architektur und Design

Bei dem in Abbildung 2-2 gezeigten traditionellen Verantwortlichkeitsmodell gibt es mehrere Probleme. Eigentlich zeigt dieses Diagramm sogar, warum Architektur nur selten auf diese Weise funktioniert. Im Besonderen geht es um den Pfeil zwischen den virtuellen und physischen Barrieren (hier durch die schraffierte graue Linie in der Mitte der Darstellung symbolisiert), die Architekten und Designer voneinander trennen. Dieser Pfeil ist die Quelle aller mit der Architektur zusammenhängenden Probleme. Manchmal dringen die Entscheidungen eines Architekten gar nicht bis zum Entwicklerteam durch. Gleichzeitig gelangen Entscheidungen des Entwicklerteams, die die Architektur verändern, nur selten zurück zum Architekten. Es besteht keine Verbindung zwischen Architekten und Entwicklerteams. Dadurch werden die ursprünglichen Ziele der Architektur nur selten tatsächlich erreicht.

Damit Architektur überhaupt funktioniert, müssen die physichen und virtuellen Barrieren zwischen Architekten und Entwicklern entfernt werden. So kann eine starke Beziehung in beide Richtungen entstehen. Damit das funktioniert, müssen Architekten und Entwickler im gleichen virtuellen Team zusammenarbeiten, wie in Abbildung 2-3 gezeigt. Dieses Modell ermöglicht nicht nur eine starke bidirektionale Kommunikation zwischen Architekten und Entwicklern, es ermöglicht den Architekten außerdem, das Entwicklungsteam zu leiten und zu unterstützen.

Abbildung 2-3: Zusammenarbeit als Bedingung für eine funktionierende Architektur

Im Gegensatz zu altmodischen Waterfall-Ansätzen für eine statische und starre Softwarearchitektur ist die heutige Architektur veränderlich und entwickelt sich mit jeder Iteration oder Projektphase beständig weiter. Daher ist eine enge Zusammenarbeit zwischen Architekten und Entwicklungsteams für den Projekterfolg absolut notwendig. Wo endet also die Architektur, und wo beginnt das Design? Das lässt sich nicht sagen. Beide sind Teil eines beständigen Kreislaufs des Lebens eines Sofwareprojekts und müssen ständig neu aufeinander abgestimmt werden, um erfolgreich zu sein.

Technische Breite

Entwickler und Architekten haben einen unterschiedlichen Bedarf an technischem Detailswissen. Entwickler brauchen ein großes Maß an technischer Tiefe, um ihre Aufgabe zu erfüllen. Softwarearchitekten brauchen dagegen ein großes Maß an technischer Breite, um wie ein Architekt denken und die Dinge aus dem entsprechenden Blickwinkel betrachten zu können. Das sieht man in Abbildung 2-4. Die hier gezeigte Wissenspyramide symbolisiert das gesamte Wissen der Welt. Welche Art von Informationen ein Technologe besonders schätzen sollte, hängt von seiner jeweiligen Karrierestufe ab.

Abbildung 2-4: Die allumfassende Wissenspyramide

Wie in Abbildung 2-4 zu sehen, können Sie Ihr Wissen in drei Bereiche aufteilen: Dinge, die Sie wissen; Dinge, von denen Sie wissen, dass Sie sie nicht wissen, und Dinge, von denen Sie nicht wissen, dass Sie sie nicht wissen.

Zu den Dingen, die Sie wissen, gehören Technologien, Frameworks, Sprachen und Werkzeuge, die ein Technologe täglich verwendet, um seine Arbeit zu tun. Als Java-Programmierer muss man Java kennen. Dinge, von denen Sie wissen, dass Sie sie nicht wissen, sind solche, über die ein Technologe wenig weiß oder von denen er gehört hat und mit denen er nur wenig oder keine Erfahrung hat. Ein gutes Beispiel hierfür ist die Programmiersprache Clojure. Die meisten Technologen haben schon mal von Clojure gehört und wissen, dass es eine auf Lisp basierende Programmiersprache ist. Sie können aber nicht in Clojure programmieren. Dinge, von denen Sie nicht wissen, dass Sie sie nicht wissen, machen den größten Teil der Wissenspyramide aus. Hierzu gehört eine Vielzahl von Technologien, Werkzeugen, Frameworks und Sprachen, die zur perfekten Lösung für ein bestehendes Problem beitragen könnte. Allerdings wissen Sie nicht, dass es diese Dinge überhaupt gibt.

Am Anfang ihrer Laufbahn müssen sich Entwickler darauf konzentrieren, den oberen Teil der Pyramide zu vergrößern, um Erfahrung und Fachwissen zu erlangen und zu erweitern, weil Entwickler mehr Perspektive, Fachwissen und Erfahrung aus erster Hand brauchen. Durch eine Vergrößerung der Spitze erweitert sich auch der Mittelteil. Je mehr Technologien und verwandte Bereiche ein Entwickler kennenlernt, desto größer wird auch der Fundus der Dinge, von denen man weiß, dass man sie nicht weiß.

In Abbildung 2-5 sieht man, dass eine Erweiterung der Pyramidenspitze sinnvoll ist, weil Fachwissen geschätzt wird. Allerdings sind Dinge, die Sie wissen, auch Dinge, um die Sie sich kümmern müssen, denn in der Welt der Software ist nichts wirklich statisch. Spezialisiert sich ein Entwickler beispielsweise auf Ruby on Rails, bleibt dieses Fachwissen nicht lange »frisch«, wenn der Entwickler Ruby on Rails für ein oder zwei Jahre ignoriert. Für die Dinge an der Pyramidenspitze muss einiges an Zeit eingesetzt werden, um dieses Wissen zu pflegen und zu erhalten. Am Ende kennzeichnet der Bereich an der Spitze der Pyramide, über welche technische Tiefe Sie verfügen.

Abbildung 2-5: Entwickler müssen ihre Fachkenntnisse pflegen, um sie zu behalten.

Mit dem Übergang von der Rolle des Entwicklers zur Rolle des Architekten ändert sich auch die Art des Wissens. Ein großer Teils des Werts eines Architekten besteht in einem breiten technologischen Verständnis und in seiner Art, bestimmte Probleme zu lösen. Als Architekt ist es beispielsweise hilfreicher zu wissen, dass es für ein bestimmtes Problem fünf verschiedene Lösungen gibt, als jede dieser Lösungen bis ins kleinste Detail zu kennen. Die wichtigsten Teile der Pyramide sind für Architekten daher die Spitze und der Mittelteil. Wie weit sich der Mittelteil in den unteren Teil erstreckt, kennzeichnet seine technische Breite, wie in Abbildung 2-6 gezeigt.

Abbildung 2-6: Was jemand weiß, bezeichnet man als technische Tiefe, wie viel jemand weiß, als technische Breite.

Für Architekten ist technische Breite wichtiger als Tiefe