Stefan Zörner
22.12.2025
Mit welchen Risikothemen aus LASR rechnen Entwicklungsteams in ihren Softwaresystemen? In diesem Beitrag zeige ich ein Stímmungsbild von zahlreichen Konferenzen und User Groups.
LASR (kurz für Lightweight Approach for Software Reviews) ist ein von Stefan Toth und mir entwickelter, schlanker Bewertungsansatz für Softwaresysteme. Er befähigt Entwicklungsteams ihre Situation in Eigenregie in wenigen Stunden zu reflektieren und so ein erstes Ergebnis zu produzieren. Zum Beispiel an einem Nachmittag. Mehr Infos zu LASR findet Ihr auf der offiziellen Homepage.
Die Motivation bei einem Architektur-Review generell ist es vor allem Risiken aufzudecken. Also Probleme, die im weiteren Verlauf des Softwarevorhabens auftreten können, aber nicht zwingend müssen. Oder andersherum und positiver gedacht: Getroffene Technologieentscheidungen, Lösungsideen und Konzepte abzusichern. Also Fragen zu beantworten, wie: “Sind wir auf dem richtigen Weg? Waren das gute Entscheidungen? Passen sie (noch)?”
LASR produziert deswegen so schnell ein erstes Ergebnis, weil es ohne Umwege direkt auf das Resultat abzielt – die Risiken. Dabei kommt im dritten und wichtigsten Schritt in LASR ein an Pre-Mortem angelehntes Verfahren zum Einsatz.
Pre-Mortem ist eine Moderationstechnik aus dem Game-Storming, in der die Gruppe in einem Gedankenexperiment das Scheitern ihres Vorhabens in nicht allzu ferner Zukunft vorwegnimmt.
Im Fall von LASR reist das Entwicklungsteam hypothetisch in eine für ihr Softwaresystem düstere, dystopische Zukunft, zum Beispiel 6 Monate oder 1 Jahr. Es blickt von dort gemeinsam in einem Brain-Storming zurück und sammelt mögliche Gründe für das Scheitern. Aus heutiger Sicht betrachtet sind das Risiken.
Um LASR auch gemessen am Aufwand leichtgewichtig zu halten ist die im Review beteiligte Gruppe idealerweise klein. 3-4 Personen können sehr effektiv damit arbeiten.
In einem Pre-Mortem hat eine kleine Gruppe mitunter den Vorteil, dass die Beteiligten offener reden. Allerdings kommen sie im Brainstorming auch auf weniger Ideen. Zudem besteht die Gefahr, dass die Leute nur Gründe zum Scheitern nennen, die eh bekannt sind, und wenig Neues, Innovatives zu Tage gefördert wird. Zudem wirkt das Ergebnis am Ende zufällig und lässt die Beteiligten mit der Frage zurück, ob sie nicht doch etwas Wichtiges übersehen haben.
Um diesen Problemen entgegenzuwirken, bietet LASR sogenannte Standard-Risiken als Ideengeber für das Brainstorming an. Wir haben sie aus den Ergebnisberichten von 100+ Reviews, die wir über die letzten Jahre durchgeführt haben, abgeleitet.
Im entsprechenden Schritt kann die Gruppe die Standard-Risiken als Spielkarten einsetzen. Abb. 2 zeigt einen solchen Workshop, der Spielplan dient zum Zuordnen der durch Spielkarten inspirierten Risiken zu den Qualitätszielen und zur Einschätzung von Eintrittswahrscheinlichkeit und Schadenhöhe.
Die insgesamt 32 Standard-Risiken sind in 8 Themen, den LASR-Risikokategorien, organisiert. Jede Kategorie enthält vier Standardrisiken. Das LASR-Kartenset enthält neben den eigentlichen Risikokarten auch Karten für die Kategorien, die ihr in Abb. 3. seht. Sie helfen in der Auswahl der Karten, die initial “ins Spiel” kommen. Da kleine Gruppen von 32 Karten mitunter mehr erschlagen als inspiriert sind, starten sie mit einem “ausgedünnten” Deck ins Brainstorming.
Die 8 LASR-Risikokategorien:
(1) Softwarelösung: Unpassende, komplexe oder unausgereifte Teil- oder Fremdlösungen
(2) Kompetenz und Erfahrung: Fehlendes oder isoliertes Wissen (technisch/fachlich)
(3) Zielsetzungen und Erwartungen: Unrealistische Ziele, Erwartungen, Deadlines, oder Uneinigkeit, fehlender Kundenkontakt
(4) Fremdsysteme und Plattformen: Instabile, fehleranfällige, unpassende Fremdsysteme oder Plattformen, Lizenzen, Integration
(5) Altsysteme und Altlasten: Behinderungen, Zerbrechlichkeit, fehlende Tests, veraltete Dokumentation, fehlendes Verständnis
(6) Organisation und Prozesse: Behindernde Prozesse oder Rollen, Organisationsgrenzen, Politik, Standards, Entscheidungskompetenzen
(7) Betrieb und Deployment: Blockierende Prozesse, geringe Automatisierung, wenig Feedback, fehlende Konzepte oder Tools
(8) Weiche Faktoren: Uneinigkeiten, Konflikte, fehlende Disziplin oder Kommunikation, unpassende Rollen oder Kultur
Wir kriegen regelmäßig positive Rückmeldungen zu den Standard-Risiken, sowohl inhaltlich als auch “haptisch” zum LASR-Kartenset. Wenn wir es herzeigen, sind die Leute immer sehr interessiert, was wohl auch am spielerischen Aspekt des sonst eher als schwerfällig empfundenen Thema Architekturbewertung liegt.
Wir haben LASR so konzipiert, dass Entwicklungsteams es möglichst ohne Hindernisse eigenständig nutzen können, um ihre Softwarelösung zu begutachten. So steht die Methode unter einer Creative Commons-Lizenz und es gibt reichlich Unterstützungsmaterial (zum Beispiel die Spielkarten).
Konsequenterweise stellen wir LASR gerne auf Konferenzen und in User Groups vor. Seit der OOP 2024 haben wir diese Gelegenheiten intensiv genutzt.
Wir waren mit Vorträgen und Workshops zu leichtgewichtigen Reviews sowohl auf kommerziellen Konferenzen wie der JAX oder dem Software Architecture Summit als auch bei diversen Java User Groups, Softwarearchitektur-Meetups und den Softwerkskammern zu Gast. Und tun das auch in Zukunft weiterhin gern. Am
In meinen Vorträgen habe ich die Teilnehmenden an verschiedenen Stellen per Live-Umfragetool Mentimeter eingebunden, um das Ganze etwas interaktiver zu gestalten. Mentimeter lässt das Auditorium per Smartphone anonym abstimmen, visualisiert die Ergebnisse und unterstützt unterschiedliche Fragen- oder Auswahltypen. Die Leute haben in meinen LASR-Vorträgen so ein wenig über sich selbst und ihre Systeme preisgegeben, konnten Ziele priorisieren, Risiken abschätzen und die Methode so trotz Frontalvortrag ein wenig “erleben”.
Unter anderem habe ich in allen Vorträgen diese beiden Fragen gestellt. Die erste eher am Anfang als Teil des Check-Ins, die zweite am Ende im Rahmen des Transfers.
Mentimeter ist anonym, stellt mir als Moderator aber alle Antworten pro Smartphone-Session zur Verfügung, so dass ich durchaus Bezüge zwischen unterschiedlichen Fragen herstellen kann. Für die folgende Auswertung habe ich die Teilnehmenden aus einem guten Dutzend Veranstaltungen in den Jahren 2024 und 2025 herangezogen, die beide Fragen oben beantwortet haben. Da die Fragen im Vortrag zeitlich recht weit auseinander waren, war das nicht immer der Fall.
Manche Teilnehmenden sind erst später im Vortrag mit Mentimeter eingestiegen, andere haben zwischenzeitlich aufgehört abzustimmen oder sind vielleicht auch einfach früher gegangen. Trotz dieser Einschränkung sind von den insgesamt 766 Leuten, die in den Umfragen insgesamt mitgemacht haben, noch 501 im Rennen geblieben (haben also beide Fragen beantwortet). Abb. 5 zeigt die Altersverteilung der Softwaresysteme bezüglich der ersten Frage. Es verteilt sich ganz gut mit überraschend vielen Systemen dabei, die schon 20+ Jahre in Produktion sind.
Am Ende des Vortrags habe ich die Leute zu einem kleinen Gedankenexperiment eingeladen. Sie sollten sich vorstellen, mit ihrem Team in eine Zukunft zu reisen, in der das Entwicklungsvorhaben, für dessen Softwaresystem sie zuvor das Alter genannt hatten, gescheitert ist.
Ich habe die Antworten auf die Frage zu möglichen Gründen zum Scheitern des Systems mit dem zugehörigen Systemalter verknüpft und daraus eine Heatmap abgeleitet. Abb. 7 zeigt das Ergebnis, die Zeilen stellen das Systemalter dar, die Spalten die LASR-Risikokategorien. Die Heatmap ist als PDF verlinkt, fall ihr sie größer sehen wollt.
Ein Wert von 50% in einer Zelle bedeutet: Die Hälfte der Teilnehmenden mit Systemen in dieser Alterskategorie vermutet vor allem im jeweiligen Risikobereich Gründe zum Scheitern (sie durften maximal drei der acht angeben).
Es hat nur eine Person “nirgendwo” angekreuzt, das betreffende System war noch nicht in Produktion. Eine recht optimistische Einschätzung.
Ein genauerer Blick auf die Heatmap zeigt erwartbare oder zumindest nachvollziehbare Entwicklungen:
Im Bereich Altsysteme und Altlasten steigt der Wert mit dem Systemalter kontinuierlich an und erreicht mit 77% bei >20 Jahre laufenden Systemen den Höchstwert der gesamten Auswertung. Dass bereits ein Drittel der Befragten mit noch nicht produktiven Systemen diesen Bereich nennt, liegt vermutlich an der Anbindung von Fremdsystemen – einem häufigen Risikothema bei Neuentwicklungen.
Der Bereich Zielsetzung und Erwartungen nimmt hingegen kontinuierlich in den Werten ab. Während die Hälfte der Leute, deren System sich noch nicht in Produktion befindet, diesen Risikobereich als besonders problematisch vermutet, sind es bei Systemen, die länger als 20 Jahren in Produktion sind, noch ein Drittel. Auch das wirkt schlüssig.
Die meisten Umfrageteilnehmer waren Entwicklerinnen und Entwickler. Ich weiß das aus einer anderen Mentimeter-Frage, und die Veranstaltungen waren auch recht umsetzungsnah. Viele von euch hätten vielleicht damit gerechnet, dass technische Risiken (Architektur, Sicherheit, Schnittstellen) die Map daher dominieren, und organisatorische Themen weniger wichtig erscheinen.
Tatsächlich hat zum Beispiel Organisation und Prozesse sehr hohe Werte. Das deckt sich mit unseren Erfahrungen aus Architektur-Reviews. Dinge rund um die Prozesse und Zusammenarbeit werden erfahrungsgemäß von Teams als mindestens genauso kritisch eingestuft wie technische Themen.
Die Erkenntnisse aus der Heatmap können euch helfen, wenn Ihr in Schritt 3 von LASR die Risikokarten reduzieren wollt. Je nach Alter eures Softwaresystem solltet Ihr bestimmte Kategorien eher drin haben als andere. Das kann einen Draft-Mechanismus, den wir sonst mit den Kategoriekarten empfehlen, durchaus unterstützen.
Für Stefan Toth und mich war spannend zu sehen, dass bereits die abstrakten Risko-Kategorien tatsächlich verfangen und kaum jemand nirgendwo Gründe zum Scheitern vermutet (0,2% in unseren Menti-Abfragen). Keine Kategorie schneidet in der Auswertung auffällig schlecht ab. Wobei in der Heatmap durchaus Favoriten zu erkennen sind, und der Teilnehmerkreis alles andere als repräsentativ war.
Bereits aus Interviews mit Leuten, die LASR angewendet haben, und unseren eigenen Anwendungen hatten wir gelernt, dass die Risikokategorien und Standardrisiken gut funktionieren. Gleichwohl wurden sich vereinzelt konkretere Risikokarten gewünscht, die auf das Umfeld des Unternehmens oder der Organisation passen. Und die das Set spezifisch für eine bestimmte Systemart (z.B. Embedded), Technologie (z.B. AI) oder Thematik (z.B. Migration) ergänzen.
Auch noch wichtig: Das hier dargestellte Stimmungsbild habe ich bei einem Publikum eingesammelt, das LASR in aller Regel noch nicht kannte. Die Vorträge waren primär dazu gedacht, es vorzustellen. Stefan Toth und ich haben allerdings im November eine Umfrage in der LASR-Community gemacht, die auf konkrete Anwendungen von LASR abzielte. Wie viele Leute waren am Review beteiligt? Wie viel Zeit habt Ihr aufgewendet? … Die Ergebnisse teilen wir demnächst mit der Community in Form eines kleinen Reports.
Falls Ihr noch nicht Teil der LASR-Community seid: Ihr erhaltet dort nicht nur Zugriff auf die Karten-Sets mit den Standardrisiken als PDF und PNG auf Deutsch und Englisch und regelmäßig Updates zur Methode. Vor allem seid ihr herzlich eingeladen, Fragen zu stellen, Wünsche zu äußern und euch mit euren Erfahrungen und Ideen einzubringen. Kostenlose Anmeldung über den Button unten:
