Software Architecture Summit 2016

Vom 16. – 18.03.2016 fand der Software Architecture Summit in München statt. An diesem Informations- und Trainingsevent für Softwarearchitekten, Senior-Entwickler und IT-Projektleiter nahm ich, Steffen Kleeberg, in diesem Jahr teil. In halb- bzw. ganztägigen Workshops gingen deutschsprachige und internationale Architektur-Experten tief ins Detail, sodass die Entscheidung, welche Vorträge ich besuchen würde, nicht leichtfiel.

Da sie für meine aktuelle Projektarbeit den größten Gewinn darstellen, werde ich zwei Vorträge herausgreifen, die mir besonders gefallen haben.

 

„Langlebige Softwarearchitekturen – Technische Schulden beherrschen und abbauen“ von  Dr. Carola Lilienthal

Nur selten ergibt sich die Möglichkeit, in einem Projekt komplett bei null zu beginnen. Meistens startet man mit vorhandenen Programmteilen und fragt sich, wie es mit der Wart- und Erweiterbarkeit aussieht.

Doch auch bei neuen Systemen lohnt es sich, den Schnitt der Module und Abhängigkeiten im Auge zu behalten. Nur so kann man sicherstellen, dass zentrale Anforderungen an die Softwarearchitektur eingehalten werden.

In diesem Zusammenhang berichtete Dr. Lilienthal aus ihrer Erfahrung: Viele Projekte geraten beim Versuch, den „Korridor der technischen Schulden“ einzuhalten, aus diesem heraus.
 

Abbildung 1: Entwicklung und Effekt von technischen Schulden (Quelle: [1])

Abbildung 1: Entwicklung und Effekt von technischen Schulden (Quelle: [1])

Die Gründe dafür können vielfältig sein. Aus meiner eigenen Erfahrung kommen mir hier sofort Budgets, Zeit und organisatorische Vorgaben in den Sinn.
Beständige Architekturanalyse und -anpassung helfen, den Korridor einzuhalten und die technischen Schulden damit gering zu halten.

Am Beispiel eines auf Architekturanalyse spezialisierten Tools zeigte Dr. Lilienthal Möglichkeiten, ein System zu analysieren, mittels des Tools Architekturen besser zu verstehen und als Ergebnis auch zu verbessern.

Es ist hilfreich, solche Tools in seinem Werkzeugkoffer zu haben, um einen Soll-Ist-Vergleich vornehmen zu können und mittels „struktureller Einfachheit und Einheitlichkeit den Schlüssel zum Erfolg des Systems“ in den Händen zu halten. Ohne eine beständige Architekturerneuerung sammeln sich technische Schulden an.

Der zentralen Aussage des Vortrags kann ich hier nur beipflichten: Einfachheit = Zeitgewinn!

Aus diesem Grund muss in Softwarearchitekturen auf Modularität, Hierarchisierung und Muster auf Architekturebene geachtet werden.

Aus diesem Vortrag konnte ich mir außerdem gute Ideen und Denkansätze für eigene langlebige Softwarearchitekturen mit in meinen Projektalltag nehmen und werde zukünftig mehr darauf achten.

Bewertung von Softwarearchitekturen

Am letzten Tag des Summits konzentrierte ich mich auf den Vortrag / Workshop zum Thema „Bewertungsmethoden unter der Lupe: Architekturziele nachhaltig absichern“ von Harm Gnoyke und Stefan Zörner.

Verteilt auf den gesamten Tag, beleuchteten sie zuerst die qualitative Sicht auf das Thema Bewertungsmethoden und danach die quantitative.

Im Bereich „Qualitativ“ stellten sie dabei architekturrelevante Anforderungen, Qualitätsmerkmale / -anforderungen (u.a. nicht funktionale Anforderungen nach ISO 25010) vor. Hierbei sollte in der Bewertung auf konkrete Qualitätsmerkmale geachtet werden. Diese sollen dabei eine Top 3 (oder 5) der Merkmale darstellen, um die Komplexität einzuschränken.

Für die Bewertung wurde die Methode ATAM (Architecture Tradeoff Analysis Method [2]) vorgestellt. Diese ist bereits früh im Projekt anwendbar und basiert auf Szenarien (beispielhafte Verwendung eines Systems bezogen auf ein Qualitätsmerkmal).

Einprägsam für die eigene Praxis war für mich hierbei die Vorstellung der „Architekturbrezn“, die am Anfang und während eines Projektes das weitere Vorgehen in Bezug auf eine Architekturarbeit abbildet.

Abbildung 2: Architekturbrezel iterativer Architekturarbeit (Quelle: [3])

Abbildung 2: Architekturbrezel iterativer Architekturarbeit (Quelle: [3])

Während des Vortrags wurden die Teilnehmer immer wieder eingebunden und erprobten das Gehörte in kleinen Gruppen. Es wurden Qualitätsbäume erstellt und Szenarien zugeordnet.

Bei den quantitativen Bestandteilen einer Architekturbewertung wurde primär das Erheben von Metriken (z.B. auf Codeebene die Statische Codeanalyse) vorgestellt.

Fazit

Für mich waren die Tage beim Software Architecture Summit eine gute Möglichkeit, neue Ansätze der Softwarearchitektur kennenzulernen und mich mit Experten auf diesem Gebiet auszutauschen.

Neben den beiden dargestellten Themen gab es viele weitere Vorträge und Workshops zu aktuellen Themen wie Microservices, Docker, Enterprise Integration Patterns, REST und Cloud-Architekturen. Auf diese im Detail einzugehen, würde jedoch den Rahmen dieses Blogs sprengen.

Abschließen möchte ich mit einer zentralen Aussage aus der Keynote von Gregor Hohpe, die sich in allen Vorträgen spüren und erfahren ließ: „Architektur muss ein zentraler Bestandteil in einer Firma sein. Softwarearchitekten sind keine Firefighter, sondern diejenigen, die mittels ausreichend Freiraum für die beständige Einfachheit eines Systems sorgen sollen.“

 

 


[1] Architecture Tradeoff Analysis Method, siehe z.B. http://www.sei.cmu.edu/architecture/tools/evaluate/atam.cfm (Abruf 04/2016)

[2] Lilienthal, Dr. Carola; „Technische Schulden als Entscheidungsgrundlage: Wie Product Owner und Entwickler für langlebige Architekturen sorgen“; Business Technology 1.16 und https://jaxenter.de/technische-schulden-als-entscheidungsgrundlage-wie-product-owner-und-entwickler-fuer-langlebige-architekturen-sorgen-36139 (Abruf 04/2016)

[3] Toth, Stefan; „Vorgehensmuster für Softwarearchitektur“; HANSER ; ISBN 978-3-446-43615-2