JAXenter: Software-Architektur galt lange als die Disziplin, in Software-Projekten für einen kohärenten Zusammenhang zu sorgen: Es geht darum, Stabilität und Langlebigkeit zu gewährleisten, Standards einzuführen, für Sicherheit zu sorgen, Pläne und Dokumentationen zu erstellen, etc. Heute wird Software-Architektur oft auch anders diskutiert, und zwar im Sinne eines Change Management: Architekturen sollen flexibel, erweiterbar, austauschbar sein. Wie siehst du dich: Wie viel in deiner Arbeit ist Kirchenbauer, wie viel Change Manager?
Christian Stettler: Ich sehe das erstmal nicht als zwei Gegensätze – kann doch z.B. Flexibilität und Erweiterbarkeit auch zu höherer Langlebigkeit führen, weil das System so eben einfacher an neue Anforderungen angepasst werden kann. Ich persönlich möchte jeweils ein System bauen, welches natürlich die fachlichen Anforderungen unterstützen kann, dabei aber möglichst simpel und verständlich bleibt.
Ich bin überzeugt, dass solche Systeme einfacher zu verändern sind. Möglichst wenig Spekulation und Komplexität “auf Vorrat”, möglichst wenig Ballast im Rucksack. Durch Ansätze wie Continuous Delivery und den unterstützenden Organisationen, Abläufe und Infrastrukturen können wir uns erlauben, nur das zu bauen, was zum aktuellen Zeitpunkt allgemein verstanden wurde und benötigt wird.
Bei allem, was wir entscheiden und bauen, sollten wir davon ausgehen, dass dies nicht in Stein gemeißelt ist.
Natürlich ist es hilfreich, wenn ein Architekt dabei etwas über den Tellerrand hinausschaut und sich so mögliche Optionen zurechtlegt, die er bei Bedarf ziehen kann. So verringern wir das Risiko, dass wir uns in einer “pragmatischen” Sackgasse verrennen. Bei allem, was wir entscheiden und bauen, sollten wir davon ausgehen, dass dies nicht in Stein gemeißelt ist und sich die Realität ständig verändert – gleichzeitig darf das aber auch nicht als Ausrede dienen, die Dinge nur “halbgar” zu bauen. Um bei der Analogie der Frage zu bleiben: Ich baue gerne kleine Kapellen, welche bei Bedarf zu einer Kathedrale ausgebaut werden können – oder aber eben vielleicht auch einfach zu einem Party-Tempel umgebaut werden können.
LUST AUF MEHR SOFTWARE ARCHITEKTUR?
Zahlreiche aktuelle Themen wie KI, LLMS und Machine Learning, sowie Frontend-Architektur, für Tools zur Softwarearchitektur, Cloudlösungen und Software beweisen.
JAXenter: Wie schafft man es, den richtigen Mix aus Stabilität und Flexibilität zu finden? Hast du da vielleicht einen Tipp aus deinen langjährigen Erfahrungen?
Christian Stettler: Der Schlüssel zum Erfolg hier ist für mich ein breites und tiefes fachliches Verständnis – nicht nur von den konkreten Anforderungen im jeweiligen Projekt, sondern auch von äußeren Aspekten wie Strategie, Geschäftsmodell, Markt, laufende oder erwartete Umwälzungen, etc. Darauf lassen sich bessere Vermutungen anstellen, in welchen Bereichen wie viel Flexibilität und Dynamik notwendig ist und welche Aspekte eher als gegeben betrachtet werden können. Dies hilft, die typischerweise durch den Flexibilitätsbedarf gesteigerte Komplexität dort in Kauf zu nehmen, wo es sich lohnt. Dies ist nicht zuletzt auch eine wirtschaftliche Frage, die sich ein Architekt ebenso stellen sollte.
JAXenter: Im Zuge der DevOps-Bewegung erweitert sich das Bild des Software-Architekten noch um eine weitere Facette: Es geht nämlich nicht nur um Anwendungsentwicklung, sondern immer mehr auch darum, wie sich Anwendungen in einer Continuous-Delivery-Landschaft einbetten. „You build it, you run it“ heißt da das Stichwort. Wie hat die DevOps-Bewegung die Rolle des Software-Architekten verändert? Was musst du als Architekt heute anders machen, als früher, als man die Anwendungen noch einfach über den Zaun hin zum Ops-Team geworfen hat?
Christian Stettler: Früher galt es vor allem, die Rahmenbedingungen und Vorgaben des Betriebs möglichst gut zu kennen und darin (manchmal trotzdem) das aus fachlicher Sicht notwendige System zu platzieren, es also “passend” auf die Infrastruktur zu machen. Meiner Erfahrung nach gab es hier sehr oft ein relativ enges Korsett, z.B. bezüglich Laufzeitumgebung, Datenbanken, Netzwerkzonen, etc., welches wiederholt starken Einfluss auf die Architektur hatte. Das war zwar einengend, hat aber auch eine Menge von schwierigen Entscheidungen bereits vorweggenommen.
Heute erlebe ich es viel mehr so, dass wir aus Architektursicht diese Betriebsanforderungen und -umgebungen aktiv mitgestalten. Wir müssen identifizieren, welche Landschaft für das zu bauende System notwendig und geeignet ist, und nicht selten beteiligen wir uns auch im Aufbau dieser Umgebungen, zugehörigen Prozesse und Tools.
Dies bietet natürlich deutlich mehr Spielraum in der Gestaltung. Damit übernehmen wir als Team aber auch mehr Verantwortung und benötigen ein noch breiteres Verständnis der Möglichkeiten, Erfolgsfaktoren und Trade-Offs. Ich persönlich empfinde das aber auf jeden Fall als Bereicherung für meine Arbeit.
JAXenter: Ein weiterer Trend ist aktuell, das Design einer Software stark an den fachlichen Domänen auszurichten. Neben DDD als Theorie erobern gerade Microservices-Architekturen die Praxis. Neben den technologischen Aspekten, die Domänen-fokussierte Anwendungen mit sich bringen, geht es hier zentral auch darum, die beteiligten Leute erst einmal in ein Boot zu holen: Fachexperten, Entwickler und natürlich auch die Geschäftsleitung und Anwender bzw. Kunden. Ist man da als Software-Architekt nicht eigentlich zu 80% Projektmanager? Wie hältst du das persönlich: Wie stark nimmst du die Rolle des Projektmanagers ein, wie viel konzentrierst du dich auf Technologien?
Christian Stettler: Ich würde diese Rolle nicht als Projektmanager, sondern eher als Kommunikator oder Vermittler bezeichnen. Und dies ist meiner Ansicht nach eine ganz zentrale Rolle, welche ein guter Architekt einnehmen können sollte. Nicht selten haben wir dank der Architekturbrille eine sehr umfassende Sicht auf die Situation und können Stakeholder aus unterschiedlichen Bereich zusammenführen.
Technologien als solches sehe ich immer mehr nur als Mittel zum Zweck.
Wir müssen in der Lage sein, unterschiedliche “Sprachen” zu sprechen und Menschen miteinander zu verbinden, gelegentlich auch zwischen ihnen übersetzen. Dadurch stehen wir als Architekten wohl noch mehr am Dreh- und Angelpunkt als früher. Mir persönlich hat diese facettenreiche Herausforderung in der Vergangenheit und auch in den aktuellen Projekten jeweils viel Spaß bereitet.
Darüber hinaus kann man so viel Akzeptanz und Wertschätzung aufbauen, was in kritischen Momenten sehr hilfreich sein kann, um dann den nötigen Einfluss nehmen zu können. Technologien als solches sehe ich immer mehr nur als Mittel zum Zweck – Technologien alleine begeistern mich schon seit geraumer Zeit nur noch sehr kurzfristig.
Natürlich sind sie essentiell für die Umsetzung der Anforderungen, aber alleine damit gewinnen wir keinen Blumentopf. Entsprechend sollten wir uns auch nicht gleich zu Beginn auf Technologien stürzen, bevor wir das Umfeld und die Anforderungen nicht wirklich verstanden und sortiert haben.
JAXenter: Auf dem Software Architecture Summit hältst du einen Workshop zu Domain-driven Design. Dabei wird es darum gehen, Bounded Contexts ganz konkret in Code umzusetzen. Als Optionen erwähnst du die Onion Architecture und Stereotypen. Worum geht es dabei?
Christian Stettler: Dabei geht es darum, wie wir den fachlichen Fokus aus den Diskussionen mit unseren Stakeholdern und aus dem strategischen Design von DDD bis in den Code beibehalten können. Seit ich mich intensiv mit DDD beschäftige, verfolge ich den Anspruch, diesen fachlichen Fokus wirklich bis in die hinterletzte Code-Zeile zu tragen, die gemeinsame Sprache (sowohl die fachliche, als auch diejenige der Elemente der Applikationsarchitektur) darin abzubilden, und dabei die Fachlichkeit konsequent von Technologien und Frameworks zu trennen.
Dabei können die Konzepte der Onion Architecture und der Einsatz von Stereotypen wirklich helfen. Ich habe damit in der Vergangenheit in “Real World“ spannende Erfahrungen gemacht und auch wahrgenommen, dass Kollegen im Team (und auch ich) wiederholt einen “Eye Opener Moment” erlebten. In diesem Workshop möchte ich basierend auf diesen Erfahrungen aufzeigen, wie eine solche Umsetzung aussehen kann. Dabei möchte ich auch Aspekte ansprechen, über welche man erst stolpert, wenn man es wirklich tut.
JAXenter: Welchen Trend außer DDD findest du im Bereich der Software-Architektur momentan besonders spannend – und warum?
Christian Stettler: Mir gefällt generell der Trend zu “self-contained”, auf allen Ebenen, nicht nur auf der technischen. Ich finde es spannend, dass wir zunehmend in “Produkten” denken, nicht mehr in Projekten, und dass wir dabei langfristig Verantwortung für Problemstellungen und deren Lösungen übernehmen wollen, in der ganzen Breite und Tiefe und über den ganzen Lebenszyklus hindurch.
Software Architecture Summit vom 11. - 13. März in München
Technische und methodische Themen, Kommunikationstrends, Cloudlösungen, MLOps, Design und Psychologie
Dabei nehme ich war, dass sich der Fächer der konzeptionellen und technischen Möglichkeiten ständig verbreitert, was die Auswahl des erfolgsbringenden Ansatzes nicht einfacher macht. Die für eine gute Entscheidung aus meiner Sicht zwingend notwendige Nähe zum “Business” und anderen Disziplinen empfinde ich als herausfordernd und bereichernd. Dies erlaubt es uns auch, über die Zeit besser zu lernen, welche unserer Entscheidungen sinnvoll waren und in welchen Bereichen unsere Annahmen bzw. die Schlussfolgerungen daraus nicht richtig waren und weshalb. Dadurch sehen wir direkter, welchen Einfluss unsere Arbeit auf den Geschäftserfolg hat. Ich persönlich bin gerne dort, wie es “real” ist, auch wenn es dort nicht immer gemütlich ist.
JAXenter: Vielen Dank für dieses Interview!
Geschrieben von: Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
