Was ist eigentlich Architekturbewertung? (2024)

In Softwarevorhaben stellen insbesondere Neue im Team gerne Fragen wie: "Warum habt ihr das so gemacht? Wäre das nicht anders besser gewesen? Also ich hätte ja ..." – Was genau heißt dann "besser"? Nachher ist man immer schlauer. Und Nörgeln ist bekanntlich einfach... In diesem Artikel diskutiere ich, welche Ansatzpunkte und Methoden es zur Bewertung einer Softwarearchitektur gibt, und welche davon zu welchen Zeitpunkten im Leben einer Software Nutzen stiften.

Ein Vergleich zur Softwareentwicklung: Auch sportliche Leistungen lassen sich je nach Disziplin unterschiedlich gut beurteilen. Manchmal schlicht durch Zählen: Wer schießt mehr Tore? Oder durch Messen: Wer wirft weiter? Schwimmt schneller? Trifft genauer? Doch auch im Sport ist das nicht immer so klar und eindeutig. Im Eiskunstlauf etwa bewerten Preisrichter die Leistungen nach einem komplizierten Schema.

Insbesondere wenn die Unsicherheit im neuen Vorhaben groß ist oder Softwaresysteme in die Jahre kommen, steht der Wunsch nach einer Einschätzung oder einem (Architektur-)Review im Raum. Aber wie läuft das genau ab? Gibt es dort so etwas wie Maßbänder und im Zweifel einen Videobeweis? Auch wie das Ergebnis aussieht ist nicht unmittelbar klar. Der Sport will Gewinner ermitteln und Medaillen verteilen. Aber Haltungsnoten in der Softwareentwicklung?

Die Softwarearchitektur eines Vorhabens ist die Summe zentraler Entwurfsentscheidungen. Hierbei kann es sich um Zerlegungsaspekte des Systems handeln (wie zerfällt es in kleinere Teile und wie hängen diese voneinander ab?). Oder um Technologieauswahl (Programmiersprachen, Frameworks, Middleware) und Fragen der Zielumgebung (auf dem Client vs. im eigenen Rechenzentrum vs. in der Cloud ...).

Mit diesen Testfragen können Sie und Ihr Team während des Entwurfs abklopfen, ob eine Entscheidung architekturrelevant ist:

• Wäre eine Fehlentscheidung aufwändig oder teuer zu revidieren?
• Betrifft die Lösung viele im Team (oder viele Teams)?
• Steckt eine große Unsicherheit darin? (z. B. unbekannte Technologien)

Schlussendlich geht es bei einer Architekturbewertung darum, diese zentralen Entscheidungen zu betrachten. Mitunter auch deutlich später im Leben des Softwaresystems.

Ganz unabhängig vom Thema erfordert eine Bewertung zwei Dinge: einen Gegenstand und einen Maßstab. Das ist auch im Sport so. Der Bewertungsgegenstand im Eiskunstlauf ist ein konkreter Lauf, z. B. eine Kür. Dessen Bewertung findet nicht im luftleeren Raum statt: Preisrichter halten den Lauf gegen klare Kriterien – früher mit der berühmten 6.0 als Bestnote. Heute geht die Skala von 0 bis 10, mit Stufen von "sehr heillos" bis "erstaunlich" [1].

Abb. 1 zeigt Optionen für ein Gegeneinanderhalten und Abgleichen in der Softwareentwicklung. So lässt sich Ihre Architektur (Entscheidungen, Konzepte, Modelle ...) auf die Verwendung von Best Practices abprüfen. In einschlägigen Büchern findet man bewährte Stile, Muster und Prinzipien. Nun passen Best Practices selten auf jedes Problem. Problemspezifische architekturrelevante Anforderungen stellen ebenfalls einen Maßstab dar. Hier sind insbesondere Vorgaben und Qualitätsziele zu nennen. Ein weiterer möglicher Vergleich überprüft, ob Lösungsentwurf und Umsetzung zusammenpassen. Finden Sie die geplante Struktur (Zerlegung in Module und geplante Abhängigkeiten) im Quelltext wieder?

Für das konkrete "Gegenhalten" (Bewerten) gibt es verschiedene Methoden und Werkzeuge, die Sie und Ihr Team zu unterschiedlichen Zeitpunkten einsetzen können. Schauen wir uns zunächst die zwei grundlegenden Analysekategorien an: Qualitative und quantitative Ansätze.

Qualität entscheidet

