Architekturkonformität

Wie Architekturkonformität untersucht wird

Eine Architekturbeschreibung kann nicht nur darstellen, welche Komponenten ein System besitzt.
Sie kann auch Vorgaben darüber enthalten, wie diese Komponenten miteinander in Beziehung stehen sollen.

Beispiele sind:

• erlaubte und verbotene Abhängigkeiten
• festgelegte Schichten
• vorgesehene Schnittstellen
• erlaubte Kommunikationswege
• verwendbare Technologien
• Sicherheitsgrenzen
• Verantwortlichkeiten einzelner Komponenten
• Regeln für Datenzugriffe

Eine Architekturkonformitätsprüfung vergleicht solche Vorgaben mit dem tatsächlichen System.

Vereinfacht entsteht:

Architekturvorgabe
        ↓
prüfbare Regel
        ↓
tatsächlicher Systemzustand
        ↓
Vergleich
        ↓
Konformität oder Abweichung

Die Schwierigkeit liegt häufig bereits darin, aus einer Architekturentscheidung eine ausreichend konkrete prüfbare Regel zu machen.

Dokumentierte und tatsächliche Architektur

Die dokumentierte Architektur eines Systems und seine tatsächliche Architektur müssen nicht dauerhaft übereinstimmen.

Ein Dokument kann beispielsweise festlegen:

Webanwendungen greifen ausschließlich über den API-Dienst auf Kundendaten zu.

Später benötigt ein Entwickler kurzfristig zusätzliche Daten und baut einen direkten Datenbankzugriff ein.
Das System funktioniert weiterhin.
Die Dokumentation wurde nicht verändert.

Damit existieren nun zwei unterschiedliche Zustände:

dokumentierte Architektur:
Web → API → Datenbank

tatsächliche Architektur:
Web → API → Datenbank
  └────────→ Datenbank

Ohne eine entsprechende Untersuchung kann diese Abweichung lange unbemerkt bleiben.

Architekturregeln müssen prüfbar werden

Aussagen wie:

Unsere Software soll modular aufgebaut sein.

sind als Architekturprinzip verständlich, aber nur eingeschränkt automatisch prüfbar.

Eine konkretere Regel könnte lauten:

Komponenten des Moduls A dürfen nicht direkt auf interne Komponenten des Moduls B zugreifen.

Oder:

Datenbankzugriffe dürfen ausschließlich aus der Persistenzschicht erfolgen.

Je genauer eine Architekturregel beschrieben werden kann, desto eher lässt sich auch untersuchen, ob das tatsächliche System ihr entspricht.
Nicht jede Architekturentscheidung lässt sich vollständig in eine automatisierbare Regel übersetzen.
Manche Entscheidungen benötigen weiterhin menschliche Bewertung.

Unterschiedliche Arten der Prüfung

Architekturkonformität kann auf verschiedenen Wegen untersucht werden.

Reviews

Menschen untersuchen Quellcode, Architekturmodelle oder Änderungen und vergleichen sie mit bestehenden Architekturentscheidungen.
Das ermöglicht die Bewertung komplexer Zusammenhänge, ist aber aufwendig und kann relevante Abweichungen übersehen.

Statische Analyse

Quellcode und Abhängigkeiten werden untersucht, ohne das System auszuführen.
Damit können beispielsweise unerlaubte Modulabhängigkeiten, Schichtverletzungen oder bestimmte verwendete Bibliotheken erkannt werden.

Automatisierte Tests

Architekturregeln können als Tests formuliert werden.
Ein Build kann dadurch beispielsweise fehlschlagen, wenn eine Komponente auf eine verbotene Schicht zugreift.

Laufzeitanalyse

Nicht jede relevante Architekturbeziehung ist vollständig aus dem Quellcode erkennbar.
Dynamische Kommunikationswege, externe Dienste oder Deployment-Strukturen können zusätzlich im laufenden System untersucht werden.
Die geeignete Methode hängt davon ab, welche Architekturregel geprüft werden soll.

