Eigentlich sollte man sich  einfach an den Rechner setzen und Software schreiben können. Nehmen wir als Beispiel einen Importer, der Daten aus einer Datei in eine Datenbank schreiben soll und den man neu schreiben will. Das scheint eine hinreichend einfache Aufgabe zu sein, die keine Architektur erfordert. Man kann einfach loslegen und ist nach einigen Stunden oder Tagen fertig. Eine Architektur scheint überflüssig.

Aber was ist  Softwarearchitektur überhaupt? Man kann über dieses Thema lange und ausführlich diskutieren [1]. Tatsächlich gibt es zahlreiche unterschiedliche Definitionen von Softwarearchitektur. Für diesen Artikel soll die Definition gelten: „Architektur umfasst die wichtigen Dinge, was auch immer das sein mag.“ [2]. Damit ist klar, dass es Architektur geben muss. Schließlich gibt es immer irgendwelche wichtigen Dinge. In gewisser Weise ist diese Definition chauvinistisch, weil sie einfach definiert, dass Architektur wichtig ist und alles andere unwichtig.

Qualitäten

Aber was ist wichtig? Bei Software gibt es eine Vielzahl von möglichen, nichtfunktionalen Anforderungen bzw. Qualitäten. Bei einem Importer könnte beispielsweise die Performance wichtig sein, damit die Daten schnell genug in das neue System gelangen. Ein weiterer wichtiger Aspekt könnte die funktionale Korrektheit sein: Arbeitet der Importer tatsächlich richtig und importiert die Daten fachlich korrekt? Oft spielt die Benutzerfreundlichkeit eine Rolle: Wenn eine Anwendung besonders gut nutzbar ist, kann man besonders produktiv mit ihr sein. Produktivität ist oft ein Grund für das Schreiben von Software und Benutzerfreundlichkeit ein wichtiges Qualitätsziel. Software kann gegebenenfalls dank Benutzerfreundlichkeit einen hohen Marktanteil erreichen, weil Benutzer:innen sie gerne verwenden und anderen Lösungen vorziehen. Auch dann ist es ein wichtiges Qualitätsziel, den Marktanteil auszubauen.

Beim Neuschreiben des Importers liegt der Verdacht nahe, dass die alte Software irgendwelche Qualitäten so schlecht erfüllt, dass die Software neu geschrieben werden muss und daher sozusagen ein Totalverlust ist. Dabei können unterschiedliche Qualitäten ausschlaggebend sein: Der Importer kann beispielsweise viel zu langsam sein und mit den aktuellen Datenmengen nicht mehr mitkommen. Dann haben sich die Qualitätsanforderungen geändert und die Software muss diesen Anforderungen genügen. Ein Neuschreiben ist dann sinnvoll, wenn dieses Qualitätsziel mit einer Änderung des vorhandenen Codes nicht mehr möglich ist.

Oft ist der Grund für das Neuschreiben eine spezifische Qualität, nämlich die Wartbarkeit. Wenn der Code sehr schlecht verständlich ist und eine Anpassung kaum noch möglich erscheint, ist ein Neuschreiben vielleicht die einzige Möglichkeit, in Zukunft wieder Änderungen am System vorzunehmen. Auch die Performance kann möglicherweise nur durch Neuschreiben verbessert werden, weil die dafür notwendigen Änderungen sonst zu schwer umsetzbar sind.

Im konkreten Fall ist es also wahrscheinlich, dass der Import deswegen neu geschrieben wird, weil die Qualität des vorhandenen Importers nicht ausreicht. Dann ist aber die Architekturarbeit an der Qualität sehr wichtig: Es wäre mehr als peinlich, wenn man den Importer neu schreibt und danach die Probleme, die Auslöser für das Neuschreiben waren, gar nicht gelöst sind. Und ein Kernpunkt von Architektur sind eben die Antworten auf Fragen wie: Was ist das Ziel des Projekts, welche Qualitäten sind dafür notwendig und welche Maßnahmen sind erforderlich, um das Ziel und die notwendigen Qualitäten zu erreichen?

