Die Rolle von Softwarearchitekt in Scrum

Heutzutage ist Scrum sehr populär in Softwareentwicklungsprojekten, indem seine agile, iterative und zielorientierte Methodik die Entwickler ermöglicht, selbst zu organisieren, Komplexität zu beherrschen, kommunikativ zusammenzuarbeiten, effektiv zu liefern und sich kontinuierlich zu verbessern.  Nach dem Spirit der agilen Entwicklung stehen die Domain Experten, die Kunden und sogar die End-Users so nah wie nie zuvor zu den Entwicklungsteams, um die Feedback-Zyklen zu kürzen.

Es scheint allem so zu sein, dass die langen Requirement- und Designphasen des traditionellen Wasserfall-Modells nicht mehr notwendig sind, weil man bei dieser Digitalisierungswelle nicht wirklich vorsehen könnte, wie die Märkte in langfristiger Zukunft ausschauen sollten.

Es erfolgt, dass die klassische Rolle der Softwarearchitekten schwammig würde. Ihre Designaufgaben werden von den Produkt-Ownern und den Entwicklern zusammen erledigt. Ihre Entwicklungsbegleitungsaufgaben werden von Senior-Entwicklern gemacht. Ihre Integrations- und Lieferungsaufgaben werden von DevOps geleistet. 

Ich, als ein System/Softwarearchitekt mit 10 Jahre Berufserfahrung, finde es ist wahr, dass ein agiles Entwicklungsprojekt kann ohne Softwarearchitekt laufen. Aber die Themen der Softwarearchitektur müssen immer noch von jemanden erledigt werden. Ohne sie ernsthaft und systematisch zu betrachten, ist tragische Konsequenz vorzusehen. 

Ich habe mehrere Projekte mitgemacht, miterlebt oder beobachtet und gefunden, als keinem Teamkollege die Rolle des Softwarearchitektes dafür genannt wurde, wollte auch niemand dafür zuständig sein, denn die Rolle ist keine einfache leichte Aufgabe. Aus meiner Beobachtung können die Entwickler ohne Delegation ehe schlecht diese Rolle spielen. Das könnte wegen mangelnder Ausbildung und Erfahrung, wegen fehlender Autorität, wegen abwesender Motivation, oder einfach wegen unzureichenden Soft-Skills sein.

Ein Softwarearchitekt wirkt als eine Brücke zwischen fachlichen und technischen Stakeholders und als ein Überwacher zwischen abstrakten Designs und konkreten Umsetzungen. Er muss in agilen Projekten nicht mehr, ausführliche und komplexe UML-Diagramme malen und daraus Code generieren lassen. Er braucht nicht mehr als Coach (oder Baby Sitter) von Entwicklern zu arbeiten. Auf die Entwickler, je nach dessen Kompetenz, kann er schon mehr oder weniger verlassen, dass sie die erwünschten Verhalten jeder Komponente liefern können. Er kann endlich darauf konzentrieren, dass das Softwareprodukt, das aus mehreren Komponenten besteht, gute Struktur hat[1].

Es gibt gute Struktur oder schlechte Struktur, aber kein Softwareprodukt hat keine Struktur. Nur mit guter Struktur können die sogenannten nicht-funktionalen Anforderungen wie Effizienz, Skalierbarkeit, Sicherheit, Wartbarkeit (Erweitbarkeit, Änderbarkeit, Verfolgbarkeit, Ersatzbarkeit...), Testbarkeit, Zuverlässigkeit, Verfügbarkeit, Portabilität usw. gewährleistet werden. Die Rolle von Softwarearchitekt ist genau dafür gedacht, immer auf gute Struktur der Softwareprodukte zu achten und über die Tellerrand zu weiterschauen, wie die Softwarekomponenten mit einander sauber und zuverlässig zusammenspielen sollen und können. Ein Softwarearchitekt soll sich aktiv an den teamübergreifenden Themen teilnehmen und die Verantwortungen zu sich ziehen, damit die gemeinsamen Interessen der Teams, z.B. Kommunikationen (REST, SOAP, Messaging, RPC usw.), Logging, Error-Handling, Monitoring, Authentifizierung und Autorisierung einheitlich ohne Bruchstellen durchgesetzt werden. Ein Softwarearchitekt soll die architektonischen Diskussionen und Schlussfolgerungen dokumentieren, konkretisieren, immer darauf achten und teamübergreifend kommunizieren, während die anderen Teamkollegen meistens nur die "Entwickelbarkeit" betonen, um ihre Software anständig effektiv auszuliefern.

