Artikel

November 2009 | Artikel

Architekturbewertung – keine Noten aber mehr Durchblick

(Link zum Artikel: http://www.it-republik.de/business-technology/artikel/2700)

Text: Stefan Toth
Softwarearchitektur ist die Brücke zwischen den Zielen der Auftraggeber und der fertigen Software. Die getroffenen Strukturentscheidungen sind von großer Tragweite, erfordern ein hohes Maß an Erfahrung und müssen darüber hinaus zum richtigen Zeitpunkt und unter den richtigen Voraussetzungen getroffen werden. Trotz dieser Bedeutung ist Architektur zu oft das Werk von Einzelnen und meistens zu weit von der Umsetzung und den eigentlichen Bedürfnissen entfernt. Die Architekturbewertung hat sich zum Ziel gesetzt, das zu ändern. Der Weg dazu führt über transparente Architekturentscheidungen – eine gläserne Architektur.
Teil 1   Teil 2   Teil 3   Teil 4   Teil 5   

Wie hätte Winnetou entschieden? Diese Frage stellt der Titel eines kleinen Managementleitfadens, den ich neulich in einem Museumsshop entdeckte. Tipp Nr.4 rät: "Leg dein Ohr auf die Schienen". Ich spreche ganz klar keine Kaufempfehlung für das Büchlein aus – die Frage wie sich andere bei schwierigen Entscheidungen verhalten hätten, ist aber eine gute. Architekturbewertung macht genau das – auch wenn nicht zwangsläufig Indianer sondern eher gute Entwickler im Fokus stehen und der Prozess ein wenig systematischer anmutet. Ein Teil dieses Prozesses ist es, sein Ohr auf die Schienen zu legen, um zu erfahren, welche Auswirkungen Entscheidungen nach sich ziehen, an welchen Stellen die Software modifizierbar gehalten werden muss und als Wichtigstes: Was der Kunde tatsächlich will. Weil man sich in solchen Themen leicht verliert, sollte man jedoch eines ganz im agilen Sinn nicht vergessen: rechtzeitig aufzustehen bevor der Zug kommt. Moderne Bewertungsmethoden setzen all diese Aspekte um und sorgen dafür, dass entscheidende Attribute erfolgreicher Projekte greifbar werden:

  • Klare und verwertbare Anforderungen
  • Gute Bindung zu wichtigen Stakeholdern
  • Frühe Klärung essenzieller Fragen
  • Umsetzbarkeit und Angemessenheit der Architektur
  • Breites Verständnis für Architektur und Probleme
Dass diese Ziele nicht durch die Anstrengung einzelner Projektmitglieder erreicht werden können, ist klar. Szenariobasierte Bewertungsmethoden, wie sie heute üblich sind, stellen deshalb einen geleiteten Gruppenprozess dar, der viele agile Prinzipien unterstützt und umsetzt. Entwickelt werden solche Methoden seit Anfang der 90er Jahre. Federführend ist dabei, das Software Engineering Institute der Carnegie Mellon Universität, das auf einem wissenschaftlichen Fundament die meisten in der Praxis erprobten Methoden konzipiert hat (Kasten: "Die wichtigsten Bewertungsmethoden"). Im Folgenden werden die Kernthemen dieser Methoden beleuchtet und gezeigt, wie man die enthaltenen Ansätze zusammen mit agilen Prinzipien erfolgreich kombinieren kann, um Architekturen sinnvoll zu bewerten.

Die wichtigsten Bewertungsmethoden

Die hier aufgeführten Methoden unterscheiden sich hauptsächlich durch ihre Ausrichtung. Die eingesetzten Techniken sind sehr ähnlich – Szenarien, Bewertungsworkshops und qualitative Durchsprachen sind dabei üblich. Weitere, spezielle Bewertungsmöglichkeiten wie Fragebögen, Checklisten oder Metriken würden den Rahmen dieses Artikels leider sprengen.

  • ATAM – Architecture Tradeoff Analysis Method: Die bekannteste und ausgereifteste Methode, die detailliert auf die Beziehung zwischen Entwurfsentscheidungen und den beeinflussten Qualitätsmerkmalen eingeht.
  • SACAM – Software Architecture Comparison Analysis Method: Eine Methode zum Vergleich mehrerer Architekturalternativen. So genannte "Extraction Directives" definieren Artefakte und Ansätze, die verglichen werden sollen.
  • CBAM – Cost-Benefit Analysis Method: Neben Qualitätsmerkmalen wird die Architektur hier auch auf Wirtschaftlichkeit geprüft. Nutzen und ROI sind wichtige Themen beim Durchsprechen.

  1. Software Engineering Institute: Evaluation Methods
  2. Clements, Kazman, Klein: "Evaluating Software Architectures: Methods and Case Studies", Addison-Wesley Longman

Teil 1   Teil 2   Teil 3   Teil 4   Teil 5   

Kommentare