Diese Betrachtungen müssen auch bei diesem recht einfachen Projekt stattfinden. Vielleicht ist diese Abwägung nicht explizit, sondern implizit: Die neue Version wird mit einer anderen Programmiersprache oder einem anderen Algorithmus umgesetzt, damit die Performance gut genug ist. Oder die Struktur des Codes wird gemanagt und Metriken wie die Länge von Methoden oder Klassen werden erhoben, damit die neue Codebasis wartbar ist. Solche Punkte explizit aufzuschreiben, hilft dabei, die Probleme und die Lösungsstrategien zu durchdenken und Alternativen gegeneinander abzuwägen. So oder so sind die Qualitäten der Treiber für die Architektur (Abb. 1). Ein solches Vorgehen, bei dem die Qualitäten der Software die Basis für die Architektur bilden, kann man sich anhand von zwei Beispielen in Videos anschauen [3], [4].

Abb. 1: Qualitäten treiben die Architektur

Manchmal sind die Qualitäten nicht nur durch die reine Entwicklungsarbeit erreichbar: Eine gute Performance kann man auch durch bessere Hardware erreichen. Auch Ausfallsicherheit hängt neben der Software von der Hardware und Infrastruktur ab. Benutzerfreundlichkeit kann man typischerweise sogar gar nicht durch technische Maßnahmen, sondern nur durch Techniken aus dem Bereich User Experience (UX) erreichen. Dennoch muss jemand diese Aspekte betrachten, weil das Projekt sonst ein Fehlschlag werden kann.

Qualitätsszenarien

Um in komplexen Systemen solche Qualitätsanforderungen zu konkretisieren, haben sich Qualitätsszenarien bewährt [5]. Sie erlauben es, konkrete Anforderungen so aufzuschreiben, dass man später verifizieren kann, ob sie tatsächlich erfüllt sind. Zu oft sind die notwendigen Qualitäten nicht konkret genug erfasst: Wann ist ein System „schnell“ oder „benutzerfreundlich“? Auch eine Angabe wie „99,999 Prozent Verfügbarkeit“ reicht nicht. Was, wenn das System nur einmal pro Jahr für 50 Minuten ausfällt, aber dann in den entscheidenden 50 Minuten, in denen der höchste Umsatz realisiert wird? Das System erreicht zwar die geforderten 99,999 Prozent Verfügbarkeit aufs Jahr, aber das kann dennoch nicht ausreichend sein. Helfen kann ein Qualitätsszenario wie „Wenn das System zwischen 9 und 18 Uhr ausfällt, muss es nach zehn Minuten wieder zur Verfügung stehen.“ Diese Aussage ist viel konkreter als eine abstrakte Verfügbarkeit und trifft die technischen Anforderungen besser. Nun ist nämlich klar, dass das System zu bestimmten Zeiten nicht lange ausfallen darf, was bei einer allgemeinen Betrachtung der Verfügbarkeit vielleicht nicht offensichtlich geworden wäre und  zu einer unzureichenden Lösung geführt hätte.

Muss das sein?

Mindestens das Thema Qualitäten lässt sich nicht umgehen: Die entwickelte Software wird bestimmte technische Qualitäten haben wie Wartbarkeit, Performance oder Korrektheit. Man hat also nur die Wahl, sich aktiv um diese Qualitäten zu kümmern, sie genau zu verstehen, Prioritäten zu setzen und Lösungsmöglichkeiten zu identifizieren, oder das System wird zufällig irgendwelche Qualitäten haben. Es ist vermutlich deutlich besser, die Qualitäten zu steuern.

