Risikomanagement für Software-Architekt:innen

This transcript was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Anja: Hallo und herzlich willkommen zum INNOQ Podcast. Mein Name ist Anja Kammer und heute habe ich Gerrit bei mir. Hallo Gerrit.

Gerrit: Hallo Anja.

Anja: Heute sprechen wir über Risikomanagement für Softwarearchitektinnen. Meine erste Frage, bevor wir in die Methode einsteigen, ist: Warum sollten sich gerade Softwarearchitektinnen mit Risikomanagement beschäftigen?

Gerrit: Meiner Meinung nach gibt es zwei Gründe, warum sie das tun sollten. Der eine ist, sie produzieren Quellen von Risiken in Form von Software. Sie treffen Entscheidungen, die manchmal Kompromisse sind und aus denen manchmal auch Risiken folgen. Das ist der eine Grund. Der andere ist, Softwarearchitektinnen sollten sich mit Risikomanagement beschäftigen, weil sie Risiken lösen können. Sie sind nicht nur Quelle von Risiken, sondern sie sind ganz häufig auch diejenigen Personen, die maßgeblich dazu beitragen können, dass Risiken abgemildert oder vielleicht sogar völlig eliminiert werden können. Das sind meiner Meinung nach zwei gute Gründe, sich mit dem Thema zu beschäftigen.

Anja: Welche Risiken treten denn normalerweise oder typischerweise bei der Softwarearchitekturarbeit oder bei Architektur-Entscheidungen auf? Auch Beispiele.

Gerrit: Da gibt es die Klassiker, die sicherlich alle kennen, wie zum Beispiel Vendor Lock-in. Man trifft Entscheidungen, macht sich von einer Technologie, einem Framework oder einem Hersteller abhängig, und dann entwickelt sich das in eine andere Richtung als geplant. Man ist aber daran gebunden, und die Änderung ist sehr teuer oder vielleicht sogar unmöglich. Das ist ein Klassiker im Risikomanagement. Andere Geschichten sind Risiken aus dem Security-Bereich, wo man vielleicht Lücken hat, die man nicht vorhersehen kann, die aus dem Standard herauskommen. Was früher immer aufgetreten ist, waren Risiken im Bereich Bluetooth-Kommunikation, wo man plötzlich festgestellt hat, dass im Protokoll ein designtechnischer Fehler ist. Das ist für mich als Architekt in dem Moment ein Risiko, wo ich auf so einen Standard aufsetze. Da gibt es Dutzende solcher Beispiele. Dann können natürlich auch Risiken aus nicht erfüllten Qualitätsanforderungen entstehen, in dem Moment, wo man beispielsweise die Software plötzlich unter leicht geänderten Rahmenbedingungen benutzt oder betreibt und unter diesen geänderten Rahmenbedingungen eine Qualitätsanforderung nicht mehr erfüllt werden kann. Dann zeigt die Software unter Umständen ein anderes Verhalten als gewünscht, und auch das kann dann beispielsweise zu einem architektonischen Risiko werden.

Anja: Zählen dazu auch organisatorische Risiken, wie beispielsweise, dass die Entscheidung von der Organisation oder von wichtigen Stakeholdern getragen wird?

Gerrit: Das ist ein Grenzbereich. Die meisten konkreten Architekturrisiken sind für die Stakeholder oft relativ egal. Die interessieren sich dann manchmal noch für die Auswirkungen davon, also zum Beispiel kann ein Vendor Lock-in teuer sein, da kann es dann durchaus sein, dass sich die Stakeholder für das konkrete Risiko interessieren. Wir haben aber auch ganz oft Situationen, wo gerade solche organisatorischen Risiken eher im Projektmanagement behandelt werden und weniger in der Softwarearchitektur.

Anja: Welche Arten von Architekturentscheidungen sind dann typischerweise riskant? Ich habe jetzt so ein bisschen rausgehört, auf jeden Fall die Entscheidung für einen Cloud-Provider oder für eine Betriebsplattform, das ist so eine typische sehr riskante Sache, weil es eben sehr viel Umbauarbeiten erzeugt, sehr viel Investitionen nötig sind. Was sind noch so die typischen großen Architekturentscheidungen, die sehr riskant sind oder viele Risiken haben?

