In den vergangenen Jahren sind IT-Architekturen in Unternehmen aufgrund einer Reihe sich weiterentwickelnder Faktoren zunehmend komplex geworden. Unternehmen sehen sich mit ständigen Veränderungen in Marktumfeld und in den Kundenbedürfnissen konfrontiert, die häufige Erweiterungen ihrer IT-Landschaften erforderlich machen. Zudem erzwingen regulatorische Anforderungen wie GDPR, HIPAA, ESG und Supply-Chain-Reporting die Einführung neuer Funktionalitäten. Die schnelle Einführung von KI- und Cloud-Technologien bietet sowohl Chancen als auch Herausforderungen, da Unternehmen dafür neue Datenmanagementplattformen und KI-Modelle integrieren müssen. Darüber hinaus erfordert die zunehmende Bedrohungslage im Bereich Cybersecurity robuste IT-Sicherheitsmaßnahmen, was die Anzahl an Systemen und Prozessen weiter erhöht.

Mit dieser Ausweitung der IT-Landschaften sammeln sich überall in Organisationen mehr Systeme, mehr Schnittstellen und mehr Abhängigkeiten an und erhöhen damit kontinuierlich die Komplexität. Bleibt diese unkontrolliert, führt dies zu höheren Aufwänden in Entwicklung und Betrieb und verlangsamt die Anpassungsfähigkeit aufgrund langer Analysezyklen zur Bewertung von Change-Auswirkungen.

Der Aufstieg des Enterprise Architecture Management (EAM)

In der letzten Phase rasant wachsender IT-Komplexität, ausgelöst durch den Beginn des Client-Server-Computing in den späten 1990er-Jahren, wurde das Enterprise Architecture Management (EAM) entwickelt und eingeführt. Es bot einen strukturierten Ansatz, um Kohärenz sicherzustellen, Effizienz zu steigern und Risiken in IT-Umgebungen zu reduzieren. Traditionelles EAM setzte auf Zentralisierung, Standardisierung und langfristige Planung, ergänzt durch die Konsolidierung von Plattformen und Prozessen. Alles diente dem Zweck, die IT-Komplexität wieder zu verringern.

Ein zentrales Repository ermöglichte Transparenz und Kontrolle über Anwendungen und Schnittstellen. IT-Roadmaps wurden für langfristige Zeiträume von drei bis fünf Jahren entworfen, sodass Veränderungen sorgfältig geplant und umgesetzt wurden. Die Governance folgte einem Top-down-Ansatz, bei dem die Einhaltung von Standards durch zentrale Entscheidungsstrukturen durchgesetzt wurde. Die wichtigsten Ziele waren die Optimierung von IT-Ressourcen, die Minimierung von Wartungskosten und die Ausrichtung der Technologie an der Unternehmensstrategie, um Stabilität und operative Effizienz zu fördern.

Während diese traditionellen Methoden in stabilen Umgebungen wirksam waren, behinderten sie häufig Anpassungsfähigkeit, Reaktionsgeschwindigkeit und Innovationskraft. In der immer dynamischeren Geschäftswelt der Gegenwart benötigen Organisationen aber zunehmend mehr Flexibilität, um wettbewerbsfähig zu bleiben und schnell auf technologische Fortschritte sowie Marktanforderungen reagieren zu können.

Wir brauchen Architektur, nicht EAM

Die Einführung von Agile Methoden, Cloud-Lösungen und Open-Source-Technologien waren die Methoden von vielen Organisationen, um genau auf diese steigenden Anforderungen an Geschwindigkeit und Flexibilität zu reagieren. Diese Ansätze fördern dezentrale Entscheidungsfindung und emergente Architektur. Entwicklungs- und DevOps-Teams treffen heute Architekturentscheidungen zunehmend eigenständig und priorisieren dabei häufig unmittelbare funktionale Anforderungen gegenüber einer langfristigen strategischen Ausrichtung auf operative Stabilität und Effizienz.

Die Verfügbarkeit von IT-Infrastruktur und -Services in der Cloud bietet Unternehmen skalierbare, bedarfsgerechte Ressourcen, die vom Cloud-Anbieter betrieben werden. Dadurch ist der Einsatz einer bestimmten Technologie nicht mehr durch interne Fähigkeiten und Kompetenzen begrenzt, was den Bedarf an interner Standardisierung während der Entwicklung verringert. Parallel dazu steigt die Bedeutung von Open-Source-Technologien, bei denen gemeinschaftlich entwickelte Standards sich organisch entwickeln und nicht durch die Organisation vorgegeben werden.