Verschiedene Faktoren beeinflussen das Treffen wichtiger Entwurfsentscheidungen. Neben funktionalen Anforderungen (z. B. User Stories), die sich oft in der Struktur der Lösung widerspiegeln, sind dies vor allem Vorgaben (Rahmenbedingungen) und die geforderte Qualität. Zur Illustration hier einige typische Fragestellungen für Entscheidungen:

• Welche Oberflächen erhalten die unterschiedlichen Benutzer?
• Wie binden wir Fremdsystem XY an?
• Welches Produkt/ welche Technologie verwenden wir für XY?
• Wie kommunizieren Bestandteile unseres Systems untereinander?
• Wie adressieren wir querschnittliche Themen (z. B. Authentifizierung)?
• Implementieren wir eine geforderte Funktionalität selbst, oder verwenden wir dazu eine bestehende Lösung ("Make or Buy")?

Rahmenbedingen schränken hier den Lösungsraum ein. Oft führen sie dazu, dass Optionen wegfallen. Diese sind beispielweise zu teuer (Budgetvorgaben), dauern zu lange in der Umsetzung (Terminvorgaben) oder passen nicht zu geforderten Standards.

Was, wenn zu einer Fragestellung trotz der Vorgaben mehrere zulässige (also im Rahmen liegende) Alternativen zur Auswahl stehen? Die entscheidenden Einflussfaktoren sind dann die Qualitätsziele Ihres Vorhabens. Abb. 2 zeigt die zentralen Qualitätsmerkmale nach ISO 25010 [2]. Die Norm differenziert noch feiner. Sie gliedert beispielsweise Effizienz (Performance) weiter in Zeit- und Verbrauchsverhalten.

Kompromisse und qualitative Bewertungsmethoden

Ihr Softwarevorhaben hat vermutlich viele Anforderungen aus Abb. 2, aber nicht alle. Oder sie sind zumindest nicht alle gleich wichtig. Tabelle 1 zeigt als Beispiel Qualitätsziele für Atlassian Confluence [3]. Die Reihenfolge gibt dabei eine Orientierung bezüglich ihrer Wichtigkeit.

Qualitative Bewertungsmethoden überprüfen nun, ob die Lösungsansätze und Entscheidungen in der Architektur zu den Zielen des Vorhabens passen. Die bei Wechselwirkungen erforderlichen Kompromisse (tradeoff) finden sich dabei im Namen der prominentesten Bewertungsmethode wieder: ATAM steht für Architecture Tradeoff Analysis Method[4].

ATAM stammt von der Carnegie Mellon University. Die Methode schlägt einen Ablauf für eine qualitative Bewertung mit mehreren Phasen und Analyseschritten vor, beteiligte Rollen inklusive. Im Kern ist ATAM eine szenarienbasierte Methode.

Ein sogenanntes Qualitätsszenario ist dabei eine beispielhafte Verwendung des zu betrachtenden Systems. Und zwar so, dass ein Qualitätsmerkmal die Hauptrolle spielt. Konkrete Szenarien für die Benutzbarkeit innerhalb des Confluence-Wikis könnten etwa so lauten:

"Ein Benutzer benennt eine Wiki-Seite um. Die Änderung ist nach einer Sekunde vollzogen, alle Verweise auf die Seite bleiben aktuell."

"Ein Benutzer schließt während des Editierens versehentlich den Webbrowser. Sämtliche Änderungen bleiben erhalten."

Hier noch ein Beispiel für Wartbarkeit: "Ein versierter Java-Entwickler beabsichtigt Confluence um ein einfaches Macro zu erweitern. Das Macro steht dem Team nach einem Personentag zur Verfügung."

Qualitätsszenarien sind nicht hundertprozentig Prosa, sondern folgen ähnlich wie User Stories einem Formulierungsschema. Abb. 4 zeigt die typischen Bestandteile eines Szenarios (Quelle, Auslöser, ...) und ordnet sie farblich einem weiteren Beispiel für Confluence zu.

Eine Sammlung derartiger Szenarien (Utility-Tree) stellt den Bewertungsmaßstab jeder ATAM-Bewertung dar. Anders als beim Eiskunstlauf, wo alle Sportler gegen die gleichen Kriterien laufen, sind sie spezifisch für das betrachtete Softwaresystem. Die an der Bewertung Beteiligten erheben und priorisieren die Szenarien im Rahmen von Workshops und sprechen sie durch. Das greifbarste Ergebnis einer solchen Bewertung sind aufgedeckte Risiken und Kompromisse. Das Workshop-Format mit breiter Stakeholder-Beteiligung fördert darüber hinaus den Austausch und schafft Transparenz.

