Softwarearchitektur 
Schiller-Stoff, Sebastian David; sebastian.stoff@uni-graz.at
Es hat sich bisher keine allgemein anerkannte Definition von Softwarearchitektur durchgesetzt. (Richards/Ford 2021, S. 3)
Der Wesenskern der Softwarearchitektur liegt jedenfalls in der Konstruktion von langlebiger Software. Sie begreift sich als ein Teilgebiet der Softwareentwicklung und betrachtet Software (weniger als das Ergebnis eines einmaligen Entwicklungsprozesses) als ein sich dauernd veränderndes, komplexes menschlich-soziales Artefakt, welches maßgeblich von zeitlich sensiblen sozialen Strukturen beeinflusst und geformt wird. (Starke 2020, S. 6f.)
In der Literatur wird in diesem Zusammenhang häufig auf das Gesetz von Conway verwiesen. Dieses besagt, dass die Architektur eines Systems früher oder später den Kommunikationsprozessen einer Organisation entspricht. Wird beispielsweise eine Applikation von zwei unterschiedlichen Teams entworfen, wird auch die Architektur letztendlich aus zwei Teilen bestehen. Damit wird Software nicht nur entworfen, sondern auch von ihren Kontexten geformt. (Dowalil 2020, S. 148-150); Martin 2018, S. 83
Grundlegendes Ziel der Softwarearchitektur ist es, die Änderungsfähigkeit einer Software zu erhalten, um den Wunsch nach Langlebigkeit zu erfüllen. Dazu muss die ständig drohende Komplexitätszunahme eines Softwaresystems dauerhaft eingedämmt werden, ohne dabei die Änderungsfähigkeit des Systems (zu stark) zu beeinträchtigen. (Richards/Ford 2021, S.17); (Lilienthal 2020, S. 6–12); (Starke et al. 2020, S.20); (Dowalil 2020, S. 2–5)
Im Fokus des Erkenntnisinteresses stehen daher, nebst Entwurfspraktiken, Designmustern und Herangehensweisen für erfolgreiche Softwareprojekte, auch die Gestaltung passender Organisationsstrukturen und funktionierender Kommunikationsweisen im Dienste des Komplexitätsmanagements. (Richards/Ford 2021 S. 3f)
Beispielsweise strukturiert ein Softwarearchitekt ein System grundlegend in Server- und Clientseite und fordert folgend die Schaffung eines eigenen Frontend- und Backend-Teams.
Die Softwarearchitektur bietet keine garantierten Leitfäden an, sondern besteht im Wesentlichen aus regelhaften Einschränkungen (in Form von Kompromissen), die auf den eigenen Anwendungsfall angepasst werden müssen. Dazu gehören unter anderem Architekturstile und-prinzipien, Designprinzipien, Kommunikations- und Visualisierungsstrategien, Dokumentations- und Architekturvorlagen, genauso wie Coding und Architektur Best Practices wie auch Architekturmuster und Anti-Patterns. (Lilienthal 2020, S. 75–140)
Diese regelhaften Einschränkungen beziehen sich auf den analysierten Abstraktionsgrad des Softwaresystems. So betrachten beispielsweise Architekturstile und Architekturprinzipien die hohe Ebene von Systemen und Subsystemen. Demgegenüber beziehen sich Designprinzipien eher mehr auf Quellcode und direkt darüber liegende Ebenen (wie zum Beispiel Module und Pakete). (Dowalil 2020, S. 146f.)
Softwarearchitekten und Softwarearchitektinnen gestalten entlang gängiger Regelwerke der Softwarearchitektur einen Systementwurf und kommunizieren diesen mit Hilfe von Diagrammen und Dokumentation. Der Systementwurf wird als Teil des Entwicklungsprozesses iterativ überarbeitet.
Beispielsweise entscheidet sich der Software-Architekt/ die Software-Architektin für die grobe Unterteilung des Systementwurfs entlang der generellen Anwendungsfelder einer Organisationseinheit. Er/Sie schneidet das System in die Subsysteme „Nutzerverwaltung“ und „Buchausleihe“ und sieht jeweils eigene Entwickler:innen für die Umsetzung vor. Ferner legt er als den verwendeten Architekturstil die „Service orientierte Architektur“ fest und empfiehlt die Umsetzung als Verteiltes System. Der Architekt/die Architektin begründet diese Entscheidungen mit einem geringen Kopplungsgrad der Subsysteme und einer einfachen künftigen Änderbarkeit der Systembestandteile.
In einem Editionsprojekt könnte eine Architekturentscheidung beispielsweise sein, die zu entwickelnde Webapplikation in eine separate Frontend-Anwendung und in ein eigenständiges Backend zu unterteilen. Diese Entscheidung wird begründet mit der geographischen Verteilung des Projektteams, welches von zwei separaten Forschungseinrichtungen gestellt wird. Der Architekt/die Architektin argumentiert, dass nach dem Gesetz von Conway zwangsläufig zwei Systemteile entstehen würden.
Literatur:
- Dowalil, Herbert. 2020. Modulare Softwarearchitektur: Nachhaltiger Entwurf durch Microservices, Modulithen und SOA 2.0 Modulare Softwarearchitektur. München.
- Lilienthal, Carola. 2019. Langlebige Software-Architekturen. Technische Schulden analysieren, begrenzen und abbauen. Heidelberg. URL: https://www.langlebige-softwarearchitekturen.de.
- Martin, Robert Cecile. 2018. Clean Architecture - Gute Softwarearchitekturen: Das Praxis-Handbuch für professionelles Softwaredesign. Regeln und Paradigmen für effiziente Softwarestrukturierung. Frechen bei Köln.
- Richards, Mark; Ford, Neal. 2020. Handbuch moderner Softwarearchitektur: Architekturstile, Patterns und Best Practices Handbuch moderner Softwarearchitektur. Heidelberg.
- Starke, Gernot. 2002. Effektive Software-Architekturen: Ein praktischer Leitfaden Effektive Software-Architekturen. München Wien.
- Gharbi, Mahbouba; Koschel, Arne; Rausch, Andreas; Starke, Gernot. 2020. Basiswissen für Softwarearchitekten. Aus- und Weiterbildung nach iSAQB-Standard zum Certified Professional for Software Architecture. Heidelberg. URL: https://www.amazon.de/Basiswissen-f-C3-BCr-Softwarearchitekten-Weiterbildung-iSAQB-Standard-dp-3864909848/dp/3864909848/ref=dp_ob_title_bk.