Infolgedessen hat die Bedeutung des traditionellen EAM – das oft als Elfenbeinturm wahrgenommen wurde – abgenommen. Während agile Methoden und DevOps-Teams klare Vorteile hinsichtlich Anpassungsfähigkeit und Innovation bieten, bringen sie gleichzeitig mehrere Herausforderungen mit sich, insbesondere wenn diese im großen Maßstab eingesetzt werden.

Eine der größten Herausforderungen ist die zunehmende Zahl an Abhängigkeiten und Schnittstellen zwischen den Teams. Existieren nur wenige agile Teams, sind Abhängigkeiten minimal und beherrschbar. Mit wachsender Zahl an Teams und geschäftlichen Funktionen steigt jedoch die Komplexität ihrer Schnittstellen deutlich an. Durch den starken Fokus auf unmittelbare geschäftliche Anforderungen übersehen Teams leicht versteckte Abhängigkeiten. Dies kann zu unerwarteten Kaskadeneffekten führen, wenn Änderungen eines Teams Störungen in anderen Bereichen auslösen.

Eine weitere Herausforderung ist die unkontrollierte Verbreitung verschiedenster Technologien durch die einzelnen Teams. Im Laufe der Zeit kann durch die Auswahl von unabhängigen Frameworks, Tools und Technologien ein fragmentiertes Ökosystem entstehen. Unterschiedliche Teams wählen für dieselbe Funktionalität unterschiedliche Ansätze – optimiert für lokale Effizienz, aber ohne Rücksicht auf langfristige operative Stabilität. Während einige DevOps-Modelle vorsehen, dass jedes Team seine eigenen Lösungen entwickelt und betreibt, ist dieser Ansatz für geschäftskritische 24/7-Anwendungen langfristig nicht tragfähig. Langfristig ist es extrem schwierig, die spezialisierten Fähigkeiten für Betrieb, Support und Weiterentwicklung innerhalb der Organisation sicherzustellen. Die Pflege vielfältiger Technologie-Stacks erfordert umfangreiche interne Expertise, um kontinuierlichen Support, Wartung und Weiterentwicklung sicherzustellen.

Zudem steigen die operativen Kosten, wenn Teams unterschiedliche Technologien einsetzen – etwa durch den zusätzlichen Aufwand im Monitoring, Logging, Sicherheitsmanagement und durch regelmäßige Updates. Im Gegensatz zum EAM Vorgehen erhöht jede Technologieentscheidung die Komplexität. Die Sicherstellung von Sicherheit und Compliance über viele Lösungen hinweg erfordert ebenfalls einen zusätzlichen erheblichen Aufwand. Ohne klare Governance verstärkt diese unkontrollierte technologische Ausbreitung Ineffizienzen und erhöht operative Risiken.

Ein weiteres kritisches Thema ist die langfristige Nachhaltigkeit emergenter Architekturen. Obwohl agile Methoden kontinuierliche Iteration betonen, kann häufiges architektonisches Refactoring bei zunehmender Systemgröße ineffizient werden. Organisationen investieren dann oft erhebliche Ressourcen, um architektonische Inkonsistenzen nachträglich zu beheben – Probleme, die durch einen strukturierteren Ansatz frühzeitig hätten verhindert werden können.

Die zentrale Herausforderung besteht darin, Agilität und operative Stabilität in Einklang zu bringen. Organisationen müssen daher Wege finden, die Anpassungsfähigkeit agiler Methoden zu nutzen und gleichzeitig architektonische Kohärenz und langfristige Effizienz sicherzustellen.

Ein föderiertes EAM-Modell

Ein föderiertes EAM-Modell bietet einen ausgewogenen Ansatz, indem es zentralisierte Governance mit lokaler Autonomie kombiniert. Dieses Modell stellt sicher, dass unternehmensweit architektonische Kohärenz gewahrt bleibt, während einzelne Teams gleichzeitig die Flexibilität haben, Lösungen auf spezifische Geschäftsbedürfnisse zuzuschneiden.

Im Kern etabliert dieses Modell ein zentrales Team, das die Architektur über die gesamte Organisation hinweg steuert. Es ist verantwortlich für die Festlegung grundlegender Prinzipien, die Definition von Governance-Strukturen sowie die Überwachung grundlegender unternehmensweiter Technologiestandards. Dieses Team stellt sicher, dass zentrale Aspekte wie Interoperabilität, Sicherheit und Compliance in allen Domänen gewährleistet bleiben.

