7 Experten diskutieren aktuelle Architekturtrends - Teil 1

Praxis-Check Software-Architektur: Die Rolle des Architekten – vom Kathedralenbauer zum Change Manager?

Hartmut Schlosser

© Shutterstock / Peshkova

Die Disziplin der Software-Architektur ist in stetem Wandel. Die komplexen Architekturpläne, die einst vor der Anwendungsentwicklung auf dem Reißbrett entworfen wurden, gehören längst der Vergangenheit an. Heute sind Werte wie Agilität, Flexibilität, Erweiterbarkeit gefragt. Wir haben uns mit sieben Experten über die heutige Rolle des Software-Architekten unterhalten. Im dreiteiligen „Praxis-Check Software-Architektur“ präsentieren wir die Ergebnisse.

Praxis-Check Software-Architektur – Teil 1

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. Ist die Rolle des modernen Software-Architekten vergleichbar mit der eines Change Managers?

Softwarearchitektur heute – Kirchenbauer oder Change Manager?

Die Experten

Ralf D. Müller arbeitet als Architekt und Entwickler und erlebt täglich die Notwendigkeit effektiver Dokumentation. Er ist erklärter AsciiDoc-Fan und Committer bei arc42 sowie Gründer des docToolchain Projektes.

Eberhard Wolff ist Fellow bei innoQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie.

Henning Schwentner (@hschwentner), Coder • Coach • Consultant bei der WPS – Workplace Solutions

Ana Medina – Software-Entwicklerin und Chaos Engineer bei Gremlin, San Francisco

Michael Plöd – Principal Consultant bei innoQ. @bitboss

Andreas Weigel ist Softwareentwickler und Berater bei synyx GmbH & Co. KG

Christian Stettler ist Senior Consultant und Architekt bei INNOQ in der Schweiz

 

 

JAXenter: Software-Architektur steht heute im Spannungsfeld zwischen Stabilität und Flexibilität. Wie siehst du dich: Wie viel in deiner Arbeit ist Kirchenbauer, wie viel Change Manager?

Aktuelle Ansätze setzen darauf, Komponenten ersetzbar zu machen, um so der mangelnden Langlebigkeit zu entgehen. Das bieten Microservices.

Eberhard Wolff: Stabilität und Standards sind keine Ziele, sondern Mittel, um ein wartbares System zu erstellen. Wenn die Software einheitlich gestaltet ist, können Entwickler sich leichter einarbeiten und die Systeme einfacher ändern. Also ist dieses Vorgehen nur dazu da, um Änderbarkeit zu erreichen. Aber dieser Ansatz funktioniert nur theoretisch. In der Praxis verlieren große Systeme mit der Zeit ihre Struktur und ihre Einheitlichkeit. So werden sie immer schwerer wartbar, was die Langlebigkeit begrenzt. Daher setzen aktuelle Ansätze darauf, Komponenten ersetzbar zu machen, um so der mangelnden Langlebigkeit zu entgehen. Das bieten Microservices. Sie können ersetzt werden, und zum Ersetzen können auch neue Technologien genutzt werden. Ebenso ist es möglich, Microservices mit unterschiedlichen Technologien zu implementieren und so mit der Vielfalt besser umzugehen.

Ralf D. Müller: Beide Aspekte der Architektur – Stabilität und Flexibilität – müssen wie immer ausgewogen vorhanden sein und bauen aufeinander auf. Erst wenn gewisse Standards existieren und die Vorgehensweise, Schnittstellen etc. dokumentiert sind, lässt sich eine Architektur auch gut ändern, ohne die Stabilität zu riskieren. Deshalb ist es ja auch so wichtig, dass die Architektur gut kommuniziert und die Pfade zur Umsetzung der architekturellen Aspekte ausgetrampelt werden. Nur wenn jeder im Team weiß, auf was es architekturell ankommt, entsteht die benötigte Stabilität, um später flexibel auf geänderte Anforderungen reagieren zu können. Das arc42-Template von Gernot Starke und Peter Hruschka hilft hier bei der Strukturierung der Dokumentation.

Henning Schwentner: Beide Rollen sind untrennbar. Stabilität im Großen bekommen wir über Flexibilität im Kleinen. Das Interessante ist ja, dass insbesondere die großen Systeme, weil sie am längsten leben, gerade deshalb am flexibelsten sein müssen. Deswegen finde ich es gut, dass Trends wie Microservices und Self-Contained Systems die (im Prinzip alten) Ideen, wie man ein System vernünftig modularisiert, im Mainstream ankommen lassen. Der wichtigste Punkt ist: Wir wollen nicht ein großes Domänenmodell haben, sondern mehrere kleine. Die kleinen Domänenmodelle können dann verständlich, beherrschbar und flexibel sein.

