EAM#30: AI Decision Rights - Wie viel darf AI entscheiden?

00:00:04: Architektur entscheidet.

00:00:06: Über Komplexität, über Kosten, über Steuerbarkeit.

00:00:09: Ich bin David Hohl und heiße Dich herzlich willkommen.

00:00:12: bei Enterprise-Architektura wirkt der Podcast zu ERM.

00:00:20: Servus grüßt Dich und herzlich Willkommen zur neuen Folge.

00:00:24: Bevor wir heute einsteigen möchte ich kurz mal zurück schauen.

00:00:30: Wir sind jetzt bei der Folge dreißig.

00:00:32: Ich habe jetzt mal nachgezählt und habe mir eine ganze Statistik durchforstet.

00:00:38: Und mit der Folge neunundzwanzig habe ich in Summe knappe zwölf Stunden, genau zu seinen zwölch stunden einundzwanzig Minuten und viervierziesekunden aufgenommen was schon noch eine ganze Menge an Stoff ist.

00:00:54: Wenn ich mir anschaue wie rüber wir diese zwölfe Stunden gesprochen haben dann ist eigentlich eine ziemlich klare Linien stangen, ohne dass es wirklich beabsichtigt war um recht zu sein.

00:01:07: Wir haben eigentlich am Anfang oder ich aber weil wir am Anfang mehr über technische Schulden und den Total-Cost of Ownership gesprochen, weil ich eigentlich die Intention hatte einfach darüber mal zu sprechen über die Sachen, die man sonst nicht liest oder spricht oder... Man eigentlich nur indirekt danach in Erfahrung bekommt.

00:01:26: Darüber ... warum eine technische Entscheidung heute kostenlos erzeugen kann.

00:01:33: Und die wir erst die Jahre später natürlich erst wirklich sehen, das waren auch noch ein wichtiger Teilaspekt der letzten Folgen.

00:01:43: und dann war halt so in Schwank Richtung Business Architektur.

00:01:47: Wir haben halt sehr viel über Business Capability gesprochen also für mich persönlich immer Ein emotionales Thema ist, weil es mich so viele Jahre jetzt einfach schon beschäftigt.

00:01:58: Und natürlich auch die nachfolgende Aktivitäten von Maturity Level, Priorisierungen

00:02:06: etc.,

00:02:07: auch wie man Strategien überhaupt richtig runterbrechen kann in die Architektur und damit arbeiten kann.

00:02:14: Und dann sind wir... Was haben wir da eigentlich gemacht?

00:02:17: Ja genau!

00:02:18: Dann kann man eine Daten noch und vor allem die Data Entities als ausfachliche Datentöpfe, dann haben wir über Data-Tisio gesprochen und die Kosten halt hinter Daten eigentlich entstehen.

00:02:33: Hier habe ich ein Datenprodukt der sich hier noch Data Governance gesprochen wie wichtig das ist.

00:02:39: und Data Governances... Ich glaube es findet immer jeder vor.

00:02:46: Es ist auch im Endeffekt kein Rocket-Sign, aber es ist sehr wichtig für jede Aktivität sobald um IT-Applikationen geht.

00:02:56: Damit haben wir eine wichtige Ebene erreicht, denn nicht nur Anwendungen und Technologien erzeugen Abhängigkeit, sondern die Daten dahinter.

00:03:11: Wenn ich mir die letzten Folgen angeschaut habe... jetzt laut meiner Statistik ganz schön erfolgreich waren, von der Zuhörerschaft vielen Dank auch fürs zuhören und fürs Rheinsnicken habe ich gemerkt halt dass der Trendsetter EI einfach zieht um das noch immer sehr viele Unstimmigkeiten geht wo die Reise hingeht.

00:03:35: Und ja im August haben wir uns halt über EITSO, EIDemend um eher Architektur und deren Agents dahinter und vor allem die Governance unterhalten.

00:03:48: Nicht ganz so tief, wie ich eigentlich gehofft habe.

00:03:50: im Nachgang aber ich denke das eine oder andere haben wir anderer essen können und hat uns danach ja natürlich in ein gewisses Sicht auf neue Technologien gebracht und für mich ist ehein nichts anderes als eine Technologie die wir aktuell einsetzen.

00:04:05: Gerade natürlich auch in meinem Berufsumfeld habe ich natürlich gerade mit solchen Fragen, die ich auch im letzten Monat probiert habe zu beantworten immer wieder zum Tun.

00:04:16: und dabei kommt halt immer wieder die Herausforderung auf wie bringen wir EI kontrollieren die Architektur?

00:04:25: Gerade slurschen Architekturen haben extremer Auswirkungen, sobald EI-Aktivitäten stattfinden und dementsprechend sind Systemarchitektur auch oft gefährdert.

