In den letzten Jahren sind die IT-Architekturen innerhalb von Unternehmen aufgrund einer Reihe sich entwickelnder Faktoren zunehmend komplex geworden. Unternehmen sehen sich ständigen Veränderungen in den Marktumfeldern und den Bedürfnissen der Kunden gegenüber, die häufige Verbesserungen ihrer IT-Landschaften erfordern. Darüber hinaus erfordern regulatorische Vorgaben wie die DSGVO, HIPAA, ESG und Berichtspflichten entlang der Lieferkette die Notwendigkeit neuer Funktionalitäten. Die rasante Einführung von KI- und Cloud-Technologien birgt sowohl Chancen als auch Herausforderungen, da Unternehmen neue Datenmanagement-Plattformen und KI-Modelle integrieren. Zudem verlangen wachsende Cybersecurity-Bedrohungen robuste IT-Sicherheitsmaßnahmen, was die Anzahl der bestehenden Systeme und Prozesse weiter erhöht.

Mit dieser Erweiterung der IT-Landschaften sammeln Organisationen mehr Systeme, Schnittstellen und Abhängigkeiten und fügen so kontinuierlich Komplexität hinzu.  Wenn dies nicht verwaltet wird, führt es zu höheren Aufwänden für Entwicklung und Betrieb und verlangsamt die Anpassungsfähigkeit aufgrund langer Analysezyklen für die Auswirkungen von Änderungen.

Der Aufstieg des Enterprise Architecture Management (EAM)

In der letzten Phase der schnell wachsenden IT-Komplexität (für diese Zeit) – bedingt durch den Aufstieg des Client-Server-Computings in den späten 1990er Jahren – wurde das Enterprise Architecture Management (EAM) eingeführt, das einen strukturierten Ansatz zur Aufrechterhaltung von Kohärenz, Sicherstellung von Effizienz und Risikominderung in IT-Umgebungen bietet. Traditionelles EAM legte den Schwerpunkt auf Zentralisierung, Standardisierung und langfristige Planung in Kombination mit der Konsolidierung von Plattformen und Prozessen zur Reduzierung von Komplexität. 

 Ein zentrales Repository erleichterte die Überwachung und Kontrolle über Anwendungen und Schnittstellen. IT-Roadmaps wurden für eine langfristige Implementierung entworfen, die sich über drei bis fünf Jahre erstreckte und sicherstellte, dass Änderungen sorgfältig geplant und umgesetzt wurden. Die Governance folgte einem Top-Down-Ansatz, bei dem die Einhaltung durch zentralisierte Entscheidungsstrukturen durchgesetzt wurde. Die primären Ziele waren die Optimierung der IT-Ressourcen, die Minimierung der Wartungskosten sowie die Ausrichtung der Technologie an den Geschäftsstrategien zur Förderung von Stabilität und operativer Effizienz.

Während diese traditionellen Methoden in stabilen Umgebungen effektiv waren, behinderten sie oft die Anpassungsfähigkeit, Reaktionsfähigkeit und Innovation. In der heutigen sich schnell entwickelnden Geschäftswelt benötigen Organisationen mehr Flexibilität, um wettbewerbsfähig zu bleiben und schnell auf technologische Fortschritte und Marktanforderungen zu reagieren.

Wir brauchen Architektur, kein EAM  

Um mit den steigenden Anforderungen an Schnelligkeit und Flexibilität Schritt zu halten, haben Organisationen agile Methoden, Cloud-Lösungen und Open-Source-Technologien weitgehend übernommen. Diese Ansätze fördern dezentrale Entscheidungsfindung und sich entwickelnde Architektur. Entwicklungs- oder DevOps-Teams treffen jetzt unabhängig Architekturentscheidungen, wobei oft unmittelbare funktionale Bedürfnisse über langfristige strategische Vereinheitlichung von operativer Stabilität und Effizienz priorisiert werden.

Die Verfügbarkeit von IT-Infrastruktur und Dienstleistungen in der Cloud bietet Organisationen skalierbare, bedarfsgesteuerte Ressourcen, die vom Cloud-Anbieter verwaltet werden. Somit ist die Verwendung einer bestimmten Technologie nicht mehr durch die internen Fähigkeiten und Kompetenzen einer Organisation eingeschränkt, was den Bedarf an interner Standardisierung während der Entwicklung verringert. Dies geht einher mit dem Aufstieg von Open-Source-Technologien, bei denen von der Gemeinschaft getriebene Standards organisch entstehen und nicht von der Organisation durchgesetzt werden.  

