Mit Stefan Zörner im Gespräch üner Softwarearchitektur

Aktuell ist bei Hanser die zweite Auflage des Fachbuches „Softwarearchitekturen dokumentieren und kommunizieren“ von Stefan Zörner erschienen. Zu diesem Anlass haben wir mit ihm ein Interview geführt. Stefan Zörner gibt uns seine Definition von Softwarearchitektur, erzählt, welche Themen derzeit heiß diskutiert werden und was den Leser in seiner zweiten Auflage des Buches erwartet. Viel Vergnügen beim Lesen wünscht Ihnen die Hanser Update Redaktion!

 

Hanser Update Redaktion: Softwarearchitektur wird laut Wikipedia in der Regel als die „früheste Softwaredesign-Entscheidung“ betrachtet. Ist das immer so?

Stefan Zörner: Für viele ist Softwarearchitektur etwas Abstraktes, wenig Greifbares. Die Softwarelösung selbst hingegen ist vergleichsweise konkret, fassbar. Eine Textverarbeitung beispielsweise, eine Smartphone-App, eine Webseite, oder die Steuerung in einem Gerät… Software ist ja sehr vielseitig.

Was genau davon ist die Architektur? Frühere Definitionen sind stark in Richtung Strukturierung gegangen. Wie zerfällt das Ganze in Teile? Wie spielen diese Teile zusammen? usw. Da steckt viel von der Idee dahinter, dass ich etwas plane, und dann baue – und früher haben viele Projekte auch so gearbeitet. System entwerfen (Design), System bauen usw.

Moderne Definitionen von Softwarearchitektur (und Definitionen gibt es viele) fokussieren häufig auf den Begriff der Entscheidung – die von Ihnen zitierte ja auch.

 

Was ist Ihre Definition?

Ich mag die Idee, Softwarearchitektur mit den weitreichenden Entscheidungen der Lösung gleichzusetzen. Solche Entscheidungen können die Strukturierung des Systems betreffen, aber zum Beispiel auch die Frage, ob bestimmte Teile zugekauft oder besser selbstgemacht werden, oder die Auswahl von Technologien. Oder, oder…

Der Zeitpunkt (siehe „früheste“) ist dabei gar nicht so entscheidend.

Spannender ist, ob es schwierig ist, eine Entscheidung im weiteren Verlauf zu revidieren, und wie groß das Risiko ist, wenn ich mich falsch entscheide. Was die Frage aufwirft, was Einfluss auf solche Entscheidungen haben sollte (Trends? Hypes? Erfahrung?), wann und wie ich sie treffe, wann und wie ich sie reflektiere.

Deswegen nehmen in meinem Buch die architekturrelevanten Anforderungen, also die Einflussfaktoren, einen großen Raum ein. Ein ganzes Kapitel.

 

Welche umgebenden Aspekte beeinflussen die Softwarearchitektur aktuell? Gibt es hier wichtige Trends?

Das ist pauschal schwer zu beantworten, da Software so vielseitig ist. Die Trends in Embedded Software sind andere als in Social Media oder innerhalb einer Versicherung – das sind verschiedene Welten.

Besonders spannend finde ich aktuell vor allem einen Aspekt: Wie wird Software heute verkauft? Und wie wird sie verteilt?

Früher gab es Schachteln mit Installationsmedien drin, heute gibt es Software-as-a-Service, AppStores, In-App-Käufe usw. Denken Sie an Adobe, die Ihre Software perspektivisch nur noch als Abo anbieten wollen (Stichwort „Creative Cloud“). Die Produkte waren früher „setup.exe“ schlecht hin.

Wer heute Software baut, hat interessante neue Möglichkeiten, die mittlerweile auch ausgereift sind. Im Sinne der weitreichenden Entscheidungen sind das Optionen, die man nicht ignorieren darf. Und in vielen Branchen stehen Cloud-Technologien ganz oben auf der Liste.

 

Welche Themen werden sonst im Bereich Softwarearchitektur derzeit heiß diskutiert?