00:04:37: Und dem nehme ich mich natürlich auch an – und das ist eine wichtige Herausforderung!

00:04:42: Dazu muss sich natürlich auch in der Tiefes sehr tiefes Verständnis haben wie EI agiert und wie man damit am besten umgeht.

00:04:50: Ich rede jetzt nicht von Entwicklung als solches sondern einfach um den gesamten Naja, und ein Frame.

00:04:56: Und deswegen habe ich mir eigentlich gedacht... Auch wenn es gegen Prinzipien verstoßt, die ich mir gesetzt habe für diese Podcaste entweder als Architektur wirkt, dass ich halt jedes Monat ein neues Thema aufgreife, das sich den September einer Sache widme, die mir selbst im Endeffekt auch immer tagtäglich unterkommt und ich dir natürlich jetzt so'n bisschen Meine Welter darin auch schildern möchte, wie ich damit aktuell umgehe.

00:05:26: Wir kommen halt an einen Punkt, in dem Enderbausarchitektur definiert werden muss wo EI unterstützen darf und wo EIs entscheiden darf.

00:05:38: Und wo bewusst ein Mensch verantwortlich bleiben muss.

00:05:44: Genau deshalb bleiben wir auch im September nochmals bei EI Aber mit einem anderen Schwerpunkt.

00:05:53: Wenn es dich erinnert, wenn du dabei warst im August haben wir halt mit den ersten Folgen gerade um Kosten gesprochen, Eidemand, Architektur, Agent & Governance nebenbei.

00:06:04: ich habe Im Anfang August ein Enterprise-Architektur Operation Model für EI auf LinkedIn veröffentlicht.

00:06:14: Es ist noch nicht ganz sauber definiert, aber bringt große Grundzüge.

00:06:18: was ich vor dem ich gesprochen habe und die Septemberfolge zahlt da nochmal drauf ein denn das Ding hat einen Marke sag' ich mal Und zwar geht es halt darum um die Verantwortung und Entscheidungsrechte und die Grenzen dahinter.

00:06:36: Verstehen wir nicht falsch?

00:06:36: Nicht als büchelogische Ehe-Debatte, das fangen wir uns sicher nicht an.

00:06:40: Außer dann debattieren kann ich damit mir selber und sicher fangen mal zu uns auch keine Ethik-Serie an.

00:06:46: Wobei das für mich persönlich... schon sehr spannend wäre, aber ich glaube da war ja ein Counter-Bad der mir bisschen den Stoff dagegen schießt.

00:06:56: Sondern wir schauen uns eigentlich aus anderes an und zwar auf der praktischen Sicht... ...aus der Enterprise-Sachrichtur.

00:07:01: und vor allem halt welche Rolle darf EI in einem Operationen Model tatsächlich übernehmen?

00:07:06: Und genau dann möchte ich mit etwas beginnen das eigentlich überhaupt nichts mit der EI Welt zum tun hat!

00:07:15: Wir reden über etwas was kennst du?

00:07:18: wahrscheinlich aus anderen Kontext und ich probiere es jetzt ein bisschen so verbinden.

00:07:21: Und zwar geht's um das Racki- und das Rapid-Modell, genau!

00:07:25: Denn vielleicht brauchen wir gar keine kompletten neue Modelle für unsere AI Operation Models?

00:07:30: Vielleicht können wir das nutzen was wir schon kennen und auch in der Vergangenheit sehr zielführend war.

00:07:37: Vielleicht müssen wir zunächst nur sehr sauber definieren welche bestehende Entscheidungsrollen wir überhaupt zugestehen wollen und welche eben nicht.

00:07:53: stelle dir ein klassisches Architektchaport vor.

00:07:58: Wer es nicht kennt, das ist im Endeffekt ein Art Kremium von lauter Architekten.

00:08:02: die haben sich einmal die Woche zusammen und entscheiden gemeinsam welche Decision Records angenommen werden welcher verschoben werden oder halt gekänzelt werden.

00:08:14: Es geht um eine wichtige Entscheidung oder Architekto-Entscheidung vielleicht sogar auch um die Ablöse eines Zentralesystems eine neue Plattform oder vielleicht für mir ein Service, das ist eigentlich gar egal.

00:08:29: Oder vielleicht sogar eine grundlegende Technologieentscheidung.

00:08:34: und stellen wir uns weiter vor an unserem virtuellen Tisch da sitzen einen Enterprise-Architekt, verschiedene Solution Architekten jemals von der Security, vielleicht auch ein Business Owner, jeweils von einem Procurement und wenn man Glück hat einer von der Operation Und jeder bringt halt seinen Blickwinkel ein und das geht ja eigentlich bei solchen Boards, nicht wahr?

00:08:55: Und jetzt sitzt da plötzlich noch jemand am Tisch.