Infolgedessen hat die Bedeutung des traditionellen EAM – das oft als Elfenbeinturm angesehen wurde – abgenommen. Während agile Methoden und DevOps-Teams klare Vorteile in Bezug auf Anpassungsfähigkeit und Innovation bringen, führen sie auch zu mehreren Herausforderungen, insbesondere im großen Maßstab.

Eine der größten Herausforderungen ist die zunehmende Anzahl von Abhängigkeiten und Schnittstellen zwischen den Teams. Wenn nur einige agile Teams existieren, sind die Abhängigkeiten minimal und handhabbar, führen jedoch zu erheblichen Aufwänden, da die Geschäftsfunktionen wachsen und die Komplexität der Schnittstellen und Abhängigkeiten zwischen den Teams zunimmt. Bei starkem Fokus auf unmittelbare Geschäftsbedürfnisse könnten Teams versteckte Abhängigkeiten übersehen, was zu unerwarteten Kaskadeneffekten führt, bei denen Änderungen eines Teams an anderer Stelle Störungen verursachen. 

Eine weitere Herausforderung ist die unkontrollierte Verbreitung von Technologien über die Teams hinweg. Wenn Teams unabhängig Rahmenwerke, Werkzeuge und Technologien auswählen, entwickelt sich im Laufe der Zeit ein fragmentiertes Ökosystem. Verschiedene Teams können unterschiedliche Ansätze für dieselbe Funktionalität anwenden, wobei sie auf lokale Effizienz optimieren, aber die langfristige betriebliche Stabilität ignorieren. Während einige DevOps-Modelle vorschlagen, dass jedes Team seine eigenen Lösungen entwickeln und warten sollte, wird dieser Ansatz für mission-critical Anwendungen 24/7 unhaltbar. Im Laufe der Zeit wird es zunehmend schwierig, eine angemessene Abdeckung von Fachkenntnissen für Betrieb, Support und Entwicklung sicherzustellen. Die Pflege vielfältiger Technologiestacks erfordert ausreichende hausinterne Expertise, um kontinuierliche Unterstützung, Wartung und Evolution sicherzustellen.

Darüber hinaus steigen mit der Übernahme unterschiedlicher Technologien durch die Teams die Betriebskosten aufgrund des Bedarfs an Überwachung, Protokollierung, Sicherheitsmanagement und regelmäßigen Updates. Jede Technologiewahl fügt Komplexität hinzu, und die Gewährleistung von Sicherheit und Compliance über mehrere Lösungen hinweg erfordert erheblichen Aufwand. Ohne Governance verschärft diese unkontrollierte Technologiedurchdringung weitere Ineffizienzen und erhöht die operationellen Risiken.

Ein weiteres kritisches Problem ist die langfristige Nachhaltigkeit von sich entwickelnden Architekturen. Während agile Methoden kontinuierliche Iterationen betonen, kann häufige architektonische Umgestaltung zu Ineffizienzen führen, insbesondere wenn IT-Systeme skalieren. Im Laufe der Zeit könnten Organisationen feststellen, dass sie erhebliche Ressourcen investieren, um architektonische Inkonsistenzen im Nachhinein zu beheben, die durch einen strukturierteren Ansatz hätten gemildert werden können.

Das Gleichgewicht zwischen Agilität und operativer Stabilität ist eine große Herausforderung für Unternehmen, die sich in diesen sich entwickelnden Dynamiken bewegen. Organisationen müssen einen Weg finden, die Anpassungsfähigkeit, die agile Methoden bieten, zu nutzen, während sie architektonische Kohärenz und langfristige Effizienz aufrechterhalten.

Ein föderiertes EAM-Modell

Ein föderiertes EAM-Modell bietet einen ausgewogenen Ansatz, indem es zentrale Governance mit lokalisierter Autonomie integriert. Dieses Modell gewährleistet eine unternehmensweite architektonische Kohärenz, während es einzelnen Teams die Flexibilität bietet, Lösungen an spezifische Geschäftsbedürfnisse anzupassen.

