Explorez tous les épisodes du podcast Enterprise Architecture wirkt.

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, Reports, AI Use Cases, manuellen Korrekturen und Abstimmungen.

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.

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.

Application Planning wird in vielen Unternehmen noch immer wie eine Inventarisierung betrachtet. Systeme werden dokumentiert, versioniert und bewertet, aber selten strategisch gesteuert. In dieser Folge geht es darum, warum moderne Unternehmenslandschaften mehr brauchen als Transparenz. Es geht um Portfolio-Steuerung, Zielbilder, Verantwortlichkeiten und die Fähigkeit, Komplexität aktiv beherrschbar zu machen. Denn die eigentliche Frage lautet nicht mehr, welche Systeme existieren, sondern welche davon überhaupt noch Zukunft haben.

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.

Viele Unternehmen glauben noch immer, sie kaufen Software. In Wirklichkeit kaufen sie zukünftige Architekturabhängigkeiten. In dieser Folge spreche ich darüber, warum günstige Plattformen später oft teuer werden, weshalb Integrationen und Betriebsmodelle die eigentlichen Kostentreiber sind und warum klassische Ausschreibungen häufig an fehlender Architekturtransparenz scheitern. Zusätzlich gehe ich auf die oft unsichtbaren Kosten vor dem eigentlichen Auftrag ein – aus Sicht von Dienstleistern, Architektur und Transformation.

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.

Was kostet eigentlich eine Applikation wirklich? Und noch wichtiger: Wo beginnt eine Applikation überhaupt? In dieser Folge geht es um Kostenzuordnung jenseits klassischer TCO-Sichten. Ich spreche über Shared Assets, Risiken falscher Kostenaufteilungen und warum Kostenmodelle immer auch Architekturmodelle sind. Von einfachen Umlageschlüsseln über usage-basierte Modelle bis hin zum Hybridmodell zeige ich, warum Kostenverteilung kein reines Finance-Thema ist, sondern ein zentraler Hebel für Steuerung, Transparenz und bessere Entscheidungen.

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.

Externe Schocks wie steigende Energiepreise oder geopolitische Spannungen treffen alle Unternehmen. Und trotzdem reagieren sie unterschiedlich. Warum? Weil Kosten nicht nur durch den Markt entstehen – sondern durch die eigene Architektur. In dieser Folge zeige ich dir, warum das klassische TCO-Modell zwar hilfreich ist, aber entscheidende Dinge nicht sieht. Und warum genau dort der Hebel für echte Steuerbarkeit liegt.

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.

Erst wirkt alles günstig. Projekt freigegeben. Budget passt. Und dann… wird es teuer. Nicht plötzlich. Sondern schleichend. In dieser Folge geht es darum, warum genau das immer wieder passiert und warum die Ursache nicht im System liegt, sondern in dem, was sich dahinter verändert. - Fähigkeiten - Architektur - Übergänge Wenn du verstehen willst, warum Kosten eskalieren, obwohl alles „richtig“ geplant war, dann ist das deine Folge.

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.

Du hast das System im Griff - denkst du. Doch die eigentlichen Kosten entstehen oft nicht im Betrieb, sondern im Moment der Veränderung. In dieser Folge geht es um Betriebsschulden, Lock-in und die Abhängigkeiten, die sich über Jahre aufbauen. Warum gerade moderne Cloud-Plattformen diese Dynamik verstärken und weshalb der teuerste Moment eines Systems oft erst beim Exit sichtbar wird.

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.

EAM#4 - Viele Unternehmen glauben, sie hätten ein klares Bild ihrer Kunden. Doch in der Realität existiert der Kunde oft mehrfach, im CRM, im ERP, im Commerce-System, im Support-System oder im Loyalty-Programm. Jedes dieser Systeme nutzt ein eigenes Datenmodell. Was zunächst harmlos wirkt, führt langfristig zu strukturellen Problemen: unterschiedliche Kundendefinitionen, widersprüchliche Daten und steigende Integrationskosten. In dieser Folge geht es um strukturelle Schuld im Datenmodell. Am Beispiel von Kundendaten zeige ich, warum nicht die Integration das eigentliche Problem ist, sondern die fehlende gemeinsame Struktur hinter den Daten. Denn wenn zentrale Geschäftsobjekte unterschiedlich modelliert sind, wird jede Integration, jedes Projekt und jede Entscheidung teurer.

EAM#3 Ein neues System wird eingeführt. Modern. Cloud. Event-basiert. Und trotzdem kommen Bestellungen zu spät im ERP an. Reports stimmen nicht. Daten sind inkonsistent. Schnell ist das Urteil gefällt: „Das neue System performt nicht.“ Aber oft liegt das Problem nicht im neuen System. Sondern in der gewachsenen Integrationsstrecke dazwischen. In dieser Folge geht es um Integrationsschuld – eine Form technischer Schuld, die selten sichtbar ist, aber wirtschaftlich massiv wirkt. Du erfährst: - Warum Integrationsprobleme strukturell entstehen - Woran man Integrationsschuld erkennt - Warum sie bei Plattformwechseln teuer wird - Und wie Enterprise Architecture hier echte Steuerungswirkung entfaltet Architektur entscheidet – auch zwischen den Systemen.

In dieser Episode geht es nicht um Technologie-Vergleiche, sondern um Unternehmenswirkung. Was passiert strukturell, wenn eine Commerce-Plattform – etwa von SAP zu Salesforce – abgelöst wird? Welche Datenflüsse, Verantwortlichkeiten und Prozessketten sind betroffen? Und welche versteckten Kosten entstehen durch Kopplung, technische Schuld und Vendor-Abhängigkeit? Ein Blick auf Plattformwechsel aus architektonischer und unternehmerischer Perspektive.

EAM#1: In dieser ersten Episode geht es um den Rahmen dieses Podcasts. Warum Architektur mehr ist als Technik – und warum Entscheidungen langfristige strukturelle Wirkung haben.