00:08:59: Der sitzt eigentlich nicht da sondern der ist im Computer irgendwo drinnen.

00:09:02: Wobei wenn man virtuell zusammensitzt dann sitzen wir alle im Computer wenn was genau nimmt.

00:09:06: Also lassen Sie uns nicht jetzt physiologisch abdriften.

00:09:12: Wir reden halt klassisch um die EI hier jetzt.

00:09:15: Denken wir mal... Was ist auch jemand der dran

00:09:18: sitzt?!

00:09:19: Nicht physisch natürlich, aber die EI hat vielleicht sämtliche ADS anders schon vorab analysiert.

00:09:25: Sie kennt unsere Landschaft in und auswendig.

00:09:29: Life-Cycle Management das was wir im Endeffekt auch mehr vergessen.

00:09:33: Kennt das Ding Und ja Dokumulation hat es aus einem FF und wahrscheinlich und da nehme ich mich einfach mal raus von vor glaube ich Kennts Kennt die EI aktuell schon unsere gesamte Systemarchitektur mehr und tiefer und fragmentierter als jeder Mensch in dieser Runde?

00:09:55: Dann stellt man sich natürlich eine Frage.

00:09:59: Was machen wir da noch, wenn das Ding alles besser kann?

00:10:03: Aber ich frage mich jetzt aus dem Protokoll.

00:10:06: Wir stellen uns eine andere Frage.

00:10:08: Welche Stimme bekommt EI eigentlich an diesem Tisch?

00:10:13: Ich habe mir diese Frage letztens gestellt und ich habe wirklich die Intention gehabt, ja als eigener Architekten mit an Sport zu holen um in den Fakt auch ins Gespräch einsteigen zu können.

00:10:26: Also es ist schon ein bisschen sehr spooky um herzusehen.

00:10:29: aber zurück zum Punkt was darf sie jetzt?

00:10:33: Darf sie nur Informationen liefern?

00:10:36: darf sie Empfehlungen sogar aussprechen oder vielleicht sogar Entscheidungen vorbereiten?

00:10:41: oder noch für das schlimme Entscheidungen treffen oder worst case scenario Entscheidung treffen und durchführen?

00:10:51: genau darüber möchte ich heute mit dir sprechen.

00:10:56: Und halt nicht darüber ob e.i.

00:10:58: Menschen ersetzen.

00:11:00: das lassen wir wirklich mal aus und vor.

00:11:02: Wir sind noch bald genug entscheiden oder Beweisen so Sondern ob er irgendwann mal intelligenter sein wird als wir.

00:11:14: Das wird auch wahrscheinlich passieren und ist wahrscheinlich sogar der Fall, wobei Intelligenz immer so ein auch noch psychologisches Thema ist.

00:11:23: Aber vor allem sondern über die wesentlichen praktischen Fragen der Architektur Entscheidungsrechte bekommt.

00:11:32: So darüber reden wir heute!

00:11:35: Let's go!

00:11:40: Kapitel eins wird diskutieren heute mal über EI aber nicht über die Rolle.

00:11:49: zunehmend zum Teil von den Unternehmensentscheidungen.

00:11:52: Kennst du wahrscheinlich?

00:11:53: Du hast halt irgendeinen Bedarf und dann lasst es mal durch deinem ganzen System durchrattern, auf einmal gibt's da im Endeffekt verschiedene Optionen auf was du alles machen kannst oder was nicht machen kannst.

00:12:04: Und somit nimmt diese digitale Software schon eine Rolle ein.

00:12:08: Ob es jetzt möchtest oder nicht.

00:12:10: Bevor wir da ein bisschen tiefer einsteigen... Gehen wir nochmal ganz kurz zurück bezüglich Rollendiffinierung.

00:12:16: Ich kann mir erinnern, wie haben wir mal in den Folgen davor?

00:12:18: Habe ich mal öfters gesprochen und würde gerne über Rollen sprechen.

00:12:21: Ich lasse das jetzt mal außen vor sondern eigentlich so ein bisschen wie man zu Entscheidungen kommt.

00:12:27: Das haben wir ja auch schon in der einen oder anderen Serie gesprochen.

00:12:30: aber wenn man es aus der Architektur spricht dann habe ich natürlich Architecture Boards, ich hab Governance Regeln, Approve Prozesse... Und ich hab Rollenmodelle um im Endeffekt mein Racki anzuwenden, dass meine ADS halt verschiedene Risken und Acceptance-Kretärin gerecht werden.

00:12:52: Und wir definieren dann halt ziemlich genau was wir machen.

00:12:59: Was macht man natürlich?

00:13:00: Wer liefert welche Informationen?

00:13:02: Was muss konsoliert werden... Wer gibt halt die Empfehlungen am Schluss des Tages ab?

