Interview
05.04.2019, 09:03 Uhr
Für welche Technologien haben wir uns entschieden und warum.
Provokant stellt Stefan Zörner in seiner Session auf der Developer Week die These auf, dass die Architektur einer Anwendung auf einen Bierdeckel passt. dotnetpro hat nachgehakt.
(Quelle: Stefan Zörner)
Stefan Zörner ist Softwarearchitekt, Berater und Coach bei embarc in Hamburg. Er unterstützt in Architektur- und Umsetzungsfragen mit dem Ziel, gute Architekturansätze wirksam in der Implementierung zu verankern. Sein Wissen und seine Erfahrung teilt er regelmäßig in Vorträgen, Artikeln und Workshops. Stefan ist Apache Committer, aktives Board-Mitglied im iSAQB und Autor des Buchs "Softwarearchitekturen dokumentieren und kommunizieren" (2. Auflage, Hanser Verlag). Auf der Developer Week 2019 hält er eine Session mit dem Thema Architektur auf dem Bierdeckel – Eure Lösung in kurz und knackig und eine zu Microservices & Makro-Architektur - Drei zentrale Entwurfsfragen bei vertikalen Anwendungsarchitekturen.
Stefan, du hältst eine Session auf der Developer Week 2019 mit dem Titel: "Architektur auf dem Bierdeckel". Ich kann mir schon sehr große Gläser und dafür passende Bierdeckel vorstellen, aber gibt es so große Bierdeckel, dass die Architektur etwa eines Buchungssystems drauf passt?
Das hängt davon ab, was man unter der Architektur eines Softwaresystems versteht. Für mich (und andere) ist es die Summe zentraler Entscheidungen, die im weiteren Verlauf nur sehr schwer zurückzunehmen sind. Daraus wiederum die wichtigsten nachvollziehbar darzustellen, in Form eines prägnanten Architekturüberblicks, braucht nicht viel Platz. Das mit dem Bierdeckel ist etwas reißerisch, aber mehr als 12 bis 15 Folien sind es sicher nicht. Auch nicht bei SAP oder Toll Collect.
Ich hab natürlich den halben Titel unter den Tisch fallen lassen. Da steht noch: "Eure Lösung in kurz und knackig". Das lässt sich sicher für jede Architektur erreichen: Eingabe, Verarbeitung, Ausgabe. Aber spiegelt das dann das Besondere einer Lösung wieder?
Entscheidungen werden in unterschiedlichen Themenbereichen getroffen. Zerlegungsaspekte - wie in Deinem EVA-Faustkeil - und Abhängigkeiten zwischen den Teilen etwa. Technologien, Zielumgebung und so weiter. Der Kern, also das Besondere, ist für mich die Nachvollziehbarkeit. Zum Beispiel nicht nur, für welche Technologien wir uns entschieden haben, sondern auch warum. Dazu muss man auch die Einflüsse darstellen, die zu der Lösung geführt haben. Welche Ziele verfolgen wir, welche Vorgaben müssen wir einhalten? Die architekturrelevanten Anforderungen machen einen guten Teil eines wirkungsvollen Architekturüberblicks aus.
Wie sollte das Vorgehen aussehen? Fängt man auf dem Bierdeckel an oder steht nur das Resultat darauf?
Es ist eine gute Idee, klein anzufangen. Stefan Toth beschreibt das in seinem Buch zu agiler Softwarearchitektur als Architekturvision. Wenige Dinge festhalten im Team, um ein gemeinsames Verständnis von Aufgabenstellung und Lösungsansätzen zu entwickeln. Um früh Lücken und Risiken zu identifizieren. Und um die Ideen gut kommunizieren zu können. Zum Beispiel an Neue im Team. In meiner Session geht es insbesondere auch darum, wie ein Entwicklungsteam anfängt, was es mindestens braucht, und wann mehr ...
Braucht es nach dem Bierdeckel vielleicht noch 2000 Seiten weitere Ausführungen zur Architektur?
Auch im weiteren Verlauf halte ich Architekturdokumentation in meinen Vorhaben auf einem Minimum. Tendenziell veralten zu detaillierte Sachen schnell und verlieren an Wert. Manche Projekte haben regulative Vorgaben im Bereich Dokumentation und müssen bestimmte Dinge bereithalten. Das ist aber eher die Ausnahme. Nimm als Beispiel einen kompakten Reiseführer von Paris. Da ist nicht von jedem Museum ein detaillierter Saalplan drin. Aber Du findest die wichtigsten Museen damit und Dich in Summe zurecht.
Der Treiber dafür, ob man tatsächlich mehr braucht, sind die Zielgruppen - zum Beispiel Entwickler, welche die Lösung (weiter-)entwickeln. Der Einsatzzweck verschiebt sich dann von der Nachvollziehbarkeit (Warum sind bestimmte Dinge so?) zur Anwendung (Wie mache ich bestimmte Dinge?). Das müssen dann nicht zwingend ausschweifende Dokumente sein. How-tos und Checklisten sind oft angemessener. Das geht dann aber über den Einstieg mit Hilfe eines prägnanten Überblicks hinaus.
