Das digitale Zeitalter stellt das Management von Unternehmensarchitekturen (Enterprise Architecture Management EAM) vor neue Herausforderungen. Insbesondere agiles, inkrementelles Arbeiten, das auf adaptive, cross-funktionale Zusammenarbeit, Bottom-Up-Entscheidungen und kurze Time-to-Market-Zyklen setzt, fordert grundlegende Veränderungen beim EAM ein.

Keine Architekturarbeit mehr auf Vorrat

In vielen Unternehmen ist EAM darauf ausgerichtet, die IT-Landschaft langfristig zu optimieren. Dazu wurde der Ist-Stand erhoben, der gewünschte Soll-Stand modelliert und daraus ein Portfolio von Projekten mit jahrelanger Laufzeit abgeleitet. Umbau oder Rückbau dauern bei diesem Ansatz genauso lange wie der Aufbau. In einer Zeit jedoch, in der sich Ziele schnell ändern, ist dieses Vorgehen nicht flexibel genug und bietet somit einen begrenzten Nutzen.

Hier gilt es, EAM auf aktuelle, konkrete Problemstellungen konzentrieren. Dafür eignen sich folgende EAM-Ergebnistypen besonders gut:

• MVP Scope Diagramm: Welche Wirkung hat das Minimal Viable Product (MVP) auf Kunden, Partner, Systemlandschaft, Ökosystem? Was genau ist Teil vom MVP und was nicht? Wen betrifft die Umsetzung vom MVP?

• Business Capability Map: Welche Fähigkeiten muss das Unternehmen bis wann aufgebaut haben, damit der Business Case für die geplanten Vorhaben (agile Transformation, digitale Transformation etc.) aufgeht?

• Agile Roadmapping: Auch wenn das Projekt keinen festen Plan hat, welche Schwerpunkte werden voraussichtlich in der nächsten Kadenz oder beim nächsten Sprint bearbeitet? Wie viele Teams müssen dafür aufgesetzt werden und nach welchen Kriterien werden diese geschnitten?

• Ecosystem Diagramm: Wie sieht die Verknüpfung zu den Kunden und Lieferanten aus? Wie sieht die Customer & Partner Journey aus? Auf welchen Standards wird gearbeitet? Wie sehen die Abhängigkeiten aus?

Abstrakte Architekturprinzipien bringen agilen Teams keinen Mehrwert

EAM war nie ein Selbstläufer. Zu den "natürlichen Feinden" von EAM gehören insbesondere der lokale Gestaltungswille, unvollständige Information, nicht eindeutige Entscheidungssituationen sowie wechselnde Prioritäten und Strategien. Zudem galt EAM oft als zu abgehoben und theoretisch. Es mangelte ferner an der Fähigkeit, komplexe technische Sachverhalte in Managementsprache zu übersetzen.

Die globale Architektursicht passt nicht immer zur agilen Teamarbeit mit lokalen Bedürfnissen, situativen Entscheiden und hoher Geschwindigkeit. Globale Architekturskizzen können nicht immer in konkrete Handlungsempfehlungen übersetzt werden, die agile Teams umsetzen könnten. Die Übersetzungsarbeit ist aus zeitlichen Gründen unrealistisch.

EAM sollte sich heutzutage auf die Themen konzentrieren, die für die jeweiligen Unternehmen relevant sind. Es muss schnell und effizient Entscheidungshilfe für aufkommende Entscheidungssituationen bieten. Nur so kann EAM weiterhin ein zentrales Werkzeug der Veränderung bleiben.

Design for Change

In der Wirtschaft vollzieht sich gerade ein fundamentaler Paradigmenwechsel: der Fokus verschiebt sich weg von der Effizienz der Abwicklung und hin zur Geschwindigkeit der Veränderung. Noch vor ein paar Jahren standen folgende Themen auf der Agenda eines CIOs: Synergien, IT-Strategie, Governance, Release Management und Standardisierung. Heute beschäftigen sich Führungskräfte vielmehr mit agilem Arbeiten, Eigenverantwortung, cross-funktionaler Zusammenarbeit, Digitalisierung, loser Kopplung und Continuous Deployment.