00:13:09: Ist der solutionen Architekt, ist der Enterprise-Archidektor oder wer auch immer?

00:13:12: und dann im Schluß wer stimmt denn zu?

00:13:16: muss jetzt jeder nicken oder noch einer?

00:13:18: Und wer entscheidet.

00:13:21: Und natürlich danach ja wer setzt das im schluss ober?

00:13:23: weil dass man das mal Naja es ist eher all demal da ist Teil von unserer Architektoerbordrunde geworden und fragt mir natürlich was kann das Ding jetzt für uns machen?

00:13:35: Ich finde, das ist vielleicht die falsche Ausgangsfrage.

00:13:38: Wir sollten uns eher darum beschäftigen, dass es möglicherweise wirklich technische Entscheidungen treffen sollte und das bedeutet natürlich nicht, dass wir das Entscheidungsrecht übertragen sollten.

00:13:52: Entscheidungen treffen und Entscheidungsrechte sind zwei Paar Schuhe für mich, vielleicht das mal klarzustellen.

00:13:57: aber genauso falsch finde ich allerdings... Diese Gegenposition, er darf halt niemals entscheiden.

00:14:03: Warum eigentlich nicht?

00:14:04: Warum darfst du nicht entscheiden?

00:14:06: Wenn eine Entscheidung klar geregelt und vollständig nachvollziehbar ist und vor allem risikoarm ist... ...und jederzeit rückgängig gemacht werden kann, könnte ihr ja möglicherweise sogar besser und konsistenter entscheiden als jeder Mensch.

00:14:20: Ein Beispiel wo ich es denke macht Sinn.

00:14:23: Nehmen wir mal so ein Technologie Lifecycle Manage wenn das super boring ist.

00:14:27: Wir haben halt jede Menge Applikationen im Haus oder auch in einer Delivery laufen und eine bestimmte Runtime hat halt seinen End-of-Support erreicht.

00:14:37: Und die Regeln sind natürlich definiert durch uns, und die Abhängigkeiten sind hoffentlich dokumentierter und die Lifecycle Information hat vorhanden.

00:14:50: Muss wirklich ein Enterprise Architekt dreihundert Einträge einzeln durchgehen?

00:14:54: Wahrscheinlich nicht!

00:14:57: Machst du

00:14:57: das?!

00:14:58: Wahrscheinlich nicht.

00:14:59: Wahrscheinlich geht es nur auf Triggerpunkte ein und das war's!

00:15:04: Und ich finde schon, dass da ihr alle könntet einem Counterpart werden oder das Ganze mit analysieren.

00:15:09: Sie könnte daraus auch Präosierungen aufbauen was wir im Endeffekt jetzt als nächster angestoßen werden müssten und vor allem halt die Entscheidung getroffen werden kann.

00:15:24: diese Applikation wird nächstes Jahr einfach stillgelegt.

00:15:28: Da wird es dann plötzlich ein bisschen schwieriger, weil sobald diese Entscheidung getroffen worden ist und jetzt das Entscheidungsrecht in der Stelle ist.

00:15:37: Dann hat es natürlich ein Business Impact vor allem auch aufs Budget und wahrscheinlich sind auch strategische Elemente davon betroffen und organisatorischer Abhängigkeiten sowieso.

00:15:47: Ich glaube, wenn ich darüber nachdenke damit reicht es halt einfach nicht mit dieser Unterscheidung.

00:15:53: Darf EI was oder darf's nicht?

00:15:55: Wir brauchen eine feine Betrachtung und darüber reden wir heute ein bisschen mehr.

00:16:04: Kapitel zwei Rapid.

00:16:06: Welche Rolle darf EI in Entscheidungen wirklich annehmen?

00:16:11: Wenn wir darüber sprechen wie weit EI den Entscheidungen eingreifen darf brauchen wir zunächst ein Modell das Entscheidungsrollen voneinander trennt.

00:16:20: Dafür finde ich Rapid recht interessant mit recommend and equip perform input und decide.

00:16:26: Und aber nicht weil Rapid für er entwickelt wurde, sondern weil wir damit ziemlich konkret prüfen können welche dieser Rollen wir eine EI tatsächlich geben wollen.

00:16:40: Wenn man es anschaut als e-arrow with recommend bei recommend sehe ich halt ein großes Potential.

00:16:46: EI könnte halt nicht einfach nur festlegen, hier sind sieben und zwanzig Applikationen mit Lifecycle Risiko sondern darüber hinaus Ableitungen für uns machen.

00:16:55: Mit zum Beispiel auf Basis von Business Criticality, Kosten- und Lifecycle und vor allem Abhängigkeiten würde ich dieses Sieben zuerst betrachten.