Gerrit: Das kritischste sind tatsächlich Architekturentscheidungen, bei denen ich mich in eine externe Abhängigkeit begebe. Wo ich plötzlich von Dingen abhängig bin, die ich nicht steuern oder kontrollieren kann. Und Entscheidungen außerhalb meines Entscheidungsraums plötzlich Auswirkungen auf meine Architektur haben. Das ist die größte Baustelle, die wir eigentlich haben. Dann gibt es noch eine ganze Reihe von, ich sag mal in Anführungszeichen, kleineren Entscheidungen, die auch einen sehr starken Einfluss auf beispielsweise Weiterentwicklungsmöglichkeiten haben können. Und das ist ein Bereich, bei dem es sehr schwer ist, tatsächlich vorherzusehen, welche Dinge, welche Entscheidungen denn überhaupt mal zu Risiken führen können, weil das manchmal Sachen sind, die sich auf Anforderungen beziehen, die ich heute noch gar nicht kenne. Es kann sein, dass ich heute eine Entscheidung treffe nach bestem Wissen und Gewissen und heute einfach niemand weiß, dass in zwei Jahren diese Entscheidung sich mal als risikobehaftet herausstellen wird. Und das sind Bereiche, in denen es tatsächlich sehr schwer ist, solides Risikomanagement zu machen. Besonders spannend finde ich persönlich aber Risiken im oder Softwarearchitekturrisiken, die man so im Bereich von Technologiefolgenabschätzung adressieren oder finden kann. Der Klassiker, den ich sehr gerne zitiere oder hernehme, der sehr schnell einleuchtet, das ist beispielsweise diese Geschichte mit den AirTags von Apple. Da ist man so an der Grenze zwischen Software- und Produktrisiken, aber diese AirTags, als sie auf den Markt gekommen sind, wurden sie ja relativ schnell benutzt, um junge Frauen zu stalken. Man hat die AirTags unter Disco bei jemandem in die Handtasche und konnte den anschließend verfolgen. Solche Arten von Risiken sind in Softwarearchitektur ganz häufig mit drin. Und das ist ein Risiko, das konnte ja dann auch softwaretechnisch gelöst werden, indem man einfach die Verfolgung für denjenigen, den so ein AirTag begleitet, transparent macht. Ist vielleicht auch schon mal passiert, dass plötzlich so eine Meldung kam, neben dir begleitet dich jetzt schon länger ein AirTag, der dir nicht gehört, und dann bist du zumindest darüber informiert und kannst entsprechende Maßnahmen ergreifen.

Anja: Das funktioniert natürlich nur, wenn man auch in diesem Ökosystem ist, gerade jetzt im Apple-Beispiel.

Gerrit: Genau, genau. Das ist an der Stelle so ein typisches Problem, aber da greift dann beispielsweise manchmal auch ein Gesetzgeber ein und sagt, das muss irgendwie mitigiert werden, weil es anders gar nicht lösbar ist. Ich kann nicht jedes dieser Risiken tatsächlich rein durch Softwarearchitekturmaßnahmen lösen, aber es gibt vieles solcher Baustellen, wo ich als Architekt oder Architektin, indem ich mal sage, ich mache jetzt mal den Diskussionsraum ein bisschen auf und wir reden mal drüber, was könnte denn alles so passieren, solche Punkte halt entdecken kann.

Anja: Das bedeutet, das ist auch eine Risikoanalyse, die man nicht alleine im stillen Kämmerlein macht, sondern die macht man auch in einem etwas breiteren Umfeld mit Entwicklungspersonen, anderen Stakeholdern, PO, PM.

Gerrit: Unbedingt.

Anja: Welche Rollen haben da welche Beiträge zu leisten?

Gerrit: Das ist sehr unterschiedlich. Ich werde mich natürlich tendenziell eher über die technologischen Risiken mit meinem Entwicklungsteam unterhalten, über Produktrisiken mit Leuten, die vielleicht aus dem Produktmanagement oder Usability Engineering kommen, und kann mit denen dann in Austausch gehen. Über rechtliche Risiken würde ich mit Leuten reden, die einen juristischen Hintergrund haben. Wenn es um softwarearchitektonische Risiken geht, komme ich wieder mit allen Stakeholdern in Berührung, mit denen ich sonst auch in irgendeiner Form unter Umständen zu tun habe. Und ganz häufig kann ich gerade an den Schnittstellen der Disziplinen sehr gut über diese Risikothemen mit den Stakeholdern diskutieren.

