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 ...