Was ist Softwarearchitektur?

Softwarearchitektur beschreibt die grundlegende Struktur einer Software: aus welchen Bausteinen sie besteht, welche Aufgaben jeder Baustein hat, wie sie miteinander kommunizieren und nach welchen Prinzipien das Ganze entworfen ist. Sie umfasst die Entscheidungen, die sich später nur mit großem Aufwand ändern lassen – etwa Aufteilung, Datenhaltung und Schnittstellen.

Nutzer sehen die Architektur nie direkt. Sie spüren sie aber: an Ladezeiten, an der Frage, wie lange eine kleine Änderung dauert, und daran, ob ein Ausfall eines Teils gleich alles lahmlegt.

Was Softwarearchitektur umfasst

Der Vergleich mit dem Bauwesen liegt nahe und trägt ein gutes Stück. Ein Architekt legt Tragwerk, Raumaufteilung, Leitungswege und Fluchtwege fest, nicht die Farbe der Türklinken. Ähnlich regelt die Softwarearchitektur:

• Bausteine: Welche Module oder Dienste gibt es, und wofür ist jeder zuständig?
• Schnittstellen: Wie tauschen die Bausteine Daten aus, und wie sprechen sie mit Fremdsystemen?
• Daten: Wo liegen welche Daten, wer darf sie ändern, wie bleiben sie konsistent?
• Qualitätsziele: Wie schnell, wie verfügbar, wie sicher, wie leicht änderbar muss das System sein?
• Technologien: Programmiersprachen, Frameworks, Datenbanken, Betriebsumgebung.

Die Norm ISO/IEC/IEEE 42010 beschreibt, wie Architekturen dokumentiert werden. In der Praxis verbreitet ist im deutschsprachigen Raum die Vorlage arc42.

Warum Architektur über Kosten entscheidet

Die Entwicklung der ersten Version ist oft nur ein kleiner Teil der Gesamtkosten einer Software. Der größere Teil entsteht über Jahre durch Änderungen, Erweiterungen und Betrieb. Eine gute Architektur hält diese Folgekosten niedrig: Neue Funktionen lassen sich an klar abgegrenzten Stellen ergänzen, ohne dass an fünf anderen Stellen etwas bricht. Eine schlechte Architektur macht jede Änderung zum Risiko, und irgendwann traut sich niemand mehr, etwas anzufassen. Die angesammelten Kompromisse nennt man technische Schulden.

Verbreitete Architekturmuster

Kein Muster ist per se besser. Die Wahl hängt von Teamgröße, Änderungstempo, Last und Budget für den Betrieb ab.

Entscheidungen, die früh fallen sollten

1. Schnitt nach Fachlichkeit: Die Grenzen der Bausteine folgen den Aufgaben im Betrieb, etwa Angebot, Auftrag, Rechnung – nicht technischen Ebenen.
2. Führendes System je Datenart: Wo werden Kundenstammdaten gepflegt, wo Artikel, wo Preise? Doppelte Pflege ist die häufigste Fehlerquelle.
3. Schnittstellen zuerst: Wie das Frontend mit dem Backend und das System mit ERP und Partnern spricht, wird festgelegt, bevor Details gebaut werden.
4. Betrieb mitdenken: Wo läuft die Software, wie wird sie ausgeliefert, überwacht, gesichert?
5. Entscheidungen dokumentieren: Kurze Architekturentscheidungen mit Begründung helfen jedem, der später dazukommt.

Beispiel aus dem Mittelstand

Ein Anbieter von Gebäudedienstleistungen plant Einsätze bisher mit Tabellen, Anrufen und Messengergruppen. Die neue Software soll Aufträge erfassen, Personal einplanen, Einsätze per App dokumentieren und abrechnen. Eine tragfähige Architektur könnte so aussehen: ein modularer Kern mit Modulen für Aufträge, Planung und Abrechnung, eine gemeinsame Schnittstelle für Web-Anwendung im Büro und App der Mitarbeitenden, eine Anbindung an die bestehende Buchhaltung, und eine getrennte Komponente für Fotos und Dokumente, weil diese viel Speicher brauchen. Microservices wären hier überdimensioniert, ein unstrukturierter Monolith würde nach zwei Jahren schwer wartbar.

Wird später ein zweiter Standort oder ein Kundenportal nötig, kommt ein weiteres Frontend an dieselbe Schnittstelle hinzu. Der Kern bleibt unverändert – genau das ist der Ertrag einer bewussten Architektur.

Typische Architekturfehler

• Architektur nach Trend: Microservices, Kubernetes und Event-Streaming für eine Anwendung mit zwanzig Nutzern.
• Keine Architektur: Alles hängt mit allem zusammen, weil nie entschieden wurde, wo was hingehört.
• Datenbank als Schnittstelle: Mehrere Anwendungen greifen direkt auf dieselben Tabellen zu. Jede Änderung wird zum Abstimmungsmarathon.
• Einmal entworfen, nie überprüft: Anforderungen ändern sich, die Architektur muss mitwachsen. Regelmäßiges Refactoring hält sie gesund.

In der Praxis: Architektur, die zum Betrieb passt

Bei der Softwareentwicklung legen wir die Architektur zu Beginn gemeinsam mit Ihnen fest und halten die Entscheidungen schriftlich fest. Wir wählen verbreitete Technologien und einen Schnitt, der zu Ihrem Team und Ihrer Wachstumsplanung passt. Bei gewachsenen Systemen prüfen wir im Rahmen der IT-Modernisierung, welche Teile tragen und welche schrittweise ersetzt werden sollten. Ein Beispiel dafür beschreibt der Beitrag Legacy-Software ablösen.

Häufige Fragen

Was ist Softwarearchitektur einfach erklärt?

Der Bauplan einer Software: welche Teile es gibt, was jedes Teil tut und wie sie zusammenarbeiten. Er entscheidet darüber, wie leicht sich die Software später ändern lässt.

Was ist der Unterschied zwischen Softwarearchitektur und Softwaredesign?

Architektur betrifft die großen, schwer änderbaren Entscheidungen über Struktur und Technologie. Softwaredesign regelt die Details innerhalb eines Bausteins, etwa Klassen und Funktionen. Die Grenze ist fließend.

Braucht ein kleines Projekt eine Architektur?

Jede Software hat eine, gewollt oder nicht. Bei kleinen Projekten reichen ein paar bewusste Entscheidungen auf einer Seite. Das kostet wenig und spart viel.

Wer ist für die Softwarearchitektur verantwortlich?

In größeren Teams eine Architektin oder ein Architekt, in kleineren meist erfahrene Entwickler. Wichtig ist, dass jemand die Entscheidungen verantwortet und sie mit den fachlichen Zielen des Auftraggebers abgleicht.