3 Wege zur neuen Rolle der IT-Architektur

Eine zentral gesteuerte IT-Architektur hilft, Anwendungs- und Infrastrukturlandschaften zukunftsorientiert aufzustellen. Durch eine holistische Betrachtung der fachlichen Anforderungen der Business-Seite und eine durchgängige Unterstützung von Geschäftsprozessen durch die Anwendungslandschaft ermöglicht sie z.B. neuartige Go-To-Market-Ansätze.

Ist die Informationsarchitektur so aufgebaut, dass unterschiedliche Geschäftsbereiche nur auf einen Master-Datensatz pro Kunde zugreifen, wird ein Cross-Selling von Produkten möglich. Darüber hinaus reduziert eine zentrale Steuerung der IT-Architektur die Komplexität in Betrieb und Entwicklung von Anwendungen und spart Kosten.

Um diese Nutzeneffekte für das Unternehmen zu erzielen, muss die IT-Architekturfunktion drei Aufgaben erfüllen:

1. Es ist eine von der Anwendungsentwicklung unabhängige Governance zu etablieren

2. Für die übergreifende Architekturplanung sind Tools und Dokumentationen innerhalb eines Architekturframeworks bereitzustellen

3. Die Geschäftsbereiche sind durch Services bei IT-Architekturfragestellungen zu unterstützen

1. Architektur-Governance

Die übliche Ausgangssituation der Governance ist, dass in Unternehmen ohne fest etablierte zentrale IT-Architektursteuerung Entwickler in verschiedenen Geschäftsbereichen oder Projekten unabhängig voneinander Entscheidungen zu Anwendungsarchitekturen treffen. Diese Architekturen sind dann für den jeweiligen Zweck, nicht aber für das Gesamtunternehmen, optimiert. Daher wird eine Architektur-Governance benötigt, die einen unabhängigen Standpunkt einnimmt.

Indem unternehmensweite Architekturrichtlinien vorgegeben und übergreifende Fragen in einem Architektur-Board geklärt werden, können individuelle Architekturentscheidungen in Richtung der übergreifenden Ziele gelenkt werden. Die Einhaltung von Richtlinien wird z.B. dadurch sichergestellt, dass Projekte mit IT-Implementierungsanteil während ihrer Laufzeit zu fest vereinbarten Zeitpunkten Reviews unterzogen werden. Maßnahmen, die im Rahmen eines Reviews zwischen dem Projekt und der IT-Architekturfunktion vereinbart werden, müssen bis zur Abnahme des nächsten Projektmeilensteins umgesetzt werden.

2. Framework-Support

Der Framework-Support stellt sicher, dass die im Rahmen der Governance formulierten Architekturrichtlinien operationalisiert werden können. Die Architekturfunktion definiert ausgehend von den Richtlinien ein Framework, das auf allen Ebenen einer Architektur Tools und Dokumente enthält, die die Richtlinien konkretisieren.

Dieses Framework beginnt mit der funktionalen Ebene, setzt sich über die Anwendungs- und Informationsebenen fort und endet bei der Infrastrukturebene. Bestandteile des Frameworks auf der Anwendungsebene sind z.B. Ist- und Ziel-Landschaften und die Beschreibung des Transformationspfades dazwischen. Für die Umsetzung und Berücksichtigung des Transformationspfades innerhalb von Projekten werden konkrete, wiederverwendbare Komponenten wie z.B. Anwendungsplattformen und Datenbusse definiert. Des Weiteren umfasst die Anwendungsebene ein Inventar der Hauptanwendungen, in dem Lebenszyklen verfolgt werden. Typischerweise werden die Artefakte des Frameworks in einem zentralen Tool verwaltet.

Bestandteil des Framework-Supports ist ebenfalls ein Architektur-Planungsprozess, der eine regelmäßige Aktualisierung und Pflege des Frameworks zum Ziel hat.

3. Services

Durch das dritte Aufgabengebiet, die Services, unterstützt die Architekturfunktion Geschäftsbereiche dabei, die Governance-Kriterien einzuhalten und das Architektur-Framework anzuwenden. Denn diese nur zu kommunizieren, garantiert nicht, dass Architektur-Konzepte auch umgesetzt werden. Daher bietet die Architekturfunktion Dienstleistungen an, die von konzeptioneller Unterstützung für Geschäftsbereiche und Projekte bis hin zum Einsatz zentraler Architekturressourcen in Projekten reichen.

Herausforderungen bei Ausrichtung der IT-Architekturfunktion

Um ihre Aufgaben erfolgreich erfüllen zu können, müssen die Verantwortlichen der Architekturfunktion in den Geschäftsbereichen als Experten akzeptiert sein und guten Einblick in die Herausforderungen der einzelnen Geschäftsbereiche haben. In der Praxis ist dies schwierig, sodass Geschäftsbereiche IT-Architektur eher als hinderlich denn als vorteilhaft ansehen.

Ein Beispiel: Ein Konzern hat mehrere Geschäftsbereiche zusammengeführt. Während dieses mehrjährigen Projekts wurden früher eigenständige Architekturfunktionen der Geschäftsbereiche zentralisiert, Aufstellung und Fokus der neuen Funktion aber nicht angepasst. Die Geschäftsbereiche fühlten sich von der zentralen Funktion zu wenig unterstützt und bauten eigene Architekten auf. Dadurch verloren die Architekten der zentralen Funktion den Anschluss an die Business-Seite. Dieser Effekt verstärkte sich dadurch, dass die zentrale Funktion versuchte, durch Kontrollen entgegenzuwirken und tieferen Einblick in die Teilprojekte zu erlangen.

Gestaltungsoptionen der IT-Architekturfunktion

