Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

13.09.2006

EAM: Was die IT dazu sagt

Rainer Scheibehenne 
Enterprise Architecture Management (EAM) ist die Ausrichtung, Gestaltung und Planung der Architektur eines Unternehmens. Bei der Umsetzung kann es reichlich menscheln.
Abbildung 1: Planung der Unternehmensarchitektur über einen dreistufigen EAM-Ansatz (vereinfachte Sicht)
Abbildung 1: Planung der Unternehmensarchitektur über einen dreistufigen EAM-Ansatz (vereinfachte Sicht)

Da "Architektur" nicht nur im Bereich der IT sehr unterschiedlich definiert und interpretiert wird, ist es sinnvoll, die "Enterprise Architecture" in folgende Ebenen aufzuteilen:

l Geschäftsarchitektur unter anderem mit Prozessen, Informationsobjekten, Funktionen (Services) und Produkten,

l Informationsarchitektur mit Informationssystemen und Schnittstellen sowie

l technische Architektur mit Infrastrukturkomponenten und Plattformen.

So weit die Definition. Wie aber sieht die Einführung eines EAM aus Sicht der IT aus? Dieser Einstieg basiert auf einem dreistufigen Ansatz, der sich in einigen Unternehmen - unter anderem auch bei der WestLB - als praktikabel erwiesen hat:

1. Herstellung von Transparenz aus Sicht der IT;

2. Etablierung von Architektur-Management aus Projektsicht;

3. Einführung von Bebauungsplänen zur Herstellung eines Business-IT-Alignment.

Stufe 1 bis 3 setzen jeweils aufeinander auf, weil zum einen gerade in Stufe 1 (Transparenz) die Informationsgrundlage für die nachfolgenden Phasen gelegt wird und zum anderen mit der sukzessiven Implementierung eine Lernkurve durchschritten wird, die für die spätere Akzeptanz nötig ist.

Stufe 1: Transparenz aus Sicht der IT

Zielsetzung ist hier die Herstellung einer Übersicht über die wesentlichen, geschäftsunterstützenden IT-Elemente des Unternehmens sowie der IT-Systeme und deren Schnittstellen. Dabei werden alle in Frage kommenden Systeme und Interfaces über einen definierten Satz von Attributen erfasst (inventarisiert) und, wenn notwendig, in Zusammenhang gebracht. Die Attributanzahl sollte gerade am Anfang nicht zu hoch sein, um Erfassungs- und Pflegeaufwendungen zu reduzieren, sonst ist die Akzeptanz in Gefahr. Das methodische Framework für die Inventarisierung bildet ein klar definiertes Architekturmodell (etwa drei Ebenen), das während der gesamten Implementierung keine grundlegenden Änderungen mehr erfährt. Ab einer Anzahl von 70 bis 100 Applikationen ist der Einsatz eines Werkzeugs / Repositorys ratsam, das im Idealfall eine Architekturmethode mitbringt.

Technisch hat es sich als durchaus pragmatisch erwiesen, die Ersterfassung mit Excel-Unterstützung zu bewerkstelligen. Diese Vorgehensweise wird in vielen Unternehmen zwar negativ gesehen, kann aber mit entsprechender Vorbereitung, Kommunikation und Support schnell zum Erfolg führen. Die Excel-Sheets, deren Qualität gesichert sein muss, bilden die Grundlage des Tool-basierenden IT-Repositories.

Stufe 2: Architektur-Management aus Projektsicht

Gerade in stark IT-lastigen Unternehmen wie etwa Finanzdienstleistern oder Telekommunikationsanbietern veraltet die einmal erlangte Informationsbasis sehr schnell, bedingt durch die Vielzahl der internen IT-Projekte, die die IT-Landschaft der Unternehmen verändern. Es ist somit eine Hauptherausforderung, das Repository aktuell zu halten. Da es gerade IT-Projekte sind, die die IT-Systemlandschaft eines Unternehmens verändern, bietet es sich an, hier den Hebel anzusetzen. Planungs- und Budgetierungsprozesse sowie Projektgenehmigungsverfahren, die in jedem größeren Unternehmen etabliert sind, bieten hierfür eine hervorragende Grundlage.