Den Prioritäten kommt dabei eine besondere Bedeutung zu: Man muss verstehen, wo welche Qualitäten gefordert sind und dafür eine passende Lösung entwickeln. Erfüllt man die notwendigen Qualitäten nicht, ist das Projekt offensichtlich ein Fehlschlag. Übererfüllt man die Qualitäten, erreicht man ein weiteres wichtiges Ziel nicht, nämlich eine möglichst wirtschaftliche Lösung. Es geht also gerade nicht darum, die in jeder Hinsicht perfekte Lösung zu bauen, sondern vielmehr die Lösung zu bauen, die das Problem löst und dabei auch möglichst kostengünstig ist.

Natürlich steht es jedem frei, diese Betrachtungen nicht anzustellen. Das ist aber kaum empfehlenswert – und meistens wird es zumindest eine oberflächliche Betrachtung geben. Und selbst wenn man diese Betrachtung nicht anstellt: Dann trifft man auch Entscheidungen, die Qualitäten beeinflussen – nur mit einer weniger guten Planung. Software hat immer Eigenschaften wie Performance, Korrektheit oder Wartbarkeit, auch wenn man sie nicht aktiv gestaltet, und diese Eigenschaften sind ein Ergebnis von technischen Entscheidungen.

Also kann man sich nicht aus der Architekturarbeit verabschieden: Das System wird irgendeine Architektur haben. Dafür ist es egal, ob man an der Architektur arbeitet oder nicht.

Architektur = Struktur?

Damit ist die Architektur also in erster Linie ein Ansatz, mit dem Qualitäten umgesetzt werden. Performance kann man durch die Auswahl geeigneter Technologien beeinflussen. Bei Korrektheit ist die Lösung eher im Bereich Tests zu suchen.

Viele verstehen unter Architektur aber nur die Struktur der Software, wie also der Source Code organisiert wird. Dazu zählt die Aufteilung in Klassen, Packages, Microservices, Source-Code-Projekte usw. – also die gesamte logische Organisation des Codes. Er wird typischerweise nach fachlichen Aspekten wie Bounded Contexts oder technischen Aspekten wie Schichten organisiert.

Die Struktur der Software hat aber nur begrenzten Einfluss auf die Qualitäten: Lediglich die Qualität „Wartbarkeit“ wird durch die Struktur der Software beeinflusst. Aber auch Wartbarkeit hängt von anderen Faktoren ab. Beispielsweise kann man Software mit vielen Tests besonders einfach warten. Bei dieser Auffassung von Architekturarbeit kommt der Struktur der Software also  keine so große Bedeutung zu, denn sie beeinflusst nur wenige Qualitätskriterien.

Das steht im Widerspruch zu der weitverbreiteten Annahme, dass die Struktur der Software im Wesentlichen die Architektur darstellt. Vielleicht kommt diese Wahrnehmung dadurch zustande, dass die Struktur der Software die Wartbarkeit und damit auch die Wirtschaftlichkeit entscheidend beeinflusst. Sie kann sogar den Aufwand beim initialen Erstellen der Software beeinflussen, nicht erst den Aufwand bei der Wartung. Wirtschaftlichkeit ist typischerweise eines der wichtigsten Ziele in der Entwicklung. Also treiben Wartbarkeit und Wirtschaftlichkeit den Fokus auf die Struktur der Software (Abb. 2).

Abb. 2: Wartbarkeit und Wirtschaftlichkeit bei der Entwicklung sind Gründe, sich auf die Struktur der Software zu fokussieren

Ein weiterer Grund für diese Gleichsetzung von Architektur mit der Struktur der Software ist, dass Architektur im Bauwesen eben auch für die Strukturen steht. In der Realität würde ein Fokus auf die Struktur als alleinige Eigenschaft der Architektur dazu führen, dass die Qualitäten jenseits der Wartbarkeit vernachlässigt werden. Das kann recht leicht zu einem Architekturfehlschlag führen.

Architektur skalieren

