Software Architektur-Reviews: Der unterschätzte Hebel für stabile Software und IT Systeme
Was, wenn ich dir sage, dass die Qualität deiner Software weniger von Code als von deiner Architektur abhängt?
️ Eine gut durchdachte Software-Architektur ist das solide Fundament deines digitalen Hauses.
❓ Doch wie oft nehmen wir uns wirklich die Zeit, diese Basis zu überprüfen? Genau hier setzen Architektur-Reviews an!
Was sind Software-Architektur-Reviews?
Ein Architektur-Review ist der Blick hinter die Kulissen deiner Software. Es geht nicht nur um Code, sondern um die Struktur, um das große Ganze.
- Welche Qualitätsziele verfolgen wir?
- Was steht diesen Zielen im Weg?
Hier kommen methodische Ansätze ins Spiel, die uns helfen, Qualitätshürden zu erkennen – sei es technische Schulden, methodische Schwächen oder organisatorische Stolpersteine.
Ziele und Nutzen von Software Architektur-Reviews
Software Architektur-Reviews helfen, die Qualität, Skalierbarkeit und Sicherheit deiner Software zu steigern. Sie sind die Roadmap, um in einem Dschungel aus Anforderungen, Deadlines und Stakeholdern nicht den Überblick zu verlieren.
gematik gemSpecPages – 3374 Treffer für Anforderungen in normativen Dokumenten für die Komponente des Basis Consumer in der Telematikinfrastruktur – Stand 21. September 2024
Komplexitätsexplosion in der Telematikinfrastruktur (TI)
Die Komplexitätsexplosion von Anforderungen in der Telematikinfrastruktur (TI) ist nicht zu übersehen.
Wie auf dem Bild ersichtlich, ergeben sich allein für den Begriff „Basis-Consumer“ über 3.374 Treffer in den gemSpecPages. Diese enorme Zahl verdeutlicht, wie dicht das Netz aus Anforderungen mittlerweile geworden ist.
Natürlich sind es nicht 3.374 Anforderungen für diese TI Komponente, sondern Fundstellen zum Suchbegriff. Aber selbst wenn sich die Trefferanzahl hier zu späterem Zeitpunkt noch durch eine optimierte Such-Funktion für die inzwischen maschinenlesbaren Spezifikationen der gematik GmbH reduzieren mag, ist die Anzahl der Afo’s für die TI inzwischen nahezu unüberschaubar geworden.
Jede einzelne Spezifikation oder Richtlinie bringt neue Verpflichtungen
Jede einzelne Spezifikation oder Richtlinie bringt neue Verpflichtungen mit sich, die nicht nur die technische Umsetzung komplizieren, sondern auch die organisatorischen Prozesse im Hintergrund massiv beeinflussen.
Anforderungen mit Leichtigkeit jonglieren? Wie geht das bei tausenden Anforderungen in einer modernen IT-Architektur?
Immense Anzahl von Anforderungen in der Telematikinfrastruktur birgt gravierendes Problem
Die immense Anzahl von Anforderungen in der Telematikinfrastrukturbirgt ein gravierendes Problem: Es ist hochgradig herausfordernd für alle beteiligten Akteure diese Vielzahl von Anforderungen auf ihre Wechselwirkungen untereinander zu validieren.
Liegen Anforderungen in Form umzusetzender Spezifikationen vor, wirkt sich das zum Nachteil der implementierenden Softwarehersteller aus. Das bedeutet, dass potenzielle Konflikte, Redundanzen oder Lücken zwischen verschiedenen Anforderungen unentdeckt bleiben können und sich schlimmstenfalls sehr schmerzlich erst in der Praxis bei den Nutzer*innen auswirken.
In zueinander unvalidierten Anforderungen schlummern Risiken
In zueinander unvalidierten Anforderungen schlummern erhebliche Risiken. Dadurch werden regelmäßig unerwartete technische Probleme, Verzögerungen in der Entwicklung und kaskadierende Supportprozesse wahrscheinlich.
Deshalb ist es entscheidend, dass Anforderungen nie isoliert betrachtet, sondern immer im Gesamtkontext überprüft und vollständig validiert werden.
Die Validierung der Anforderungen stellt in der Telematikinfrastruktur (TI) nach wie vor eine enorm große Herausforderung dar, die im Interesse aller Beteiligten dringend noch stärker adressiert werden sollte. Nur so können unerwartete technische Probleme und Verzögerungen in der Umsetzung vermieden werden. Das wirkt sich ebenso positiv auf die Verwirklichung effizienter und kundenzentrierter Support-Prozesse aus.
Ebenso wichtig sind agile und leichtgewichtige Methoden um die Anforderungen in Echtzeit #gemeinsam in einer #SingleSourceOfTruth zu validieren.
Damit lassen sich die Risiken frühzeitig erkennenund die Stabilität und Sicherheit von Software langfristig gewährleisten. In der TI und anderswo.
Durch diese stetige Zunahme an Anforderungen drohen Projekte den Überblick zu verlieren, und die Gefahr, an der eigenen Komplexität zu scheitern, wächst.
Agiles und strukturiertes Vorgehen mit klaren Prioritäten für Qualitätsziele ist entscheidend
Ein agiles und zugleich strukturiertes Vorgehen mit klaren Prioritäten sind essentiell, um Qualitätszielezu erreichen und die Effizienz trotz dieser Flut an Spezifikationen aufrechtzuerhalten.
Wer sich die Zeit nimmt, seine Software Architektur zu prüfen, sorgt langfristig für nachhaltige Software-Entwicklung und vermeidet teure Fehler in der Zukunft.
Im letzten Podcast habe ich mit Stefan Zörner über die Bedeutung und Methoden von Software Architektur Reviews gesprochen. In meinem Post zur Podcast Folge wirft Volker Dörrin den Kommentaren eine spannende Frage auf:
„Lohnen sich Reviews wirklich, wenn das Team schon in technischen Schulden versinkt?“
Technische Schulden sind nur ein Teil des Problems
Die Antwort ist klar: Ja!
Technische Schulden sind regelmäßig nur ein Teil des Problems. Ein Architektur-Review schafft Klarheit über die eigentlichen Hürden, sei es in der Technik, in den Prozessen oder der Kommunikation. Es ist der analytische Blick, der uns hilft, Prioritäten zu setzen und nicht in vermeidbaren Problemen zu ertrinken.
Vorteile und Herausforderungen von der Architecture Trade-off Analysis Method (ATAM)
ATAM bietet dir eine strukturierte Methode, um die Qualität von Softwarearchitekturen zu bewerten und frühzeitig Risiken zu identifizieren. Dabei fördert es die Zusammenarbeit zwischen verschiedenen Stakeholdern. Allerdings ist die Durchführung komplex und zeitaufwendig, was eine gute Vorbereitung und engagierte Beteiligung erfordert.
Vorteile von ATAM
- Strukturierter Ansatz zur Bewertung von architektonischen Entscheidungen: ATAM gibt dir einen klaren Fahrplan an die Hand, um komplexe Architekturentscheidungen zu analysieren und Qualitätsszenarien systematisch zu bewerten. Der strukturierte Prozess hilft dir, den Überblick zu behalten und alle relevanten Aspekte der Architektur zu berücksichtigen.
- Frühzeitige Identifikation von Risiken: Ein großer Vorteil von ATAM ist die Fähigkeit, potenzielle Risiken bereits früh im Entwicklungsprozess zu erkennen. Dadurch können teure Fehler in späteren Phasen vermieden werden, was besonders in großen Projekten von unschätzbarem Wert ist.
- Stärkung der Kommunikation zwischen Stakeholdern und Architekt*innen: ATAM fördert die Zusammenarbeit zwischen verschiedenen Stakeholdern und schafft eine gemeinsame Grundlage, um über Qualitätsanforderungen und Architekturentscheidungen zu sprechen. Das sorgt für Klarheit und verhindert Missverständnisse.
Herausforderungen von ATAM
- Aufwand und Komplexität bei der Durchführung: ATAM kann gerade bei großen Projekten zeitaufwändig und komplex sein. Es erfordert eine genaue Vorbereitung und die Bereitschaft, sich intensiv mit den Architekturentscheidungen auseinanderzusetzen. Der Erfolg hängt davon ab, dass alle relevanten Beteiligten aktiv mitarbeiten.
- Abhängigkeit von der Qualität der Input-Daten und Stakeholder-Engagement: Die Ergebnisse von ATAM sind nur so gut wie die Daten, die du in den Prozess einbringst. Wenn nicht alle Stakeholder*innen ihre Anforderungen klar formulieren oder die Input-Daten unvollständig sind, kann es schwierig werden, die richtigen Risiken und Trade-offs zu identifizieren.
LASR – Leichtgewichtige Software Architektur Reviews
Von ATAM zu LASR: Der pragmatische Ansatz für Software-Reviews
ATAM (Architecture Trade-off Analysis Method) ist eine großartige Methode, um tiefgehende Analysen durchzuführen. Aber oft brauchen wir leichtere Ansätze, die schnell ein Ergebnis liefern und direkt anwendbar sind. Hier kommt LASR (Lightweight Approach for Software Reviews) ins Spiel.
Was macht LASR so besonders?
- Schlanker als ATAM, aber dennoch zielgerichtet.
- In deinem Team oder sogar alleine durchführbar.
- Liefert schnelle Ergebnisse, zum Beispiel an einem Nachmittag.
- Pre-Mortem-Ansatz „auf Steroiden“: Hier wird geführtes Denken eingesetzt, um Risiken schon im Vorfeld zu erkennen und präventiv zu handeln.
- Spinnennetzgraphik: Ein visuelles Werkzeug, das komplexe Zusammenhänge klar und schnell aufzeigt.
- Optionale Aktivitäten zur Erhöhung der Zuversicht und Sicherstellung der Ergebnisse.
Das LASR-Kartenset – Spielerisch zu wertvollen Erkenntnissen für deine Software!
Um LASR noch greifbarer zu machen, haben Stefan Toth und Stefan Zörner das LASR-Kartenspiel entwickelt. Jede Karte beleuchtet einen Aspekt deiner Architektur. Durch das Ziehen und Diskutieren dieser Karten eröffnen sich völlig neue Perspektiven, die oft im Tagesgeschäft untergehen. Es geht darum, verborgene Risiken zu entdecken und diese in einen strukturierten, pragmatischen Review-Prozess einzubinden.
Risiko-Karten aus dem LASR Kartendeck zur Unterstützung des Basis-Reviews – weitere Informationen unter embarc.de
Warum das funktioniert?
Ganz einfach: Weil es Spaß macht und effektiv ist. Ob du mit deinem Team zusammen die Karten durchgehst oder sie alleine für dein Review verwendest – die spielerische Komponente sorgt dafür, dass relevante Themen nicht nur entdeckt, sondern auch sofort adressiert werden.
Die Methode in Aktion: Im letzten Review, das ich mit LASR durchgeführt habe, war die Spinnennetzgraphik der Wendepunkt. Ein vermeintlich kleines Problem in der Benutzerfreundlichkeit entpuppte sich als massiver Stolperstein für die Skalierbarkeit. Ohne diesen Review-Prozess hätten wir es nie erkannt.
Das Buch von Stefan Toth und Stefan Zörner „Software-Systeme reviewen“ist bei LeanPub erschienen.
Softwaresysteme reviewen – Buch bei leanpub.com erhältlich
Der Link mit dem „Coupon“ ist exklusiv für Leser und Abonennt*innen des Rock the Prototype Newsletter und reduziert den empfohlenen Preis von $17.99 auf $7.99
Ich beziehe keinerlei Provision oder sonstige Vergütung, sondern unterstütze einzig die soliden Werkzeuge und Methodik weil ich sie selbst schätze und anwende.
Podcast Folge 21 – Software Architektur Reviews – Interview mit Stefan Zörner
Willst du mehr erfahren? Dann hör dir die neueste Rock the Prototype Podcast-Episode an, in der wir tief in die Materie eintauchen. Stefan und ich sprechen über genau diese Ansätze und wie sie in der Praxis funktionieren.
Software pragmatisch reviewen
In dieser Podcast Episode von Rock the Prototype spreche ich mit Stefan Zörner, einem besonders erfahrenen Software-Architekten, über die Bedeutung und Methoden von #Softwarearchitektur #Reviews.
Warum sind Software Reviews relevant?
✅ Gemeinsam beleuchten wir, wie diese Reviews dazu beitragen, die #Qualität #Skalierbarkeit und #Sicherheit von #Software zu verbessern und warum sie ein unverzichtbares Instrument für den Entwicklungsprozess sind.
✅ Stefan erklärt, welche Soft Skills bei Reviews notwendig sind und wie wir spielerisch mit dem LASR-Kartenspiel Risiken frühzeitig erkennen.
Erkunden wir mit einem Deep Dive #gemeinsam die #SoftwarearchitekturAnalyse und wie #pragmatische #Reviews eure #Software nachhaltig verbessern!
Los geht’s!
Listen on Spotify: Spotify Podcast: https://bit.ly/4e8zI8y
Enjoy on Apple Podcasts: Apple Podcasts: https://bit.ly/4e6Gn3e
Freu dich aufs Zuhören – wie immer bekommst du jede Menge spannende Infos, leicht verständlich und auf den Punkt!
Alle Rock the Prototype Podcast Folgen findest Du hier:
Listen on Spotify: Spotify Podcast: spoti.fi/3NJwdLJ
Enjoy on Apple Podcasts: Apple Podcasts: apple.co/3CpdfTs
Und jetzt?
Unterstützt mich bitte mit Eurem Abo meines Newsletters, Podcast & YouTube Kanals. Ich freue mich natürlich ebenso über Euer Feedback und Eure Kommentareund
Mein verschafft Dir wie immer relevantes Wissen und bietet einen kompakten Überblick.
Jetzt Linkedin Newsletter abonnieren: https://lnkd.in/exv82i4M Kompakte Informationen – leicht verständlich!
Bleibt sicher, kreativ und vor allem neugierig!
Euer Sascha Block
Über den Autor:
Sascha Block
Ich bin Sascha Block – IT-Architekt in Hamburg und der Initiator von Rock the Prototype. Ich möchte Prototyping erlernbar und erfahrbar machen. Mit der Motivation Ideen prototypisch zu verwirklichen und Wissen rund um Software-Prototyping, Softwarearchitektur und Programmierung zu teilen, habe ich das Format und die Open-Source Initiative Rock the Prototype geschaffen.