Um einen solchen Teufelskreis aufzubrechen, ist es sinnvoll, die Organisation der Architekturfunktion zu optimieren. Diese verfolgt drei Ziele:

• Etablierung der Architekturfunktion als wertstiftender Business-Partner

• Bereitstellung der richtigen Expertise für Projekte und Geschäftsbereiche

• Wahrung der unabhängigen Governance

Die Optimierung umfasst mehrere Aspekte, von denen wir im folgenden drei betrachten:

1. Schnittstellen zwischen Geschäftsbereich und IT-Architekturfunktion

2. Zuschnitt von Architekturdomänen und Verantwortungsbereichen

3. Organisation der IT-Architekturexperten

1. Schnittstellen zwischen Geschäftsbereich und IT-Architekturfunktion

Bei der Gestaltung der Schnittstellen zwischen Geschäftsbereich und IT-Architekturfunktion, geht es darum, Ansprechpartner für bestimmte Architekturdomänen zu definieren. Die Architekturlandschaften sind in Architekturdomänen eingeteilt. Für die Geschäftsbereiche werden die Architekturdomänen nach außen hin durch eindeutige Single Points of Contact (SPOCs) vertreten.

Geschäftsbereiche suchen in einem SPOC eine Person, die inhaltlich berät und den Governance-Prozess betreut. Z.B. bereitet dieser Ansprechpartner Reviews vor, stimmt Fragen, die während des Reviews gestellt werden, vorab mit dem Geschäftsbereich ab und begutachtet Lösungen. Dadurch werden Konfrontationen vermieden und die Reviews werden zu konstruktiven Abnahme-Terminen.

Dafür benötigt der Ansprechpartner Kenntnis über die Vorgänge im Geschäftsbereich. Für die Definition der SPOC-Rolle ist es ein entscheidender Unterschied, ob die Ansprechpartner auch für Architektur-Entscheidungen verantwortlich sind oder nicht. Koordinieren sie lediglich das Weiterleiten von Anfragen an Experten, sprechen die Geschäftsbereiche bald nur noch direkt mit den Experten. Dadurch fehlt den SPOCs der notwendige Einblick und sie können nicht vorausschauend Hilfestellung leisten oder Architekturen planen. Daher sind sie idealerweise gleichermaßen für IT-Architekturfragestellungen und für die regelmäßige Abstimmung mit dem Geschäftsbereich verantwortlich.

In dem oben zitierten Beispiel des Konzerns haben sich die Architekturansprechpartner einmal wöchentlich mit ihrem Counterpart aus dem Geschäftsbereich ausgetauscht. Der Architekturansprechpartner hat den Geschäftsbereich dabei regelmäßig über die anstehenden Projektreviews informiert, Hilfestellung geleistet und im Gegenzug Neuigkeiten aus der Projektplanung des Geschäftsbereiches erfahren.

2. Zuschnitt von Architekturdomänen und Verantwortungsbereichen

Die zweite Gestaltungsoption betrifft den Zuschnitt der Architekturdomänen, für die die eindeutigen Ansprechpartner eines Geschäftsbereichs zuständig sind. In einem idealisierten Setup orientiert sich dieser an der Wertschöpfungskette des Unternehmens. Praktisch ist ein solches Setup mitunter aufgrund unternehmenspolitischer Begebenheiten selten anzutreffen, weswegen in erster Näherung eine Orientierung der Domänen an der Linien- oder Projektorganisation sinnvoll ist. Eine an der Linie orientierte Domäne umfasst z.B. alle Finance-/Controlling-Anwendungen. Eine an einem Projekt orientierte Domäne fokussiert z.B. über alle Anwendungsbereiche hinweg auf Business-Analytics.

Die Projektorientierung empfiehlt sich nur, falls ein Unternehmen überwiegend projektgetrieben ist oder einen Transformationsprozess mit mehreren Programmen/Projekten durchläuft. Andernfalls ist es für die Stabilität der Organisation besser, Domänen entlang der Linienorganisation auszurichten, erfordert aber die Koordination domänenübergreifender Lösungen für komplexe Projekte.

3. Organisation der IT-Architektur-Experten

Drittens ist neben der Festlegung, wie SPOCs agieren und wie die Architekturdomänen zugeschnitten sind, die Organisationsform der Architekturexperten zu gestalten. Sie können fest einer Domäne zugeordnet oder Teil eines Pools sein, aus dem für Aufgaben in den Domänen Teams zusammengestellt werden. Eine feste Zuordnung führt dazu, dass Experten deutlich vertiefte Erkenntnisse erlangen, Kapazitätsschwankungen zwischen den Domänen aber schwerer auszugleichen sind. Bei einer typischerweise geringen Anzahl von Mitarbeitern ist diese Organisationsform ein Engpass.

Daher ist es sinnvoller, die Mitarbeiter poolförmig mit Zugriff durch die Ansprechpartner zu organisieren. In dem Beispiel des Konzerns wurde nach wöchentlichen Gesprächen mit den Geschäftsbereichen der Ressourcenbedarf zur Lösung von Projektfragen mit einem zentralen Poolmanagement abgestimmt. Weitere Aufgaben der Funktion, insbesondere Reviews, wurden zentral im Pool mitgeplant.

Neben diesen drei beispielhaften Aspekten sind im Rahmen der Organisationsoptimierung einer IT-Architekturfunktion weitere wie die operative Wahrung einer unabhängigen Architektur-Governance und die Zusammenarbeitsprozesse für den jeweiligen Unternehmenskontext auszugestalten.

Andreas Dietze ist Partner, Curt Cramer Projektleiter im Kompetenzzentrum InfoCom bei Roland Berger Strategy Consultants.