00:17:03: Somit liefert EI mal nicht nur Daten, sondern bereits eine begründete Empfehlung.

00:17:09: die Entscheidung bleibt aber trotzdem bei Menschen.

00:17:13: wenn man das A nimmt das Equie, bei Equi wird es bis zu kritischer wie ich finde.

00:17:19: Hier geht es um einen Umzustimmung oder auch darum eine Entscheidung zu blockieren.

00:17:26: Nehmen wir eine Abweichung von einem Architekturstandard.

00:17:31: EI könnte sehr gut prüfen ob definierte Kriterien erfüllt sind aber darf sie daraus auch ableiten.

00:17:38: diese Abweicherung wird akzeptiert.

00:17:41: Damit geben wir ja bereits eine Governance und Kontrollfunktion, was ich nicht so cool finde.

00:17:47: P. Perform.

00:17:50: Perform finde ich gerade bei Agents besonders spannend.

00:17:53: EI muss halt nicht selbst entscheiden um sehr autonom zu sein, um ehrlich zu sein.

00:17:58: Im Mensch entscheidet beispielsweise.

00:18:01: diese vierzig Applikationen müssen bewertet werden.

00:18:04: Ein Agent könnte Anschließende Informationen zusammen tragen, Analysen durchführen und vielleicht sogar auch gleichzeitig Task erzeugen.

00:18:16: Verantwortliche kontaktieren und ihr Erlaubnis... ...erlaubnisblödsinn um Ergebnisse zusammenzuführen!

00:18:23: Also Human Decide, ja Perform, das könnte ein guter Grundsatz werden.

00:18:30: Entscheidungshoheit oder operative Autonomie sind für mich einfach zwei unterschiedlichen Dinge.

00:18:35: so sollen sie auch behandelt werden EI oder Input.

00:18:40: Bei Input dürften die Schwellen für die Rolle natürlich extrem niedriger liegen, denn EI kann Kosten, Lifecycle Datenabhängigkeiten und so weiter zusammentragen und vor allem kann sie etwas was wir nicht so gut sind und zwar verdichten.

00:19:01: also das auf den Punkt zu bringen.

00:19:04: Dabei entscheidet es eigentlich gar nichts, sie schafft einfach nur eine bessere Grundlage für unsere Entscheidungen.

00:19:10: Und gerade in der Enterprise-Architektur dürfte das einer der Bereiche sein wo ich schon denke da ist er jetzt schon sehr gut unterwegs und sollte eine komplette Daseinsberechtigung bekommen Die, die seid.

00:19:27: und dann kommen wir da schon natürlich bei etwas rein wo es sehr unangenehm wird darf er ja tatsächlich Architektur Entscheidungen treffen.

00:19:38: Ich finde halt klar bei definierten und Risikoarmen und bei Entscheidungen die man auch rückgängig machen könnte möglicherweise Charme oder vielleicht, naja das kommt halt wirklich auf den Bereich an bei strategischen Plattformentscheidungen oder der regulatorischen, relevanten Ausnahmen.

00:19:57: Ich glaube da würde ich schon relativ stark die Grenzen sehen im Unternehmen und sagen so weit nicht.

00:20:04: Und ja genau hier zeigt sich eigentlich die Grenze von Rapid für mich auf.

00:20:11: Das Modell hilft uns das zu beschreiben.

00:20:14: halt welche Rolle EA innerhalb einer Entscheidung übernimmt.

00:20:18: Es beantwortet aber etwas Wichtiges halt nicht, ich hoffe du hörst das auch ein bisschen raus.

00:20:23: Unter welchen Bedingungen darf EI diese Rolle überhaupt übernehmen?

00:20:27: Und dafür brauchen wir einfach eine zweite Schicht.

00:20:35: Kapitel drei Nicht jede Entscheidung ist halt gleich.

00:20:39: Der zuverlässige Entscheidungs Spielraum für EA sollte nicht von der Technologie abhängig sein, sondern von der Art und Tragweite der Entscheidung.

00:20:48: Also wie weit hat das Endeffekt Auswirkungen auf uns Unternehmen?

00:20:54: Ich würde da vielleicht in unterschiedlichen Dimensionen denken.

00:21:00: Unterteilen einmal der Business Impact, was passiert wenn eine Entscheidung falsch ist.

00:21:06: Eine automatisch falsche klassifizierte Architekturipositäre Item ist natürlich unangenehm aber eine falsche Entscheidung über eine geschäftskritische Plattform.

00:21:15: das hat ganz andere Dimensionen also der Business impact.

00:21:18: da muss man natürlich sehr vorsichtig.

00:21:20: seine Finder sollte ja überhaupt kein Entscheidungsraum haben.

00:21:24: Der zweite Dimension die ich Mal für mich gefunden und definiert habe ist einfach die Rückgängigkeit, also dass ich etwas rückgängig mache.

