Reviews – Warum eigentlich?

Architekturbewertung ist eine extrem vielseitige Praktik. In agilen Projekten kann sie sehr schlank für die iterative Steuerung von Architekturarbeit und Transparenz im Team genutzt werden, in großen und lang laufenden Projekten kann sie die größten Schwachstellen identifizieren und Überarbeitungsaufwände fokussieren. Bei Neuentwicklungen oder Migrationen steht oft die Frage im Raum ob man am richtigen Weg ist und Reviews geben Sicherheit. Risiken und Kompromisse werden sichtbarar und nebenbei entstehen klarer gefasste Anforderungen und Entscheidungen.

Finden Sie die passenden Praktiken für Ihr Projekt und sorgen Sie für Fokussierung, Transparenz und Entscheidungssicherheit!

Fundierte Architektur-Reviews nutzen Ideen vieler Methoden

Architektur-Reviews können ad-hoc erfolgen oder eine der unzähligen Methoden nutzen, die seit den 90er Jahren entwickelt wurden und werden. In der Praxis ist es oft ein Mix an Methodikelementen der am zielführendsten ist. Häufige Quellen sind:

  • ATAM (Architecture Tradeoff Analysis Method): Die ATAM wurde am Software Engineering Institute (SEI) der Carnegie-Mellon Universität entwickelt und im Jahr 2000 erstmals veröffentlicht. In zwei Kernphasen-Workshops wird die Architektur detailliert und analysiert. Wegen ihres
    Umfangs wird die Methode für kleinere Reviews meist nur ausschnittsweise angewendet, Sie ist gleichzeitig die ausgereifteste und bekannteste Reviewmethode für Architekturen.
  • CBAM (Cost-Benefit Analysis Method): Die CBAM kommt ebenfalls vom SEI und konzentriert sich auf Kosten-Nutzen Bewertungen. Gerade beim Vergleich mehrerer Alternativen die unterschiedliche Qualität, aber auch Kosten haben kann die Methode zielgerichtet eingesetzt werden (Make vs. Buy vs. Legacy). Flächendeckend eher nicht brauchbar.
  • QAW (Quality Attribute Workshop): Der QAW beschreibt die Erarbeitung von Qualitätsszenarien die in ATAM und CBAM als Basis benötigt werden. Sie werden weiter unten auf dieser Seite etwas genauer beschrieben.
  • ARID (Active Review for Intermediate Designs): Der ARID ist eine Technik in der Entwurfsideen kommuniziert und mit Pseudolösungen getestet werden. Beispielsweise könnte eine Schnittstellenspezifikation in eine Runde von Entwicklern geworfen werden, um zu sehen ob sie intuitiv verwendbar ist.
  • Strukturanalyse: Der Code wird in seiner Gliederung und Abhängigkeiten visualisiert und kann anschließend auf Best-Practices und Problemherde untersucht werden. Auch die Abweichung von Architekturideen wird sichtbar und kann zur Überarbeitung von Architektur- oder Codeseite führen.
  • Pre-Mortem Meetings: Eine leichtgewichtige Variante einer qualitativen Bewertung aus dem Game Storming. Hierbei wird angenommen das Projekt sei gescheitert und die Workshop-Teilnehmer suchen nach realistischen (und technisch motivierten) Gründen. Die einfache und schnelle Durchführung machen diese Variante für schnelle Risikofindung interessant.
  • Statische Code-Analyse: Metrikauswertungen können Problemgebiete in der Software identifizieren und vor allem im Bereich der Wartbarkeit unterstützen bestehende Softwareteile zu bewerten oder Aufwände zu fokussieren.
  • Dynamische Code-Analyse: Dynamische Analyse kann in den Bereichen der Performanz, Skalierung oder Zuverlässigkeit gute Aufschlüsse über die Tauglichkeit einer Softwarelösung geben und kann bei bestehenden Systemteilen mit realistischen Einsatzszenarien prüfen ob Architekturideen tatsächlich greifen.