Einzelne Technologien lasse ich hier mal weg, konzeptionell ist sicher die Microservices-Debatte zu nennen – auch wieder im Zusammenhang mit Cloud. Ist schon ein guter Indikator, wenn es zu einem neuen Thema plötzlich schon eigene Konferenzen gibt. Inklusive der Diskussion, ob das Thema überhaupt neu ist.

Microservices sind ein Architekturstil, der vereinfacht Aussagen darüber macht, wie Applikationen strukturiert werden sollen (in kleinen, möglichst unabhängigen Services), und der vor allem mit einem alten Dogma der Softwarearchitektur bricht. Früher haben wir gerne konzeptionelle Integrität über den grünen Klee gelobt, d.h. übergreifende Fragestellungen (Welche Programmiersprache, welche Frameworks verwenden wir? Wie speichern wir Daten? Wie bauen wir UIs? usw.) waren einheitlich zu entscheiden. Microservices brechen damit. Was früher inkonsistent geheißen hätte, ist heute polyglott und schick.

Für die weitreichenden Entscheidungen (um wieder die Kurve zur Softwarearchitektur im Sinne von oben zu kriegen) sind Microservices deswegen so spannend, weil sie die Frage adressieren: Was legen wir übergreifend fest, und wo lassen wir Teams, die für einzelne Services zuständig sind, Freiheiten? Manche Leute sprechen hier von Macro- und Micro-Architektur.

 

Ihr Buch „Softwarearchitekturen dokumentieren und kommunizieren“ ist gerade in der zweiten Auflage erschienen. Spiegelt sich dieser Trend in den Veränderungen oder Erweiterungen im Buch wider?

Nicht direkt. Bei dem Buch geht es verkürzt darum, wie man weitreichende Entscheidungen nachvollziehbar festhält. Der Begriff „Entscheidung“ taucht nicht von ungefähr im Untertitel auf.

Spannend ist dann im Zusammenhang mit Microservices, wie man übergreifende Dinge festhält und an unterschiedliche Teams kommuniziert, und auch wie Teams gute Lösungsansätze, die sie gefunden haben, mit anderen teilen.

Der Trend ist also gut für das Thema Architekturdokumentation. Er macht die Notwendigkeit deutlich, und zeigt gleichzeitig auf, wo es lohnt in das Festhalten von Entscheidungen zu investieren.

 

Was ist denn dann neu in der zweiten Auflage?

Neben typischen Aktualisierungen, Fallbeispiele überarbeiten, Kleinigkeiten usw. gibt es aus meiner Sicht vor allem zwei inhaltlich interessante Dinge.

Zum einen habe ich arc42 gegen eine mittlerweile ebenfalls recht sichtbare Alternative zur Strukturierung von Architekturbeschreibungen gehalten, Gemeinsamkeiten und Unterschiede herausgearbeitet: Spoiler; Die Gemeinsamkeiten überwiegen.

Zum zweiten ist die Darstellung der Lösungsstrategie viel zwingender als in der ersten Auflage. Insbesondere bei dieser Zutat für Dokumentation sind Rückmeldungen von Lesern und jüngste eigene Projekterfahrungen eingeflossen. Wer neugierig ist, kann den Blog-Beitrag arc42-Starschnitt: Gradle. Schnipsel Nr. 10: Lösungsstrategie auf Hanser Update vom Dezember dazu lesen. Da sind schon erste Ideen in diese Richtung skizziert.

 

In Ihrem Buch sind Übungsaufgaben, Sie laden die Leser dazu ein, Ihnen Lösungen zum Review zu schicken. Das war auch in der ersten Auflage schon so. Kriegen Sie viele Einsendungen?

Nein. Was ich aber interessant finde: Regelmäßig kommen Anfragen, ob man die Aufgaben statt mit dem vorgegebenen Übungsbeispiel auch mit dem eigenen Projekt machen, und die Sachen dann begutachten lassen kann.

Das finde ich klasse. Es zeigt, dass die Leser die vorgeschlagenen Dinge gleich ausprobieren. Die Aufgaben scheinen da zu helfen, auch wenn die Leute am Ende was anders machen. Was viel besseres. Und ja, ich gebe sogar viel lieber Rückmeldungen und Einschätzungen zu Architekturüberblicken von Projekten der Leser.

Herzlichen Dank für das Gespräch, Herr Zörner!