00:21:34: Ich hab es Reservability genannt kann ich die Entscheidung einfach zurücknehmen.

00:21:39: Das halte ich eigentlich schon für extrem wichtig.

00:21:42: wenn ihr eine falsche Jarotask von mir erstellt dann kann ich ihn lösen.

00:21:47: Wenn ihr eine Falschklassifizierung erzeugt dann kann das auch korrigieren.

00:21:55: Wenn er aber eine strategische Wendauentscheidung trifft.

00:21:58: Das würde ein bisschen schwierig, das wieder rückgängig zu machen und ich glaube da müsste man schon klar den Card setzen.

00:22:05: deswegen die Dimension zwei ist ein bisschen offener und gibt mir Möglichkeiten EI einzusetzen.

00:22:12: Die dritte und letzte Dimension die für mich definiert habe ist Decision Complexity Und damit meine ich jetzt nicht die technische Komplexität.

00:22:21: Verstehen wir nicht falsch Eine EI kann technisch sehr komplexe Dinge hervorragend analysieren, wie ich finde.

00:22:27: Also ich nutze es ja auch tagtäglich.

00:22:32: Sie kann halt technisch das hervorragen für mich einfach analysieren und die Menge an Kontexten, die außerhalb der verfügbaren Daten liegt sind natürlich da auch enorm Und ich finde, gerade kann es für mich auch sehr gut analysieren.

00:22:50: Was ist der bessere TCO?

00:22:52: Welche Funktionen passen besser fürs Unternehmen?

00:22:54: Gerade diese Ableitung, Application Capabilities und dann was Business Capabilities?

00:23:00: Und danach welcher Wendor passen da am besten?

00:23:04: also von meiner Art und Weise ist grad dieses... Wenn man diese Komplexität dahinter sieht wenn die geringe... Also die Komplexidät jetzt von diesen Annahmen sehr hoch ist Ja, natürlich im extremen Mehrwert und man können alle davon profitieren.

00:23:21: Aber je mehr nicht dokumentiert ist und wenigstrategischer, organisatorischer Kontext vorhanden ist umso schwieriger wird eigentlich das und um so weniger darf man EI einsetzen weil es dann natürlich einen falschen Kontext und ein falschen Blick hat für diese Wendauentscheidung.

00:23:50: Wenn ich mir jetzt zurückdenke, wie wir heute mal in der Früh dieses Kapitel erstellt haben.

00:23:57: Ich habe lange gebraucht im Endeffekt um mich da die Kernbotschaft für dich herauskitzeln weil das ist nicht ganz einfach zu beantworten Es gibt Bereiche in der Enterprise Sache, in denen mehr EI Autonomie nicht nur vertretbar sondern zielvoll sein kann.

00:24:20: Das steht jetzt mal aus der Frage, das ist mir extrem wichtig.

00:24:25: Ich möchte nicht bei EI berät einen Menschenentscheiden enden und das wäre einfach ein bisschen zu simpel.

00:24:38: Einmal ein Beispiel wenn wir so eine Architektur Repository anschauen die EI erkennt halt etwas Das eine Applikation ist seit sechs Monaten oder was ich sieben Monaten einfach nicht mehr aktiv und der Kontext, der Life Cycle fehlt.

00:24:57: Es gibt auch kein Ohne im Unternehmen das jetzt auch nichts Neues ist, es gibt sehr häufig leider nicht.

00:25:04: Eine andere Applikierung deckt dieselben Capable-Bildes ab darüber haben wir auch schon mal gesprochen kommt auch sehr häufig vor.

00:25:11: hier kann Ja, ist ja weitgehend wie ich finde.

00:25:14: Gerade dieses Input Recommand Performance Richtung Rapid noch mal zurückgehen vielleicht sogar bestimmte Änderungen automatisiert durchführen wenn Regeln klar definiert worden sind.

00:25:27: Ein zweites Beispiel was ich auch gefunden habe für mich wäre dann hier noch Standards und Compliance.

00:25:39: Nehmen wir mal an, ein solution nach architecture wird gegen definierte Architekturstandards geprüft.

00:25:48: Viele Architekten haben nebenbei immer diese Herausforderungen.

00:25:52: Sie machen solution-Architekten auf, probieren halt die Vergangenheit aus der Erfahrung mit reinzubringen, nach einem gewissen neuen Prinzip in sich auszurichten und vergessen halt oft die Standards, die im Projekt oder im Unternehmen vielleicht definiert worden sind.

00:26:07: Da ist natürlich auch ja eigentlich recht spannend wenn Erkennt, was ich durch zwei Standards erfüllt.

00:26:14: Eines ist kritisch und da hast du kommen die Abwächung drin und warum hast Du die abwächungen gemacht?

