Softwarearchitektur bezeichnet den Bauplan einer Software: welche Grundpfeiler gelten, welche Randbedingungen einzuhalten sind und welche Entscheidungen getroffen werden müssen. Entscheidungen lassen sich dabei in zwei Kategorien einteilen: unveränderliche Typ-1-Entscheidungen mit großem Impact und revidierbare Typ-2-Entscheidungen. Eine lebendige Architektur verteidigt sich selbst, etwa durch messbare KPIs, Fitness Functions und automatisierte Tests.
Das Wichtigste in Kürze
- Architekturdokumente, die nur in einem Wiki liegen, verteidigen sich nicht selbst: Erst wenn ADRs und Fitness Functions automatisiert prüfbar gemacht werden, schützen sie die Architektur aktiv vor Verletzungen.
- Typ-1-Entscheidungen wie die Wahl zwischen Monolith und Microservice lassen sich in der Praxis kaum umkehren und müssen deshalb mit klarem Begründungsrahmen festgelegt und dauerhaft verteidigt werden.
- Typ-2-Entscheidungen wie die Wahl des Logging-Frameworks dürfen und sollen sich ändern, wenn Team-Feedback oder Metriken dagegen sprechen, weil ihr Impact die Architektur nicht gefährdet.
- Architektur-Gremien sollten ausschließlich Typ-1-Entscheidungen diskutieren, weil Typ-2-Themen dort Evolution blockieren, die das Team im direkten Austausch einfach zulassen könnte.
- KI kann helfen, weiche Architekturregeln technisch prüfbar zu machen: Sie erkennt im Kontext, ob ein Catch-Block zwar geloggt, dabei aber sensible Daten wie Kreditkartennummern offengelegt werden.
Architektur veraltet, sobald sie fertig beschrieben ist
Eine Softwarearchitektur beschreibt, wie ein System gebaut werden soll: was wichtig ist, welche Randbedingungen gelten, worauf man achten muss. Sie ist der Bauplan, einige Ebenen über dem Code. Genau dieser Plan hinkt der Realität oft hinterher.
Die Überlegungen zur Architektur dauern Tage, Wochen, manchmal Monate. Währenddessen drehen sich Produkt, Software und Anforderungen weiter. In einem strikten Wasserfall fällt das weniger auf, weil die Welt dort relativ stabil bleibt. Sobald ein Team agil arbeitet und Anforderungen sich ändern, läuft eine lange ausgearbeitete Architektur Gefahr, am tatsächlichen Bedarf vorbeizuzielen.
Das ist kein Argument gegen Architekturarbeit, sondern eines für die richtige Dosierung. Sich zu lange Gedanken zu machen kann bedeuten, an Anforderungen festzuhalten, die es so nicht mehr gibt. Die Aufgabe besteht darin, Stabilität und Veränderbarkeit gegeneinander auszubalancieren.
Warum frühe Architekturentscheidungen den Test bestimmen
Performance und Security gehören früh getestet, weil sie an der Architektur hängen. Wer hier zu spät ansetzt, muss an fundamentalen Strukturen rütteln, und das wird teuer.
Daraus entsteht ein Spagat. Auf der einen Seite stehen Entscheidungen mit großem Einfluss auf das System und auf Qualitätsmerkmale, die sich später kaum noch drehen lassen. Auf der anderen Seite steht der Wunsch, fluide genug zu bleiben, um auf Veränderungen zu reagieren. Beides gleichzeitig zu bedienen ist die eigentliche Schwierigkeit.
Der Ausweg liegt in der Unterscheidung: Welche Entscheidung ist ein Grundpfeiler, den man verteidigen muss? Und welche ist zwar nötig, aber ohne Drama revidierbar?
Typ-1- und Typ-2-Entscheidungen trennen
Die Analogie von Jeff Bezos liefert ein einfaches Raster. Eine Typ-2-Entscheidung ist eine Tür, durch die man wieder zurückgehen kann. Eine Typ-1-Entscheidung ist eine Tür, die hinter dir zufällt: Die Wand ist groß, du kommst nicht mehr zurück.
Für jede Architekturentscheidung lohnt am Anfang die Frage, in welcher Kategorie sie liegt. Daran hängt, wie viel Energie das Durchdenken verdient und wie viel Energie es später kostet, die Entscheidung zu verteidigen.
Ein klassisches Typ-1-Beispiel ist die Wahl zwischen Microservice-Architektur und Monolith. Vom Monolith zu Microservices kommt man in der Theorie durch reines Auseinanderschneiden. In der Praxis funktioniert das nicht so einfach. Auch der umgekehrte Weg, Microservices per Copy-Paste in eins zusammenzuführen, klingt machbar und wird in der Umsetzung schwierig.
Wichtig ist die Entlastung, die darin steckt: Gibt es gute Gründe für einen Monolithen, ist das in Ordnung. Microservices sind kein Pflichtprogramm. Sie bringen eigene Nachteile mit, etwa viel Kleinkram zwischen den Services. Entscheidend ist, dass die Wahl begründet ist und über den Lebenszyklus der Anwendung getragen wird.
Das Logging-Framework ist das Gegenbeispiel. Irgendwann muss die Wahl fallen, aber stellt sich nach acht Wochen heraus, dass sie nicht passt, tauscht man sie aus. Das System läuft weiter, kein fundamentaler Change. Solche Entscheidungen darf man treffen und später wieder anders treffen.
| Typ 1 | Typ 2 | |
|---|---|---|
| Reversibilität | praktisch nicht | jederzeit |
| Beispiel | Microservice vs. Monolith, Hyperscaler-Bindung | Logging-Framework |
| Aufwand beim Durchdenken | hoch | moderat |
| Wo entscheiden | Board, mit Management-Rückhalt | im Team |
| Dokumentation | hieb- und stichfest | knapp halten |
Generisch bauen hat eine Grenze
Austauschbarkeit erkauft man sich mit Aufwand, und ab einem Punkt kippt der Aufwand in Overengineering. Beim Logging muss man schon viel falsch machen, um es nicht mehr getauscht zu bekommen. Andere Themen lassen sich nur mit erheblichem Aufwand so generisch halten, dass die Wahl für immer offen bleibt.
Wer alles maximal generisch abbildet, baut ein massiv überengineertes System, und das aus Gründen, die niemand braucht. Je offener eine Stelle gehalten ist, desto weniger konkrete Vorgabe gibt es für die Umsetzung. Dann fehlen den Entwicklern die Beispiele.
Manche vermeintliche Typ-1-Entscheidung lässt sich zudem auf Typ 2 herunterbrechen, sobald ein passendes Pattern existiert. Liegt darüber ein sauberes Muster, ist die konkrete Implementierung ziemlich egal.
Die Cloud-Frage hängt an der Strategie, nicht nur am Architekten
Wie viel Spielraum eine Entscheidung hat, bestimmt nicht der Architekt allein. Die Wahl des Hyperscalers zeigt das. Steht sie frei, hat der Architekt eine große Wahl. Gibt das Unternehmen einen großen Hyperscaler vor, ist die Richtung gesetzt.
Kommt zur Vorgabe der Zusatz “halte das System trotzdem generisch”, verschiebt sich die Einordnung. Sich auf einen Hyperscaler festzulegen ist eigentlich eine Typ-1-Entscheidung. Wer Cloud-native baut, bindet sich weniger stark an einen Anbieter und holt sich Spielraum zurück.
Bindet man dagegen die anbieterspezifischen Dienste tief ins System ein, ist es klar Typ 1. Von diesem Hyperscaler kommt man nicht mehr weg, jedenfalls nicht mit vertretbarem Aufwand. Transformationen sind möglich, aber die Aufwände werden enorm.
Eine Architektur, die sich selbst verteidigt
Architekturdokumentation funktioniert nur, wenn sie sich über das Blatt Papier hinaus manifestiert. ARC42-Templates, C4 und ADRs sind die richtigen Werkzeuge, um Gedanken festzuhalten, ohne sich zu verzetteln. Ein ADR allein, abgelegt in einem Wiki, auf das niemand schaut, wird nichts bewirken.
Das Ziel ist eine Dokumentation, die sich wehrt, wenn jemand gegen sie verstößt. Sie soll eine rote Lampe anschalten: Die Idee, die ihr hier habt, verstößt gegen das, was festgelegt wurde.
Dabei gilt unterschiedlicher Aufwand je nach Typ. Typ-1-Entscheidungen brauchen saubere, belastbare Dokumentation, und im Projekt sollte sie jeder kennen. Bei Typ-2-Entscheidungen darf man kürzer dokumentieren, und man sollte davon ausgehen, dass nicht jeder im Team sie kennt.
Wenn ich es schaffe, meine ADRs so hinzubekommen, dass sie sich wehren können, wenn sie gebrochen werden, oder dass sie zumindest eine rote Lampe anschalten, dann kommt jemand vorbei, dem das sagt: Denk nochmal drüber nach. — Ralf Enderle
Wie Architektur testbar wird
Eine Architektur verteidigt sich, sobald ihre Kriterien in prüfbare Form übersetzt sind. “Die Architektur soll performant sein” ist schön, aber wertlos, solange daraus keine KPIs werden, gegen die man testen kann.
Der Hebel ist die Verknüpfung der KPIs mit den dahinterliegenden Entscheidungen. Microservices wählt man etwa, um pro Service skalieren und eine bestimmte Performance halten zu können. Genau diese Ziele werden zu Kennzahlen. Schlägt ein Test fehl, geht eine Lampe an und meldet, dass etwas nicht passt.
Fitness Functions, ein Konzept von Neil Ford, übersetzen harte Architekturkriterien in technisch prüfbare Form. Die Kriterien fühlen sich auf dem Papier hart an und werden im Moment des Testens weich genug, um sie technisch greifen zu können.
Wo KI im Test zusätzlichen Kontext liefert
KI ergänzt technische Prüfungen dort, wo reine Regelprüfungen die Absicht hinter einer Regel nicht erfassen. Ein Beispiel: Jeder Catch-Block soll im Log erscheinen, damit man auf produktive Fehler reagieren kann. Über reguläre Ausdrücke lässt sich prüfen, dass nach einem Catch-Block ein Log-Statement folgt. Was dort geloggt wird, sagt der reguläre Ausdruck nicht.
Beschreibt man zusätzlich, warum dieses Logging wichtig ist, kann eine KI den umgebenden Kontext lesen. Im Kontext einer Kreditkartenzahlung kann sie erkennen, dass das, was aus dem Fehler herausgeloggt wird, womöglich die Kreditkartennummer enthält. Ein regulärer Ausdruck würde das nicht finden.
Diese Prüfung liefert keine hundertprozentige Sicherheit. KI-Systeme stehen nicht jeden Tag mit derselben Laune auf. Aber es gibt keinen Grund, auf die zusätzliche Absicherung zu verzichten, die so entsteht.
Architekturentscheidungen gehören dorthin, wo sie Wirkung haben
Ein übergreifendes Board, das alle paar Wochen Architektur reviewt und Ideen einbringt, läuft Gefahr, weit von der Realität der Software entfernt zu diskutieren. Auch hier hilft die Typ-Unterscheidung. Typ-1-Entscheidungen können in so ein Gremium gehören, weil sie das Standing des Managements brauchen.
Typ-2-Entscheidungen in großen Runden zu diskutieren ist verlorene Zeit. Wer das tut, verhandelt Themen ohne Impact und verhindert die Evolution, die sonst mühelos passieren würde, statt sich um die schwierigen Dinge zu kümmern. Diese Entscheidungen gehören ins Team.
Stellt das Team in der Retro fest, dass eine Typ-2-Entscheidung nach Wochen nicht trägt, ändert man sie. Sie ist genau dafür gebaut, mit geringem Impact. Warum eine Entscheidung verteidigen, deren Änderung nicht schmerzt? Sich an ihr festzubeißen heißt, leicht zu habende Evolution zu verpassen.
Was Tester von Architekten einfordern sollten
Tester sollten nicht nur fragen, wie die Architektur aussieht, sondern wie sie sich in prüfbare Faktoren übersetzt. Die zentrale Bitte an den Architekten lautet: Überleg, wie sich deine Architektur in KPIs manifestiert, in weichen oder harten Faktoren, die man prüfen kann.
Aus dieser Frage entsteht ein gemeinsames Ziel: sicherstellen, dass die aus guten Gründen gewählte Architektur auch gelebt und nicht verletzt wird. Fitness Functions sind ein Weg dahin, KI-gestützte Kontextprüfungen ein weiterer.
Viele Teams haben bereits einen laufenden Architekturprozess. Den kann man anpassen. Eine Retro ist ein guter Ort, um die Frage einzubringen, ob das aktuelle Vorgehen die richtigen Entscheidungen verteidigt und die richtigen freigibt.