Für die Ausgestaltung eines Reviews ist es wichtig die Aspekte zu bestimmen die unter die Lupe genommen werden sollen. Isoliert oder auch gemeinsam könnten das z.B. die folgenden sein:

  • Qualität der Architektur prüfen: Hierbei wird meist „von außen“ bewertet ob die Architektur gängigen Best-Practices folgt, ob sie verständlich ist und eine gewisse konzeptionelle Integrität aufweist. Diese inhaltliche Bewertung erfolgt oft recht methodikfrei und setzt ein gewisses Maß an Branchenkenntnis und Technologieerfahrung voraus.
  • Angemessenheit der Architektur prüfen: Hierbei erarbeitet man ein gemeinsames Ziel- und Architekturverständnis und bewertet ob die architektonischen Konzepte für die Zielerrichung geeignet sind. Elemente aus ATAM oder CBAM (bei ökonomischen Betrachtungen) sind interessant. Für die Ziel-Abstimmung auch der QAW – in größeren Vorhaben oft asynchron und vorweg.
  • Umsetzbarkeit architektonischer Konzepte prüfen: Hierbei steht nicht die strategische Idee, sondern die tatsächliche Umsetzbarkeit im Fokus. Ist die Architektur einheitlich verstanden, so einfach wie möglich, sind zentrale Elemente klar und sind Feedback-Kanäle von der Umsetzungs- und Deploymentebene vorhanden? Hier hilft der ARID oder auch die Toolgestützte Strukturanalyse von bereits umgesetzten Lösungsteilen.
  • Umsetzung mit der Architekturidee abgleichen: Hierbei wird geprüft ob Architekturentscheidungen auf Code-Ebene nachvollziehbar sind oder ob es Ziel-gefährdende Auffälligkeiten in der Umsetzung gibt. Hierbei wird Tool-gestützt gearbeitet und meist auf Metriken, Strukturprüfungen und dynamische Messwerte zurückgegriffen. Als Ergänzung kann diese Prüfung auch die Validität der Erkenntnisse auf Architekturebene belegen.

Architektur-Reviews skalieren

Wie groß Reviews angelegt werden sollten hängt von vielen Faktoren ab. Im Folgenden einige wichtige:

Qualitätsszenarien als zentrales Konzept

Qualitätsszenarien konkretisieren qualitative Anforderungen und sind in QAWs, ATAM und CBAM ein Thema. Sie ermöglichen die Architektur aus unterschiedlichen Blickwinkeln detailliert zu betrachten ohne sich zu verzetteln und sind gut geeignet um technische Kompromisse auch für technikfernere Stakeholder verständlich zu machen. Ähnlich wie User Stories haben auch Qualitätsszenarien einen typischen Aufbau:

In realen Reviews erarbeiten wir Qualitätsszenarien entweder in einem schnellen Brainstorming oder destillieren sie aus Einzelgesprächen (bei größeren Vorhaben). Die entstandenen Aussagen werden meist den übergeordneten Qualitätsmerkmalen (wie Security, Effizienz oder Modifizierbarkeit) zugeordnet. Der so entstandene Baum wird als „Utility Tree“ bezeichnet und bildet den Kern von Reviews die auf Qualität und Angemessenheit der Architektur ausgelegt sind. Startpunkt für einen solchen Baum kann die ISO 25010 sein – Im Anhang gibt es eine entsprechende X-Mind-Vorlage.

Nützliche Publikationen und Veröffentlichungen zum Thema Architekturbewertung:

Architekturspicker: Architektur-Reviews

Unsere Architekturspicker beleuchten die konzeptionelle Seite der Softwareentwicklung. In Ausgabe #4 finden Sie einen tieferen Einblick in Architektur-Reviews.. (Architektur-Reviews Spicker download)

Architekturspicker: Quantitative Analyse

