Architecting for Quality: Qualität methodisch herbeiführen (4/4)

Recap Teil 3

Im vorigen, dritten Teil der Serie zum Thema Architecting for Quality haben wir einen Blick auf die Anforderungsanalyse geworfen. Wir haben Qualitätsszenarien als Mittel der Wahl für Qualitätsanforderungen vorgestellt und anschließend die Einflussfaktorenanalyse als zentrale Methode der Architekturarbeit vorgestellt.

Dieser vierte und letzte Teil gibt einen (natürlich auf Qualität fokussierenden) Einblick in die übrigen Phasen und Tätigkeiten des Software-Lebenszyklus: Entwurf, Dokumentation, Implementierung, Test und Monitoring.

Entwurf

Nachdem wir die kritischen Einflussfaktoren methodisch herausgearbeitet, spezifiziert und priorisiert haben, können wir zentrale Architekturthemen identifizieren. Das sind diejenigen Themen, die für das zu entwerfende System zentral bzw. risikobehaftet sind. Häufig gehören dazu mehrere kritische Einflussfaktoren, die zueinander in starker Wechselwirkung stehen. Sie können sich dabei ergänzen oder widersprechen.

Für diese Architekturthemen gilt es nun, Lösungsstrategien zu erarbeiten. Zu den Strategien gehört die Anwendung von Taktiken, Patterns und Prinzipien sowie die Auswahl und Kombination passender Technologien. Eine mögliche Strategie, um eine sehr kurze Lead Time zu erreichen, wäre die Wahl einer Microservice Architektur.

Transparente Kommunikation

Neben der puren Entwurfsarbeit ist es aber genauso entscheidend, dass wir Konflikte rechtzeitig transparent machen und mit den verschiedenen Stakeholdern thematisieren. Denn manche scheinbar kaum lösbaren Konflikte können sich manchmal schnell in Luft auflösen oder zumindest deutlich entschärft werden. Damit können wir häufig noch rechtzeitig das Setzen falscher Prioritäten vermeiden oder die unnötige Verschwendung von Ressourcen durch das Implementieren aufwändiger Lösungen verhindern.

Dokumentation

Zu guter Architekturarbeit gehört eine gute Dokumentation. Nicht weil dies irgendein ein Prozess erfordert, sondern weil eine gute Dokumentation die Basis dafür ist, dass Architektur nachhaltig ist und langfristig methodisch erarbeitet werden kann.

Frühzeitig und inkrementell

Dokumentation sollte frühzeitig und inkrementell erfolgen, begleitend zu den Analyse-, Entwurfs- und Implementierungstätigkeiten. Wer einmal gespürt hat, wie es sich anfühlt, wenn gute Dokumentation ernsthaft gelebt wird, wird „Dokumentieren“ hoffentlich nicht mehr als lästige Pflicht empfinden, sondern als befriedigenden, anspruchsvollen Teil einer zeitgemäßen Entwicklungsarbeit.

Das heißt als Konsequenz: Bevor wir auch nur angefangen haben, die ersten Zeilen Code zu schreiben, sollten wir schon viele Arbeitsergebnisse dokumentiert haben. Dazu zählen mindestens die Resultate der Anforderungsanalyse, der Einflussfaktorenanalyse und entwickelte Strategien und Konzepte. Dies erlaubt es uns außerdem, eine erste, frühe (d.h. vor der Implementierung stattfindende) Architekturbewertung vorzunehmen.

Qualität in arc42

Was die eigentliche Architekturdokumentation angeht, so halte ich die Struktur nach dem arc42 Template in den meisten Fällen für die beste Wahl. Als Quasistandard für Softwarearchitekturdokumentation im deutschsprachigen Raum beleuchtet deswegen auch arc42 Qualität ganz explizit: Qualitätsziele sowie Qualitätsanforderungen mit Qualitätsbaum und Qualitätsszenarien sind essenzielle Bestandteile.

Implementierung

Die Implementierung liegt zwar außerhalb der Hauptverantwortlichkeit der Architekturdisziplin. Dennoch ist es unsere Aufgabe als Architekt*innen sicherzustellen, dass die Implementierung die Entwurfskonzepte umsetzt. Neben dem nachträglichen Abgleich von Code und Entwurf mittels Reviews und Analysetools sind wir dafür verantwortlich, das Team in Architekturfragen zu unterstützen. Und wir tragen Sorge dafür, dass ein gemeinsames Verständnis bzgl. Konzepte, Strategien und Entscheidungen besteht.

Architecting for Quality im Weiteren Sinne bedeutet außerdem, dass wir die Möglichkeit nutzen, Qualitätsziele in der täglichen Entwicklungsarbeit zu verankern. Über Review Guidelines können wir gezielt den Blick auf Qualitätsattribute wie Sicherheit, Benutzerfreundlichkeit oder Wartbarkeit lenken. Standups, Refinements und Retrospektiven als regelmäßige Events sind eine wunderbare Gelegenheit, um Qualitätsthemen ständig sichtbar im Fokus zu halten. Und natürlich sollte auch das Backlog Qualitätsaspekte und architekturelle Tätigkeiten explizit widerspiegeln.

Test, Bewertung, Monitoring

Die schönsten Konzepte und Lösungsstrategien auf dem Papier taugen am Ende aber nichts, wenn sie sich nicht auch in der Praxis bewähren.

Durch geschicktes Auswählen, was wir früh implementieren, können wir architektonische Risiken rechtzeitig unter die Lupe nehmen. Das Feedback aus der Implementierung zeigt uns, ob wir auf dem richtigen Weg sind. Tests, z.B. Lasttests, als quantitative Bewertungsverfahren und szenariobasierte Methoden gehen dabei Hand in Hand und vernünftig ausgewählte Metriken können eventuell zusätzlich unterstützen.

Das Thema Qualität ist mit dem Inverkehrbringen der Software mitnichten abgeschlossen: Ein System ist nicht ein für allemal sicher oder performant. Qualität betrifft also den gesamten Software-Lebenszyklus. Je nach System müssen wir uns deshalb zum Beispiel auch Gedanken dazu machen, wie wir das Monitoring von Qualitätskennzahlen bewerkstelligen, um frühzeitig potenziellen Qualitätsproblemen im Produktivbetrieb entgegenzuwirken.

Wrap-up

Nach vier Teilen Architecting for Quality sollte klar sein, dass „Qualität“ nicht durch ein paar halbherzige Initiativen oder Werbeslogans herbeigeredet werden kann. Eine hohe Qualität bedeutet letztendlich, dass wir das richtige System gebaut haben. Hierfür ist eine methodische, gesamtheitliche Vorgehensweise unabdingbar, wenn wir uns nicht nur auf unser Glück verlassen wollen.

Natürlich kann eine Blogserie dieses anspruchsvolle Thema nicht ansatzweise erschlagen. Letztendlich sollte Qualität für uns Softwarearchitekt*innen als treibender Faktor im Zentrum unserer Arbeit stehen. Und wenn wir das ernst nehmen, wird uns so schnell sicher nicht langweilig.

 

Mehr Informationen zum Thema Software Engineering findest du hier in unserem Kompetenzfeld.