Bisher haben wir einen sehr einfachen Fall betrachtet: Den Importer schreibt nur eine Person und die Entwicklung dauert nicht sonderlich lange. Typischerweise arbeitet aber ein Team an einer Software. Damit ist eine Kommunikation der Architektur und eine gemeinsame Arbeit an der Architektur unumgänglich. Dabei geht es um die Koordination der Techniker:innen, deren Ideen in die Architektur einfließen sollen, und um die verschiedenen Stakeholder, die Erwartungen an die Software haben und damit eine Quelle von Qualitätsanforderungen sind.

Dementsprechend muss die Architektur dokumentiert und kommuniziert werden. Wenn das Projekt groß und komplex genug ist, kann das eine Vollzeitaufgabe sein. Dann gibt es die Möglichkeit, dass sich eine Person Vollzeit um das Thema Architektur kümmert und nicht an der Codeentwicklung selbst teilnimmt. Eine andere Möglichkeit ist, dass die Architekt:innen als „Coding Architects“ an der Entwicklung teilnehmen. Dann müssen sich aber mehrere Architekt:innen die Architekturarbeit aufteilen, wenn die reine Architekturarbeit tatsächlich ein Vollzeitjob ist und sie noch Zeit für Coding haben wollen. Die Architekt:innen müssen untereinander kommunizieren und sich koordinieren, was zu mehr Kommunikation und Koordination führt.

Coding Architects haben oft einen besseren Ruf, weil sie durch die Arbeit am Code wissen, was im Projekt geschieht und daher nicht von der Realität entkoppelt im Architekturelfenbeinturm enden können. Allerdings sollten auch Vollzeitarchitekt:innen, wenn sie kommunikationsstark sind, genügend Informationen über die Situation im Projekt haben. Sie sollten dann eine moderierende Rolle einnehmen und die anderen am Projekt Beteiligten als Expert:innen für die jeweiligen Bereiche wahrnehmen. Eine Person, die sich beispielsweise mit dem Frontend eines Systems beschäftigt, ist vermutlich qualifizierter, Entscheidungen über diesen Bereich zu treffen, als eine Person, die sich allgemein um die Architektur kümmert und in diesem Bereich keine Tiefe hat. Die Meinung der Frontend-Expert:in muss mindestens in die Entscheidung einfließen und wird sie vermutlich entscheidend beeinflussen. Dementsprechend müssen Vollzeitarchitekt:innen meistens Abstand davon nehmen, eine Entscheidungen alleine zu treffen. Es geht in dieser Rolle um Kommunikation und Koordination. Deswegen ist es nicht so einfach, die Rolle „Softwarearchitekt:in“ zu verstehen und gut auszufüllen [6], [7].

Manche Architekturentscheidungen werden auch gar nicht explizit getroffen. Entwickler:innen schreiben Code und treffen dabei immer wieder Entscheidungen, die die Struktur des Systems beeinflussen. Schließlich wird erst dann entschieden, wie der Code in Packages oder Microservices strukturiert ist, wenn er geschrieben wird. Ebenso wählen Entwickler:innen gegebenenfalls bestimmte Technologien aus und nehmen so Einfluss auf die technischen Eigenschaften des Systems, die wiederum die Qualitäten beeinflussen. Also treffen auch sie Architekturentscheidungen. All diese Entscheidungen zu kontrollieren, wäre zu zeitaufwendig, sodass auch Entwickler:innen manchmal die Rolle „Softwarearchitekt:in“ spielen. Damit diese Entscheidungen nicht konträr zu anderen Entscheidungen stehen, ist wieder Kommunikation und Koordination notwendig.

Zu viel oder zu wenig?

Man kann noch die Frage stellen, ob es zu wenig oder zu viel Architektur geben kann. Wenn man zu wenig Aufwand in die Architektur steckt, besteht die Gefahr, dass man die technischen Ziele nicht erreicht, weil man sie entweder nicht versteht oder sich keine Lösungen für die Erreichung überlegt hat. Ebenso kann es gut sein, dass die Struktur und der Rest der Architektur nicht ausreichend kommuniziert wird. Das kann dann dazu führen, dass die Architekturkonzepte nicht durchgehalten werden und das Softwaresystem im Chaos endet, also technische Konzepte nicht umgesetzt werden oder die Strukturierung des Systems von dem eigentlich geplanten Design signifikant abweicht.