Die Ausgabe #2 unserer Architekturspicker führt Sie in die Welt der Tool-gestützten Analysen. Erhalten Sie Einblicke, wie Sie Verbesserungspotentiale Ihrer Software erkennen und wie Sie unterschiedlichen Aussagen zur Qualität Ihrer Software bewerten.. (Quantitative Analyse Spicker download)

Was (genau) ist eigentlich Architekturbewertung?

Stefan Zörner stellte in seinem Vortrag bei der JUG Hamburg vor, wie Sie Ihre Softwarearchitektur bewerten. Können Ihre Architekturideen in der Umsetzung aufgetretene Probleme effektiv lösen? Helfen sie bei der Erreichung Ihrer Ziele oder behindern sie diese eher? (Zum Beitrag, inkl. Foliendownload)

Ihr Nutzen

Entscheidungssicherheit – Klare Einflüsse, definierte Kompromisse und effektive Einbeziehung von Experten
Aufgedeckte Risiken – Früh erkannte potentielle Probleme und Schwachstellen Ihrer Software
Bessere Stakeholderbindung – Definierte und fokussierte Kommunikation mit wichtigen Beeinflussern des Projekts
Definierte Architekturanforderungen – Klar gefasste und verständliche Architekturanforderungen in Form von Qualitätsszenarien

Weniger Rückschläge – Weniger späte Überraschungen und Missverständnisse
Höhere Transparenz – Breitere Beteiligung an Architekturarbeit ohne Aufblähen oder Verlangsamen des Prozesses
Bessere Dokumentation – Gut nachvollziehbarer Kontext zu Entscheidungen aus Bewertungsworkshops
Angepasst auf Ihr Vorhaben – Vom unabhängigen Architekturreview als Quick-Check bis zur Projektbegleitung

Produkte

Architektur-Reviews führen wir in verschiedenen Formen bei Kunden aller Branchen durch. Als Dienstleistung können wir in diesem Bereich selbst reviewen (häufigster Einbindungsgrund) oder eine Gruppe innerhalb des Unternehmens zu guten Reviews befähigen bzw. bei Reviews begleiten. Sprechen Sie uns einfach an.

Architektur-Review (von uns durchgeführt)

(ab 1 Tag, bis mehrere Wochen)
Gemeinsam mit Ihnen bewerten wir Ihre Software-, System- oder Unternehmensarchitektur. Sie bekommen eine Einschätzung von Außen wie es um Ihre Architektur steht. Wir wählen die passenden Review-Methoden und -Techniken aus und wenden Sie passgenau an. Mit unserem Kontext aus vielen Projekten bzw. Branchen und unserem technologischen Wissen sind wir in der Rolle von externen Experten eingebunden und moderieren nötige Workshops. Je nach Projektgröße und Rahmenbedingungen kann ein Architekturreview in ein bis zwei Tagen erfolgen oder sich asynchron über mehrere Wochen strecken.

Architekturbewertung: Coaching

(projektbegleitend ab 2 Tagen)
Wir kommen direkt in Ihr Projekt und unterstützen Sie bei der Etablierung oder Durchführung von Architektur-Reviews. Wir helfen bei der internen Kommunikation, der Erhebung von Szenarien, der Planung oder Moderation von Bewertungsworkshops, wir bewerten selbst mit, verankern einzelne Praktiken schlank und natürlich in Ihrem Vorgehen oder helfen bei der Toolauswahl und -integration für quantitative Bewertung. Haben Sie konkrete Fragen oder Probleme sind schon zwei Coachingtage sinnvoll, einige Projekte unterstützen wir auch wiederkehrend und in regelmäßigen Abständen bei der Bewertung.

Stefan Toth

Stefan Toth

(Berater und Coach)

 

Sprechen Sie uns an!

Sie haben Fragen zum Thema? Zögern Sie nicht Kontakt mit uns aufzunehmen!
 
Email: stefan.toth@embarc.de
Xing: xing.to/sto
Twitter: @st_toth