Architekturbewertung mit LASR
Schnell, schlank, effektiv
Hinweis in eigener Sache:
In diesem Beitrag berichten wir über unsere eigenen Erfahrungen mit LASR. Falls dir LASR bisher kein Begriff ist oder du dich vorab näher informieren möchtest, empfehlen wir dir einen Blick auf die offizielle Website.
Anfang 2024 hörte ich einen Vortrag von Stefan Toth über LASR – den „Lightweight Approach for Software Reviews“. Was dort skizziert wurde, klang vielversprechend: eine leichtgewichtige Methode für Architekturbewertungen, die sich auch in einem agilen Umfeld gut anwenden lässt. In meinem aktuellen Projekt wollten wir genau das ausprobieren – und was ursprünglich nur als eine kleine Bewertung geplant war, wurde zu einer echten Team-Erfahrung.
Warum überhaupt bewerten?
Wir entwickeln eine Individualsoftware zur Verwaltung von Fahrzeugflotten – ein Projekt, das seit 2018 kontinuierlich gewachsen ist. Neue funktionale Herausforderungen und ein Teamwechsel, bei dem mehrere Nearshore-Kolleg:innen dazustießen, machten eine Architekturbewertung sinnvoll. Ich wollte mir als Architekt ein klares Bild über den Status Quo verschaffen: Kann das System ohne großes Refactoring mehrmarktfähig werden? Wie steht es um Dokumentation, Verständlichkeit und Wartbarkeit?
Da es keine gravierenden Bauchschmerzen mit der Architektur gab, entschieden wir uns bewusst gegen schwergewichtige Ansätze wie ATAM oder DCAR – und stattdessen für LASR. Eine Entscheidung, die sich als goldrichtig erwies.
Leichtgewicht mit Tiefgang
Regelmäßige Architekturbewertungen gehören selten zum Projektalltag, weil sie oft mit hohem Aufwand verbunden sind. LASR verfolgt einen anderen Ansatz: Es ist bewusst schlank gehalten, mit wenig notwendiger Vorbereitung und kurzer Dauer (ab ca. zwei Stunden). Dadurch eignet es sich hervorragend für regelmäßige Wiederholungen – ein echter Vorteil im agilen Alltag.
Wir entschieden uns für das sogenannte Kern-Review, das aus vier Schritten besteht:
Schritt 1 & 2: Verstehe, was dich speziell macht
Wir begannen remote mit einem Miro-Board, so wie wir auch sonst im Projekt zusammenarbeiten. In kleiner Runde definierten wir zunächst unser „Produktbierdeckel“-Statement: Was tun wir? Was bewirken wir? Wer ist unsere Zielgruppe? Aus Stichpunkten formten wir eine prägnante Beschreibung des Bewertungsgegenstands.
Im zweiten Schritt folgte das „Top-5-Challenger“-Spiel mit den Qualitätszielkarten. Daraus entstanden unsere Top-5-Qualitätsziele, inklusive einer Einschätzung der jeweiligen Anforderungen (z. B. „hohe Ansprüche“ bei Wartbarkeit). Die Diskussion half uns, implizite Erwartungen zu explizieren – ein echter Erkenntnisgewinn.
Schritt 3 & 4: Durchleuchte die Architektur
Grundlage des Basis-Reviews ist die Pre-Mortem-Methode: Wir blicken aus einer gescheiterten Zukunft zurück und identifizieren mögliche Ursachen. Statt freiem Brainstorming orientierten wir uns an Risikothemenkarten. Schnell sammelten wir konkrete Risiken – von Wissensinseln bis zu potenziell veralteter Dokumentation.
Zunächst versuchten wir, die Risikothemen wie im Buch vorgeschlagen zu bewerten. Doch das Ergebnis fühlte sich „falsch negativ“ an. Unser Bauchgefühl passte nicht zu den starken Abweichungen in der Spinnennetzgrafik. Also änderten wir die Methode: Risiken wurden nur den tatsächlich betroffenen Qualitätszielen zugeordnet. Eine Zuordnung zu allen Zielen, etwa als Pauschalablage unter 2 bis 5, fand bewusst nicht statt. Das Ergebnis spiegelte unsere Realität deutlich besser wider.
Für die zielorientierte Analyse erweiterten wir den teilnehmenden Kreis auf das gesamte Team. Dort betrachteten wir bewusst die Qualitätsziele, bei denen Ziellinie und erreichtes Qualitätsniveau weit auseinander lagen. Wir sammelten Architekturansätze, Kompromisse und Folgeaktivitäten – ohne gleich in Lösungsdiskussionen abzudriften.
Und danach?
Eines der größten Versprechen von LASR haben wir ebenfalls ausprobiert: die Iteration. Vier Sprints später prüften wir Mission Statement und Qualitätsziele, aktualisierten die Spinnengrafik und dokumentierten Verbesserungen – etwa durch gezielte Refactorings.
Auch wenn es für die Iterationsbewertung noch wenig offizielles Material gibt, hat sich dieser leichtgewichtige Check-in für uns bewährt.
LASR – eine echte Alternative?
LASR hat sich in unserem Projekt als sehr wirkungsvoll erwiesen. Die Methode ist leichtgewichtig, aber strukturiert genug, um echte Erkenntnisse zu fördern. Besonders hilfreich waren das umfangreiche Unterstützungsmaterial – und die Möglichkeit, remote zu arbeiten.
Was mich am meisten begeistert: Die Ergebnisse sind nicht nur für die eigentliche Bewertung hilfreich. Sie entfalten auch darüber hinaus Wirkung – etwa bei der Einarbeitung neuer Teammitglieder oder in der Kommunikation mit Stakeholdern. Einzelne Elemente wie das „Top-5-Challenger“-Spiel lassen sich sogar unabhängig von einer Bewertung einsetzen, z. B. zu Beginn eines Projekts, um spielerisch ein gemeinsames Verständnis für die wichtigsten Qualitätsziele zu entwickeln.
Ich bin überzeugt: Für viele Teams ist LASR eine echte Alternative zu klassischen Reviews – und wurde sicher nicht zum letzten Mal in unserem Projekt eingesetzt.
Über den Autor
Felix Rieß ist Software Architect bei BettercallPaul in Stuttgart. Er spezialisiert sich auf agile Architekturarbeit, Architekturbewertungen und den gezielten Einsatz von Microservices – auch darauf, wann man besser darauf verzichtet. Innerhalb der Teams entwickelt und steuert er tragfähige Software-Architekturen für unternehmenskritische Anwendungen.