Es gibt eine ganze Reihe ähnlicher Methoden [5][6]. ATAM ist aber die bekannteste und verbreitetste davon. Sie gilt als schwergewichtig. Tatsächlich lässt sich ATAM jedoch gut auf konkrete Vorhaben anpassen und auch schlank durchführen. Eine frühe qualitative Bewertung, die eine Architektur-Vision grob absichert, ist durchaus in einem einzelnen Workshop-Tag machbar.

Qualitative Bewertungsmethoden wie ATAM setzen auf Fokussierung, die Durchsprache von Lösungsansätzen und die Erfahrung und Argumente der Workshop-Beteiligten. Eine gewisse Unsicherheit bleibt (Restrisiko).

Dahingegen setzen quantitative Bewertungsansätze auf vermeintlich belastbarere Fakten. Sie "vermessen" die Lösung, konkret also den Quelltext der Software, die Struktur der Elemente und deren Beziehungen untereinander, und Leistungswerte des laufenden Systems. Abb. 5 illustriert grundsätzliche Ansätze für Überprüfungen und Messungen.

Die Untersuchungen erfolgen toolgestützt. Die Ergebnisse sind entweder Messwerte (Größen, Zeiten, Anteile) oder einzelne Befunde (Verdachtsmomente, Verstöße und Verletzungen), die sich wiederum zählen lassen. Eine umfassende Betrachtung von Kennzahlen zur Messung von Komplexität und struktureller Qualität von Software finden Sie hier [7]. Die Kurzreferenz "Quantitative Analyse" [8] beschreibt allgemeiner, welche Metriken und Tools verbreitet sind, wie sie helfen und vor allem, wie Sie und Ihr Team sinnvoll mit Ergebnissen umgehen.

Generell kommen diese Ansätze erst dann zum Einsatz, wenn es etwas zu vermessen gibt. Lösungskonzepte und Ideen reichen dazu nicht aus. Dafür lassen sich viele dieser Ansätze automatisieren und kontinuierlich durchführen, etwa im Build oder im laufenden Betrieb. Abb. 6 zeigt eine Auswertung des Confluence-Quelltextes mit dem Werkzeug Teamscale [9].

Die Überprüfung von Kennzahlen im Rahmen einer Analyse liefert Indikatoren. Die Ergebnisse gehören aber immer mit vorhaben-spezifischen Zielen oder konkreten Schwerzpunkten verknüpft.

Messungen sind insbesondere dann interessant, wenn sie kontinuierlich erfolgen, um Veränderungen zu beobachten. Solche Überprüfungen können durch eine vorherige Architekturbewertung motiviert sein, etwa um bestimmte Qualitätsziele im Blick zu behalten. Mitunter sehe ich solche Messungen mit Standardwerten (d. h. Defaults der Tool-Hersteller) in Projekten mitlaufen, aber ohne Bezug zu Zielen des Teams oder des Vorhabens. Konsequenterweise guckt dann keiner auf die Ergebnisse.

In welcher Situation wendet man nun welche der Methoden und Werkzeuge an? Abb. 5 zeigt Herausforderungen, die zugleich typische Bewertungsanlässe darstellen. Zur groben Orientierung ordnen sie sich entlang eines Zeitstrahls für den Lebenszyklus des Softwaresystems an.

Zu Beginn gibt es wenig zu messen und man ist auf qualitative Ansätze angewiesen. Aus dieser Analyse ergeben sich Risiken und Unsicherheiten, die Sie und Ihr Team mitunter mit Durchstichen oder Prototypen adressieren. Hier kommen dann auch Messungen zum Tragen, etwa Last- und Performancetests.

Ist der Bewertungsgegenstand ein Softwaresystem, das sich bereits in der Entwicklung oder Weiterentwicklung befindet, kommen quantitative Methoden als Ergänzung zu Argumenten und Durchsprachen hinzu. Tabelle 2 verknüpft die Herausforderungen aus Abb. 7 mit Leitfragen und möglichen Bewertungsansätzen.

Stefan Zörner

Stefan Zörner ist Softwarearchitekt, Berater und Coach bei embarc in Hamburg. Er unterstützt in Architektur- und Umsetzungsfragen mit dem Ziel, gute Architekturansätze wirksam in der Implementierung zu verankern. >>Weiterlesen

Neuen Kommentar schreiben