Das macht noch mehr Sinn in Welt der Microservices, z.B. um einen Geschäftsprozess zu schaffen, involvieren immer mehrere Microservices, die auf diversen Servern oder auf Cloud laufen. Es ist nicht mehr möglich, durch einfache Setzung von Break-Points, den ganzen Prozess zu debuggen. Ohne einheitlichen Logging und Error-Handling-Mechanism lassen sich die eventuellen Laufzeitfehler sehr schwierig effizient und effektiv lokalisieren und sich daraus die Lösung ausarbeiten.

Ein Softwarearchitekt ist ein Designer seines Scrum-Teams. Durch seine Beiträge kann der Auftraggeber die kontinuierlichen Feature-Lieferungen erhalten, dadurch dass weniger technische Schulden entstehen. Deswegen soll der Softwarearchitekt seine Bemühungen im Scrum-Backlog sichtbar machen und sie nach Rücksprache mit dem Produkt-Owner bzw. dem ganzen Team in den entsprechenden Sprint einplanen, normalerweise bevor die Programmierung der User Stories anfängt.

Während der Implementierung ist ein Softwarearchitekt ein Entwickler. Er soll hautnah zu dem Code. Nur wenn er mitmacht, kann er die Fragen der anderen Entwickler besser beantworten, die Umsetzung der anderen besser verstehen und auf eventuelle Designänderungen vernünftig reagieren.

Nach der Implementierung ist ein Softwarearchitekt ein Bewerter. Er soll die Umsetzung gegenüber der Design auf die Compliance prüfen. Darüber hinaus soll er anhand der von ihm eingeleiteten Integrationstests das Zusammenspiel der gelieferten Features mit dem Kontext validieren.

Für alle oben genannte Einsätze ist die Kommunikationsfähigkeit eine  der Kernkompetenzen eines Softwarearchitektes. Seine Arbeit ist niemals nur IT-technisch. Die zwischenmenschlichen Soft-Skills spielen eine entscheidende Rolle. Die Softwarearchitektur ist praktisch keine statische Gestaltung. Es gibt immer Änderungen wegen z.B. neuen ungeplanten Anforderungen oder wegen verschiedenen Projektphasen. Ein Softwarearchitekt muss immer Überzeugungen einbringen, die architektonischen Änderungen zu widerstehen oder anzunehmen. Die Überzeugungszielgruppen können sowohl die Fachabteilungen oder Manager, als auch die Scrum-Teams sein. Außerhalb den Scrum-Teams soll ein Softwarearchitekt die technischen Details verständlich abstrahieren, während er innerhalb den Scrum-Teams die Überlegungen und Begründungen immer konkretisieren muss. Die verständlichen und taktvollen Ausprägungen sind extrem wichtig, da die Zuhörer keine Softwareprogramme sondern unterschiedlichen Typen von Menschen mit sensitiven Gefühlen sind. Ein Softwarearchitekt muss lernen, wie man mit den Stakeholders umgeht, sie überzeugt oder überzeugen lässt. Meines Erachtens dazu noch soll ein Softwarearchitekt darauf achten, nicht in die unendlichen Diskussionen und Meetings zu geraten, wo schließlich keine Lösung ausgearbeitet werden kann. Insbesondere für die philosophischen Fragen, die keine objektiven Antworten haben, sollte er kompromissbereit sein, um eine gemeinsam akzeptierbare Lösung zu finden.

[1] Clean Architecture, Robert C Martin