„Bei Architekturbewertung nicht sklavisch an ATAM-Details festhalten“ [Interview]

Claudia Fröhling

Architekturbewertung hat eine langjährige Geschichte, die Idee dahinter ist aber aktuell wie eh und je: Warum bauen wir unsere Architektur so und nicht anders? Stefan Toth wird dieses Thema auf dem kommenden Architecture Summit unter die Lupe nehmen. Wir sprachen vorab mit ihm über Architekturbewertung, ihre Methoden und übliche Probleme.

JAXenter: Stefan, du präsentierst auf dem Software Architecture Summit einen Ganztagsworkshop zum Thema Architekturbewertung. Was schließt der Bereich Bewertung von Softwarearchitektur alles ein?

Stefan Toth: Das Feld „Architekturbewertung“ wird unterschiedlich abgegrenzt, grundsätzlich geht es aber immer darum, herauszufinden ob die konzeptionelle und technologische Basis einer Softwarelösung trägt. Dabei geht es nicht um kleine Verfehlungen oder unelegante Codezeilen, sondern um schwer zu korrigierende, teure, weitreichende Entscheidungen. Architekturentscheidungen eben.
Um zu erkennen wo gute Entscheidungen besonders wichtig sind, umfasst Architekturbewertung meist auch ein gutes Stück Anforderungsarbeit. Gleichst du zentrale Anforderungen mit getroffenen Entscheidungen ab, werden vielleicht größere Risiken offensichtlich. Besonders spannend sind die z.B. wenn Softwarelösungen gekauft werden, über größere Umstellungen nachgedacht wird oder auch wenn während der Entwicklung von Software richtungsweisende Entscheidungen zu Frameworks, Plattformen, Integrationen oder Infrastruktur getroffen werden.

Event-Tipp

Software Architecture SummitVom 17. bis 19. September 2014 präsentiert das Business Technology Magazin in Kooperation mit der Entwickler Akademie den Software Architecture Summit 2014. Das große Trainingsevent richtet sich an alle, die in IT-Projekten mit dem Thema Softwarearchitektur in Berührung kommen: Software-Architekten selbst, aber auch Projektleiter, Analysten, Entwickler, Qualitätssicherer und alle, die mit Architekten und Entwicklern besser kommunizieren möchten. Mehr Informationen.

JAXenter: Welche Bewertungsmethoden gibt es – grob beschrieben – für Softwarearchitektur?

Toth: Sagen wir so: Es gibt viel was als Architekturbewertungsmethode bezeichnet wird. Einige Toolhersteller behaupten Architekturbewertungstools zu bauen, ihre Werkzeuge überprüfen aber lediglich ob der Code einer im Tool hinterlegten Architektur gehorcht. Ist die hinterlegte Architektur risikoreich oder unpassend, deckt das Tool das in keiner Weise auf.
Im Merger & Acquisition Bereich gibt es auch Bewertungen oder Audits die sehr stark auf rechtliche Rahmenbedingungen und Standards fokussieren. Dabei ist wichtiger alles ordentlich gemacht zu haben, als passende Architekturideen entwickelt zu haben.
Szenariobasierte Bewertungsmethoden können meiner Meinung nach am ehesten als Architekturbewertung bezeichnet werden. In diesen Methoden wird tatsächlich die Architektur selbst geprüft – gegen wichtige Qualitätsaussagen. Zu den szenariobasierten Methoden gehören etwa SACAM, um Architekturentwürfe miteinander zu Vergleichen, CBAM, um die Kosten für Architekturalternativen einfließen zu lassen, oder eben ATAM – Die Architecture Tradeoff Analysis Method – eindeutig die berühmteste Methode mit eher allgemeinem Fokus.

Szenariobasierte Bewertungsmethoden können meiner Meinung nach am ehestens als Architekturbewertung bezeichnet werden.“

JAXenter: ATAM ist 15 Jahre alt. Warum ist das Thema Architekturbewertung gerade jetzt aktuell?

Toth: Die älteste Bewertungsmethode der Carnegie Mellon Universität – SAAM, die Software Architecture Analysis Method – ist sogar noch älter. Aber die Methoden haben im Kern ein aktuelles Thema: Warum bauen wir unsere Architektur so und nicht anders? Architektur- und Designarbeit an Anforderungen zu orientieren und keine neutralen Best-Practice Architekturen oder Luftschlösser zu bauen ist immer eine gute Idee. In Zeiten in denen einige Systeme hochskalierbar, hochperformant oder hochsicher sein müssen, vom Standard also abweichen, wird das noch wichtiger.
Szenariobasierte Bewertung hat außerdem Fokussierungsmechanismen, um die wichtigsten Themen für das Projekt und die bewertende Gruppe herauszufiltern. Sie unterstützen die Kommunikation über technisch zentrale Themen, erleichtern Architekturarbeit in großen Projekten und ermöglichen so auch gemeinsame Architekturarbeit von Teams. Sicherheit in zentralen Entscheidungen zu gewinnen ist ohnehin zeitlos. Ich glaube es spricht sehr viel für die Aktualität oder Zeitlosigkeit des Themas.

