Stefan Zörner
01.12.2020
Türchen #1 im arcvent(s)kalender 2020
Vergleiche zwischen Realarchitektur und Softwarearchitektur hinken in der Regel. Im Einzelfall versperren solche Analogien sogar den zeitgemäßen Blick darauf, wie Softwarelösungen heute entstehen, wachsen und sich weiterentwickeln.
Das betrifft zum Beispiel die strikte Trennung zwischen Planungs- und Bauphase aus der klassischen Bauarchitektur. Oder auch damit verbundene Rollenverständnisse (Architekt/Bauarbeiter vs. Softwarearchitekt/-entwickler). Derartige Übertragungen fallen aus der Zeit.
Beim Begriff des Architekturstils (oder alternativ Baustils) verhält es sich meiner Meinung nach jedoch anders. Wir benutzen ihn auch in der modernen Softwarearchitektur gern. Und wir tun es aus sehr ähnlichen Gründen wie in der “analogen” Architektur. Ich finde den Begriff “Stil” inklusive der Analogie zum Bauen nützlich. Lasst mich kurz erklären warum!
Zunächst einmal sind Architekturstile ungemein praktisch für eine effiziente Kommunikation. Bei Wikipedia steht „Der Kölner Dom ist eine der größten Kathedralen im gotischen Baustil.“ und mit “gotisch” ist schon viel gesagt (“weitgehende Durchbrechung der Außenwandflächen durch Fenster mit Spitzbögen, Reduzierung der Wandstärken …“) — vorausgesetzt der Leser weiß, was Gotik bedeutet.
Der Satz “Unsere neue Schaden-Anwendung ist eine Microservices-Lösung …” funktioniert ähnlich gut (“unabhängig deploybare, sehr lose gekoppelte Teile, große technologische Freiheiten in der Umsetzung …” ). Aber auch hier natürlich nur, wenn der Architekturstil bekannt ist, und es ein einheitliches Verständnis dafür gibt.
Über einen Stil lässt sich reden. Über seinen angemessenen Einsatz diskutieren. Neue Stile fördern den Austausch unter Softwareentwicklern in Form von Konferenzen, Blogs oder Büchern.
Ganz ähnlich wie bei Bauwerken ist der Architekturstil in der Softwarearchitektur ein Trendthema. Gleichzeitig wechseln die Vorlieben hier naturgemäß etwas schneller. Beim Barock reden wir über Jahrhunderte, bei SOA eher über Jahrzehnte.
Aber was genau ist eigentlich ein Architekturstil in Software? Rozanski und Woods definieren den Begriff in Ihrem Buch “Software Systems Architecture” so:
Ein Architekturstil drückt ein grundlegendes Organisationsschema für Softwaresysteme aus. Er stellt eine Reihe vordefinierter Elementtypen bereit, spezifiziert ihre Verantwortlichkeiten und enthält Regeln und Richtlinien für die Organisation der Beziehungen zwischen ihnen.
Bei den Elementtypen kann es sich um Module, Teilsysteme, Schichten, Services handeln, bei den Regeln etwa um Prinzipien oder Abhängigkeitsrichtungen.
Ein Stil etabliert also (Strukturierungs-)begriffe und (Bau-)prinzipien. Das klingt im ersten Moment strikt, kann gleichzeitig aber auch einen Rahmen für eine verteilt agierende, zielgerichtete Entwicklung schaffen. Denkt an Trendthemen wie Microservices oder Conway’s Law.
James Lewis und Martin Fowler definierten Microservices bereits im Jahr 2014 in einem gemeinsamen Blogbeitrag so:
“Kurz gesagt, der Microservice-Architekturstil ist ein Ansatz zur Entwicklung einer einzelnen Anwendung als einer Familie kleiner Services, die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren.”
Und die beiden Autoren bezeichneten eine Reihe von Eigenschaften als charakteristisch für den Stil – die Prinzipien und Regeln:
Zerlegung in relativ kleine (fachliche) Services
Services sehr lose gekoppelt
Services einzeln installierbar und upgradebar
Dezentrale Datenhaltung
Hoher Freiheitsgrad bei Technologieauswahl
Ist Eure eigene Microservices-Lösung “stilecht” im Sinne von Fowler und Lewis? Wo weicht Ihr ab? Wie begründet Euer Team dies?
Die grundlegende Änderung des Baustils nach Fertigstellung eines Gebäudes ist eher unüblich. Bei einem kompletten Neubau ist es denkbar. Auslöser dafür kann eine Katastrophe sein, die das alte Gebäude ohnehin stark beschädigte oder ganz zerstörte. So erstrahlt St. Pauls in London seit 1708 im Barock. Der im Wesentlichen gotische Vorgängerbau fiel dem großen Brand von 1666 zum Opfer.
Die Wahl des Architekturstils ist auch in der Softwareentwicklung in der Regel eine Architekturentscheidung. Das heißt eine Entscheidung, die im weiteren Verlauf des Vorhabens nur schwer zu revidieren ist.
Größere Softwareablösungen hingegen gehen gern mit einem neuen Architekturstil einher. Mitunter sind die Heilsversprechen des neuen Stils sogar ein Treiber. So wurden aus vielen Client-Server-Applikationen mit lokal am Desktop installierten Clients Anfang der 2000er Intranet-Anwendungen mit Browser-basierter Oberfläche. Sie waren leichter zu betreiben und zu aktualisieren. Microservices als Gegenentwurf zum Monolithen versprechen Flexibilität.
Wer die Anwendung komplett neu baut (“Complete Rewrite”) hat es auf den ersten Blick einfach. Spannend wird es wenn die Altanwendung parallel weiterbetrieben werden muss, und/oder die Daten später migriert werden sollen.
Ein “Big bang” ist mit großen Risiken verbunden, Weshalb bei größeren Umbauten gerne zu iterativen Vorgehen gegriffen wird (Stichwort: Application Strangulation).
Gerade bei sehr großen Vorhaben kommt es manchmal auch bei echten Gebäuden zu einer schrittweisen Migration des Baustils. Ein schönes Beispiel hierfür liefert die Kathedrale von Beauvais in Frankreich. Der Bischof dort plante ab 1225 den romanischen Vorgängerbau Trend-gemäß durch eine gotische Kathedrale zu ersetzen. Und zwar eine richtig Große.
Das Vorhaben war allerdings zu ambitioniert. Man begann im Osten beim Chor und baute mit Unterbrechungen bis 1573, wobei es immer wieder Rückschläge (unter anderem zwei große Einstürze) und damit verbunden Planänderungen gab.
Heute sehen wir in Beauvais eine halbfertige gotische Kathedrale, die immerhin den Rekord für das höchste Kirchengewölbe der Welt hält. Auf dem Foto unten ist der romanische Vorgängerbau, der nicht komplett abgelöst wurde, auf der linken Seite gut zu erkennen.
Auch die Softwareentwicklung kennt ambitionierte Umbauvorhaben an großen produktiven Systemen, denen nach der Hälfte die Luft ausging. Anwender und Betrieb müssen dann auch mit Hybrid-“Lösungen” leben, Medienbrüche und Mehraufwände inklusive. Entwickler erklären diese Stilbrüche dann wahlweise (zu Recht) als technische Schulden oder historisch gewachsen.
Für das Erklären einer Softwarearchitektur ist der Architekturstil – also die wesentlichen (Struktur-)elemente und die für ihre Entwicklung geltenden Prinzipien – ein exzellenter Ausgangspunkt.
Das erlebe ich regelmäßig beispielsweise in Architekturbewertungen, wo wir die Lösungsansätze gemeinsam mit dem Team herausarbeiten und gegen die architekturrelevanten Anforderungen halten. Aber gerade auch für neue Vorhaben ist das Auswählen und Ausprägen essentieller Teil der Architekturarbeit. Keine Architekturvision ohne Stil.
Die spannende Geschichte der Kathedrale von Beauvais könnt Ihr im schönen Buch “Atlas der nie gebauten Bauwerke” nachlesen. Das ist mein Tipp für den Gabentisch.
… mit den nicht gebauten Projekten wurden anspruchsvolle neue Ideen erforscht, Konventionen hinterfragt und Wege in die Zukunft gewiesen. … Manche Ideen erscheinen unglaublich kühn. Aber sie verweisen auch auf Gebäude, die Jahrzehnte später entstanden sind …
Das Buch von Philip Wilkinson erzählt die Geschichte von fünfzig Vorhaben, die nie verwirklicht (oder zumindest nicht vollendet) wurden. Vom frühen Mittelalter bis fast in die Gegenwart. Mit Protagonisten wie Leonardi da Vinci (Renaissance), Antonio Gaudi (Jugendstil) und Ludwig Mies van der Rohe (Moderne, Bauhaus). Mit Klöstern, Kathedralen und Kuppeln – eine über Manhattan. Phantastisch erzählt und wunderschön bebildert mit Bauplänen.
Ich wünsche Euch eine schöne Adventszeit und auch weiter viel Spaß mit unserem arcventskalender.