Konformität ist nicht gleich Qualität

Ein System kann vollständig mit seiner Architektur übereinstimmen und trotzdem schlecht konstruiert sein.
Wenn die Architektur beispielsweise eine unnötig komplizierte Abhängigkeit ausdrücklich vorsieht, ist eine Implementierung dieser Abhängigkeit architekturkonform.

Die Konformitätsprüfung beantwortet zunächst nur:

„Entspricht das tatsächliche System der festgelegten Vorgabe?“

Sie beantwortet nicht automatisch:

„Ist diese Vorgabe sinnvoll?“

Das sind zwei unterschiedliche Fragen.

Eine Abweichung erfordert nicht automatisch eine Korrektur

Wird eine Architekturregel verletzt, liegt eine Abweichung zwischen erwartetem und tatsächlichem Zustand vor.
Daraus folgt noch nicht automatisch, dass die Implementierung zurückgesetzt werden muss.

Mögliche Ursachen sind beispielsweise:

• unbeabsichtigte Verletzung einer Regel
• fehlendes Wissen über die Architektur
• kurzfristige technische Umgehung
• veränderte Anforderungen
• unvollständige Architekturvorgaben
• eine inzwischen ungeeignete Architekturentscheidung

Deshalb kann die angemessene Reaktion unterschiedlich sein.
Die Implementierung kann korrigiert werden.
Die Abweichung kann bewusst akzeptiert und dokumentiert werden.
Oder die Architektur selbst muss verändert werden.

Die Konformitätsprüfung liefert dafür zunächst die Information:

„Hier unterscheiden sich Soll und Ist.“

Architekturdrift

Wenn sich über längere Zeit immer mehr Abweichungen zwischen dokumentierter und tatsächlicher Architektur ansammeln, kann von einer Architekturdrift gesprochen werden.
Eine einzelne Abweichung muss dabei noch kein großes Problem darstellen.
Viele unbekannte Abweichungen können jedoch dazu führen, dass Architekturmodelle und Dokumentation ihre Aussagekraft verlieren.
Das wird spätestens dann relevant, wenn ein System verändert, integriert oder modernisiert werden soll.
Eine vermeintlich einfache Änderung kann plötzlich unerwartete Abhängigkeiten betreffen, die in der bekannten Architektur überhaupt nicht vorkommen.
Regelmäßige Konformitätsprüfungen können solche Entwicklungen früher sichtbar machen.

Regeln können maschinenlesbar werden

Ein Teil von Architekturregeln kann so formuliert werden, dass Werkzeuge sie automatisch prüfen können.

Beispielsweise:

Regel:
Modul frontend darf Modul database nicht importieren.

Ein Werkzeug kann anschließend die tatsächlichen Abhängigkeiten untersuchen:

frontend → api       erlaubt
api      → database  erlaubt
frontend → database  VERLETZUNG

Dadurch wird die Einhaltung einer Architekturentscheidung zu einer wiederholbar prüfbaren Eigenschaft des Systems.
Die Architektur existiert dann nicht mehr ausschließlich als Diagramm oder Dokument.
Ein Teil ihrer Regeln kann unmittelbar gegen das tatsächliche System geprüft werden.

Automatische Durchsetzung ist eine weitere Entscheidung

Eine erkannte Abweichung kann unterschiedliche Folgen haben.

Ein Werkzeug könnte:

nur protokollieren

oder:

eine Warnung erzeugen

oder:

einen Review verlangen

oder:

den Build abbrechen

Die Prüfung einer Regel und ihre Durchsetzung sind deshalb zwei unterschiedliche Entscheidungen.
Das ist insbesondere bei Regeln wichtig, deren Verletzung nicht in jedem Kontext dieselbe Bedeutung besitzt.
Eine automatische Prüfung muss nicht zwangsläufig eine automatische Korrektur oder Blockierung auslösen.

KI-generierter Code verändert das Problem nicht