JAXenter: Warum wirft man deiner Meinung nach diesen Methoden oft vor, sie seien teuer und schwergewichtig?

Toth: Das hat denke ich zwei Gründe. Erstens: ATAM ist teuer und schwergewichtig. Zumindest im beschriebenen Standard der teilweise mehrtägige Bewertungsworkshop mit dutzenden Teilnehmern beschreibt. Natürlich ist recht viel Methode notwendig, um solche Gruppen effektiv und zielorientiert zu machen. Auch der militärische Kontext in dem die Methode entwickelt wurde ist nicht unbedingt einfach. Die Ideen sind jedoch viel leichtgewichtiger umsetzbar. In kleinen oder nicht stark regulierten Umfeldern sollte man nicht sklavisch an ATAM-Details festhalten.
Der zweite Grund ist, dass ATAM keine Voraussetzungen diktiert, außer Zugang zu den richtigen Menschen. Selbst Projekte in denen Architekturarbeit bisher nicht einmal eine abstrakte Idee war können mit ATAM bewerten. Innerhalb der Methode wird dann an einer Architekturvision gearbeitet, es werden die geschäftlichen Treiber analysiert, ein Architekturüberblick erarbeitet, Entscheidungen dokumentiert, konkrete Qualitätsziele detailliert. Alles Vorarbeiten um gut bewerten zu können, aber vieles davon ist sowieso und auch schon vorher sinnvoll. Ausprägungen von ATAM können sehr schlank sein, solange man sich nicht jede Architekturtätigkeit bis zur Bewertung aufhebt.

JAXenter: Wie sieht denn eine leichtgewichtige oder agile Ausprägung von Architekturbewertung konkret aus?

Toth: Leichtgewichtig gedacht, sind Architekturbewertungsworkshops keine einmaligen oder seltenen Ereignisse. Stattdessen finden sie jede oder jede zweite Iteration statt. Viele Arbeiten aus klassischen Workshops finden stetig statt, wie die Erarbeitung von Qualitätsszenarien – also konkreten Aussagen zu Sicherheit, Performanz, Verfügbarkeit oder Wartbarkeit. Qualitätsszenarien werden wie andere Anforderungen priorisiert verarbeitet. Die Workshops selbst bestehen nur noch aus der Einigung welche Szenarien spannend genug für eine Besprechung sind und der Besprechung – also der Bewertung – selbst. Das ist in ein bis zwei Stunden durch, dient als Feedbackmöglichkeit und Kommunikationsplattform bis hin zum Kunden.

Workshops zur Architekturbewertung finden jede oder jede zweite Iteration statt.“

Je kleiner die Projekte oder je weniger herausfordernd das Architekturumfeld desto informeller können Workshops ablaufen. In einigen Projekten hatten wir gar keine expliziten Workshops mehr, sondern nutzten einfach einige Techniken wie Szenarien oder den Utility Tree um Architekturarbeit etwas zu strukturieren.

JAXenter: An welche Zielgruppe richtet sich dein Workshop, wer sollte deiner Meinung nach kommen?

Toth: Meiner Meinung nach sollte jeder kommen den das Thema interessiert. Wer bis hier hin gelesen hat auf jeden Fall!
Natürlich bin ich ein Fan von Entwicklern und Architekten die sich „von innen heraus“ mit Architekturbewertung beschäftigen wollen. Mit Ihnen arbeite ich sehr gerne in solchen Workshops. Tatsächlich sind in Architekturbewertung aber viele Rollen beteiligt und auch Management oder Fachbereich können sicher etwas Sinnvolles mitnehmen.

Stefan Toth arbeitet als Entwickler, Softwarearchitekt und Berater bei der embarc GmbH. Seine Schwerpunkte liegen in der Konzeption und der Bewertung mittlerer bis großer Softwarelösungen sowie der Verbindung dieser Themen zu agilen Vorgehen. Er ist Autor zahlreicher Artikel und des Buchs „Vorgehensmuster für Softwarearchitektur“.

Geschrieben von
Claudia Fröhling
Claudia Fröhling
Claudia Fröhling hat in verschiedenen Redaktionen als TV- und Onlineredakteurin gearbeitet, bevor sie 2008 zur Software & Support Media GmbH kam und sich bis 2014 um alle Projekte des Verlages im Ressort Java kümmerte. Claudia hat einen Abschluss in Politikwissenschaften und Multimedia Producing. Ihr Google+ Profil findest du hier.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: