Suche
7 Experten diskutieren aktuelle Architekturtrends - Teil 2

Praxis-Check Software-Architektur: DDD, Microservices und die Rolle als Projektmanager

Hartmut Schlosser

© Shutterstock / mamanamsai

Wir haben uns mit sieben Experten über die heutige Rolle des Software-Architekten unterhalten. Ging es im ersten Teil um die Frage, was vom alten Modell des Software-Architekten als Kathedralenbauer übrig geblieben ist, wenden wir uns heute der Aufgabe des Architekten als Vermittler zwischen Fachlichkeit und Technologie zu.

Praxis-Check Software-Architektur – Teil 2

Ein Architektur-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?

DDD & Microservices – vom Architekten zum Projekmanager?

Architektur ist eigentlich die Strukturierung der Fachlichkeit.

JAXenter: Wie stark nimmst du in deiner Arbeit als Software-Architekt die Rolle des Projektmanagers ein, wie viel konzentrierst du dich auf Technologien?

Eberhard Wolff: Fachliche Anforderungen zu verstehen ist zentral, um die richtigen Probleme zu lösen. Außerdem ist Architektur eigentlich die Strukturierung der Fachlichkeit. Das geht nur mit fachlichem Wissen und dem Austausch mit fachlichen Experten. Das ist aber kein Projektmanagement und auch nichts Neues. Domain-driven Design ist auch schon fast 15 Jahre alt. Am Ende sollte der Architekt wie alle anderen auch seinen Teil dazu beitragen, dass das Projekt erfolgreich ist. Dazu ist die Fachlichkeit und ihre Strukturierung meist wichtiger als die Technik.

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

Ralf D. Müller: Es stimmt schon, dass Software-Architektur streckenweise mehr mit Management als mit Technologie zu tun hat. Aber wie bei allem hängt es sehr stark vom eigentlichen Projekt und des Typs „Architekt“ ab, den man verkörpert. Mich selbst würde ich weniger als Projekt-, sondern mehr als Architekturmanager sehen. Die Architektur, die in meinem Kopf ist, muss irgendwie raus in die Umsetzung. Das geschieht durch Dokumentation, Kommunikation und auch Management.

Henning Schwentner: Von Jerry Weinberg wissen wir: »No matter how it looks at first, it’s always a people problem.« Die erste Aufgabe jedes Menschen, der mit Softwareentwicklung beschäftigt ist, ob er nun Programmierer, Architekt, Projektmanager oder wie auch immer heißt, ist, mit anderen Menschen zu kommunizieren. Mit Computern zu kommunizieren kommt frühestens auf Platz zwei.

Technologien sind nicht unwichtig, aber sekundär. Frag dich mal selbst: Von wievielen Programmen und Apps, die du einsetzt, weißt du, welche Programmiersprache, Frameworks usw. darin verwendet wird? Ist dir das wichtig? Oder willst du lieber, dass die ihren Job machen?

Die Gemeinheit ist: In der Software-Entwicklung gilt das Anna-Karenina-Prinzip, d.h. ein Projekt kann nur dann erfolgreich sein, wenn alle Faktoren stimmen. Technologien kennen und beherrschen wird deshalb immer wichtig und nötig sein.

Andreas Weigel: Für den Erfolg eines Produktes sind manchmal Prozessänderungen erforderlich, die aus dem Team heraus z.B. von einem Architekten gefordert werden. Wie hoch der notwendige Aufwand ist, hängt von der Flexibilität der Organisation ab. Maßgeblich sind dabei die Länge der Kommunikationswege sowie das Vertrauen untereinander. Beide Faktoren nehmen zu Projektbeginn mehr Zeit in Anspruch. Durch zunehmende direkte Kommunikation auf der einen Seite und Projekterfolge auf der anderen Seite nimmt der Aufwand für Aufgaben neben der reinen Softwareentwicklung über die Projektlaufzeit ab.

Im aktuellen Kundenprojekt haben wir etabliert, dass Akzeptanztests zusammen mit dem Product Owner, dem Functional Owner und einem Entwickler erstellt werden. Die Tests dienen als Contract zwischen den Parteien, schärfen das Problemverständnis und schaffen Vertrauen in die Software und das Team. Zu Beginn hat der ungewohnte Prozess mit den neuen Beteiligten mehr Zeit in Anspruch genommen. Mittlerweile ist er fester Bestandteil des Sprints. Ich sehe den Architekten weniger als Projektmanager, auch wenn er vor allem zu Beginn eines Projektes neue Prozesse etablieren oder bestehende Prozesse adaptieren muss. Der Projektmanager bettet das Produkt in einen größeren Kontext ein und verantwortet weitere Themen wie Personal und Budget.

Ana Medina: Ich glaube definitiv, dass sich die Rolle des Software-Architekten sehr verändert hat. Ich konzentriere mich derzeit hauptsächlich auf die technologische Seite der Dinge. Technische Inhalte lesen, mit verschiedenen Tools herumspielen und die Infrastruktur anderer Unternehmen kennen lernen.

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.

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 solche 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: Software-Architektur und Projektleitung bleiben weiterhin zwei getrennte Disziplinen. Ich als Software-Architekt sehe mich hier eher in einer coachenden Rolle für die Projektleitung. Ich vermittle, warum integrierte Teams eine gute Idee sind, ich gebe Hinweise und Pro- und Contra-Argumentationen im Hinblick auf die Kombination von Organisation und Entwicklung bzw. Architektur. Aber ich halte mich weitestgehend aus Themen wie Budgets oder Timesheets heraus.

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.

