Bisher haben wir im Rahmen der Artikelreihe „EAM für den öffentlichen Sektor“ mit der IT-Konsolidierung sowie der OZG-Umsetzung zwei mögliche Einsatzszenarien und Anknüpfungspunkte für Methoden des Enterprise Architecture Managements (EAM) vorgestellt. In diesem Artikel soll nun das Verhältnis zwischen EAM und einem projekt- und themenübergreifenden Paradigma betrachtet werden, das mittlerweile selbstverständlich auch den öffentlichen Sektor erreicht hat: Agilität bzw. agile Teams, Projekte, Organisationen, Methoden und Prinzipien.

Agile Prinzipien und EAM

2001 wurde von 17 namhaften Softwareentwicklern das sogenannte „Manifest for Agile Software Development“ (oder kurz: „Agile Manifesto“) verfasst, das bis heute als einer der wichtigsten Entwicklungsschritte der agilen Bewegung gilt. Es enthält grundlegende Feststellungen und Prinzipien, die bis heute den gemeinsamen Nenner vieler agiler Praktiken (wie z. B. Scrum) bilden. Das Agile Manifesto enthält vier zentrale Prinzipien:

- Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.

- Funktionierende Software ist wichtiger als umfassende Dokumentation.

- Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.

- Reaktion auf Veränderung ist wichtiger als das Befolgen eines Plans.

Vergleicht man diese Prinzipien mit typischen Charakteristika von EAM entsteht der Eindruck, dass EAM und agile Prinzipien nicht kompatibel sein können:

- Zentraler Gegenstand vieler EAM-Initiativen ist die Auswahl eines EAM-Werkzeugs und eine daraus folgende starke Prägung des gesamten Vorhabens sowie die Etablierung von strukturierten EAM-Prozessen zu Erstellung, Pflege, Weiterentwicklung und Nutzung der Architekturen.

- Die Planungs- und Dokumentationsfunktion ist ein zentrales Charakteristikum von EAM.

- EAM wird häufig als eine schwer zugängliche und sehr stark theorieorientierte Disziplin wahrgenommen. Die Kommunikation von EAM-Themen mit dem Management oder den Fachbereichen kann problematisch sein.

- Eines der Hauptanliegen von EAM ist die langfristige Planung und Entwicklung von Unternehmens- und IT-Architekturlandschaften.

Dazu kann man zunächst zu Recht anmerken, dass das Agile Manifesto für die Softwareentwicklung verfasst wurde und dass es von einer nach strengem Wasserfall-Vorgehen geprägten Industrie beeinflusst war, in der heutige hybride Ansätze nicht verbreitet waren. Schauen wir uns aber die agilen Werte noch einmal im Detail an – mit dem Fokus darauf, wie ein modernes EAM hierzu konform gestaltet werden kann:

- EAM sollte nicht werkzeugorientiert geplant, eingeführt oder betrieben werden. Dies würde das Risiko bergen, dass nicht die Ziele der Organisation oder die Ziele des EAM maßgeblich für die Umsetzung des EAM sind, sondern die Funktionalität und technischen Möglichkeiten des Werkzeugs. Selbstverständlich sollte EAM werkzeuggestützt betrieben werden, allerdings sollte zu keinem Zeitpunkt die Ziel- und Wertorientierung des EAM durch das geplante beziehungsweise eingesetzte Werkzeug beschnitten werden.

Für den langfristigen Mehrwert von EAM ist es selbstverständlich wichtig, dass die Architekturen und die Methode selbst auch nach der ersten Einführung gepflegt, weiterentwickelt und ausgewertet werden. Hierfür werden typischerweise EAM-Prozesse etabliert, beispielsweise um das regelmäßige Aktualisieren von Architekturinhalten oder die Bereitstellung von Informationen aus der Architektur zu verstetigen. Grundsätzlich sind derartige Prozesse auch in einem agilen Umfeld wichtig, allerdings sollte jederzeit die Möglichkeit bestehen, dass sich selbst organisierende Teams die Architekturen gemäß den aktuellen Erfordernissen ihrer Aufgabe flexibel nutzen und weiterentwickeln können, auch wenn dies nicht in den etablierten EAM-Standardprozessen abgebildet ist.

- EAM wird häufig mit einem Anspruch auf Vollständigkeit der Architekturabbildung in Verbindung gebracht, sowohl hinsichtlich des Scopes als auch in Bezug auf die abgebildeten Architekturperspektiven. Ein modernes und mit Prinzipien der Agilität konformes EAM wählt einen pragmatischeren Ansatz: Nur jene Ressourcen und Beziehungen, deren architekturbasierter Entwurf einen klaren Mehrwert für Design und Umsetzung darstellt, werden erfasst. Es wird nicht an zentraler Stelle ein umfassendes Gesamtbild dokumentiert, sondern die Architekturlandschaft wächst inkrementell durch einzelne Architekturinitiativen auf.

- Entscheidend für die Zusammenarbeit mit dem Kunden ist ein ausgeprägtes Verständnis der Architektur als gemeinsame Sprache. Daher ist von Anfang an ein Bewusstsein für die verschiedenen Anspruchsgruppen der Architektur zu schaffen. EAM darf nicht zu einer schwer zugänglichen akademischen Übung einzelner Experten werden. Sämtliche Methoden und Konstrukte sind so zu gestalten, dass diese von allen relevanten Akteuren verstanden werden. Nur dann kann EAM zur Basis einer engen Zusammenarbeit mit den verschiedenen betroffenen Stakeholdern des Kunden werden.

- Entwicklungszyklen mit den typischen Phasen der Beschreibung von Ist-Architekturen, der Entwicklung von Soll-Architekturen und der Konzeption und Umsetzung eines Transformationsvorgehens sind, wenn sie über lange Zeiträume und für große Architekturbereiche durchgeführt werden, relativ unflexibel gegenüber sich schnell ändernden Anforderungen. Die Architecture Development Method des in der Industrie weit verbreiteten EAM-Rahmenwerks TOGAF enthält ein inkrementelles Vorgehen. Wird dieses in zeitlich kurzen Zyklen und für kleine Teilbereiche der Architektur umgesetzt, ist eine hohe Anpassbarkeit an sich schnell ändernde Anforderungen möglich. Auch TOGAF-unabhängige EAM-Ansätze können die für agile Praktiken üblichen inkrementellen und kurzfristigen Entwicklungszyklen umsetzen.

Wichtig sind in diesem Zusammenhang auch die Prozesse von Veränderungs- und Konfigurationsmanagement: Aufwendige Freigabeprozesse und die Einbeziehung großer Entscheidungsgremien bremsen die Veränderbarkeit und Anpassungsfähigkeit.

Ein Ansatz fürs agiles EAM?

Der Blick auf die agilen Grundsätze und ihre Realisierungsmöglichkeiten durch EAM zeigt, dass EAM und Agilität grundsätzlich vereinbar sind. Gerade die scheinbare Widersprüchlichkeit in der Verbindung von EAM und Agilität bietet für beide Bereiche gleichzeitig Herausforderungen und Chancen. 

Der strukturierte und ganzheitliche Ansatz von EAM liefert einen Orientierungspunkt in einem agil geprägten Umfeld. Gleichzeitig können agile Methoden unflexible Prozesse, allzu langfristige Planungshorizonte sowie wenig praxisorientierte Aspekte des EAM aufbrechen. Somit können die Zielorientierung und der Mehrwert beider Methoden nachhaltig voneinander profitieren und gesteigert werden.

 

Mitautor des Beitrags ist Martin Czerwick, Consulting, Public Sector, KPMG AG Wirtschaftsprüfungsgesellschaft