Den einzelnen Teams wird dagegen die Autonomie gegeben, lokale Entscheidungen gemäß ihren Anforderungen zu treffen. Nach den Prinzipien schlanker Architektur werden Entscheidungen auf der jeweils niedrigsten geeigneten Ebene innerhalb der Hierarchie getroffen, sodass Teams agil bleiben und schnell auf unmittelbare Anforderungen reagieren können. Anstatt starre Vorgaben durchzusetzen, dienen zentrale Governance-Strukturen als Enabler: Sie unterstützen Teams dabei, komplexe regulatorische und operative Anforderungen zu navigieren. Regelmäßige Bewertungen und Überprüfungen stellen sicher, dass die Architektur mit den sich weiterentwickelnden Geschäfts- und IT-Strategien im Einklang bleibt.

IT-Landschaften werden nach diesem Ansatz entlang geschäftsnaher Domänen strukturiert. Innerhalb jeder Domäne überwachen dedizierte Architekten die Architekturentwicklung, treffen unabhängige Designentscheidungen und bleiben gleichzeitig mit übergreifenden Unternehmensrichtlinien abgestimmt. Um die Entscheidungsfindung weiter zu dezentralisieren, kann die Verantwortung für Architekturentscheidungen an Subdomänen oder sogar einzelne Teams delegiert werden, wenn dadurch zusätzliche Effizienz gewährleistet wird, ohne die eigene Governance zu beeinträchtigen.

Ein föderiertes Modell betont zudem strategisches Domain-driven Design, das sicherstellt, dass Beziehungen und Abhängigkeiten zwischen verschiedenen Domänen klar definiert sind. Die Festlegung eindeutiger Upstream- und Downstream-Verantwortlichkeiten verhindert Engpässe, ermöglicht nahtlose Interaktionen zwischen IT-Komponenten und minimiert Störungen.

In diesem Vorgehen können große Architekturentscheidungen bis zum notwendigen Zeitpunkt (aber nicht später!) herausgezögert werden, bis ausreichend viele Informationen vorliegen. Dadurch können Organisationen besser informierte Entscheidungen treffen und vermeiden eine verfrühte Standardisierung, die sich später als Einschränkung erweisen könnte. Dieser iterative Prozess wird durch kontinuierliche Feedbackschleifen gestärkt, die inkrementelle architektonische Verbesserungen ermöglichen.

Transparenz ist ein weiterer kritischer Aspekt dieses Modells. Die Dokumentation architektonischer Entscheidungen, Leistungskennzahlen und Integrationsstrategien schafft einen klaren Überblick über die IT-Landschaft, stellt Konsistenz sicher und lässt dennoch Raum für Flexibilität. Organisationen definieren außerdem Qualitätsstandards, die die Weiterentwicklung der Architektur leiten und ein Gleichgewicht zwischen Anpassungsfähigkeit und Kontrolle schaffen.

Durch die Implementierung dieses Modells profitieren Organisationen von einer Struktur, die Autonomie ermöglicht und gleichzeitig strategische Kohärenz sicherstellt. Der föderierte Ansatz gewährleistet Skalierbarkeit, indem er Reibungsverluste in wachsenden IT-Landschaften minimiert. Er steigert Effizienz durch die Vermeidung von Redundanzen und unkontrollierter Technologieverbreitung und sichert langfristige operative Stabilität, indem er architektonische Best Practices mit sich verändernden Geschäftsanforderungen verbindet

Fazit

Traditionelles EAM, mit seinem Fokus auf rigide Planung und Standardisierung, tut sich heute schwer damit, an schnellen technologischen Wandel zu berücksichtigen. Umgekehrt fehlt rein agilen, emergenten Architekturen die Skalierbarkeit und Governance, die große Organisationen benötigen.

Ein föderiertes EAM-Modell bietet das Beste aus beiden Welten: Es schafft ein Gleichgewicht zwischen Struktur und Agilität. Durch die Implementierung dieses Ansatzes können Organisationen IT-Komplexität effizient bewältigen, Innovation fördern und gleichzeitig langfristige Nachhaltigkeit in einem sich ständig weiterentwickelnden technologischen Umfeld sicherstellen.