Alle Episoden

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.

Strategie wirkt nicht direkt auf Projekte. Strategie verändert Fähigkeiten. In dieser Folge geht es darum, warum capability-basierte Budgetierung erst dann funktioniert, wenn der Reifegrad der betroffenen Business Capabilities ehrlich bewertet wird.

Am Beispiel eines produzierenden Unternehmens wird gezeigt, warum Lieferfähigkeit, Produktionsplanung und Systemlandschaft nicht isoliert betrachtet werden dürfen. Entscheidend ist die Frage, ob eine Capability das leisten kann, was die Strategie von ihr erwartet.

Der deutschsprachige EAM Podcast, überall wo es Podcast gibt.
Freue mich auf Dein Feedback, gerne jederzeit direkt auf https://eam.podigee.io/ oder direkt www.linkedin.com/in/david-hohl

David Hohl

Möge die Enterprise Architecture mit dir sein.

Jedes Jahr investieren Unternehmen Millionen in Transformationen, Projekte und neue Technologien. Trotzdem bleibt oft unklar, welche Fähigkeiten dadurch tatsächlich verbessert werden sollen und welchen Beitrag diese Investitionen zur Unternehmensstrategie leisten.

In dieser Folge betrachten wir Capability Budgeting als Bindeglied zwischen Strategie und Umsetzung. Statt Strategien direkt in Maßnahmen und Projekte zu übersetzen, analysieren wir zunächst die betroffenen Business Capabilities, identifizieren Capability Gaps und leiten daraus gezielte Investitionen ab.

Dabei sprechen wir über Capability Based Planning, strategische Investitionssteuerung und warum Budgets künftig stärker den Fähigkeiten eines Unternehmens folgen sollten als klassischen Organisationsstrukturen.

Nachdem wir in der letzten Folge betrachtet haben, was eine Business Capability eigentlich ist, gehen wir nun einen entscheidenden Schritt weiter.

Unternehmen bestehen nicht aus isolierten Fähigkeiten. Erst wenn Fähigkeiten miteinander interagieren, Informationen austauschen und Ergebnisse weitergeben, entsteht Wertschöpfung. Genau aus diesen Beziehungen entstehen Abhängigkeiten, Komplexität und letztlich die Struktur eines Unternehmens.

In dieser Folge sprechen wir über Producer- und Consumer-Verhalten, sichtbare Abhängigkeiten, Data Entities und warum sich aus diesen Zusammenhängen die Grundlage für Architektur, Ownership und Applikationslandschaften ableiten lässt.