Anja: Und wie komme ich auf die Idee, mit dem Legal Team zu sprechen oder mit, okay, vielleicht UX Design weiß man vielleicht als Architekt schon, aber wie kommt man auf die Idee, genau mit den Leuten zu reden? Ich habe das Gefühl, es ist meistens gut, wenn man solche Architekturentscheidungen offen kommuniziert, damit Interessierte einsteigen und sagen können, dazu habe ich Input, dazu kann ich dir etwas sagen, weil oftmals kommt man ja nicht selbst auf die Idee, was für weitere Risiken es geben kann.

Gerrit: Genau, da ist tatsächlich die beste Vorgehensweise, die ich im Laufe der Jahre identifiziert habe, einfach so viel wie möglich mit Leuten zu reden.

Anja: Also, was man gerade macht oder?

Gerrit: Genau, genau. Und dann kann es sein, dass die halt sagen, hast du daran mal gedacht, hast du das und das auf dem Schirm? Und dann entdecke ich immer wieder Punkte, die ich einfach nicht auf dem Schirm hatte, weil ich sie nicht kannte. Und da ist es gut, auf jeden Fall ein vertrauensvolles Verhältnis zu seinen Stakeholdern zu haben, damit man sich mit denen über solche Dinge offen austauschen kann.

Anja: Mir ist in meiner Projektarbeit aufgefallen, dass solche Veranstaltungen wie beispielsweise Sprint Reviews oder auch All-Hands-Meetings, in denen der aktuelle Stand von irgendwelchen Projekten dargestellt wird, oftmals sehr wichtig für diese Art der Kommunikation sind. Weil alle in der Organisation daran teilnehmen müssen und auch da sind und dann auch sehen, dazu habe ich ja was zu sagen, wo man halt sonst mit den Leuten vielleicht nicht in Kontakt tritt, weil man sie nicht kennt, weil sie an einem anderen Standort arbeiten oder weil sie remote arbeiten oder ähnliches.

Gerrit: Genau, solche Austauschformate, die irgendwie verschiedene Disziplinen zusammenführen und dazu führen, dass Leute überhaupt die Chance haben, sich zu Dingen zu äußern und darüber zu diskutieren, die sind da auf jeden Fall wertvoll.

Anja: Das ist ja aber eher so eine unstrukturierte Art und Weise, Architekturentscheidungen noch mal zu schärfen und Risiken zu sammeln oder zu bewerten. Wie sieht es mit einer strukturierten Analyse aus? Also machst du eine typische Risikoanalyse auch im Software-Kontext oder beziehungsweise, wie sieht das aus?

Gerrit: Also, wo ich tatsächlich strukturiert vorgehe, ist, dass wenn ich oder mein Team oder wir zusammen Architekturentscheidungen treffen, ich immer die Frage stelle: Was könnte denn da jetzt alles schiefgehen?

Anja: Ja.

Gerrit: Und das ist aus meiner Sicht auch der beste Zeitpunkt, um über Risiken zu sprechen, weil was wir jederzeit tun können, was aus der Architektur heraus aber eher selten sinnvoll zu motivieren ist, das ist so prinzipielle externe Risiken zu diskutieren. Das fordere ich dann, wenn es gar nicht passiert, mal von meinem Product Owner oder meiner Projektleiterin ein und sage: Kümmert euch mal darum, dass es mal von außen betrachtet wird. Aber wo wir in der Architekturarbeit sehr strukturiert uns mit Risiken beschäftigen können, ist immer zu dem Zeitpunkt, wo eine Entscheidung ansteht. Und die meisten Templates, die so mit Entscheidungen zu tun haben, ob jetzt Architectural Decision Records oder auch andere, die haben ja so einen Abschnitt Konsequenzen.

Anja: Ja.

Gerrit: Ein Risiko ist nichts anderes als eine Konsequenz. Ich bin mittlerweile immer misstrauisch, wenn eine Architekturentscheidung, ein ADR, zu mir kommt und ich es mir ansehen soll, aber kein einziges Risiko darin steht. Dann frage ich, ob wirklich darüber nachgedacht wurde, denn ich habe bisher noch nie eine Architekturentscheidung getroffen, die 100% risikofrei war. Manchmal waren die Risiken nicht schlimm, aber an eine, die keinerlei Risiken hatte, kann ich mich eigentlich nicht erinnern.

Anja: Ja, das ist spannend. Methodisch gehst du also so vor, dass du in Architekturentscheidungsdokumentationen darauf achtest, dass Risiken bedacht werden.