Andreas Weigel: Beides hat Anteile an meiner Arbeit, die Rolle des Software-„Change Managers“ überwiegt jedoch. Ein agiler Entwicklungsprozess ist unsere Antwort auf die sich ständig verändernden Anforderungen der schnelllebigen Branchen heutzutage. Im Kern gibt uns der iterative Charakter dieser agiler Prozesse die Chance, früh Feedback zu erhalten und darauf mit Anpassungen zu reagieren. Damit muss die Architektur stets flexibel und erweiterbar gedacht werden. Dennoch gehört eine Architekturvision als grobe Leitplanke dazu, um zu gewährleisten, dass das Team ein einheitliches Bild hat und ein gemeinsames Ziel ansteuert. Also einige Impulse als Kirchenbauer, aber tatsächlich überwiegend als 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. 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 gemeisselt 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.

Michael Plöd: Ich denke, die Situation von Software-ArchitektInnen ist immer stark getrieben von der Ausgangslage, in der man tätig ist. Es wird sicherlich viele Kolleginnen und Kollegen geben, deren Arbeit zu einem großen Teil das Kirchenbauen ist, und das gleiche gilt für das Thema Change Management. Unabhängig von der Ausgangslage ist für mich die wichtigste Tätigkeit die Kommunikation mit unterschiedlichen Stakeholdern, welche wiederum unterschiedliche Informationsbedarfe haben und meist sogar unterschiedliche „Sprachen sprechen“: von fachlich bis hin zu technisch.

Lesen Sie auch: Praxis-Check Software-Architektur: Conway’s Law auf der Spur

Ana Medina: Ich stand schon immer auf der Seite der Konstrukteure von Dingen, angefangen beim Entwickeln von Web- und Mobile-Anwendungen bis hin zum Bauen von Infrastrukturdiensten. Auf diesem Weg gelangte ich zu meinem aktuellen Titel als „Site Reliability Engineer“ und begann mit der Arbeit am Chaos Engineering. Ich glaube, meine Arbeit ist irgendwie eine Kombination aus Bauen und Abreißen von Kathedralen. Ich habe mich mit meinem Kollegen darüber unterhalten und eine Analogie, die ins Gespräch kam, war, dass der Bau von Kathedralen dem Bau von Software-Monolithen ähnelt. Meine Arbeit besteht aber im Bauen von verteilten Systemen.

Der Bau von Kathedralen ähnelt dem Bau von Software-Monolithen.

Bei einer Kathedrale baut man Schicht für Schicht – erst nach dem Legen der ersten Schicht kann man mit der nächsten beginnen. Der Aufbau verteilter Systeme gleicht eher der Entwicklung einer Stadt. Man kann mit einem Gebäude beginnen, aber bald merkt man, dass man mehr skalieren und bauen muss, ohne das aktuelle Gebäude verändern zu müssen. Wenn eine Stadt mehr Aufmerksamkeit und Verkehr bekommt, müssen weitere Gebäude, Geschäfte und Parks hinzugefügt werden. Man muss nicht schon zu Beginn wissen, wo diese Anlagen stehen sollen – das ist das Schöne daran!

Als Chaos Engineer setze ich mich dafür ein, dass Unternehmen und Entwickler ihre Infrastrukturen absichtlich zerbrechen. Es ist eine ungewöhnliche Denkweise, aber sie hilft Unternehmen, Ausfallzeiten zu vermeiden. Die Praxis des Chaos Engineering wird von Kolton Andrus, dem CEO von Gremlin, als „durchdachte, geplante Experimente, die die Schwächen unserer Systeme aufdecken sollen“ definiert. Anstatt den Wandel zu bewältigen, geht es in meiner Arbeit darum, Veränderungen vorzunehmen, Dinge zu lernen und weiter zu iterieren, um widerstandsfähigere Kathedralen und Städte zu bauen.

W-JAX 2018 Java-Dossier für Software-Architekten

Kostenlos: 40+ Seiten Java-Wissen von Experten

Sie finden Artikel zu Enterprise Java, Software-Architektur, Agilität, Java 11, Deep Learning und Docker von Experten wie Kai Tödter (Siemens), Arne Limburg (Open Knowledge), Manfred Steyer (SOFTWAREarchitekt.at) und vielen weiteren.

Software-Architektur in Zeiten von DevOps & Continuous Delivery

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. Was muss man in Zeiten von DevOps und CD als Architekt anders machen, als früher, als man die Anwendungen noch einfach über den Zaun hin zum Ops-Team geworfen hat?

JAXenter: Wie hat die DevOps-Bewegung die Rolle des Software-Architekten verändert?

