Enterprise Architecture wirkt.

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 nicht das beste AI-Modell über den Erfolg einer AI-Initiative – sondern die Fähigkeit eines Unternehmens, AI verantwortungsvoll einzusetzen.

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 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.

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.

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.

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.

Zum Start des Capability-Monats beschäftigen wir uns mit einer der grundlegendsten Fragen der Business Architecture: Was ist eine Business Capability eigentlich wirklich? Anhand eines einfachen Beispiels aus dem Alltag entwickeln wir Schritt für Schritt ein Verständnis dafür, warum Fähigkeiten deutlich stabiler sind als Prozesse, Organisationsstrukturen oder Technologien. Von dort schlagen wir die Brücke in die Unternehmenswelt und betrachten, warum Strategie, Transformation und Steuerung letztlich immer auf Fähigkeiten wirken. Die Folge bildet die Grundlage für die kommenden Episoden rund um Capability Mapping, Producer-Consumer-Beziehungen, Budgetierung, Reifegrade und das BDA Capability Model.

Viele Unternehmen kennen ihre Systeme. Aber nur wenige verstehen ihre tatsächlichen Abhängigkeiten, Kostenwirkungen und organisatorischen Folgen. In dieser Folge spreche ich darüber, warum klassische Portfolio-Bereinigung oft scheitert, weshalb Komplexität nicht durch Tooling verschwindet und warum echte Transparenz der wichtigste Hebel für bessere Entscheidungen ist. Denn Portfolio Management ist aus meiner Sicht keine Inventur. Sondern aktive Unternehmenssteuerung.

Run und Change werden in vielen Unternehmen getrennt geplant, getrennt budgetiert und getrennt gesteuert. Oft wirkt das logisch – erzeugt aber genau dadurch neue Kosten, Zielkonflikte und strukturelle Spannungen. In dieser Folge schaue ich darauf, warum diese Trennung häufig selbst Teil des Problems ist und wie Enterprise Architecture helfen kann, Betrieb und Veränderung neu zusammenzuführen. Es geht um Steuerungslogik statt Budgetlogik. Um Capabilities als gemeinsames Bezugsobjekt. Um Architektur als dritte Steuerungsebene zwischen Betrieb und Projektwelt. Und darum, was Architektur möglich macht, wenn sie nicht nur beschreibt, sondern wirklich wirkt.

Controlling misst Kosten. Architektur versteht ihre Wirkung. In dieser Folge geht es um den grundlegenden Unterschied zwischen beiden Perspektiven und warum genau daraus falsche Entscheidungen entstehen. Du erfährst, wie Jahresbudgets Verhalten beeinflussen, warum „Budget muss weg“ echte Kostentreiber erzeugt und weshalb deine Roadmap immer zwischen kurzfristigem Druck und langfristiger Stabilität steht.

Betriebskosten steigen. Und meistens suchen wir die Ursache an der falschen Stelle. Ich zeige dir in dieser Folge, warum steigende Run-Kosten selten durch ineffiziente Prozesse entstehen, sondern durch strukturelle Entscheidungen in der Architektur. Du erfährst, wie Komplexität über Zeit wächst, warum ESM und ITIL oft nur Symptome sichtbar machen und weshalb echte Kostentreiber in Übergängen, Abhängigkeiten und fehlender Klarheit liegen.

Du kennst deine IT-Kosten. Du hast vielleicht sogar ein sauberes TCO-Modell. Und trotzdem kannst du oft nicht sicher entscheiden. In dieser Special-Folge gehen wir einen Schritt zurück und schauen uns an, wie TCO überhaupt entstanden ist – und warum es bis heute so stark genutzt wird. Gleichzeitig wird klar: Das Modell ist nicht falsch. Aber es zeigt nur einen Teil der Realität.

EAM#5 - Customization wirkt oft wie eine schnelle Lösung. Ein zusätzliches Feld, ein neuer Workflow oder eine kleine Erweiterung und der Prozess passt perfekt zum Unternehmen. Doch über Jahre entfernen solche Anpassungen Systeme immer weiter vom Standard. Was kurzfristig sinnvoll wirkt, kann langfristig zu einer strukturellen technischen Schuld werden. In dieser Folge schauen wir uns an, wie Customization entsteht, warum sie häufig auf Ebene der Business Architecture beginnt und welche wirtschaftlichen Auswirkungen sie auf die Fähigkeiten eines Unternehmens hat.