embarc logo
embarc logo

Architektur-Review

Sorgen Sie für Fokussierung, Transparenz und Entscheidungssicherheit in Ihrem Vorhaben! Überwinden Sie technische Probleme und bekommen Sie die Ursachen für verfehlte Stakeholder-Wünsche in den Griff.

 
 

Warum Architektur-Reviews?

Architektur-Reviews schaffen Transparenz in der Softwareentwicklung, identifizieren Risiken und decken Kompromisse auf. Sie machen Probleme quantifizierbar und fokussieren Investitionen in die technische Verbesserung von Systemen effektiv.
Details

Steckbrief

Unser Angebot
Wir skalieren Architektur-Reviews vom kleinen Quick-Check bis zur großen Evaluierung. Dabei orientieren wir uns bedarfsgerecht an etablierten Review-Standards wie ATAM oder DCAR, nutzen kleinere Methoden wie das Pre-Mortem oder greifen auf unser eigenes leichtgewichtiges Vorgehen (LASR) zurück.
Unsere Expertise
Unsere Berater:innen verfügen über langjährige Erfahrung in der Durchführung von Architektur-Reviews in unterschiedlichsten Branchen. Dieses Wissen ist in viele Publikationen und das Buch “Leichtgewichtige Software Reviews” geflossen. embarc hat auch den Standard-Lehrplan des iSAQB zu diesem Thema ausgearbeitet (ARCEVAL).
Typische Anlässe
Reviews bieten sich an, wenn große / richtungsweisende Architekturentscheidungen anstehen, größeren Lieferschwierigkeiten bestehen, zentrale Qualitätsziele drohen verfehlt zu werden, Inverstitionen oder Kaufentscheidungen abzusichern sind oder die Kommunikation in und zwischen Entwicklungsteams suboptimal funktioniert.
Ihr Nutzen
Ihr Nutzen in der Unterstützung durch embarc besteht in unserer methodischen Führerschaft im Bereich von Software- und Architektur-Reviews und unserer Unabhängigkeit. Gemeinsam decken wir kritische Risiken auf, schaffen Entscheidungssicherheit und sprechen bei Bedarf Empfehlungen zur Weiterentwicklung aus.

Vorgehen

Architektur-Reviews können wenige Stunden in Anspruch nehmen, oder mehrere Tage oder Wochen dauern. In sehr kleinen Ausprägungen greifen wir auf Experteneinschätzungen oder die eigentwickelte Methode LASR (Lightweight Approach for Software Reviews) zurück. In größeren Kontexten zimmern wir aus Methoden wie DCAR, ATAM und anderen ein passendes und effizientes Vorgehen. Der hier skizzierte Ablauf ist grundsätzlich immer ähnlich, wird aber individuell und punktgenau an Ihre Situation angepasst. Die Punkte 02 bis 04 durchlaufen wir bei großen Bewertungen auch iterativ.
00
Initiale Klärung
Wir definieren eine Zielsetzung für den Review und legen gleichzeitig einen Zeithorizont für Ergebnisse fest. Aus diesen beiden Dingen plus dem Kontext aus Lösung, Domäne, Stakeholdern etc. ergibt sich das Review-Modell das wir anwenden.
01
Architektur vorstellen
Um uns ein Verständnis zur Lösung zu erarbeiten, brauchen wir früh einen Überblick zur Architektur des Systems. Was sind die eingesetzten Technologien, Konzepte und Ideen? Wo kommt das System her und wo soll es sich hin entwickeln? Wir geben erstes Feedback und planen Follow-Ups.
02
Ziele detaillieren
Bei größeren Reviews detaillieren wir die Zielebene mit den gewünschten Sytsemeigenschaften genauer. Das Ergebnis ist ein Bewertungsmaßstab mit konkret formulierten Qualitätsszenarien - in ATAM ein “Utility Tree”. In kleineren Reviews reichen uns grobe Aussagen zu Qualitätszielen.
03
Code analysieren
Vor allem in Reviews mit starken Wartbarkeits-Zielen ist dieser Schritt relevant. Auf Code-Ebene ist der konkrete Einsatz von Technologien und Frameworks einsehbar, es lassen sich Inkonsistenzen (zur Architekturidee) erkennen und Hot Spots identifizieren.
04
Details durchsprechen
In Workshops oder kurzen Besprechungen mit wechselndem Teilnehmerkreis arbeiten wir uns tiefer in die Softwarelösung ein. Wir leiten Risiken und Kompromisse ab und identifizieren Stärken bzw. Schwächen die uns auffallen. Wie ausführlich und strukturiert diese Besprechungen sind, hängt von der Review-Größe ab.
05
Ergebnisse aufbereiten
Je nach Bedarf, können wir die Ergebnisse eines Reviews entweder in Empfehlungen ummünzen, mit Teams direkt an der Beseitigung von Risiken arbeiten oder Erkenntnisse abstrakter aufbereiten. Von kurzer Task-Identifizierung bis Management-Report und -Präsentation gibt es hier alle Möglichkeiten.

FAQs

Wann sind Architektur-Reviews angebracht?
Reviews von Software oder Architektur binden einige Entwickler*innen und andere Rollen. Selbst kleine Reviews sollten deshalb einen konkreten Anlass haben. Für sehr schlanke Reviews (z.B. nach LASR - Lightweight Approach for Software Reviews) reicht z.B. ein Kommunikationsdefizit zwischen Teams. Für größere Reviews sollten klare Unsicherheiten im Architekturbereich vorhanden sein, größere Investitionen anstehen oder Produktionsprobleme bestehen.
Was ist das Ergebnis von Reviews?
Jedes Review benennt Risiken oder Problembereiche der betrachteten Lösung. Man weiß also zumindest welche Teillösungen (potentiell) schlecht sind. Je aufwendiger das Vorgehen, desto eher werden Stärken und Schwächen auch eingeordnet, Kompromisse im Lösungsdesign identifiziert, die Zielerreichung detaillierter bewertet oder auch Empfehlungen für die Weiterentwicklung ausgesprochen. Die Form reicht einfachen Erkenntnis-Listen bis zu managementkompatiblen Bewertungs-Reports.
Sind Reviews "von außen" wirklich sinnvoll?
Die Bewertung durch externe Partner hat Vor- und Nachteile. Externe Partner haben weniger Domänen- und vor Allem weniger Lösungswissen. Dadurch werden Bewertungen etwas aufwendiger und bleiben ggf. etwas mehr an der Oberfläche. Auf der anderen Seite ermöglicht der Blick von außen auch frische Impulse, eine unabhängige Sicht und Bubble-freie Erkenntnisse. Auch die methodische Kompetenz von externen Reviewern kann helfen. Am gewinnbringensten ist das eher in mittleren bis großen Bewertungen.

Haben wir Ihr Interesse geweckt?

Verwenden Sie das Kontaktformular oder senden Sie unserem Koordinator für diese Leistung, Stefan Toth, eine E-Mail.