Gerrit: Genau. Dann kann ich die mit meinen Stakeholdern besprechen. Einige davon werden tatsächlich auch als Projektrisiken behandelt. Andere sind von ihren Auswirkungen her nicht groß genug, dass sich die Projektleitung oder ein Lenkungsausschuss damit beschäftigt. Da ist es völlig in Ordnung, wenn das Team die auf dem Schirm hat und sagt, das können wir im Entwicklungsteam klären. Aber dass ich überhaupt erstmal diese Risiken sichtbar gemacht habe und die Möglichkeit geschaffen habe, dass jemand sie bemerkt, das ist schon der erste wichtige Schritt, den man da gehen muss.

Anja: Im Projektmanagement gibt es ja auch diese Impact-Analysen, die sind noch ein bisschen umfangreicher. Ist das ein Overkill in der Softwarearchitektur?

Gerrit: Bei großen, wichtigen, kritischen Projekten würde ich das auch so machen. Bei vielen kleineren Softwareprojekten, wo es jetzt nicht um wirklich hohe Risiken in der Software geht, die wir damit produzieren, kann es sein, dass das tatsächlich methodisch zu viel Ballast ist, den man einem Entwicklungsteam aufbürdet. Ich würde aber auf jeden Fall sagen, wenn in einem Projekt eine Impact-Analyse gemacht wird, sollte jemand aus der Softwarearchitektur oder mit Softwarearchitektur-Know-how mit dabei sein und einen entsprechenden Beitrag und eine entsprechende Perspektive beisteuern.

Anja: Wenn jetzt so ein Risiko eintritt, vielleicht sogar ein etwas höheres Risiko.

Gerrit: Mhm.

Anja: Wie geht man damit praktisch um? Man hatte ja schon irgendwo aufgeschrieben, dieses Risiko könnte eintreten. Sollte man sich auch dann dazu Gedanken machen, wie man das auch mitigiert, wenn es dann eintritt?

Gerrit: Ja, Mitigation kann ja im Prinzip zu zwei Zeitpunkten passieren: Entweder bevor es eintritt, dass ich versuche zu vermeiden, dass es überhaupt eintritt, oder dass ich mir Gedanken darüber mache, was passiert, wenn es eintritt. Die Herausforderung, die ich da immer wahrnehme und erlebe, ist, dass viele Leute irgendwann mal diese Erwartungswertformel gelernt haben: Eintrittswahrscheinlichkeit mal Schadenhöhe, und dann beschäftigen wir uns damit. Das große Problem ist, in der Praxis wird ein Risiko, wenn es denn eintritt, immer zu 100% eintreten. Es tritt nicht mit dem Erwartungswert ein, sondern es tritt mit dem vollen Impact, mit dem vollen Schaden ein. Was ich brauche, ist für die drei, vier, fünf kritischsten, schwierigsten, blödesten, gefährlichsten Risiken, die ich mir in meinem Projekt vorstellen kann, eine Strategie, wie ich mit ihnen umgehe, wenn sie wirklich eintreten. Das machen wir an einigen Stellen. Ich kenne etliche Softwaresysteme, wo es ein Duplikat in einem anderen Rechenzentrum gibt, wo man sagt, wenn das Rechenzentrum ausfällt, startet irgendwo anders die Software und übernimmt den Dienst. Also, dass man wirklich so große Redundanzen beispielsweise aufbaut. Das ist so eine Risikomitigation, die vielen Leuten vertraut ist. Das kann ich im Kleinen machen, dass ich sage, ich habe irgendwie ein Cluster, wenn der eine Service ausfällt, übernimmt der nächste, das kann ich auch weitestgehend automatisieren. Das geht im Kleinen, das kann ich aber auch im Großen machen, da ist es aber dann halt um einen Faktor teurer, dass es sich für viele Softwaresysteme dann unter Umständen auch nicht lohnt. Das ist das, was ich ausbalancieren muss, wo ich halt rechnen muss, brauchen wir das, brauchen wir das nicht, lohnt sich das. Fallback-Geschichten als Mitigationsmaßnahme sind dann verbreitete Strategien für eine bestimmte Klasse von Risiken, die man da anlegen kann, und die geht halt davon aus, ich habe die gleiche Infrastruktur noch mal irgendwo und kann halt komplett kompensieren.

Anja: Obwohl auch diese Strategien wieder Risiken haben, ob sie überhaupt funktionieren. So etwas wie Datenkorruption ist halt ein typisches Beispiel oder dass die Daten schnell genug in das andere System kommen. Also auch diese Strategien brauchen wieder eine Architekturentscheidung und wieder Risiken beziehungsweise Risikoanalyse.