Im Kern etabliert dieses Modell ein zentrales Team, das die Architektur im gesamten Unternehmen verwaltet. Es ist verantwortlich für die Festlegung grundlegender Prinzipien, die Definition von Governance-Strukturen und die Überwachung grundlegender unternehmensweiter Technologiestandards. Dieses Team sorgt dafür, dass kritische Aspekte wie Interoperabilität, Sicherheit und Compliance in allen Bereichen intakt bleiben, während es einzelnen Teams die Autonomie gewährt, lokale Entscheidungen zu treffen, die auf ihre Bedürfnisse zugeschnitten sind.

Gemäß den Prinzipien der schlanken Architektur werden Entscheidungen auf der niedrigsten angemessenen Ebene innerhalb der Hierarchie getroffen, sodass die Teams agil und reaktionsschnell auf unmittelbare Anforderungen bleiben können.

Anstatt starre Vorgaben durchzusetzen, fungieren zentrale Governance-Strukturen als Ermöglicher, die den Teams helfen, komplexe regulatorische und betriebliche Anforderungen zu navigieren. Regelmäßige Bewertungen und Einschätzungen halten die Architektur in Übereinstimmung mit sich entwickelnden Geschäfts- und IT-Strategien.

IT-Landschaften sind in geschäftsorientierte Bereiche strukturiert. Innerhalb jeder Domäne überwachen dedizierte Architekten die Architekturentwicklung, treffen unabhängige Entwurfsentscheidungen und bleiben dabei im Einklang mit den übergeordneten Unternehmensrichtlinien. Um die Entscheidungsfindung weiter zu dezentralisieren, kann die Verantwortung für architektonische Entscheidungen an Unterdomänen oder sogar an individuelle Teams delegiert werden, um Effizienz zu gewährleisten, ohne die Governance zu gefährden.

Das föderierte Modell betont auch strategisches domänengetriebenes Design, das sicherstellt, dass Beziehungen und Abhängigkeiten zwischen verschiedenen Domänen ausdrücklich definiert sind. Das Festlegen klarer Aufwärts- und Abwärtsverantwortlichkeiten verhindert Engpässe, ermöglicht nahtlose Interaktionen zwischen verschiedenen IT-Komponenten und minimiert Störungen.

Indem wichtige architektonische Entscheidungen aufgeschoben werden, bis dies notwendig ist (aber nicht später!), wenn ausreichend Informationen vorhanden sind, können Organisationen besser informierte Entscheidungen treffen und eine vorzeitige Standardisierung vermeiden, die später als Einschränkung erwiesen werden könnte. Dieser iterative Prozess wird durch kontinuierliche Rückkopplungsschleifen weiter verstärkt, die inkrementelle architektonische Verbesserungen unterstützen.

Transparenz ist ein weiteres kritisches Element dieses Modells. Die Dokumentation architektonischer Entscheidungen, Leistungskennzahlen und Integrationsstrategien bietet einen klaren Überblick über die IT-Landschaft und gewährleistet Konsistenz, während Raum für Flexibilität bleibt. Organisationen definieren auch Qualitätsstandards, die die evolution der Architektur leiten und ein Gleichgewicht zwischen Anpassungsfähigkeit und Kontrolle herstellen.

Durch die Implementierung dieses Modells profitieren Organisationen von einer Struktur, die Autonomie ermöglicht und gleichzeitig strategische Kohärenz aufrechterhält. Der föderierte Ansatz gewährleistet Skalierbarkeit, indem er Reibung in wachsenden IT-Landschaften minimiert, verbessert die Effizienz, indem er Redundanz und Technologiedurchdringung verhindert, und sichert die langfristige betriebliche Lebensfähigkeit, indem er architektonische Best Practices mit sich entwickelnden Geschäftsbedürfnissen integriert.

Fazit

Traditionelles EAM, mit seinem starren Planungs- und Standardisierungsfokus, hat Schwierigkeiten, sich an den schnellen technologischen Wandel anzupassen. Im Gegensatz dazu fehlt rein agilen, emergenten Architekturen die Skalierbarkeit und Governance, die für große Organisationen erforderlich sind.

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