Wenn Quellcode durch ein KI-System erzeugt wird, gelten dieselben Architekturregeln wie für menschlich geschriebenen Code.

Ein Modell kann eine Vorgabe im Kontext erhalten:

Alle Ausgaben müssen über die zentrale Logging-Komponente erfolgen.

Trotzdem kann es Code erzeugen, der direkt auf die Standardausgabe schreibt.

Damit entstehen zwei unterschiedliche Fragen:

Hat das Modell die Architekturregel als Kontext erhalten?

und:

Entspricht der erzeugte Code tatsächlich der Architekturregel?

Die erste Frage betrifft unter anderem Context Engineering.
Die zweite betrifft Architekturkonformität.
Eine Regel im Kontext zu haben, ist deshalb nicht dasselbe wie ihre Einhaltung nachzuweisen.

Warum Architekturkonformität praktische Auswirkungen hat

• Architekturdrift wird sichtbar: Dokumentiertes und tatsächliches System können miteinander verglichen werden.
• Architekturentscheidungen werden überprüfbar: Aus Prinzipien können konkrete Regeln entstehen.
• Abhängigkeiten bleiben kontrollierbarer: Unerlaubte Verbindungen können früh erkannt werden.
• Reviews können unterstützt werden: Automatisierbare Regeln müssen nicht bei jeder Änderung erneut manuell gesucht werden.
• Legacy-Systeme werden untersuchbarer: Tatsächliche Abhängigkeiten können mit vorhandener Dokumentation verglichen werden.
• KI-generierter Code kann denselben Regeln unterliegen: Die Herkunft des Codes ändert die Architekturvorgaben nicht.
• Abweichungen werden zunächst sichtbar gemacht: Prüfung und Reaktion bleiben getrennte Schritte.

Typisches Beispiel

Ein Softwareprojekt besitzt eine zentrale Komponente für Kommandozeilenausgaben.

Die Architekturregel lautet:

Anwendungskomponenten erzeugen keine direkten Ausgaben auf stdout.
Alle Ausgaben erfolgen über die dafür vorgesehene Komponente.

Während einer Änderung entsteht neuer Code:

print("Operation completed")

Die Funktion arbeitet technisch korrekt.
Sie verletzt jedoch die festgelegte Architekturregel.
Eine automatisierte Konformitätsprüfung erkennt den direkten Ausgabeaufruf und meldet die Abweichung.

Nun muss entschieden werden:

Ist die Implementierung falsch?

oder:

Gibt es einen guten Grund für diese Ausnahme?

oder sogar:

Ist unsere bisherige Architekturregel für diesen Fall ungeeignet?

Die Prüfung beantwortet diese Fragen nicht automatisch.
Sie sorgt zunächst dafür, dass sie überhaupt gestellt werden können.

Abgrenzung

• Architekturkonformität beschreibt die Übereinstimmung des tatsächlichen Systems mit festgelegten Architekturvorgaben.
• Systemarchitektur beschreibt die grundlegende Struktur des Systems, seine Elemente, Beziehungen, Schnittstellen und Architekturprinzipien.
• Verifikation und Validierung betrachten allgemeiner, ob Anforderungen erfüllt werden und ein System für seinen vorgesehenen Zweck geeignet ist. Architekturkonformität kann ein Gegenstand der Verifikation sein.
• Beobachtbarkeit ermöglicht Rückschlüsse auf tatsächliche Zustände und Verhalten eines Systems. Solche Informationen können für Konformitätsprüfungen verwendet werden.
• Policy as Code geht einen Schritt in Richtung maschinenlesbarer Regeln. Architekturregeln können als solche Policies formuliert und automatisiert geprüft oder durchgesetzt werden.

Weiterführend

Verwandte Begriffe

→ Systemarchitektur
→ Systemanalyse
→ Verifikation und Validierung
→ Beobachtbarkeit
→ Context Engineering
→ Policy as Code
→ Resilienz