00:26:19: Und das danach halt zurückzuschicken und dieses Review im Endeffekt zu gerade beim Architekt-Sport zu beschleunigen.

00:26:29: Somit hat das aber keine wilden... Da sind keine wilde Entscheidungen dahinter sondern es entscheidet ja nur darauf hin was produziert worden ist.

00:26:37: macht das Sinn?

00:26:38: macht das nicht Sinn?

00:26:41: Ja, genau.

00:26:46: Probieren wir noch ein anderes Beispiel rauszuziehen.

00:26:49: Richtung Target Architecture kommt sich auch bei deinem Umfeld sehr häufig vor.

00:26:54: soll unsere zukünftige Customer Architecture zentralisiert oder stärker dezentralisiert aufgebaut werden?

00:27:02: also ich bin ein zentranisierter Fan was gerade Customer Architecture angeht.

00:27:06: aber es gibt auch viele Anwendungsfälle wo's decentralized angenehmer ist.

00:27:12: wie auch immer, auch wieder Erfahrungsstaats.

00:27:15: Aber auch hier kann halt AI klare Szenarien erzeugen und die Dependency ist dahinter analysieren und vor allem den TCO vergleichen.

00:27:24: Und wenn man halt weitergeht bis runter halt vielleicht sogar Windows Strategien aufbauen und welche Business Direction wir halt eingehen... ...und hier sehe ich halt AI wirklich sehr stark bei gerade das Input and Recommand.

00:27:40: aber vor allem wo man wo es nicht gut ist, ist dann natürlich halt beteiligt.

00:27:45: Somit gibt's halt auf diese Kapitelfrage die ich vorhin gestellt habe keine klare Antwort.

00:27:53: Es kommt immer auf das jeweilige... ...auf den Kontext drauf an.

00:28:10: Hier würde ich bewusst gegen beide Extreme argumentieren.

00:28:14: also Ein Extrem ist halt, was ich eher heute auf niemals Entscheidungen treffen.

00:28:22: Ich habe es schon vor ein bisschen angeträgert das halte ich für langfristig sehr unrealistisch.

00:28:28: wenn wir jede Triwale und Entscheidungen die regelbasiert sind, die halt rückgängig gemacht werden kann abweiser und weiterhin von Menschen freigeben machen kann, dann schaffen wir uns lediglich einen neuen Governance-Bottleneck.

00:28:44: und das wollen wir eigentlich gerade eh sowieso alle nicht.

00:28:46: Und ich finde du...das ist halt genau das was ich vorhin gemeint habe.

00:28:50: Kann EI schon eine komplette Rolle übernehmen und auch Entscheidungen treffen?

00:28:54: Aber es gibt natürlich wieder eine extreme auf der anderen Seite.

00:28:58: EI kann das besser also lassen wir lieber die Entscheidung.

00:29:02: Das find' ich extrem problematisch.

00:29:05: Gerade diese Analysequalität halt nicht Kleidung in Entscheidungsverantwortlichkeit.

00:29:12: Also eine EI kann möglicherweise die beste technische Option identifizieren, Check und das bedeutet aber für mich heute noch lange nicht dass es automatisch diese Option die richtige fürs Unternehmen ist weil das hat verschiedenste Kontext und ich finde da kommt halt natürlich auch etwas anderes rein der menschliche Gedanke.

00:29:34: Unternehmen sind vom Menschen geführt und Entscheidungen sind manchmal vielleicht nicht so ganz plausibel.

00:29:40: Und EI kann das halt nicht eins zu eins entscheiden und mitnehmen, weil oft halt auch Menschen davon betroffen sind durch diese Entscheidung und Persönlichkeiten und Rollen und Herzblut etc.

00:29:51: Davon hat das Ding ja keine Ahnung.

00:29:53: Ich komme nochmal kurz zur dieser Frage, was ich bei Kapitel IV gestellt habe.

00:29:58: die eigentliche Aufgabe Also Enterprise Architektur sollte deshalb nicht jeden AI-UseCase einzeln danach bewerten, darf man AI einsetzen?

00:30:08: ja nein.

00:30:09: Sondern wie viel Entscheidungsrecht geben wir dieser AI Capability und warum?

00:30:18: Das könnte zukünftig sogar Bestandteil sein einer AI Capacity oder eines Architecture Decision Prozesses.

00:30:30: Wer wird der EI folgende Rolle bekommen, dass es halt nicht nach Rapid läuft sondern das ist input recommend agree decide und perform läuft.

00:30:43: Also das ist die Rolle also ein bisschen anders.

00:30:45: wie immer das Rapid sich anschaut wenn man zum Beispiel bei Business Impact anschaut dass man definiert von low bis high ... oder die von Einsetzbarkeit, ... ... diese Rolle vielleicht so erklärt ist.

