Transparenz durch EAM-Tools

Management und CIOs dürfen IT nicht isoliert von Geschäftsprozessen, Geschäftszielen und StrategienStrategien betrachten. Ziel des Enterprise Architecture Managements (EAM) ist es deshalb, die gesamte Architektur zu dokumentieren, ihre Entwicklung zu steuern sowie die Planung zu unterstützen, um schließlich ein "Alignment" von Business und IT zu erreichen. EAM-Tools helfen dabei, Prozesse und Architekturen zu modellieren. Zwar gibt es schon viele davon, doch fehlt bisher noch ein qualifizierter Überblick über ihre Fähigkeiten. Alles zu Strategien auf CIO.de

Diese Lücke haben Professor Florian Matthes vom Lehrstuhl für Informatik an der Technischen Universität (TU) München und seine Wissenschaftler erkannt und widmen sich mit der Studie "Enterprise Architecture Management Tool Survey 2005" ausführlich diesem Thema. Um möglichst realitätsnahe Ergebnisse zu erzielen, wurden renommierte Unternehmen wie BMW, Deutsche Post, HVB Systems, T-Com und Münchener Rück hinzugezogen, was laut Matthes ein qualitativ hohes Niveau garantiert: „Unsere Studie ist eine unabhängige Analyse der zurzeit im Markt angebotenen Lösungen.“ Die Anforderungen an EAM sind in zweierlei Hinsicht umfassend. Zum einen muss die komplette Anwendungslandschaft abgebildet werden – oft handelt es sich um mehrere hundert Anwendungen auf verschiedenen Plattformen. Zum anderen ist die Organisation des Unternehmens abzubilden.

Die wichtigsten Datenlieferanten

Dabei reicht es nicht aus, die Daten ad hoc zu sammeln und zu speichern. Denn in dynamischen Systemen sind diese oft kurz nach ihrer Erfassung nicht mehr aktuell und würden zu falschen Analysen führen. Erschwerend kommt hinzu, dass auf unterschiedliche Informationsquellen zugegriffen werden muss. Ein großer Teil davon ist in den meisten Organisationen bereits in Subsystemen vorhanden. Laut der Studie kommen folgende fünf Datenlieferanten in Betracht:

– Informationen über Geschäftsprozesse, Prozessfluss und Prozessschritte liefern Prozessmodellierungs- Tools wie Aris (IDS Scheer),Corporate Modeler (Casewise) oder Mega Process (Mega).

– Informationen über Applikationen, deren Komponenten sowie Schnittstellen stellen Modellierungswerkzeuge wie Rational Rose (IBMIBM) oder Together Control (Borland) zur Verfügung.

– Daten über Service Level Architecture, Service Level Agreements und Service-Nutzer sind verfügbar in den Datenbanken gängiger Frameworks wie ITILITIL oder dem MicrosoftMicrosoft Operations Framework.

– Im Bereich System- und Asset-Management lagern Daten über Betriebssysteme, Anwendungen, Hardware und NetzwerkeNetzwerke. Quellen hierfür sind Tools wie Open View (HPHP), Tivoli (IBM) oder SMS (Microsoft).

– Informationen über Projektplanung und Business IntelligenceBusiness Intelligence können abgefragt werden aus Anwendungen wie SAPSAP Business Warehouse oder Microsoft Project. Alles zu Business Intelligence auf CIO.de Alles zu HP auf CIO.de Alles zu IBM auf CIO.de Alles zu ITIL auf CIO.de Alles zu Microsoft auf CIO.de Alles zu Netzwerke auf CIO.de Alles zu SAP auf CIO.de

Mathes hat seine Evaluierung bewusst nicht in Form eines Rankings verfasst. Stattdessen zeigt er in Scorecards Stärken und Schwächen einzelner Werkzeuge auf. Für jedes Tool wurden zwei Netzdiagramme erstellt, aus denen auf Skalen von null bis fünf die Bewertung in verschiedenen Einzeldisziplinen herauszulesen ist. Dabei bildet das erste Diagramm die Aspekte der Tool-Funktionalität ab, das zweite die Beurteilung im Bereich EA-Management- Aufgaben. Die Wissenschaftler raten bei der Wahl eines EAM-Tools folgende Punkte:

a) Anzahl der Stakeholder und Rollen der Stakeholder

b) Anzahl der Informationsgeber und Rollen der Informationsgeber im Unternehmen

c) Gewünschte Aktualität der Informationen

d) Grad der benötigten Flexibilität des Werkzeugs

Zu a: Die Stakeholder (Interessenvertreter) der Enterprise Architecture nehmen eine besondere Rolle ein, da sie die Nutznießer sind und mit den Daten arbeiten. Sie legen fest, welche Informationen benötigt werden und welche Funktionalitäten das Werkzeug bereitstellen muss.

Zu b: Den größten Aufwand müssen die Informationsgeber leisten, daher sollte man sie frühzeitig in den Aufbau eines EAM-Prozesses einbeziehen. Informationsgeber, die gleichzeitig in der Rolle des Stakeholders auftreten, erkennen den Mehrwert von EAM am besten und bringen ein besseres Verständnis für dessen Notwendigkeit auf.

Zu c: Aus der Zahl der Informationsgeber und dem gewünschten Grad der Aktualität der Informationen lässt sich der Aufwand für die Dokumentation der Unternehmensarchitektur abschätzen. Kontinuierliche Planungsprozesse, die beispielsweise quartalsweise Informationen zur Validierung der Zielsetzung benötigen, erfordern ein höheres Maß an Aktualität als ein jährlicher Abstimmungsprozess.

Zu d: Flexibilität erlaubt dem Anwender einen persönlichen Zuschnitt des Modells. Diese Flexibilität kann aber zu einem unzureichend definierten Metamodell führen, was nachträgliche Anpassungen und inkonsistente Datenstände zur Folge hat.

Abschließend beleuchtet die Studie Besonderheiten und Schwächen der getesteten Tools. So vermissen die Informatiker beispielsweise ein standardisiertes Schema für den Datenaustausch – jedes Produkt besitzt ein individuelles Import- und Export-Konzept. Um der Forderung nach hoher Datenaktualität gerecht zu werden, sollte ein EAM-Tool zudem Möglichkeiten der verteilten Dateneingabe von unterschiedlichsten Arbeitsplätzen bieten.

Die Autoren kritisieren an den Workflow- und Collaboration- Funktionen, dass sie bei manchen der Tools unzureichend sind. Als ungenügend bezeichnen sie überdies die eingeschränkten Visualisierungsmöglichkeiten. Zwar lassen sich aus den Daten in der Regel Diagramme erstellen, den meisten getesteten Produkten fehlen aber Funktionen, um beispielsweise mit Attributen die Position oder das Layout einer Form zu verändern.

Kritisch äußern sich die Autoren schließlich auch noch zum mangelnden Interesse der Business-Bereiche am Thema EAM. „Bisher befassen sich hauptsächlich IT-Abteilungen mit der Unternehmensarchitektur – und dabei ist es das Business, das das Geld verdient und Waren verkauft, während die IT lediglich Teile dieser Einnahmen dafür aufwendet, um dem Geschäft zu mehr Effizienz zu verhelfen.“ Die Business-Bereiche, so das Fazit, sollten sich im eigenen Interesse aktiver als bisher am Enterprise-Architecture-Management-Prozess beteiligen.