Eine klare und umsetzbare Definition von Softwarearchitektur

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

YouTube immer entsperren

Es gibt viele Definitionen von Softwarearchitektur. Einige sind breit und wage; andere verfolgen einen wissenschaftlicheren Ansatz. Ich bevorzuge die Softwarearchitektur Definition von Martin Fowler und Ralph Johnson, weil sie klar und umsetzbar ist.

Die wichtigen Dinge

Dieses Zitat ist in seiner Form ziemlich einfach, aber wir müssen näher beleuchten, um seine Bedeutung und seine Klarheit zu verstehen.

Wenn Experten und Softwareentwickler an einem Softwaresystem arbeiten, teilen sie ein gemeinsames Verständnis des Softwaredesigns. Sie können dieses Verständnis in Diagrammen, Code oder jeder anderen Form dokumentieren, aber das Wesentliche ist das gemeinsame Bild über Komponenten und Modelle in den Köpfen der Experten.

Der zweite Aspekt betrifft „die Entscheidungen, die später schwer zu ändern sind“ – ein wesentliches Zitat von Martin Fowler (ins Deutsche übersetzt). Wir können die Zukunft nicht vorhersagen. Wir wissen nicht, welche Bereiche der Software sich ändern müssen, wenn sich das Produkt weiterentwickelt oder das Unternehmens seinen Kurs anpasst. Was wir vorhersagen können, sind die Kosten der Anpassung der Software. Wenn die Kosten für die Änderung einer Komponente hoch und die Komponente für das Produkt wesentlich sind, haben wir etwas Wichtiges identifiziert.

Diese beiden Aspekte sind Hilfen, um wichtige Dinge zu identifizieren.

Was auch immer das ist

Ralphs zweiter Satz: „Was auch immer das ist.“ ist ebenso wichtig. Bei der Softwarearchitektur geht es nicht nur um die Auswahl von High-Level-Architekturmustern wie z.B. Microservices oder Monolithen. Es geht nicht nur um die Auswahl der perfekten Persistenzschicht. Es kann wirklich alles sein, was zukünftige Änderungen einfach macht.

Wenn ich mit Kunden an bestehenden Softwareprodukten arbeite, beginne ich damit, ein gemeinsames Verständnis des Architekturentwurfs zu finden. Oft zeigt sich hier schon ein Mangel an Kommunikation bzw. ein fehlendes gemeinsames Verständnis zwischen den Teammitgliedern.  Der Prozess der Abstimmung des Verständnisses zwischen den Experten führt normalerweise schnell zu notwendigen Maßnahmen, um ihre Architektur flexibler für Veränderungen zu machen. Die Dokumentation der wichtigen Teile der Architektur hilft dieses Verständnis zu bewahren.

Bei Projekten, die auf der „grünen Wiese“ starten oder bei neuen Features liegt der Fokus eher darauf, Bereiche zu identifizieren, die später schwer zu ändern sind. Dies können etwa die Zuständigkeiten einzelner Microservices, die generelle Wahl der Architektur oder die zu verwendenden Programmiersprachen sein. Diese Bereiche sind es wert, gründlicher gestaltet und durchdacht zu werden als Bereiche, die sich leicht verändern lassen. Dieser Prozess zielt darauf ab, flexible Lösungen zu entwickeln und das gemeinsame Verständnis aufbauen.

Als Softwarearchitekt hat mich diese Definition nie im Stich gelassen. Sie ist leicht zu erklären und umsetzbar, auch für Personen, die keine Spezialisten im Bereich Softwareentwicklung sind. Dies ist praktisch, denn die Arbeit eines Softwarearchitekten läuft immer darauf hinaus, einen strategischen technischen Plan zu erstellen, der gut auf die Produktvision ausgerichtet ist. Diese Softwarearchitektur Definition und die daraus entstehenden Artefakte (gemeinsames Verständnis, Diagramme, Dokumentation) sind wichtig für alle Beteiligten und machen Änderungen einfach.