Dieser Paradigmenwechsel ist nur teilweise im EAM angekommen. EAM muss sich diesem Veränderungsprozess anpassen und seinen Ansatz verändern:

• Collaboration statt Meldepflicht: Was schon immer nicht funktioniert hat, ist die Meldepflicht oder das Melden der Veränderungen an die EAM-Funktion innerhalb der Organisation. Hier muss eine Verschiebung von der Meldepflicht zur Collaboration stattfinden.

• Automatisierung: EAM sollte sich weg von Application Reposity in Richtung Perpetual Modeling bewegen. Automatische Discovery und Updates können hier eine große Hilfe sein.

• Neue EAM Governance: Das bisherige EAM-Governance-Model funktionierte durch Freigaben. Das widerspricht an vielen Stellen den Grundsätzen des agilen Arbeitens und verlangsamt den Lösungsentwicklungsprozess. Die neue Governance sollte dezentral aufgebaut werden und durch das Veto-Recht funktionieren.

• Fokus auf Resilience und Flexibilität und nicht auf die Vollständigkeit. Der ursprüngliche Gedanke des EAM war auf der Analogie zu Städteplanung aufgebaut. EAM hat es zum Ziel, IT-Landschaften vorausschauend und großräumig zu planen und gestalten. EAM war zentral als Stabsfunktion angedacht. Die Unternehmensarchitekten haben sich um die EAM-Pläne gekümmert und diese stets aktuell gehalten. Um das Business und die IT optimal zu unterstützen, sollte EAM sich mehr auf die Widerstandsfähigkeit und Flexibilität konzentrieren.

• Neue, menschenzentrierte EA-Frameworks: Der grundsätzliche Trend bei der EA-Modellierung bewegt sich weg von Engineering und Technik und hin zu Business, Verständnis von sozialen Systemen, Ökosystemen und Umgebungen. Eine interessante Frage wäre, ob der Mensch als solcher mit in die Modellierung aufgenommen werden soll. Die heutigen bekannten EA-Frameworks modellieren dieses Paradigma nicht explizit.

EAM organisatorisch einbetten (am Beispiel von Spotify-Modell)

In einer agilen Organisation gibt es keine Funktions-Silos mehr. Somit gibt es auch hier keinen Platz mehr für eine EAM-Stabsfunktion. Die Aufgaben und Kompetenz sind atomisiert und verteilen sich auf diverse Stellen innerhalb der Organisation um. Nichtsdestotrotz muss die Einbettung von EAM in die Lösungsentwicklung und die Entscheidungsprozesse sorgfältig konzipiert und umgesetzt werden.

Eine agile Organisation, welche dem Spotify-Modell folgt, setzt sich aus den folgenden wesentlichen Elementen zusammen:

• Squad: Kleine, selbstorganisierte, cross-funktional besetzte, agile Teams mit einer konkreten Mission. Sie entwickeln ein Produkt, Dienstleistung, Feature etc.

• Tribe: eine Gruppe von Squads, die am gleichen Produkt oder Service bzw. an miteinander in Verbindung stehenden Produkten oder Services arbeiten.

• Chapter: besteht aus den Mitgliedern mehrerer Squads (innerhalb eines Tribe), die über dieselbe Expertise verfügen. Ein Chapter ähnelt einem Fachgebiet, wie beispielsweise Qualitätsmanagement, Testautomatisierung etc.

• Guild: ist eine Gruppe von Menschen mit demselben Fachwissen oder gleichen Interessen. Guilds beschränken sich nicht auf einen Tribe, sondern beziehen die gesamte Organisation mit ein.

So kann beispielsweise EAM als eine EA-Gilde umgesetzt werden. Dies bietet einige Vorteile:

• Weniger Management durch Pläne, Vorgaben und Konzepte, sondern mehr Beeinflussung durch Normen, Werte und Zusammenarbeit.

• EAM als Mindset in der gesamten Organisation verankern.

• Soft Power: dezentrale Entscheidungsfindung, Befähigen zu lokalen Entscheidungen unter Einhaltung vorherrschender Standards, Architekturentscheide so spät wie möglich treffen.

• Die Architektur-Funktion ist Teil des Entwicklungsprozesses und nicht ein Außenstehender. (jd)