Gerrit: Ganz genau. Die führen zu neuen Risiken und das sind halt Maßnahmen, die funktionieren nur, wenn ich sie übe.

Anja: Ja.

Gerrit: Wir können uns da die wunderschönsten Theoriegebäude bauen und sagen, theoretisch müsste die Architektur so funktionieren, dass das Hotspare-Rechenzentrum einspringt, wenn das Primärrechenzentrum ausfällt, aber wenn ich diesen Fall nie übe und dann irgendwas nicht so perfekt funktioniert, wie man sich das in der Theorie gedacht hat, ist die ganze Maßnahme hinfällig. Also das sage ich auch den Entwicklungsteams, ihr könnt euch noch so tolle Maßnahmen ausdenken, ihr müsst dafür sorgen, dass klar ist, wer tut wann was, wenn das Risiko eintritt. Das Beispiel Feuerwehr: Die meiste Zeit, die Menschen bei der Feuerwehr arbeiten, verbringen sie damit zu üben, was sie tun müssen, wenn ein Problem oder wenn ein Risiko eintritt. Genauso müssen wir uns in der Softwareentwicklung an der Stelle halt auch verhalten.

Anja: Ja. Oder man bindet es so in den Alltag ein, dass man es schon die ganze Zeit verwendet, ohne es explizit üben zu müssen.

Gerrit: Ja, da bin ich auch ein ganz großer Fan davon, zu sagen, es gibt ja so zwei Schulen der Automatisierung. Die einen, die sagen, automatisiere Dinge, die häufig vorkommen, damit du Zeit sparst. Das sind so die BWL-Richtung. Die Risikoleute gucken da anders drauf und sagen, die Dinge interessieren uns eigentlich nicht, wir müssen die Sachen automatisieren, die sehr selten passieren, weil dort die Gefahr am höchsten ist, dass Fehler gemacht werden.

Anja: Mhm, okay.

Gerrit: Und wenn ich diese Dinge automatisiert habe, habe ich schon mal das Risiko reduziert, dass im Fall des Falles irgendwas schiefgeht. Das ist auch keine 100% Garantie, und auch das Automatisierte birgt wieder Risiken, wie du ja vorhin auch schon gesagt hast. Aber das ist halt so eine Perspektive, dass ich sage, ich will dieses Umschalten vom Rechenzentrum beispielsweise nicht manuell machen müssen. Ich will, dass das automatisch passiert und will da entsprechende Mechanismen etablieren, weil wenn es hoffentlich selten passiert, hoffentlich brauchen wir es nie. Das ist immer so die Geschichte, aber wenn dann, wollen wir eigentlich, dass es fehlerfrei passiert, und das kann ich nur entweder durch Üben, bei einigen Dingen kann ich es auch nur durch Üben machen, und bei einigen Dingen kann ich es durch Automatisierung erreichen, und dann würde ich sowas tendenziell bevorzugt automatisieren.

Anja: Ich weiß auf jeden Fall, dass du ein Training zum Thema Risikomanagement anbietest. Das geht wie lange? Zwei Tage, drei Tage?

Gerrit: Das geht tatsächlich nur einen Tag. Das ist so ein Intensivtraining, wo man mal einen Tag wirklich durch die komplette, für Softwarearchitektur relevanten Bereiche des Risikomanagements, ich sag mal, durchfliegt. Das ist jetzt kein spezifisches, was konkrete Methoden im Detail beleuchtet, sondern wirklich so einen Überblick gibt, was kann ich da sinnvoll eigentlich alles tun, wenn ich in der Softwarearchitektur Verantwortung bin?

Anja: Mhm. Und wo erntest du denn immer diese Aha-Momente von den Teilnehmenden, so, ah, das wusste ich gar nicht oder so habe ich das noch nie gesehen?

Gerrit: Die finden an ganz verschiedenen Stellen statt, weil die Leute üblicherweise einen unterschiedlichen Hintergrund haben, wenn sie in das Training kommen. Einige machen das schon, die finden dann häufig im Detail so ein paar Erkenntnisse. Andere überrasche ich, wenn ich mit ihnen über Risikoneutralität spreche und darüber diskutiere, warum diese häufig verwendete Formel mit diesem Erwartungswert für Risiken eigentlich Unsinn ist und sie eher daran hindert, das Richtige zu tun. Wieder andere sind überrascht, auf wie viele Arten man eigentlich Risiken abschätzen kann, was es da so an strukturierten Möglichkeiten gibt. Es ist sehr unterschiedlich, was die Leute da jeweils dann individuell mitnehmen.

Anja: Magst du mal kurz sagen, wie man Risiken abschätzen kann? So ein paar Methoden?

Gerrit: Es gibt, wie gesagt, die verschiedensten Herangehensweisen. Das eine ist natürlich, was beim Schätzen ein Klassiker ist: Ich mache Vergleiche. Ich suche ähnliche Risiken raus und sage, was ist denn da eingetreten, was ist da passiert, wie waren da die Schadenshöhen oder so, und stelle über diesen Weg relativ straightforward so einen Vergleich her. Eine andere Geschichte, die ich sehr gerne mache, basiert auf der Idee, dass wir ganz häufig unvollständiges Wissen haben, aber wir wissen bestimmte Dinge durchaus. Und wie kann ich jetzt aus diesen Dingen über eine strukturierte Herangehensweise, strukturiertes Überlegen, zu Erkenntnissen kommen? Das ist eine Methodik, die geht auf Enrico Fermi zurück, dem immer nachgesagt wird, er hätte seinen Studierenden die Frage gestellt, wie viele Klavierstimmer gibt es in Chicago? Und hat dann im Prinzip aus dem Wissen, das er hatte, nämlich wie viele Personen leben in Chicago, wie viele Haushalte gibt es in Chicago, im Prinzip runtergebrochen, wie viele Klavierstimmer gibt es in der Stadt? Und lag da meistens so um plus minus 5% daneben mit seinen Schätzungen, die er auf diese Weise abgegeben hat. Das üben wir dann beispielsweise auch mal in dem Training anhand von Beispielen, weil das etwas ist, was ich als sehr wertvoll erlebt habe, wenn man vor dieser Unsicherheit steht, ja, ich soll jetzt eine Schadenshöhe beziffern, und jemand wie der Gerrit kommt ins Projekt und sagt, hoch, mittel, niedrig nützt mir gar nichts als Schadenshöhe. Ich brauche eine Zahl. Ich will wissen, wie viele Euros haben wir da, wie komme ich jetzt auf die Euros? Und da kann einem diese Methodik von Enrico Fermi tatsächlich sehr gut helfen.

Anja: Ja, klingt auf jeden Fall sinnvoll zu wissen, wie viele Euros etwas kostet und nicht, ob etwas hoch oder niedrig eingeschätzt wird. Ja, das stimmt schon.

Gerrit: Genau. Genau.

Anja: In den heutigen Zeiten ist es ja so, dass wir in der Softwareentwicklung sehr viel mit künstlicher Intelligenz arbeiten. Wir lassen uns Stories schreiben, wir lassen uns auch Architecture Decision Records schreiben. Wir lassen uns alles Mögliche von der KI schreiben mit so ein bisschen Kontext. Können wir auch so eine Risikoanalyse mit der KI schreiben? Sollten wir das überhaupt tun? Kommt die KI vielleicht auf andere Dinge, auf die wir nicht gekommen sind?

Gerrit: Ja, why not? Also, tatsächlich, wo KI helfen kann, sind Dinge, die ich jetzt auch schon genannt hatte, Dinge, die du jetzt gerade genannt hast. Wenn ich so eine Technologiefolgenabschätzung machen kann, ist die ein super Partner für ein Brainstorming. Szenarien zu erfinden, auf die man selber nie gekommen wäre, wenn man nicht viele Science-Fiction-Romane liest. Da kann die total hilfreich sein. Andere Sachen sind, ich gebe mal meine 35 Architecture Decision Records und frage, welche Risiken ich übersehen habe. Da findet das schon noch ein paar, die ich überhaupt nicht auf dem Schirm hatte. Also, da kann das definitiv ein Partner sein, der hilft. Das würde ich durchaus sehen. Auf der anderen Seite produzieren wir mit KI aber auch wieder Risiken. Und die Risiken würde ich gar nicht so sehr beispielsweise darin sehen, dass sie irgendwie User Stories schreibt und in der User Story irgendwas falsch ist oder so. Das kriege ich relativ leicht hin, sondern das, wo wir mit KI heute in Software Risiken einbauen, ist die Tatsache, dass die aktuell gerne benutzten KI-Systeme nicht deterministisch sind. Aber 50 Jahre Didaktik in der IT-Ausbildung hat Menschen konstruiert, die davon ausgehen, dass ein Computer sich deterministisch verhält. Und diese Erwartung produziert einen immensen Risikovektor. Wir sind einfach nicht darauf trainiert, dass ein Computer nicht deterministisches Verhalten zeigt. Und ich glaube, der Risikoraum, der da geöffnet wird, sobald wir KI in Software als Baustein einsetzen, also nicht als Sparringspartner benutzen, wie ich das gerade beschrieben habe, sondern dass KI ein Baustein wird in Computersystemen, wenn es um Entscheidungen geht, wenn es um Bewertungen geht und so weiter und so fort. Da machen wir einen Risikoraum auf, der sehr schwer abzuschätzen ist. Und wo ich halt auch wieder mit der Perspektive rangehen muss, in 90% oder 99% der Fälle macht die KI das genauso, wie wir das gerne hätten. Aber dann gibt es das eine Prozent, wo sie das halt falsch macht und da kann es sein, dass wirklich der Schaden zu 100% eintritt. Und dafür brauche ich wieder eine Mitigationsstrategie.

Anja: Okay, also das, was du sagst, ist im Grunde, wenn wir die KI alleine lassen und nicht überwachen, dann wird sie halt auch Dinge tun, die wir nicht vorausgesehen haben.

Gerrit: Ja, also das würde ich unabhängig von unserer Überwachung tun. Das macht sie ja auch, wenn wir das überwachen. Das Entscheidende ist an der Stelle, glaube ich, dass wir es bemerken. Und dass wir für den Fall, dass es passiert, eine Strategie haben, wie gehen wir damit um? Also, dass wir nicht an jeder Stelle einen Fallback-Mechanismus oder so etwas brauchen, aber dass wir uns, wann immer wir das als Teil von Softwarearchitektur verwenden, dann auch eine Risikoanalyse machen, die halt einpreist, dass die KI oder es gibt ja auch deterministische KI-Systeme, aber wenn wir halt so ein Large Language Model beispielsweise einsetzen, dass sich das nicht deterministisch verhalten wird. Das ist etwas, das muss man an der Stelle einfach mit auf dem Radar haben.

Anja: Genau, mit berücksichtigen, ja. Gibt es noch etwas, was du unseren Hörern mitgeben möchtest zum Thema, was wir vielleicht noch nicht angemerkt haben, was dir aber wichtig ist?

Gerrit: Also mir wäre es tatsächlich wichtig, dass sich mehr Menschen, die Softwarearchitektur-Verantwortung haben, bewusst mit dem Thema Risiken auseinandersetzen und das nicht als so ein nebenbei oder macht jemand anders oder so etwas sehen, sondern dass sie tatsächlich verstehen, dass wann immer wir jetzt Softwaresysteme bauen, dass wir da im Prinzip potenziell eine Quelle für Risiken sind und mit diesen Risiken bewusst umgehen müssen. Das wäre mir wichtig, das ist auch der Grund, warum ich irgendwann mal gesagt habe, ich muss dieses Training anbieten, weil ich da einfach eine Lücke sehe.

Anja: Ja, wunderbar. Vielen Dank, Gerrit, dass ich mit dir sprechen durfte.

Gerrit: Klar, gerne. Tschüss.

This summary was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Welche Risiken birgt Ihre Softwarearchitektur und wie gehen Sie damit um?

Die Rolle von Softwarearchitekt:innen im Risikomanagement

Gerrit betont, dass Softwarearchitekt:innen eine doppelte Rolle im Risikomanagement spielen: Sie sind sowohl Verursacher als auch Lösungsanbieter von Risiken. Architekturentscheidungen, oft Kompromisse, können neue Risiken schaffen. Gleichzeitig sind Architekt:innen maßgeblich daran beteiligt, diese Risiken zu mindern oder zu eliminieren. Typische Risiken reichen von Vendor Lock-in und Sicherheitslücken bis hin zu nicht erfüllten Qualitätsanforderungen, die sich unter geänderten Rahmenbedingungen manifestieren können. Gerrit hebt hervor, dass auch organisatorische Risiken, wie die Akzeptanz von Entscheidungen durch Stakeholder, relevant sein können, obwohl diese oft eher im Projektmanagement behandelt werden.

„Softwarearchitektinnen sollten sich mit Risikomanagement beschäftigen, weil sie Risiken lösen können. Also sie sind nicht nur Quelle von Risiken, sondern sie sind ganz ganz häufig auch diejenigen Personen, die maßgeblich dazu beitragen können, dass Risiken ja abgemildert werden können oder vielleicht sogar völlig eliminiert werden können.“

Risikoreiche Architekturentscheidungen und ihre Entdeckung

Besonders kritisch sind Architekturentscheidungen, die externe Abhängigkeiten schaffen und somit die Kontrolle über bestimmte Aspekte der Architektur entziehen. Gerrit nennt als Beispiel die Wahl eines Cloud-Providers oder einer Betriebsplattform. Schwieriger vorhersehbar sind Risiken, die sich auf zukünftige, noch unbekannte Anforderungen beziehen. Ein spannendes Feld ist die Technologiefolgenabschätzung, bei der Architekt:innen potenzielle negative Auswirkungen einer Technologie auf die Gesellschaft oder Nutzer:innen identifizieren können, wie das Beispiel der Apple AirTags zeigt. Um solche Risiken zu entdecken, ist ein offener Austausch mit verschiedenen Stakeholdern unerlässlich. Anja und Gerrit sind sich einig, dass informelle Kommunikationsformate wie Sprint Reviews oder All-Hands Meetings wertvoll sind, um unterschiedliche Perspektiven einzuholen und Risiken frühzeitig zu erkennen.

„Das kritischste ist tatsächlich Architekturentscheidungen, wo ich mich in eine externe Abhängigkeit begebe. Wo ich plötzlich von Dingen abhängig bin, die ich nicht steuern kann, die ich nicht kontrollieren kann.“

Strukturierte Risikoanalyse und Mitigation

Gerrit empfiehlt, Risiken strukturiert im Rahmen von Architekturentscheidungen zu behandeln. Jede Architekturentscheidung sollte die Frage aufwerfen: „Was könnte denn da jetzt alles schief gehen?“ Risiken sind Konsequenzen von Entscheidungen und sollten in Architectural Decision Records (ADRs) dokumentiert werden. Gerrit ist misstrauisch, wenn ein ADR keine Risiken auflistet, da jede Entscheidung potenziell Risiken birgt. Für kritische Projekte können Impact-Analysen sinnvoll sein, wobei Architekt:innen ihr Fachwissen einbringen sollten. Bei der Mitigation von Risiken ist es wichtig, nicht nur die Eintrittswahrscheinlichkeit und den Schaden zu betrachten, sondern konkrete Strategien für den Fall des Eintretens zu entwickeln. Dies kann den Aufbau von Redundanzen oder Fallback-Mechanismen umfassen. Solche Strategien müssen jedoch regelmäßig geübt und idealerweise automatisiert werden, um im Ernstfall fehlerfrei zu funktionieren.

„Ich bin mittlerweile immer misstrauisch, wenn ich irgendwie wenn so eine Architekturentscheidung, so ein ADR zu mir kommt und ich den mal angucken soll und da steht kein einziges Risiko drin. Da frage ich dann mal, habt ihr wirklich drüber nachgedacht, weil eigentlich ich also, wenn ich so zurückblick, ich habe bisher noch nie eine Architekturentscheidung getroffen, die 100% Risikofrei war.“

Risikoeinschätzung und der Einfluss von KI

Gerrit erläutert verschiedene Methoden zur Risikoeinschätzung. Neben dem Vergleich mit ähnlichen Risiken schätzt er die Fermi-Methode sehr, die es ermöglicht, auch bei unvollständigem Wissen zu fundierten Schätzungen zu gelangen. Diese Methode hilft, abstrakte Risikobewertungen wie „hoch, mittel, niedrig“ in konkrete Zahlen, beispielsweise in Euro, zu überführen. Im Kontext von Künstlicher Intelligenz (KI) sieht Gerrit sowohl Chancen als auch neue Risiken. KI kann als Sparringspartner für Brainstorming und zur Identifizierung übersehener Risiken in ADRs dienen. Gleichzeitig birgt der Einsatz von KI als Baustein in Softwaresystemen erhebliche Risiken, insbesondere aufgrund ihrer nicht-deterministischen Natur. Dies kollidiert mit der Erwartung vieler Entwickler:innen an deterministisches Computerverhalten und eröffnet einen schwer abschätzbaren Risikoraum. Es ist entscheidend, diese Nicht-Deterministik bei der Risikoanalyse zu berücksichtigen und Strategien für den Fall zu entwickeln, dass die KI unerwartet oder fehlerhaft agiert.

„Das große Problem ist, in der Praxis wird ein Risiko, wenn es denn eintritt, immer zu 100% eintreten. Das tritt nicht mit dem Erwartungswert ein, sondern es tritt mit dem vollen Impact, sage ich mal, mit dem mit dem vollen Schaden ein.“