Enterprise Architecture wirkt.

Zwei CRM-Systeme, mehrere Marketingplattformen und Kundendaten, die überall verteilt sind. Für mich als neuen Chief Enterprise Architect bei TronicTech klingt das zunächst nach einem klaren Fall: harmonisieren! Doch die Marketingchefin hat ganz andere Probleme. Internationale Kampagnen dauern zu lange, die Übergabe von Leads an den Vertrieb funktioniert nicht durchgängig und der tatsächliche Beitrag zum Geschäftserfolg bleibt oft unklar. In der zweiten Folge unserer November-Serie begleiten wir eine B2B Customer Journey und untersuchen, welche Business Capabilities, Daten, Anwendungen und Integrationen wirklich dahinterstehen. Dabei kommen auch meine AI Agents zum Einsatz – und liefern Erkenntnisse, die meinen ursprünglichen Konsolidierungsplan ordentlich infrage stellen.

In dieser Folge stelle ich das klassische Vorgehen im Enterprise Architecture Management bewusst auf den Prüfstand. Und dafür habe ich mir etwas Besonderes überlegt: Ich übernehme als neuer Chief Enterprise Architect die fiktive TronicTech GmbH. Ein traditionsreicher Mittelständler mit 120 Jahren Unternehmensgeschichte, 850 Mitarbeitern und einer über Jahrzehnte gewachsenen IT-Landschaft.

Eine richtige Information kann zu spät kommen. In Transport und Logistik beeinflusst der Zeitpunkt einer Information, welche Entscheidungen getroffen werden können. Aus meiner EAM-Perspektive betrachte ich, wie Fähigkeiten, Daten, Ereignisse und externe Partner zusammenwirken – und was daraus für Kritikalität, Resilienz und TCO folgt. Zum Abschluss der Oktober-Serie verbinde ich Produktion, Zulieferer, internationale Märkte und Logistik: Die Methoden bleiben stabil, während das Geschäftsumfeld ihre Gewichtung verändert. Im November geht es weiter mit Journeys in unterschiedlichen Unternehmensdomänen und ihrer Verbindung zu Fähigkeiten, Daten und Anwendungen.

Internationales Geschäft verändert die Gewichtung von Architekturentscheidungen. Gemeinsame Business Capabilities treffen auf regionale Vertriebsmodelle, unterschiedliche Datenanforderungen und lokale Betriebsbedingungen. In dieser Folge betrachte ich meinen EAM-Ansatz für internationale Landschaften: von den geschäftlichen Anforderungen über Daten und Anwendungen bis zu Betriebsmodellen, Governance und TCO. Im Mittelpunkt steht die bewusste Entscheidung, welche Gemeinsamkeiten das Unternehmen braucht und welche regionalen Unterschiede sinnvoll bleiben.

Ein produzierendes Unternehmen baut selten alles selbst. Komponenten, Technologien und teilweise sogar Innovationen kommen von Zulieferern und Partnern. In dieser Folge geht es darum: - Wann wird ein Zulieferer zu einer Architekturabhängigkeit? - Warum Produktdaten nicht an der Unternehmensgrenze enden - Supplier Lock-in jenseits von Software und Cloud - Wie externe Roadmaps die eigene Zielarchitektur beeinflussen - Warum Procurement und EAM unterschiedliche Perspektiven auf dieselbe Abhängigkeit haben - Wie kritische externe Abhängigkeiten sichtbar und steuerbar werden

Nach zwei sehr AI-lastigen Monaten wechseln wir im Oktober bewusst die Perspektive und schauen uns an, wie unterschiedlich Enterprise Architecture je nach Industrie wirken muss. Zum Auftakt geht es um die **produzierende Industrie**: - Warum Business Criticality im Manufacturing sehr schnell physisch wird - Unterschiedliche Lebenszyklen von Maschinen und Software - Warum das Produkt oft der eigentliche rote Faden durch die Architektur ist - Zentrale Standards versus lokale Freiheit in einzelnen Werken - Warum Komplexität häufig mehr kostet als die eigentliche Software - Welche Rolle EAM zwischen Business, Produkt, Daten, Anwendungen und Produktion einnimmt

AI Agents werden gerne als digitale Mitarbeiter oder Kollegen bezeichnet. Sie greifen auf Daten und Systeme zu, führen Prozesse aus und treffen zunehmend operative Entscheidungen. Gleichzeitig werden sie häufig deutlich weniger konsequent geführt und kontrolliert als menschliche Mitarbeiter.

AI wird für Unternehmen umso interessanter, je besser sie Zusammenhänge versteht. Genau darin liegt aber auch die architektonische Herausforderung. In dieser Folge geht es nicht um einen neuen AI Use Case, sondern um Context: Wie aus bestehenden Daten, Applications, Abhängigkeiten, Kosten und Business-Relevanz ein neues Gesamtbild entsteht. Am Beispiel eines imaginären WHY-Buttons für eine strategische KPI schauen wir darauf, warum AI gerade dort spannend wird, wo nicht nur gerechnet, sondern Zusammenhänge erkannt, verdichtet und eingeordnet werden sollen.

AI wird zunehmend Teil von Geschäftsprozessen, Entscheidungen und Wissensarbeit. Dabei entsteht nicht nur Output, sondern auch Kontext, Historie und neues Wissen. In dieser Folge geht es um die Frage, was passiert, wenn dieses Wissen langfristig stärker an AI-Systeme, Agents oder Plattformen gebunden ist als an das Unternehmen selbst.

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.