Eberhard Wolff: Eigentlich geht es immer noch um dasselbe: Ein System ist für Anwender nur nützlich, wenn es in Produktion ist. Das ist mittlerweile durch Continuous Delivery und DevOps offensichtlich. Daher sollte der Architekt auch diesen Aspekt betrachten. Das klassische Ziel der einfachen Änderbarkeit kann durch Continuous Delivery ebenfalls besser erreicht werden: Software, die schneller und einfacher in Produktion gebracht werden kann, ist einfacher änderbar, weil Änderungen schneller dahin gebracht werden, wo es zählt: In die Hände der Nutzer und zwar abgesichert durch Tests. Auf der anderen Seite ist die einfache Betreibbarkeit einer Anwendung eine Voraussetzung für eine möglichst einfache Continuous-Delivery-Pipeline. Das kann die Auswahl der Technologien einschränken oder dazu führen, dass Ops-Anforderungen wie Monitoring oder Logging schon frühzeitig betrachtet werden. Das verringert das Risiko und macht allen – Betrieb und Entwicklung – das Leben einfacher

Ralf D. Müller: Hat man das früher gemacht – Anwendungen einfach über den Zaun hin zum Ops-Team geworfen? 😉 Der Betrieb der Software war schon immer ein wichtiger Aspekt der Architektur. Eine Applikation wird meist länger betrieben, als entwickelt. Somit ist der Aspekt des Betriebs für den Erfolg der Software mindestens genauso wichtig wie z.B. der Aspekt des Clean Code.

Der Betrieb der Software war schon immer ein wichtiger Aspekt der Architektur.

Aus meiner Sicht hat sich in diesem Bereich die wichtigste Änderung nicht direkt durch DevOps ergeben, sondern durch die iterativen Entwicklungszyklen eines agilen Projekts. Es gibt nicht mehr das Upfront-Design der Architektur, sondern man kann ein Projekt nun über mehrere Release-Zyklen begleiten. Dadurch sieht der Architekt vor allem, wie die Architektur die Qualitätskriterien des Projekts auch tatsächlich implementiert und kann die Architektur entsprechend anpassen.

Henning Schwentner: Mir geht es da wie vielen: Ich freue mich, dass die unnatürliche Trennung von Entwicklung und Betrieb aufgehoben wird. Als Entwickler und Architekt wird man jetzt von Anfang an darauf fokussiert, nicht eine ausführbare Datei, sonderen laufende Software auszuliefern.  Und nur die hat Wert für den eigentlich wichtigen Menschen – unseren Anwender.

Lesen Sie auch: Praxis-Check Software-Architektur: Was macht gute Architektur aus?

Andreas Weigel: Nicht nur ein Architekt, sondern das gesamte Team muss sich den Betriebsthemen öffnen und die DevOps-Bewegung als Chance wahrnehmen, das entwickelte Produkt ganzheitlich zu verantworten. Aus dem Entwicklungsteam wird ein crossfunktionales Produktteam mit sinkenden Abhängigkeiten bzw. sinkendem Kommunikationsaufwand und folglich schnellerer Reaktionszeit.

„Infrastructure-as-Code“-Werkzeuge erleichtern den Einstieg in die Betriebsthemen und ermöglichen gleichzeitig einen hohen Automatisierungsgrad. Natürlich sieht sich das Team mit neuen Aufgaben konfrontiert. An dieser Stelle sollte die Architektenrolle Offenheit gegenüber der neuen Thematik vorleben. Abhängig von vereinbarten Service Level Agreements, könnte zum Beispiel eine (Ruf-)Bereitschaft zum Aufgabengebiet des Teams werden, was aus Erfahrung positive Auswirkungen auf die Stabilität des Systems hat, da niemand nachts geweckt werden will.

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 Bereichen zusammenführen. 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.

Architekten müssen in der Lage sein, unterschiedliche „Sprachen“ zu sprechen und Menschen miteinander zu verbinden.

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

Michael Plöd: Ich denke ehrlich gesagt, dass auch früher nichts „einfach“ zum Ops Team rübergeworfen werden konnte. Im Gegenteil, das war meist ein komplexer und von vielen Missverständnissen geprägter Vorgang, welcher stark davon lebte, wie gut die Architektinnen und Architekten den Stakeholder „Betrieb“ in ihre Diskussionen eingebunden habe. Eigentlich hätte das Berücksichtigen von Ops-Anforderungen ständig stattfinden müssen, was natürlich unter der organisatorischen Trennung litt. Ich denke, durch DevOps werden viele dieser vormals implizit versteckten Themen zu expliziten Treibern für die Arbeit von Architektinnen und Architekten.

Weiter geht es mit Teil 2 unseres Praxis-Checks Software-Architektur. Dabei nehmen wir uns die Themen Domain-driven Design und Microservices vor und klären, wie man den Spagat zwischen Stabilität und Flexibilität einer Software-Architektur schafft.

Microservices: Patterns und Antipatterns from JAX TV on Vimeo.

Geschrieben von
Hartmut Schlosser
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
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: