# Strategic Risk Management for Software Architecture

**Podcast:** INNOQ Podcast
**Published:** 2026-06-15

## Transcript

Hallo und herzlich willkommen zum InnoQ Podcast.
Mein Name ist Anja Kammer und heute habe ich Gerrit bei mir.
Hallo Gerrit.
Hallo Anja.
Heute sprechen wir über Risikomanagement für Softwarearchitektinnen.
Und da ist schon meine erste Frage, bevor wir in die Methode einsteigen zu Risikomanagement, wie man das überhaupt macht.
Warum sollten sich gerade Softwarearchitektinnen mit Risikomanagement beschäftigen?
Da gibt es meiner Meinung nach zwei Gründe, warum sie das tun sollten.
Der eine ist, sie produzieren Quellen von Risiken in Form von Software.
Sie treffen Entscheidungen und diese Entscheidungen sind manchmal Kompromisse und manchmal folgen aus diesen Entscheidungen auch Risiken.
Das ist der eine Grund.
Und der andere ist, 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 abgemildert werden können oder vielleicht sogar völlig eliminiert werden können.
Und das, finde ich, sind zwei gute Gründe, sich mit dem Thema zu beschäftigen.
Welche Risiken treten denn normalerweise oder typischerweise auf bei der Software-Architektur-Arbeit oder bei Architekturentscheidungen?
Welche Risiken können da typischerweise auftreten?
Auch so Beispiele.
Da gibt es so die Klassiker.
Das, was sicherlich alle kennen, das sind so Risiken wie zum Beispiel Vendor-Login.
Dass man eine Entscheidung trifft, macht sich von irgendeiner Technologie, von einem Framework, von einem Hersteller abhängig und dann entwickelt sich das in eine andere Richtung, als man geplant hatte und man ist aber dran gebunden und die Änderung ist sehr, sehr teuer oder vielleicht sogar unmöglich.
Das ist so ein Klassiker im Risikomanagement.
Andere Geschichten sind Risiken, die so aus dem Security-Bereich kommen.
wo man vielleicht Lücken hat, die man nicht vorhersehen kann, die aus dem Standard herauskommen.
Was weiß ich, was früher immer mal aufgetreten ist, waren so Risiken im Bereich Bluetooth-Kommunikation, wo man dann plötzlich festgestellt hat, in dem Protokoll ist designtechnisch ein Fehler drin.
Das ist für mich als Architekt in dem Moment ein Risiko, wo ich halt 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, betreibt und unter diesen geänderten Rahmenbedingungen eine Qualitätsanforderung nicht mehr erfüllt werden kann.
Und dann unter Umständen die Software ein anderes Verhalten zeigt, als gewünscht ist.
Und auch das kann dann beispielsweise zu einem architektonischen Risiko werden.
Zählen dazu auch organisationelle Risiken, wie beispielsweise, dass die Entscheidung getragen wird von Organisationen oder von wichtigen Stakeholdern?
Das ist so ein Grenzbereich.
Also 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 so ein Vendor-Login kann halt was Teures sein.
Da kann es dann durchaus sein, dass sich die Stakeholder für das konkrete Risiko interessieren.
Wir haben aber auch ganz, ganz oft Situationen, wo gerade solche organisatorischen Risiken eher so im Projektmanagement behandelt werden und weniger in der Softwarearchitektur.
Welche Arten von Architekturentscheidungen sind dann so 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 viele Investitionen nötig sind.
Was sind noch so die typischen großen Architekturentscheidungen, die sehr riskant sind oder viele Risiken haben?
Also das Kritischste ist tatsächlich, Architekturentscheidungen, wo ich mich in der externe Abhängigkeit begebe.
Wo ich plötzlich von Dingen abhängig bin, die ich nicht steuern kann, die ich nicht kontrollieren kann.
Und Entscheidungen außerhalb meines Entscheidungsraums plötzlich auf meine Architektur eine Auswirkung haben.
Das ist die größte Baustelle, die wir eigentlich haben.
Dann gibt es noch eine ganze Reihe von, ich sage mal, in Anführungszeichen kleineren Entscheidungen, die auch einen sehr, sehr starken Einfluss haben können auf beispielsweise Weiterentwicklungsmöglichkeiten.
Und das ist ein Bereich, bei dem ist es sehr, sehr schwer, 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.
Also 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 so Bereiche, in denen ist es tatsächlich sehr, sehr schwer, solides Risikomanagement zu machen.
Besonders spannend finde ich persönlich aber Risiken.
Softwarearchitektur-Risiken, die man so im Bereich von Technologiefolgenabschätzung adressieren kann oder finden kann.
Also der Klassiker, den ich sehr, 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 die ja relativ schnell benutzt, um junge Frauen zu stalken.
Man hat seine AirTags unter Disco bei jemandem in die Handtasche und konnte den anschließend verfolgen.
Solche Arten von Risiken sind in Softwarearchitektur ganz, ganz häufig mit drin.
Und das ist ein Risiko, das konnte ja dann auch softwaretechnisch gelöst werden, also indem man einfach die Verfolgung für denjenigen, den so ein AirTag begleitet, transparent macht.
Es ist vielleicht auch schon mal passiert, dass plötzlich so eine Meldung kam, neben dir, dich begleitet jetzt schon länger ein AirTag, der dir nicht gehört.
Und dann bist du zumindest darüber informiert und kannst eine entsprechende Maßnahme.
Das funktioniert natürlich nur, wenn man auch in diesem Ökosystem ist.
Also gerade jetzt im Apple-Beispiel.
Genau, genau.
Also das ist an der Stelle so ein typisches Problem.
Aber da greift dann beispielsweise manchmal auch ein Gesetzgeber ein und sagt, ja, das muss irgendwie mitigiert werden, weil es anders gar nicht lösbar ist.
Also ich kann nicht jedes dieser Risiken tatsächlich rein durch Software-Architektur-Maßnahmen lösen.
Aber es gibt viele 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 darüber, was könnte denn alles so passieren, solche Punkte halt entdecken kann.
Das bedeutet, das ist auch sozusagen eine Risikoanalyse, die man nicht alleine im stillen Kämmerlein macht, sondern die macht man auch in einer etwas breiteren Umfeld mit Entwicklungspersonen, anderen Stakeholdern, PO, PM.
Unbedingt.
Welche Rollen haben da?
Haben da welche Beiträge zu leisten?
Also das ist sehr unterschiedlich.
Also ich werde mich natürlich tendenziell eher über die technologischen Risiken mit meinem Entwicklungsteam unterhalten, über Produktrisiken mit Leuten, die vielleicht aus dem Produktmanagement kommen, aus dem Usability Engineering und kann mit denen dann in Austausch gehen.
Über irgendwelche rechtlichen Risiken würde ich mit Leuten reden, die einen juristischen Hintergrund haben.
Also ich komme beim, wenn es um softe architektonische 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, ganz häufig kann ich halt gerade an den Schnittstellen der Disziplinen sehr, sehr gut über diese Risikothemen mit den Stakeholdern diskutieren.
Und wie komme ich auf die Idee, mit dem Legal-Team zu sprechen?
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 können 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 noch weitere Risiken das geben kann.
Genau, also da ist tatsächlich die beste Quelle, die ich, oder die beste Vorgehensweise, die ich so identifiziert habe im Laufe der Jahre, einfach so viel wie möglich mit Leuten zu reden.
Also was man gerade macht?
Genau, genau.
Und dann...
Kann es sein, dass die halt sagen, hier 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.
Mir ist in meiner Projektarbeit aufgefallen, dass solche Veranstaltungen wie beispielsweise Sprint Reviews oder auch All Hands Meetings, in dem sozusagen der aktuelle Stand von irgendwelchen Projekten dargestellt werden, dass die oftmals sehr, sehr wichtig sind für diese Art der Kommunikation, weil sozusagen alle in der Organisation daran teilnehmen müssen und auch da sind und dann auch sehen, ah, 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 in einem anderen Standort arbeiten oder weil sie remote arbeiten oder ähnliches.
Genau, also 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.
Das ist ja aber eher so eine unstrukturierte Art und Weise, Architekturentscheidungen nochmal 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 Softwarekontext oder beziehungsweise wie sieht das aus?
Also wo ich tatsächlich strukturiert vorgehe, ist, dass wenn ich oder mein Team oder wir zusammen Entscheidungen treffen, Architekturentscheidungen, ich immer die Frage stelle, was könnte denn da jetzt alles schief gehen?
Und das ist aus meiner Sicht auch der beste Zeitpunkt, um über Risiken zu sprechen.
Also 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 ist was, das fordere ich dann, wenn es gar nicht passiert, mal von meinem Product Owner oder meiner Projektleiterin ein und sage hier, kümmert euch mal darum, dass das mal von außen betrachtet wird, aber wo wir in der Architekturarbeit sehr, 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.
Und ein Risiko ist nichts anderes als eine Konsequenz.
Und ich bin mittlerweile immer misstrauisch, 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 immer, habt ihr wirklich drüber nachgedacht?
Weil eigentlich, wenn ich so zurückblicke, ich habe bisher noch nie eine Architekturentscheidung getroffen, die 100% risikofrei war.
Manchmal waren die Risiken nicht schlimm oder so, aber eine, die keinerlei Risiken hatte, kann ich mich eigentlich nicht daran erinnern, dass es so eine Entscheidung jemals gegeben hat.
Ja, das ist spannend.
Also methodisch gehst du so vor, dass du in Architekturentscheidungen Dokumentation darauf achtest, dass Risiken bedacht werden.
Genau.
Dann kann ich die mit meinen Stakeholdern besprechen und einige davon werden tatsächlich auch als Projektrisiken behandelt.
Andere sind nicht von ihren Auswirkungen her nicht groß genug, dass sich jetzt eine Projektleitung oder ein Lenkungsausschuss oder sowas mit diesen Themen beschäftigt.
Da ist es völlig okay, wenn das Team die auf dem Schirm hat und sagt, das können wir im Entwicklungsteam klären.
Aber dass ich überhaupt erstmal diese riesigen Sichtbau gemacht habe und die Möglichkeit geschaffen habe, dass jemand die bemerkt, das ist schon der erste wichtige Schritt, den man da gehen muss.
Und im Projektmanagement gibt es ja auch diese Impact-Analysen, die sind noch ein bisschen umfangreicher.
Ist das ein Overkill in der Software-Architektur?
Bei großen, wichtigen, kritischen Projekten würde ich das auch so machen.
Bei vielen kleineren Software-Projekten, wo es jetzt nicht um...
wirklich um hohe Risiken in der Software geht, die wir damit produzieren, kann es sein, dass das tatsächlich methodisch zu viel Ballast ist, den man da eventuell so 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 Software-Architektur oder mit Software-Architektur-Know-how mit dabei sein.
und da einen entsprechenden Beitrag und eine entsprechende Perspektive mit beisteuern.
Wenn jetzt so ein Risiko eintritt, vielleicht sogar ein etwas höheres Risiko, wie geht man damit so praktisch um?
Ich meine, man hat 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?
Ja, also Mitikation kann ja im Prinzip zu zwei Zeitpunkten passieren.
bevor es eintritt, dass ich versuche zu vermeiden, dass es überhaupt eintritt oder dass ich mir halt Gedanken darüber mache, was passiert denn, wenn es eintritt.
Und 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 Prozent eintreten.
Das tritt nicht mit dem Erwartungswert ein, sondern es tritt mit dem vollen Impact, sage ich mal, mit dem vollen Schaden ein.
Und was ich brauche, ist für die drei, vier, fünf kritischsten, schwierigsten, blödesten, gefährlichsten Risiken, die ich mir vorstellen kann in meinem Projekt.
Brauche ich eine Strategie?
Wie gehe ich mit denen um, wenn die wirklich eintreten?
Das machen wir an einigen Stellen.
Also ich kenne etliche Software-Systeme, wo es ein Duplikat in einem anderen Rechenzentrum gibt.
Wo man sagt, wenn das Rechenzentrum ausfällt, startet irgendwo anders die Software und übernimmt halt 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 und sowas.
Also das geht im Kleinen.
Das kann ich aber auch im Großen machen.
Da ist es aber dann halt um einen Faktor teurer, der sich für viele Software-Systeme dann unter Umständen auch nicht lohnt.
Und das ist das, was ich ausbalancieren muss, wo ich halt rechnen muss.
Also brauchen wir das, brauchen wir das nicht?
Lohnt sich das?
Also so Fallback-Geschichten als Mitigationsmaßnahme sind eine verbreitete und für eine bestimmte Klasse von Risiko verbreitete Strategie, die man da anlegen kann.
Und die geht halt davon aus, ich habe die gleiche Infrastruktur nochmal irgendwo und kann halt komplett kompensieren.
Obwohl auch diese Strategien wieder Risiken haben, also ob sie überhaupt funktionieren.
Also 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 Risikenanalyse.
Die führen zu neuen Risiken und das sind halt Maßnahmen, die funktionieren nur, wenn ich sie übe.
wir können uns da die wunderschönsten Theoriegebäude bauen und sagen, theoretisch müsste die Architektur so funktionieren, dass das Hotspair-Rechenzentrum einspringt, wenn das Primärrechenzentrum ausfällt oder sowas.
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 an 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.
Also das Beispiel Feuerwehr, die meisten 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.
Und genauso müssen wir uns in der Softwareentwicklung an der Stelle halt auch verhalten.
Oder man bindet es so in den Alltag ein, dass man es schon die ganze Zeit verwendet, ohne es explizit üben zu müssen.
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-Richtungen.
Und die Risikoleute gucken da anders drauf und sagen, nee, die Dinge interessieren uns eigentlich nicht.
Wir müssen die Sachen automatisieren, die sehr selten passieren, weil dort ist die Gefahr am höchsten, dass Fehler gemacht werden.
Und wenn ich diese Dinge automatisiert habe, habe ich schon mal das Risiko reduziert, dass im Fall des Falles irgendwas schief geht.
Das ist auch keine 100% Garantie.
Und auch das automatisiert 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 hoffentlich passiert es ja selten, hoffentlich brauchen wir es nie.
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.
Ich weiß auf jeden Fall, dass du ein Training zum Thema Risikomanagement anbietest.
Das geht wie lange?
Zwei Tage, drei Tage?
Das geht tatsächlich nur einen Tag.
Das ist so ein Intensivtraining, wo man mal einen Tag wirklich durch die komplette, ja, für Software-Architektur relevanten Bereiche des Risikomanagements, ich sage 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 Software-Architektur-Verantwortung bin.
Und wo erntest du dann immer diese Aha-Momente von den Teilnehmenden?
So, ah, das wusste ich gar nicht oder so, habe ich das noch nie gesehen?
Die finden an ganz verschiedenen Stellen statt, weil die Leute üblicherweise einen unterschiedlichen Hintergrund haben, wenn sie in das Training kommen.
Also einige machen das schon, die finden dann häufig im Detail so ein paar Erkenntnisse oder sowas.
Überraschlich, wenn ich mit Ihnen über Risikoneutralität spreche und darüber diskutiere, warum diese häufig verwendete Formel mit diesem Erwartungswert für Risiken halt 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.
Und ja, also es ist sehr, sehr unterschiedlich, was die Leute da jeweils dann individuell mitnehmen.
Magst du mal kurz sagen, wie man Risiken abschätzen kann?
Also so ein paar Methoden?
Also da gibt es, wie gesagt, die verschiedensten Herangehensweisen.
Also das eine ist natürlich, was beim Schätzen ein Klassiker ist.
Ich mache Vergleiche.
Also ich suche ähnliche Risiken raus und sage, was ist denn da?
eingetreten, was ist da passiert, wie waren da, was weiß ich, die Schadenshöhen oder sowas und stelle über den Weg relativ straightforward so einen Vergleich her.
Eine andere Geschichte, die ich sehr, sehr gerne mache, ist basiert auf der Idee, wir haben ganz, ganz häufig unvollständiges Wissen, aber wir wissen bestimmte Dinge durchaus.
Und wie kann ich jetzt aus diesen Dingen, ja, über eine strukturierte Herangehensweise, strukturiertes Überlegen, wie kann ich da 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 fünf Prozent daneben mit seinen Schätzungen, die er auf diese Weise abgegeben hat.
Und das üben wir dann beispielsweise auch mal in dem Training anhand von Beispielen, weil das, was ich als sehr, 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, also 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, sehr gut helfen.
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.
Genau.
In den heutigen Zeiten ist es ja so, dass wir in der Softwareentwicklung sehr viel mit künstlicher Intelligenz arbeiten.
Wir lassen uns Storys schreiben, wir lassen uns auch Architektur, also nochmal, 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?
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.
Also 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 Claude mal meine 35 Architecture Decision Records und frage Claude, welche Risiken habe ich übersehen?
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.
Also 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 die 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 Menschen konstruiert hat, die davon ausgehen, dass ein Computer sich deterministisch verhält.
Und diese Erwartung, die produziert ein Risikovektor, der ist immens.
Wir sind einfach nicht darauf trainiert, dass ein Computer nicht deterministisches Verhalten zeigt.
Und ich glaube, dass der Risikoraum, der da geöffnet wird, z.B.
KI in Software als Baustein einsetzen, also nicht als Bearingspartner benutzen, wie ich das gerade beschrieben habe, sondern das 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, sehr schwer abzuschätzen ist und wo ich halt auch wieder mit der Perspektive rangehen muss, in 90 Prozent oder 99 Prozent 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 Prozent eintritt.
Und dafür brauche ich wieder eine Mitigationsstrategie.
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.
Ja.
Also das würde ich unabhängig von unserer Überwachung tun.
Das macht 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 wir werden jetzt nicht an jeder Stelle einen Fallback-Mechanismus oder sowas brauchen, aber dass wir uns, wann immer wir das als Teil von Software-Architektur verwenden, dass wir 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 was, das muss man an der Stelle einfach mit auf dem Radar haben.
Genau, mit berücksichtigen, ja.
Gibt es noch etwas, was du unseren Hörerinnen mitgeben möchtest zum Thema, was wir vielleicht noch nicht angemerkt haben, was dir aber wichtig ist?
Also mir wäre es tatsächlich wichtig, dass sich mehr Menschen, die Software-Architektur-Verantwortung haben, bewusst mit dem Thema Risiken auseinandersetzen und das nicht als so nebenbei oder macht jemand anderes oder sowas sehen, sondern dass sie tatsächlich verstehen, dass wann immer wir jetzt Software-Systeme 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.
Ja, wunderbar.
Vielen Dank, Gerrit, dass ich mit dir sprechen durfte.
Klar, gerne.
Tschüss.