Über unsMediaKontaktImpressum
Stefan Zörner 06. Dezember 2018

Was ist eigentlich Architekturbewertung?

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?

Softwarearchitektur und Architekturbewertung

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.

Qualitätseigenschaften sind nicht völlig unabhängig voneinander. Ganz im Gegenteil gibt es regelmäßig Wechselwirkungen. Maßnahmen zur Erhöhung der Portierbarkeit beispielsweise haben ggf. negativen Einfluss auf die Effizienz. Eine Entscheidung, die gut für die Sicherheit Ihrer Anwendung ist, reduziert mitunter deren Benutzbarkeit. Klassische Beispiele hierfür sind CAPTCHAs (s. Abb. 3), oder dass ein Kennwort bei Eingabe nicht angezeigt wird. Ein typischer Kompromiss.

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.

Tabelle 1: Qualitätsziele für das Enterprise Wiki Confluence

Qualitätsziel Beschreibung
Leicht zu betreiben Für ein Team ist es einfach, mit Confluence zu starten.
Gute Benutzbarkeit Confluence ist effizient und intuitiv von allen Team-Mitgliedern zu verwenden.
Hohe Zuverlässigkeit Das System steht den Anwendern jederzeit zur Verfügung.
Gute Wartbarkeit Confluence ist leicht zu ändern und um Funktionalität zu erweitern.
Sicherheit der Inhalte Inhalte sind vor unberechtigtem Zugriff und Veränderung geschützt.

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.

Tools, Metriken und quantitative Ansätze

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.

Konkrete Anlässe zur Architekturbewertung

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.

Tabelle 2: Typische Anlässe, Leitfragen und mögliche Maßnahmen für Bewertungen

Anlass Leitfrage Möglicher Bewertungsansatz
Eine Neuentwicklung steht an und erste Lösungsansätze stehen im Raum. Sind Sie und Ihr Team auf dem richtigen Weg? Team-interner Workshop. Schlanke szenarienbasierte Durchsprache der Architekturvision, um Fokus für Konzeption/Entwicklung zu setzen ("Discovery Review").
Unterschiedliche Stakeholder verfolgen widersprüchliche Ziele mit der Software. Wie konkretisieren und priorisieren Sie deren Wünsche? Workshop gemeinsam mit maßgeblichen Stakeholdern, um Klarheit bezüglich Ziele zu schaffen (s. auch Quality Attribute Workshop [5]).
Das Management hat das Vertrauen in die Lösung verloren. Wie gewinnen Sie es zurück und strahlen Sicherheit aus? Qualitative Bewertung mit projektfremder Unterstützung und Management-Beteiligung, um Stärken und Kompromisse sichtbar zu machen.
Größere Umbaumaßnahmen der Software stehen an. Wie wählen Sie und Ihr Team passende Lösungsansätze nachvollziehbar aus? Umfassende qualitative Analyse, flankiert mit quantitativen Ansätzen. Verknüpfung von Problemen mit Maßnahmen (s. auch Cost Benefit Analysis Method [6]), Priorisierung.

Fazit

Architekturbewertungen halten die Architektur (Lösungsansätze, Entscheidungen, Konzepte) gegen zentrale Anforderungen (Qualitätsziele, Vorgaben). Bei qualitativen Ansätzen wie ATAM schauen die Beteiligten gemeinsam, wie gut der Bewertungsgegenstand zum Bewertungsmaßstab passt. Als Ergebnis stehen hier vor allem Risiken im Raum. Kompromisse werden sichtbar. Messungen können als Argumente unterstützen und helfen, aufgedeckte Risiken messbar und über die Zeit behandelbar zu machen.

Tabelle 3 stellt die wesentlichen Stärken und Schwächen von qualitativen und quantitativen Analysen gegenüber. Einen pointierten Überblick über Nutzen und Abläufe (inklusive einer Workshop-Agenda) liefert die Kurzreferenz unter [10].

Tabelle 3: Stärken und Schwächen von Bewertungsansätzen

Ansatz Stärken Schwächen
Qualitativ (Argumentieren in Workshops) - bereits früh anwendbar,
- passt auf alle Qualitätsmerkmale,
- bindet Stakeholder optimal ein und fördert den Austausch
- Durchsprache ist kein Messen (ein "Restrisiko" bleibt),
- Workshops nicht trivial in der Durchführung (Planung, Moderation ... )
Quantitativ (Messen mit Tools) -wenig Bauchgefühl, Zahlen sind gute Argumente,
- Messungen leicht automatisierbar und wiederholbar
- vergleichsweise spät einsetzbar,
- Messungen können nicht alle Qualitätsmerkmale gut erfassen,
- Gefahr der Missdeutung und Fehlleitung

Obgleich eine klassische Bewertung nach ATAM schwergewichtig anmutet, lassen sich qualitative Bewertungsansätze und Szenarien gut in einen iterativen Prozess, etwa nach Scrum, integrieren (vgl. auch [11]). Die Architektur regelmäßig zu reflektieren passt weitaus besser zu einem zeitgemäßen Vorgehen als eine umfassende Bewertung "am Ende". Spät gefundene Schwächen lassen sich dann oft nur noch als technische Schulden verbuchen.

Stefan Zörner auf den IT-Tagen 2018

Zum gleichen Thema hält Stefan Zörner einen Vortrag auf den diesjährigen IT-Tagen – der Jahreskonferenz der Informatik Aktuell.

Nörgeln ist einfach. Aber was (genau) ist eigentlich Architekturbewertung?
(11.12.2018, 11:30 Uhr)

Quellen
  1. Wikipedia: International Skating Union: ISU-Wertungssystem für Eiskunstlauf und Eistanz
  2. International Organization for Standardization: ISO 25010, Systems and software engineering —  System and software quality models
  3. S. Zörner: ATAM Anthologie. Eine Architektur im Wandel der Zeit am Beispiel Atlassian Confluence, Vortrag auf der OOP Konferenz, München 2016
  4. L. Bass et al.: Software Architecture in Practice, Addison Wesley, 3. Auflage 2012
  5. M. R. Barbacci et al.: Quality Attribute Workshops (QAWs), Technical Report, Carnegie Mellon University 2003
  6. R. Kazman et al.: Making Architecture Design Decisions: An Economic Approach, Technical Report, Carnegie Mellon University 2002
  7. H. Dowalil: Über die Vermessung von Software
  8. Quantitative Analyse, Architektur-Spicker #2 (6 Seiten PDF)
  9. Teamscale
  10. Architektur-Reviews, Architektur-Spicker #4 (4 Seiten PDF)
  11. S. Toth: Vorgehensmuster für Softwarearchitektur: Kombinierbare Praktiken in Zeiten von Agile und Lean, 2. Auflage, Hanser 2015

Autor

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
Bücher des Autors:

botMessage_toctoc_comments_9210