Interview mit Harm Gnoyke

Architekturen bewerten – aber wie?

Hartmut Schlosser

Harm Gnoyke

Softwarearchitekturen kann man auf ganz unterschiedliche Art und Weise bewerten. Welche Möglichkeiten es aber gibt, dass Architekturbewertungen tatsächlich objektiv ausfallen und ein Projekt in der Praxis voranbringen, haben wir mit Harm Gnoyke, Architekt bei embarc und Trainer auf dem Software Architecture Summit, besprochen.

Softwarearchitektur bewerten – dazu hältst du einen Workshop auf dem Architecture Summit. Nun gibt es ja ganz unterschiedliche Möglichkeiten, Methoden und Kriterien für eine solche Bewertung. Was kann man tun, damit eine Bewertung nicht beliebig wird und ins Subjektive abrutscht?

Harm Gnoyke: Oftmals übernehmen Projekte einfach eine im Team bekannte Bewertungsmethode, ohne sie auf den eigenen Kontext anzupassen. Das Ergebnis ist dann schwierig interpretierbar und bietet keine echte Orientierung für die tägliche Arbeit.

Für mich ist es besonders wichtig, sich erst einmal einen Überblick über die Ziele des Projektes zu verschaffen und anschließend die Methode einzusetzen, die die eigenen Ziele am besten bewerten kann. Wenn ich schon eine Bewertungsmethode für meine Zwecke gefunden habe, kann ich mich darum kümmern, diese Bewertungen leicht wiederholbar zu machen und damit auch kontinuierlich in die richtige Richtung zu arbeiten. Dabei überprüfe ich somit auch wiederholt, ob ich noch die richtigen Ziele verfolge.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

Es gibt quantitative und qualitative Analysemethoden. Kannst du für beides einmal ein Beispiel nennen?

Harm Gnoyke: Quantitative Analysemethoden haben als Ergebnis eine Zahl und damit einen gut kontrollierbaren Wert, den es anschließend zu interpretieren gilt. Ich unterscheide dabei gerne noch in statische und dynamische Analysen des Codes. Für statische Analysen ist ein Beispiel die zyklomatische Komplexität einer Methode oder Klasse, die die Anzahl möglicher Pfade durch den Code darstellt. Eine dynamische Analyse betrachtet den Code zur Laufzeit in einer bestimmten Umgebung und hat zum Beispiel die Antwortzeit für einen User Request als Ergebnis.

Qualitative Methoden haben hingegen nicht so ein klares Ergebnis. Ich betrachte hier Szenarien und halte sie gegen meine Architekturidee. Als Ergebnis bekomme ich nun eine Indikation, wie gut meine Architektur ein Szenario unterstützt, d.h. ob ich dieses leicht erfüllen kann oder eventuell große Risiken damit verknüpfe. Das wohl bekannteste Beispiel für eine solche Bewertungsmethode ist ATAM, die Architecture Tradeoff Analysis Method, die wir uns im Workshop genauer anschauen werden.

Wozu sind Architekturbewertungen eigentlich nützlich? Bei der reinen Bewertung hört es ja sicher nicht auf…

Harm Gnoyke: Der größte Nutzen entsteht sicherlich, wenn die Ergebnisse aus einer Bewertung in der täglichen Projektarbeit aufgegriffen werden. Risiken werden gezielt gemindert, indem zum Beispiel Prototypen oder Durchstiche für bestimmte Themen umgesetzt werden. So vermeide ich große Fehlinvestitionen oder unnötige Entwicklung. Für das gesamte Projektteam schafft die Bewertung Transparenz über die Stärken und Schwächen der Architektur. Die Potenziale der Architektur können in der Entwicklung genutzt werden, um Lösungsalternativen zielgerichtet zu bewerten.

In einigen Projekten habe ich erlebt, dass die Bewertung der Architektur erst dazu geführt hat, dass man sich über die Ziele seiner Software bewusst geworden ist. Die in der Bewertung angestoßene Diskussion setzt sich meistens auch danach noch fort, was wiederum förderlich für die zukünftige Ausrichtung der Architektur ist.

Schließlich ist es nötig, leichtgewichtige Methoden aus der Bewertung in den Projektalltag einzubauen und diese damit einfach wiederholbar zu machen. Konkrete Beispiele, wie das im eigenen Projekt funktionieren kann, behandeln wir im Workshop gemeinsam mit den Teilnehmern.

Kannst du ein Beispiel aus deiner Praxis nennen, wo eine Architekturbewertung Dinge zum Positiven verändert hat?

Harm Gnoyke: Gerade aktuell, da Microservices-Architekturen das am meisten diskutierte Thema sind, stoße ich mit meinen Kollegen bei Bewertungen häufig auf die Frage, wie man seine aktuelle Architektur auf Microservices umstellen kann. Beispielsweise kam diese Frage als konkretes Zielbild im Rahmen einer Bewertung auf uns zu. Wir haben in der Bewertung erst einmal die Ziele überprüft, die die Software erreichen sollte.

Im Vergleich mit den Zielen, die der Microservices-Stil am besten unterstützt (z.B. Skalierbarkeit, unabhängige Entwicklung ohne geteilte Artefakte) gab es nur wenige Übereinstimmungen mit den Zielen des Projekts. Einen großen Vorteil hat das Projekt zum Beispiel aus der häufigen Wiederverwendung von fachlichen Komponenten gezogen. Um es kurz zu machen: Unsere Empfehlung war schließlich, erst einmal mit dem aktuellen Architekturstil weiterzuarbeiten und diesen gezielt weiterzuentwickeln.

Mittelfristig bereitet sich das Projekt schon darauf vor, in Richtung Microservices gehen zu können. Das Ziel ist, handlungsfähig zu sein, wenn neue fachliche Szenarien eine Skalierbarkeit des Systems einforden. Dass dieses Thema strategisch auf das Projekt zukommt, konnten wir mit der Bewertung bestätigen. Allerdings haben wir einen sinnvolleren Weg dahin aufzeigen können.
Bei einem anderen Kunden wiederum hat sich der Microservices-Ansatz als passend gezeigt und wir begleiten dort schon die schrittweise Umsetzung.

Was ist die Kernbotschaft des Workshops. Was sollten die Teilnehmer auf alle Fälle mitnehmen?

Harm Gnoyke: Die wichtigste Botschaft ist, dass Architekturbewertung sich oft schwergewichtig und einmalig anhört, es aber gute Möglichkeiten gibt, diese effizient in seinem Projekt zu verankern, und man damit auch seine Architekturideen und Alternativen geeignet darstellen kann.

Harm-GnoykeHarm Gnoyke ist Berater und Architekt bei embarc in Hamburg. Nach mehreren Jahren als Entwickler und Architekt im Enterprise-Umfeld konzentriert er sich nun auf die Bewertung und Entwicklung von Softwarearchitekturen. Seinen besonderen Schwerpunkt legt er dabei auf die Balance aus verschiedenen Bewertungsmethoden: Der quantitativen Analyse des Source Codes via Metriken oder Strukturanalyse sowie der qualitativen Analyse via szenariobasierten Bewertungsmethoden.

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

2 Kommentare auf "Architekturen bewerten – aber wie?"

avatar
400
  Subscribe  
Benachrichtige mich zu:
trackback

[…] bewerten – aber wie? Interview mit Harm Gnoyke (Fragen von Hartmut Schlosser) online bei JAXenter erschienen am 27. […]

Joachim Arrasz
Gast

Echt jetzt? Doch wieder ATAM? Puhh, da stellt sich mir die „Aufwand versus Effekt“ Frage…