Zu viel Architektur erscheint zunächst kaum möglich, aber man kann zu viel Aufwand für Architektur treiben, ohne dabei ausreichende Ergebnisse zu erzielen. Beispiel ist eine übermäßige Bürokratie für Entscheidungen. Ebenso können frühzeitige Entscheidungen eingefordert werden, statt Entscheidungen so spät wie möglich zu treffen. Das führt zu theoretischen Diskussionen, weil über Probleme in der ferneren Zukunft gesprochen wird. Zu einem späteren Zeitpunkt stehen mehr und bessere Informationen zur Verfügung, weil man mit der Zeit mehr über die jeweiligen Probleme lernt und sie dann besser lösen kann.

In der Praxis kommt beides vor, zu wenig und zu viel Architektur, sodass man hier keine generellen Hinweise geben kann, wie man typischerweise vorgehen soll (Abb. 3).

Abb. 3: Es kann zu wenig oder zu viel Softwarearchitektur geben – oder gar ein Architekturtheater

Architekturtheater?

Kevlin Henney hat den Begriff Architekturtheater geprägt [8]: Ein schwergewichtiger, komplizierter Prozess mit viel Bürokratie und Hierarchie, bei dem aber am Ende keine sinnvollen Entscheidungen getroffen werden. Hier ist  ein Zuviel an Prozess mit einem Zuwenig an Ergebnis kombiniert – es ist  gleichzeitig zu viel und zu wenig Architektur. „Architekturtheater“ beschreibt gut, was vor sich geht: Es wird vorgespielt, dass man sich intensiv um Architektur kümmert, aber weil der Prozess so schwerfällig ist und auch im Sinne des Elfenbeinturms keine echte Beziehung zur Realität hat, findet in Wirklichkeit keine effektive Architekturarbeit statt.

Fazit

Es gibt also in einem Softwaresystem immer eine Architektur. Sie umfasst neben der Struktur der Software auch die technischen Lösungen für die spezifischen Herausforderungen. Man kann die Architektur nur aktiv gestalten oder die Gestaltung dem Zufall überlassen. Dementsprechend gibt es irgendwelche Personen, die an der Architektur arbeiten. Die können sich entweder Vollzeit mit der Architektur beschäftigen oder es können mehr Menschen sein, die dann nur einen Teil ihrer Zeit mit Softwarearchitektur verbringen.Mit dem Thema des Artikels hat sich auch eine Episode von „Software Architektur im Stream“ beschäftigt [9].

Links & Literatur

[1] Software Architektur im Stream: „Was ist Softwarearchitektur überhaupt?“: https://software-architektur.tv/2022/02/11/folge109.html

[2] https://martinfowler.com/architecture

[3] Software Architektur im Stream, Folgen zu „Wir bauen eine Software-Architektur“: https://software-architektur.tv/tags.html#Wir%20bauen%20eine%20Software-Architektur

[4] Software Architektur im Stream, Folgen zur iSAQB-Beispiel-Aufgabe: https://software-architektur.tv/tags.html#iSAQB%20Advanced%20Beispielaufgabe

[5] Software Architektur im Stream: „Qualitätsszenarien“: https://software-architektur.tv/2021/07/16/folge67.html

[6] „Die Rolle ‚Software-Architekt:in‘ – Folge 1“: https://software-architektur.tv/2022/07/07/folge126.html

[7] „Die Rolle ‚Software-Architekt:in‘ – Folge 2“: https://software-architektur.tv/2022/07/15/folge127.html

[8] https://mastodon.social/@kevlin/112003129757159797

[9] „Softwarearchitektur – Muss das sein?“: https://software-architektur.tv/2024/03/08/folge206.html