Der Ansatz ist einfach: Bevor die Mittel für IT-Vorhaben oder -Programme bewilligt werden, müssen die Verantwortlichen die erwarteten Veränderungen der IT-Landschaft dokumentieren - eine Tätigkeit, die sie in verschiedensten projektinternen Dokumenten sowieso erledigen müssen. Diese Dokumentation erfolgt durch Abbildung des Ist-Zustandes (Situation vor dem Projekt) als Extrakt aus dem IT-Repository und durch die Planung des Soll-Zustandes (nach dem Projekt), idealerweise als Architekturplanung mit Hilfe des Repository-basierten Tools.

Die Beschreibung erfolgt meistens in Architekturdiagrammen. Diese enthalten neben den IT-Systemen und Schnittstellen oft auch technische und fachliche Komponenten sowie verwendete Plattformen. Die erwähnten Dokumentations- und Planungsaktivitäten können leicht in die für das Projektgeschäft typischen Aktivitäten wie Anforderungs-Management, Architekturdesign und Projektplanung integriert werden. Nebenbei beendet die Verwendung einer einheitlichen Architekturmodellierungsmethodik das Chaos an projekt- und bereichsbezogenen Architekturdokumentation und -modellen, das häufig für Projektverzögerungen und Missverständnisse in der Auslegung von Architekturdiagrammen verantwortlich war.

Die Durchsetzung dieses projektbezogenen Architekturmanagements bei Projektleitern und IT-Systemverantwortlichen ist häufig alles andere als einfach: Diese Menschen stehen häufig unter hohem Zeitdruck und haben daher wenig Zeit und Lust, Schulungs- und Lernaufwand für neue Methoden und Tools aufzubringen. Darüber hinaus müssen sie oft mit einer Vielzahl von teilweise nicht abgestimmten und Redundanzen fördernden Managementinformationswerkzeugen arbeiten. Nur durch intensive Schulung und frühzeitige Involvierung der Betreuung, verbunden mit dem "sanften Druck" seitens des IT-Managements, lässt sich die Unterstützung der IT-Verantwortlichen gewinnen und erhalten.

Stufe 3: Bebauungspläne für Business-IT-Alignments

Der Bebauungsplan hilft bei der Planung der IT-Systeme, die für das Geschäft nötig sind - basierend auf den Geschäfts- und IT-Strategien von relevanten Unternehmensbereichen. Diese strategische Architekturplanung, häufig auch als Masterplan bezeichnet, umfasst die Ausrichtung von IT-Systemen an Prozessen, Produkten und Organisationen über einen definierten Zeithorizont, oft drei Jahre. Hierbei werden Bestandteile der Geschäftsarchitektur mit Elementen der Informationsarchitektur verbunden, und damit wird das vorhandene und künftige Business-Alignment der IT dargestellt. Konkret arbeitet man mit Matrizen, auf deren Achsen zum einen Prozesse und zum anderen Produkte oder Organisationen abgebildet sind. IT-Systeme werden je nach Unterstützung in die Matrizen eingeordnet. Aus dem Unterschied zwischen den Ist- und Soll-Szenarien werden grobe Umsetzungs-Roadmaps abgeleitet, die Basis für nachfolgende IT-Budget-Planungen sind und die Grundlage für Architekturkonkretisierungen künftiger Projekte darstellen. Die Gesamtheit aller Mastermaps bildet die strategische Architekturausrichtung eines Unternehmens.

Masterplan jährlich aktualisieren

Es ist sinnvoll, die Bebauungsplanung zumindest jährlich fortzuschreiben, wobei die entsprechenden Geschäfts- und IT-Strategien selbstverständlich die Grundlage bilden. Die Bebauungsplanung integriert die noch fehlenden Komponenten der Geschäfts- in die Unternehmensarchitektur.

Die drei Stufen zur Einführung eine EAM bilden nur den Anfang und die Basis für weitere unternehmensweite Architekturaktivitäten. Exemplarisch seien genannt die Einführung von Service-orienterten Architekturen (SOA) zur Steigerung der IT-Agilität, die Integration von CMDBs zur Abbildung der physischen Anteile der IT-Architektur sowie Ableitung und Monitoring von Indikatoren für Architekturqualität. Jede der dargestellten Stufen hat ihre eigenen Herausforderungen, die oftmals "menschlicher Natur" sind. Geduld, Beharrlichkeit und die Bereitschaft zur Unterstützung auf jeder Ebene sind wichtige Erfolgskriterien.

Rainer Scheibehenne ist tätig im Geschäftsbereich IT-Strategie/Architektur/ Projektcontrolling bei der WestLB.