Software-Architektur prüfen: 10 Fragen zum Selbsttest
Ob die Architektur Ihrer Software ein Problem ist, zeigen zehn Fragen zu Änderungsdauer, Auslieferung, Daten, Abhängigkeiten, Tests und Wissen, die Sie ohne Blick in den Code beantworten. Jede Antwort ist grün, gelb oder rot; die Summe sagt, ob Sie die Software-Architektur prüfen lassen sollten.
Architektur ist das, was an einer Software teuer zu ändern ist: wie sie in Teile geschnitten ist, wo die Daten liegen, wie die Teile miteinander reden und wie neuer Code live kommt. Probleme damit sieht man selten am Code selbst, sondern an Folgen, die Geschäftsführer aus dem Alltag kennen: Kleine Wünsche dauern lange, Auslieferungen machen nervös, und für bestimmte Bereiche gibt es genau eine Person.
Die zehn Fragen unten übersetzen solche Folgen in Kriterien. Sie beantworten sie zusammen mit Ihrem Entwicklungsteam oder Dienstleister in etwa einer Stunde. Was technische Schulden sind und was sie kosten, erklärt Technische Schulden erklärt für Geschäftsführer; wie ein Team die Code-Qualität mit Tests und Analyse belegt, steht unter Code-Qualität messbar machen. Der Selbsttest prüft die Struktur darüber: wie Teile zusammenhängen und wo eine Änderung landet.
Änderungen und Auslieferung
Die ersten drei Fragen folgen den Kennzahlen, mit denen das Forschungsprogramm DORA die Lieferfähigkeit von Software-Teams misst: Durchlaufzeit einer Änderung, Häufigkeit der Auslieferung und Anteil der Auslieferungen, die sofort nachgebessert werden müssen. Die Grenzwerte für grün, gelb und rot sind unsere Einschätzung für eine Webanwendung im Mittelstand, keine DORA-Werte.
1. Wie lange dauert eine kleine Änderung, bis sie live ist?
Gemeint ist eine Änderung wie ein neues Pflichtfeld im Formular, gemessen vom fertigen Code bis zur Auslieferung. Grün: wenige Tage. Gelb: ein bis vier Wochen, weil auf ein Sammel-Release gewartet wird. Rot: länger als ein Monat, oder niemand kann es sagen.
2. Wie wird ausgeliefert, und wer kann das?
Grün: automatisiert über eine Pipeline, mindestens zwei Personen können es, ein Rückweg ist erprobt. Gelb: nach schriftlicher Anleitung von Hand. Rot: Dateien werden direkt auf den Server kopiert, und nur eine Person weiß, wie.
3. Wie oft muss nach einer Auslieferung sofort nachgebessert werden?
Grün: selten, und ein Fehler ist in Minuten zurückgenommen. Gelb: bei jeder fünften oder sechsten Auslieferung. Rot: fast nach jeder, oder Auslieferungen werden aus Angst davor auf Wochen geschoben.
Daten und Abhängigkeiten
4. Wo liegen die Daten, und wer schreibt sie?
Für jede wichtige Datenart, etwa Kunden, Aufträge oder Preise, gibt es idealerweise genau ein System, das sie führt. Grün: eine führende Quelle je Datenart, andere Systeme lesen. Gelb: Kopien in anderen Systemen, nachts abgeglichen. Rot: mehrere Systeme schreiben dieselben Daten, und Unterschiede werden in Excel aufgelöst.
5. Wie viele Systeme hängen voneinander ab, und was passiert bei einem Ausfall?
Grün: Eine Liste aller angebundenen Systeme existiert, und fällt eines aus, steht nur die betroffene Funktion. Gelb: Die Liste ist unvollständig, ein Ausfall bremst mehrere Funktionen. Rot: Niemand hat die Liste, und der Ausfall eines Zahlungs- oder Versanddienstes legt die ganze Anwendung still. Wie sich die Zahl der Dienste selbst zum Problem auswachsen kann, beschreibt Microservices, die niemand bestellt hat.
Tests und Code-Struktur
6. Was wird vor einer Auslieferung automatisch geprüft?
Grün: Automatisierte Tests decken die Kernabläufe ab, etwa Bestellung, Anmeldung und Abrechnung, und laufen vor jeder Auslieferung. Gelb: Tests gibt es für Teile, der Rest wird von Hand durchgeklickt. Rot: Geprüft wird nach dem Livegang, durch die Fachabteilung oder die Kunden.
7. Steckt dieselbe Regel an mehreren Stellen?
Eine Preisregel, die im Shop, in der Rechnung und im Export getrennt programmiert ist, muss bei jeder Änderung dreimal angepasst werden. Grün: Jede Geschäftsregel steht an einer Stelle. Gelb: an zwei Stellen, bekannt und dokumentiert. Rot: Niemand weiß, an wie vielen Stellen.
Bei einem REST-API-Backend für ein internes Tools-Portal haben wir zwei Frontends gebaut, eines für interne Disponenten und eines für externe Mitarbeiter, beide über dieselbe Auth-Schicht mit denselben Rollen-Checks. Ein Fehler an der Anmeldung war damit an einer Stelle zu beheben, und eine neue Rolle ließ sich an genau einer Stelle einhängen.
8. Gibt es Bereiche, die niemand gern anfasst?
Grün: Nein, Änderungen verteilen sich über die ganze Anwendung. Gelb: Ein Bereich gilt als heikel, Änderungen dort werden mit Aufschlag geschätzt. Rot: Wünsche werden abgelehnt oder umgangen, weil ein Teil als zu riskant gilt.
Wissen und Betrieb
9. Wie viele Personen kennen jeden Teil der Anwendung?
Melvin Conway hat 1968 beschrieben, dass Organisationen Systeme entwerfen, deren Struktur ihre Kommunikationsstruktur abbildet. Umgekehrt zeigt die Verteilung des Wissens, wo die Struktur an Personen hängt. Grün: mindestens zwei Personen je Bereich, wichtige Entscheidungen sind schriftlich festgehalten. Gelb: zwei Personen, aber ohne Dokumentation. Rot: genau eine Person, und sie ist schwer erreichbar. Was dieser Fall für das Unternehmen bedeutet, steht unter Bus-Faktor: Was passiert, wenn Ihr einziger Entwickler ausfällt?.
10. Sind Konfiguration und Zugangsdaten vom Code getrennt, und gleicht das Testsystem dem Live-System?
Die Twelve-Factor-Methode verlangt eine strikte Trennung von Konfiguration und Code und schlägt als Probe vor, ob der Code jederzeit veröffentlicht werden könnte, ohne Zugangsdaten preiszugeben. Sie rät außerdem, in Entwicklung und Produktion dieselben Dienste wie Datenbank und Cache zu nutzen. Grün: Beides trifft zu. Gelb: Konfiguration getrennt, das Testsystem weicht ab. Rot: Passwörter stehen im Code, oder es gibt kein Testsystem.
Auswertung: grün, gelb, rot
Zählen Sie grün mit 0, gelb mit 1 und rot mit 2 Punkten. Die Summe liegt zwischen 0 und 20. Die Schwellen unten sind unsere Einschätzung; sie folgen daraus, dass zwei bis drei gelbe Antworten in einer gewachsenen Anwendung normal sind, rote Antworten bei Auslieferung, Daten und Tests aber jede künftige Änderung verteuern.
0 bis 5 Punkte: Die Architektur trägt. Arbeiten Sie die gelben Punkte im laufenden Betrieb ab.
6 bis 11 Punkte: Einzelne Stellen bremsen. Legen Sie für jede rote Antwort eine Maßnahme mit Verantwortlichem und Termin fest.
12 Punkte oder mehr, oder rot bei Frage 2, 4 oder 6: Lassen Sie die Architektur von außen ansehen, bevor größere neue Funktionen beauftragt werden.
Wie es nach einem schlechten Ergebnis weitergeht, ob mit schrittweisem Umbau oder Neubau, ordnet Refactoring oder Neubau? Eine Entscheidungshilfe ein. Tiefergehende Prüfungen von Infrastruktur und Sicherheit beschreibt unsere Seite zu IT-Analysen und Audits.
Tragen Sie je Frage eine Farbe und einen Satz Begründung ein; die Begründung ist für das Gespräch mit dem Dienstleister wertvoller als die Summe.
SELBSTTEST SOFTWARE-ARCHITEKTUR
Anwendung: ____________________ Datum: __________ Beteiligte: ____________________
Punkte: grün = 0, gelb = 1, rot = 2
Nr. | Frage | Farbe | Punkte | Begründung in einem Satz
1 | Dauer einer kleinen Änderung bis live | | |
2 | Auslieferung: wie, und wer kann es | | |
3 | Nachbesserung direkt nach Auslieferungen | | |
4 | Führende Quelle je Datenart | | |
5 | Abhängigkeiten und Folgen eines Ausfalls | | |
6 | Automatische Prüfung vor der Auslieferung | | |
7 | Geschäftsregeln an einer Stelle | | |
8 | Bereiche, die niemand anfassen will | | |
9 | Personen je Bereich, Entscheidungen dokumentiert | | |
10 | Konfiguration getrennt, Testsystem wie Live | | |
Summe: ____ von 20
Rot bei Frage 2, 4 oder 6? ja / nein
Auswertung:
0 bis 5 Architektur trägt, gelbe Punkte im Betrieb abarbeiten
6 bis 11 je rote Antwort eine Maßnahme mit Verantwortlichem und Termin
12 bis 20 oder rot bei 2, 4 oder 6: Architektur von außen ansehen lassen
Zum Selbsttest
Häufige Fragen
-
Software-Architektur beschreibt die grundlegende Struktur einer Anwendung: in welche Teile sie geschnitten ist, wo Daten liegen, wie Teile und Fremdsysteme miteinander kommunizieren und wie Code ausgeliefert wird. Es sind die Entscheidungen, die sich später nur mit großem Aufwand ändern lassen. Einzelne Code-Zeilen und die Wahl eines Plugins gehören meist nicht dazu.
-
An Zeit und Angst: Ähnliche Änderungen dauern von Mal zu Mal länger, Auslieferungen werden aufgeschoben, und einzelne Bereiche fasst nur noch eine Person an. Dazu kommen doppelt gepflegte Daten und Ausfälle, bei denen ein Fremddienst die ganze Anwendung mitnimmt. Die Fragen 1, 3, 4, 5 und 8 im Selbsttest zielen genau darauf.
-
Vor einer größeren Investition in neue Funktionen, vor einem Dienstleisterwechsel und wenn der Selbsttest 12 oder mehr Punkte oder rote Antworten bei Auslieferung, Daten oder Tests ergibt. Ein Review von außen lohnt außerdem, wenn intern niemand mehr den Gesamtaufbau erklären kann. Bringen Sie den ausgefüllten Bogen mit, das spart die erste halbe Stunde.
Mehr als zwei rote Antworten?
Bringen Sie den ausgefüllten Selbsttest in das Architecture Review (60 min) aus unserem Shop mit. Wir gehen die roten Antworten zuerst durch, danach bekommen Sie eine schriftliche Bewertung auf einer Seite und drei priorisierte Empfehlungen mit Aufwandsschätzung, für 590 Euro netto.
Nachweise
Quellen und Stand
Stand: 28.10.2026. Die Grenzwerte für grün, gelb und rot und die Punkteschwellen sind unsere Einschätzung für Webanwendungen im Mittelstand.
Artikel teilen