Wie flexibel müssen Architekturen sein?

Software-Architekturen stehen im Spannungsfeld zwischen Stabilität und Flexibilität. Einerseits geht es darum, Langlebigkeit zu gewährleisten, Standards einzuführen, für Sicherheit zu sorgen, Pläne und Dokumentationen zu erstellen, etc. Andererseits sollen Architekturen flexibel an sich immer schneller verändernde Bedürfnisse bzw. Marktgegebenheiten angepasst werden können.

JAXenter: Wie schafft man es, den richtigen Mix aus Stabilität und Flexibilität zu finden?

Eberhard Wolff: Meiner Meinung nach liegt das Problem auf einer anderen Ebene: Stabilität und Flexibilität sind nur unterschiedliche Wege, um das Ziel Wartbarkeit zu erreichen. Meistens treffe ich in Projekten auf das Problem, dass die Ziele des Projektes unklar sind oder nicht in der Architektur abgebildet worden sind.

Sicher ist Wartbarkeit wichtig, damit man auch in der Zukunft noch das System anpassen kann. Aber wenn das System gar nicht in Produktion geht, weil es Compliance-Richtlinien nicht einhält, die notwendige Performance nicht erreicht oder die Vorgaben im Betrieb nicht erfüllt, hilft die Wartbarkeit nichts. Und wenn das System in den Betrieb geht, aber kein sinnvolles Geschäftsziel unterstützt, ist das System ebenfalls sinnlos.

Architektur bedeutet, eine technische Lösung für ein Problem zu finden. Das wiederum bedeutet, das Problem zu kennen. Zu oft wird einfach nur Wartbarkeit angestrebt – ohne die wirklichen Probleme überhaupt zu lösen oder zu analysieren.

Ralf D. Müller: Jedes Projekt ist anders und bringt unterschiedliche Anforderungen bezüglich Stabilität und Flexibilität mit. Deswegen ist es wichtig, einen Blick auf die Requirements zu werfen und nicht einfach eine interessante Architektur eines anderen Projekts zu übernehmen. Die Requirements geben meist vor, welcher Teil der Architektur flexibel und welcher stabil sein muss. Soll z.B. ein White-Label Produkt erstellt werden, dann ist das Design sicherlich flexibler zu halten als bei einer Anwendung zur internen Verwendung. Aber die beiden Attribute müssen sich auch nicht widersprechen: Erst die Stabilität in den Schnittstellen zwischen wohldefinierten Modulen ermöglicht die Flexibilität zur Änderung einzelner Module.

Man muss sich immer wieder klar machen, dass Software kein Selbstzweck ist.

Henning Schwentner: Erstens: sich immer und immer wieder klar machen, dass Software kein Selbstzweck ist. Software (und auch Softwarearchitektur) bauen wir nicht für uns selbst, sondern für den Fachexperten. Zweitens: nicht nach dem einen Domänenmodell streben, das alle Probleme auf einmal löst. Das wird nämlich viel zu groß, fehleranfällig und schwer verständlich. Interessanterweise also gleichzeig instabil und unflexibel. Stattdessen wollen wir mehrere kleine Modelle.

Andreas Weigel: Stabilität und Flexibilität spielt an unterschiedlichen Stellen eine Rolle. Generell treffen wir viele Entscheidungen, die darauf einzahlen, ein autarkes Entwicklungsteam zu sein. Das betrifft insbesondere Schnittstellen zu anderen Teams sowie den vertikalen Schnitt der Software, um ein Feature ganzheitlich ausliefern und verantworten zu können. Die dadurch gewonnene Stabilität nach außen gibt uns auf der anderen Seite die Flexibilität innerhalb den von uns verantworteten Produkten. Außerdem streben wir stets nach Einfachheit in unserem Architekturdesign, etwa durch das Verfolgen von Prinzipien wie YAGNI und KISS.

Ana Medina: Die Infrastruktur sollte stabil und konsistent sein, aber einen gewissen Spielraum bieten, um Veränderungen zu ermöglichen. Die Arbeit im Cloud-Native-Bereich hat mich gelehrt, dass Flexibilität ein Ziel ist, auf das hin optimiert werden sollte. Beispielsweise bei der Fähigkeit, bei Bedarf mehr Ressourcen einzubinden und nach der tatsächlichen Nutzung zu bezahlen. Mein Tipp: Wenn man sich bei der Entwicklung schon früh Gedanken über die Zuverlässigkeit des Systems macht, ist die Stabilität das Fundament für eine mögliche Flexibilisierung.

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.

Michael Plöd: Nehmt Qualitätskriterien ernst und verhandelt diese explizit mit euren Stakeholdern. Aus diesen könnt Ihr als Architektinnen und Architekten häufig sehr brauchbare Indikationen für den richtigen Mix aus Stabilität und Flexibilität ableiten.

Weiter geht es mit Teil 3 unseres Praxis-Checks Software-Architektur. Es wird 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.

MEHR ZUM THEMA:

Die Rolle des Architekten im 21. Jahrhundert

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: