Was passiert in der Praxis ohne klare Methodik? Es wird gelobbyt. Es wird politisiert. Wer lauter ist oder mehr internen Rückhalt hat, setzt sich durch. Und am Ende weiß nach sechs Monaten niemand mehr, warum eigentlich Lösung A gewählt wurde – außer vielleicht: „Das wollte damals der Abteilungsleiter so.“

Ich war selbst schon auf beiden Seiten dieses Tisches. Als derjenige, der eine Lösung bewertet – und als derjenige, dessen Lösung bewertet wurde. Und ich kann sagen: Der Unterschied zwischen einer sachlichen und einer emotionsgetriebenen Entscheidung liegt nicht in den Menschen im Raum. Er liegt im Prozess.

Das eigentliche Problem: Fehlende Kriterien erzeugen Emotion

Eine Aussage wie „Lösung A ist besser als Lösung B“ ohne klare Begründung ist eine Einladung zum Streit. Sie erzeugt Ablehnung – nicht weil die Aussage falsch sein muss, sondern weil sie nicht nachvollziehbar ist.

Was ich über die Jahre gelernt habe: Wenn man sich vorher auf Kriterien einigt, verändert das die gesamte Dynamik im Raum. Plötzlich diskutiert man nicht mehr über Geschmack oder Loyalität, sondern über messbare Eigenschaften. Und – das ist das Überraschende – oft stellt man dabei fest, dass beide Lösungen gute und weniger gute Seiten haben. In einem konkreten Fall, an dem ich selbst beteiligt war, haben wir am Ende keine der beiden Lösungen gewählt. Stattdessen haben wir gemeinsam eine dritte Option identifiziert: eine Kombination der besten Bausteine aus beiden Welten. Das wäre ohne einen strukturierten Vergleich nie entstanden.

Die Antwort muss nicht „A oder B“ sein. Sie kann auch „C“ sein.

ISO 25010 als Orientierung – nicht als Dogma

Als Grundlage für meine Architekturbewertungen nutze ich die Qualitätsmerkmale der ISO/IEC 25010. Der Standard definiert acht Oberkategorien für Softwarequalität:

1. Funktionale Eignung – Tut das System das, was es soll?
2. Leistungseffizienz – Wie verhält es sich unter Last?
3. Kompatibilität – Kann es mit anderen Systemen zusammenarbeiten?
4. Gebrauchstauglichkeit – Wie gut ist die Nutzererfahrung?
5. Zuverlässigkeit – Wie stabil und ausfallsicher ist es?
6. Sicherheit – Wie gut schützt es Daten und Zugriffe?
7. Wartbarkeit – Wie leicht ist es zu ändern und zu testen?
8. Übertragbarkeit – Wie gut lässt es sich in andere Umgebungen migrieren?

Wichtig: Ich behandle diese Kategorien nicht als starres Korsett. Sie sind ein Orientierungsrahmen. In der Praxis definiere ich gemeinsam mit den Stakeholdern die konkreten Merkmale, die für den jeweiligen Kontext relevant sind – und platziere sie in die passende Oberkategorie. Manchmal braucht es auch neue Merkmale, die im Standard so nicht vorgesehen sind, etwa „Betreibbarkeit unter konzernweiten Governance-Vorgaben“ oder „Onboarding-Aufwand für neue Entwickler“.

Der Standard gibt die Sprache vor – die Stakeholder geben den Inhalt.

Die Tücke: Merkmale stehen in Spannung zueinander

Hier wird es spannend – und das ist der Punkt, den ich in der Praxis am meisten erklären muss.

Qualitätsmerkmale sind keine isolierten Checkboxen. Sie beeinflussen sich gegenseitig, manchmal sogar entgegengesetzt.

Ein klassisches Beispiel: Systemstabilität vs. Time-to-Market.

Wer ein hochstabiles System will, in dem kaum etwas schiefgehen darf, braucht intensive Testautomatisierung, kontrollierte Deploymentprozesse und gründliche Qualitätssicherung. Das kostet Zeit. Entwicklungszyklen werden länger. Das ist kein Fehler – das ist die bewusste Entscheidung für Qualität vor Geschwindigkeit.

Wer dagegen flexibel auf den Markt reagieren und schnell neue Features liefern will, muss an anderen Stellen Abstriche machen. Vielleicht ist die 80%-Lösung manchmal akzeptabel. Vielleicht nimmt man bewusst in Kauf, dass ein Bug in Produktion landet – wenn das bedeutet, zwei Wochen früher live zu sein.

Keiner dieser Ansätze ist per se falsch. Beide sind legitime Strategien – je nach Kontext. Und genau das ist die Aufgabe im Workshop mit den Stakeholdern: diese Spannungsbögen sichtbar zu machen, gemeinsam zu diskutieren und dann bewusst zu priorisieren.

Der Prozess: Wie ein Bewertungsworkshop funktioniert

In der Praxis läuft eine Architekturbewertung bei mir in mehreren Schritten ab:

1. Stakeholder identifizieren und einbinden

Wer hat ein legitimes Interesse an der Entscheidung? Das sind nicht nur die Entwicklungsteams. Das sind Fachbereichsverantwortliche, Betrieb, Security, Compliance, manchmal auch der Einkauf. Jeder bringt eine eigene Perspektive mit – und das ist gut so.

2. Kriterienkatalog gemeinsam erarbeiten

Im Workshop frage ich: Was ist euch bei dieser Entscheidung wichtig? Die Antworten kommen in der Sprache der Stakeholder – nicht in ISO-Nomenklatur. „Wir müssen das in zwei Jahren noch selbst betreiben können“ wird zu einem Merkmal unter Wartbarkeit oder Betreibbarkeit. „Das darf nie down sein“ landet unter Zuverlässigkeit. Ich übersetze – die Stakeholder entscheiden.

3. Merkmale klar definieren

Jedes Merkmal bekommt eine klare Definition. Nicht „Performance ist wichtig“, sondern: „Das System muss 95% der Anfragen unter 200ms beantworten bei 1.000 gleichzeitigen Nutzern.“ Je weniger Interpretationsspielraum, desto weniger Diskussion später.

4. Gewichten

Welche Merkmale sind kritisch, welche nice-to-have? Hier kommen die unterschiedlichen Stakeholder-Interessen an die Oberfläche. Der CFO gewichtet Kosteneffizienz anders als der CISO die Security. Das ist normal. Im besten Fall einigt man sich gemeinsam. Im schlechtesten Fall braucht es jemanden mit Entscheidungskompetenz – aber dann wenigstens auf einem sauberen Fundament.

5. Lösungen bewerten

Jede Lösung wird auf Basis des Kriterienkatalogs bewertet – mit einer klaren Begründung, warum sie bei einem Merkmal X Punkte bekommt. Nicht nur eine Zahl, sondern ein Satz: „Lösung A bekommt hier 3 von 5, weil sie zwar eine gute Testabdeckung hat, aber keine CI/CD-Pipeline mitbringt.“

6. Entscheidung treffen und dokumentieren Architecture Decision Record

Und dann – das ist der Teil, der oft vernachlässigt wird – alles sauber in einem Architecture Decision Record (ADR) festhalten.

Das Architecture Decision Record: Gedächtnis der Architektur

Ein Architecture Decision Record (ADR) ist kein bürokratisches Dokument. Es ist das institutionelle Gedächtnis einer Entscheidung. Wer ein Jahr später fragt „Warum haben wir das damals so gemacht?“, bekommt eine Antwort – nicht ein Schulterzucken.

Meine Standard-Struktur für ein ADR:

Zum Thema Status: Verworfen ist kein Scheitern

Wenn sich Rahmenbedingungen ändern und eine alte Entscheidung überholt ist, erstelle ich keinen neuen Abschnitt im alten ADR. Ich erstelle einen neuen ADR, referenziere den alten in der Beschreibung, erkläre was sich verändert hat – und setze den alten ADR auf „Verworfen“, mit einem Link auf den Nachfolger.

So bleibt die Geschichte lesbar. Niemand stolpert versehentlich über einen veralteten ADR und hält ihn für gültig. Die Dokumentation folgt denselben Prinzipien wie gute Software: Versionierung statt Mutation.

Fazit: Der Prozess verändert das Ergebnis

Was ich nach vielen Architekturbewertungen sagen kann: Das Wertvollste an diesem Vorgehen ist nicht die Matrix am Ende. Es ist der gemeinsame Weg dorthin.

Wenn alle Beteiligten – Teams, Fachbereiche, Führung – gemeinsam Kriterien erarbeitet und gewichtet haben, dann gehört die Entscheidung allen. Nicht dem lautesten im Raum. Nicht dem ranghöchsten. Und wenn am Ende trotzdem jemand per Dekret entscheiden muss, dann zumindest auf einem sauberen, transparenten Fundament.

Das ist keine Garantie für die perfekte Entscheidung. Aber es ist die beste Grundlage, die wir haben.

Der Beitrag Architecture Decision Record & ISO 25010: Architekturbewertung ohne Bauchgefühl erschien zuerst auf Das ist die Welt von Thomas.