Alle Episoden

In dieser Folge geht es um eine zentrale Frage für den Einsatz von AI im Unternehmen:

Welche Rolle darf AI in Entscheidungen tatsächlich übernehmen?
Besonders spannend ist dabei die Trennung zwischen Entscheidung und Ausführung:

Human Decide. AI Perform.
Denn hohe Autonomie bedeutet nicht automatisch, dass AI auch die Entscheidungshoheit besitzen muss.
Aus Sicht der Enterprise Architecture reicht RAPID allein jedoch nicht aus. Zusätzlich müssen Kriterien wie Kritikalität, Risiko, Reversibilität, Datenqualität und regulatorischer Einfluss berücksichtigt werden.

Mit dieser Folge schließen wir unsere erste AI-Serie ab.
In den vergangenen Episoden haben wir den Weg von AI TCO, über AI Demand, Enterprise Architecture und Solution Architecture aufgebaut. Heute folgt der letzte Baustein: AI Governance.

AI Governance bedeutet weit mehr als Datenschutz oder Compliance. Sie schafft den organisatorischen Rahmen, damit AI-Initiativen wirtschaftlich, sicher und langfristig erfolgreich betrieben werden können.

In dieser Folge sprechen wir darüber, warum Governance bereits mit der ersten AI-Idee beginnt, weshalb klare Verantwortlichkeiten entscheidend sind und wie Enterprise Architecture, Solution Architecture und Governance gemeinsam dafür sorgen, dass AI im Unternehmen steuerbar bleibt.
Denn am Ende entscheidet...

In dieser Folge schließen wir unsere zweiteilige Serie zur AI Architecture ab.
Nachdem wir in EAM#27 die Rolle der Enterprise Architecture betrachtet haben, wechseln wir heute bewusst in die Solution Architecture.

Im Mittelpunkt stehen nicht einzelne AI-Technologien, sondern die Architekturentscheidungen, die darüber bestimmen, ob eine AI-Lösung langfristig erfolgreich betrieben werden kann.

Du erfährst, welche Bausteine eine moderne AI-Lösung besitzt, welche Aufgaben ein Solution Architect übernimmt und warum eine gute Architektur wichtiger ist als die Wahl eines bestimmten AI-Modells.
Außerdem vergleichen wir die drei führenden AI-Plattformen – ChatGPT (OpenAI), Claude (Anthropic) und Gemini (Google) – aus Sicht eines Enterprise- und Solution...

In dieser Folge beginnt der erste Teil der zweiteiligen Reihe zur AI Architecture.

Nachdem wir in den vergangenen Episoden die wirtschaftliche Bewertung von AI (EAM#25) und die Priorisierung von AI Use Cases (EAM#26) betrachtet haben, geht es heute um die strategische Einordnung von AI in die Unternehmensarchitektur.
Du erfährst, warum AI keine eigene Architekturdomäne ist, weshalb Business Capabilities und Data Entities weiterhin das Fundament bilden und welche Rolle Enterprise Architecture dabei spielt, AI-Initiativen unternehmensweit steuerbar und skalierbar zu machen.
Die technische Umsetzung folgt in der nächsten Episode aus Sicht der Solution Architecture.

Artificial Intelligence bringt Unternehmen nicht in die Situation, zu wenige Ideen zu haben – sondern zu viele. Die eigentliche Herausforderung besteht darin, die richtigen AI Use Cases auszuwählen und gezielt in diejenigen zu investieren, die den größten Business Value schaffen.

In dieser Folge betrachten wir AI Demand aus der Perspektive der Enterprise Architecture. Es geht nicht um Formulare oder Genehmigungsprozesse, sondern um eine strukturierte Bewertungsmethodik für AI Use Cases. Außerdem stelle ich das Konzept einer AI Organization und eines AI Architecture Boards vor, die Unternehmen dabei unterstützen, AI-Initiativen strategisch zu priorisieren und nachhaltig zu steuern.

Artificial Intelligence verändert nicht nur Technologien, sondern auch die wirtschaftliche Betrachtung von IT-Investitionen. Klassische TCO-Modelle reichen für AI nicht mehr aus, da neben Lizenzen und Betrieb neue Kostenarten wie Token, Modelle, APIs, Datenqualität und Governance entstehen.

In dieser Folge startet die neue AI-Serie und zeigt, warum Enterprise Architecture die entscheidende Rolle spielt, um AI wirtschaftlich, nachhaltig und mit echtem Business Value einzusetzen. Außerdem wird der Zusammenhang zu den vorherigen Episoden rund um Business Capabilities und Daten hergestellt.

Data Governance klingt oft nach Regeln, Boards, Policies und Bürokratie. Genau deshalb haben viele darauf wenig Lust.

In dieser Folge geht es darum, Data Governance pragmatisch zu betrachten: nicht als großes Framework, sondern als Arbeitsmodell für bessere Daten. Denn Datenqualität entsteht nicht zufällig. Sie braucht Verantwortung, klare Definitionen, führende Systeme, Qualitätsregeln und Entscheidungswege.

Der zentrale Punkt: Data Governance beginnt nicht mit Regeln. Sie beginnt mit Verantwortung.

Viele Unternehmen glauben, dass Daten verfügbar sind, sobald eine Schnittstelle existiert. Doch eine Schnittstelle bewegt Daten nur von A nach B. Sie macht Daten nicht automatisch verständlich, vertrauenswürdig oder wiederverwendbar.

In dieser Folge geht es um den Unterschied zwischen technischer Integration und echten Datenprodukten. Warum APIs wichtig sind, aber nicht ausreichen. Warum Datenprodukte mehr brauchen als Transport: klare Bedeutung, Qualität, Ownership, Nutzungskontext und Verantwortung.

In Folge 10 haben wir gesagt: TCO ist nicht falsch – aber oft blind. Blind wird TCO dann, wenn nur direkte Kosten betrachtet werden: Lizenz, Betrieb, Infrastruktur oder Support.

In dieser Folge übertragen wir diese Logik auf Daten.

Denn Datenkosten entstehen selten dort, wo man zuerst hinschaut. Nicht beim Storage. Nicht nur bei der Plattform. Sondern immer wieder dort, wo Daten schlecht geführt sind: bei fehlender Qualität, unklarer Ownership, doppelter Datenhaltung, schlechten Integrationen und fehlender Governance.

Wenn nicht klar ist, welche Data Entity führend ist, wer sie verantwortet und wo sie verändert werden darf, entstehen Kosten schleichend: in Projekten, Migrationen,...

Nach den Folgen rund um Business Capabilities startet mit EAM#21 eine neue Serie zum Data Layer.

Im Mittelpunkt steht die Frage, warum Daten nicht einfach der IT gehören und warum Data Entities ein zentraler Baustein moderner Enterprise Architecture sind. Wir sprechen darüber, was eine Data Entity ist, wie sie aus Business Capabilities abgeleitet wird, wie man sie sinnvoll schneidet und warum Data Ownership mehr bedeutet als technischer Systembesitz.

Außerdem geht es um regulatorische Anforderungen wie GDPR und PIPL, Datenhaltung, Verantwortung und die Frage, warum AI ohne saubere Datenbasis schnell zum Risiko wird.