00:31:05: Das hast du im Kontext nicht.

00:31:06: Also jetzt gerade ein bisschen Durchgift für mich im Kopf ist,... ... wo setze ich es am besten ein und wo kriege ich mehr Entscheidungsrechte?

00:31:15: Also beim Business Impact würde ich sagen Low bis High... ... und das gibt's halt da verschiedene Abgrenzungen bei der Reverseability vom High.

00:31:27: kann man auf jeden Fall einsetzen bis halt zu low.

00:31:30: Bei Decision Context ist es halt abhängig vom Kontext natürlich und vor der Strategie, daraus lassen sich dann verschiedene Handlungsspielräume finde ich ableiten und definieren.

00:31:42: Da ist jetzt nichts Falsches dran.

00:31:48: Kapitel six was bedeutet das für einen CIO?

00:31:55: Der bin ich nicht aber kein einiger für die.

00:31:59: oder vielleicht bist du auch einer, der COO muss nicht jede Entscheidung kontrollieren finde ich.

00:32:06: Aber er sollte... Oder sie sollte... Also das ist ein bisschen bescheuert zum Geschlecht her aber er sollte sicherstellen dass das Unternehmen bewusst entscheidet also aus der Unternehmenssicht und welche Entscheidungsrechte es delegiert.

00:32:26: Das ist für für mich der Unterschied zwischen EI einsetzen und EI insvisionalisieren.

00:32:34: Wenn irgendwann hundert EI Kapabilites und Agents im Unternehmen existieren, reicht es halt nicht zu wissen wir haben zweihundert siebzehn EI-Huskäse.

00:32:44: was hier oben möchte ich natürlich etwas anderes wissen.

00:32:47: welche davon informieren?

00:32:48: nur?

00:32:49: Welche geben Empfehlungen Welche treffen von mir aus Entscheidungen?

00:32:54: Welche führen selbstständige Aktionen aus.

00:32:57: Aber vor allem interessiert mich dann, wo haben wir ihr Entscheidungsrechte gegeben, deren Auswirkungen geschäftskritisch sind?

00:33:06: und dass immer halt bei diesem Punkt.

00:33:07: das gehört aus meiner Sicht irgendwann genau in die Enterprise-Architektur.

00:33:12: wie halt Business Criticality, Life Cycle and Data oder halt Data Criticality.

00:33:18: also wir werden uns da nicht rauswenden können.

00:33:25: Da sind wir auch wieder beim Ende angekommen.

00:33:27: Wir diskutieren momentan einfach viel zuviel, was er alles kann und was es vielleicht können muss.

00:33:34: Vielleicht sollten wir uns auch mal eine andere Frage stellen gerade aus der Architektur Was davon wollen wir ihr eigentlich entscheiden lassen?

00:33:44: Und halt wie in dieser Folge darüber gesprochen das nicht jede Entscheidung braucht ist wirklich ein Menschen Aber auch nicht jede Entscheidung sollte von der EI delegiert werden.

00:33:57: Die Aufgabe von der Enterprise-Architektur ist deshalb aus meiner Sicht nicht, die EI möglichst stark einzuschränken aber vor allem auch nicht möglichst viel zu viel zu automatisieren.

00:34:11: Die Aufgabe ist die richtige Entscheidungsspielraum zu definieren.

00:34:15: also wir sind da wieder im Governance Bereich angekommen.

00:34:18: vielleicht hilft es uns dafür sogar unser allbekantes Rapid-Modell zu nutzen.

00:34:24: Nur kommt jetzt eine neue Rolle mit an den Tisch und das ist halt AI, wir müssen entscheiden welche Stimme sie bekommt.

00:34:33: Folge einunddreißig.

00:34:34: also.

00:34:35: in der nächsten werden wir uns genau darüber auch beschäftigen weil es fehlt mir etwas Wichtiges und zwar Denn bevor ihr ja analysieren empfehlen oder entscheiden kann, braucht es sie halt Informationen und genau daran steht möglicherweise ein viel größeres Problem.

00:34:52: Wir brauchen data leaks verbindende finance customers tracking bla bla bla brauchen all diese informationen natürlich in Unternehmen um sich mit einer anderen zu verknüpfen Und dann geben wir auf einmal Zugriff darauf.

00:35:05: die Frage, die dann in der Folge natürlich beantworten wollen ist.

00:35:11: Was darf EAE eigentlich über unsere Unternehmen wirklich wissen?

00:35:15: Und ich finde das sehr spannend denn vielleicht liegt... Das ist hier das größte Risiko in der Enterprise-Archivatur mit EAE und was wir den mal nicht geben und was mir eher nicht geben sollten!

00:35:27: Servus und Papa bis auf bald.