Um die Komplexität einer IT-Landschaft managen zu können, kommen heute vielfach IT-gestützte Werkzeuge zum Einsatz. Im Forschungsprojekt "Softwarekartographie", in dem Modelle und Methoden zur Beschreibung, Bewertung und Gestaltung von Anwendungslandschaften entwickelt werden und das am Lehrstuhl für Informatik 19 der TUM betrieben wird, werden in Zusammenarbeit mit zahlreichen Industriepartnern wie BMW Group, Deutsche Börse Systems, Deutsche Post, HVB Information Services, Münchener Rück, Siemens und T-Com existierende Darstellungen von IT-Landschaften untersucht, die auch einen Teil der Enterprise Architecture darstellen.

In einer Studie, die zwischen Januar und August des vergangenen Jahres erstellt wurde, hat der Lehrstuhl folgende Werkzeuge getestet: Adaptive EAM (Adaptive, Ltd.), planningIT (alfabet AG), ADOit (BOC GmbH), Corporate Modeler Suite & IT Architecture Accelerator (Casewise, Inc.), ARIS Toolset (IDS Scheer AG), MEGA (MEGA International SA), process4.biz (process4.biz GmbH), System Architect (Telelogic AB) und Metis (Troux Technologies, Inc.).

In dieser Studie hat die TUM gemeinsam mit den Industriepartnern zunächst einen Fragenkatalog und Szenarien entwickelt, mit denen die Eignung einzelner Werkzeuge zum Management von Enterprise Architectures untersuchen werden kann. Wesentlich für die Studie sind die je sieben Szenarien zur Analyse spezifischer Funktionalitäten und der Unterstützung von Aufgaben des Enterprise Architecture Managements.

Der Aufbau aller sieben Szenarien aus dem exemplarisch hier dargestellten Bereich ist gleichartig und besteht aus den Interessen (engl. Concerns), den daraus abgeleiteten Fragestellungen und den gewünschten Ergebnissen nach der Simulation. Das Szenario "Landscape Management" simuliert Tätigkeiten, die beim Management der Anwendungslandschaft relevant sind, und soll deren weitere Entwicklung planen. Die Interessen dieses Szenarios wurden wie folgt definiert:

Um Informationen über die weitere Entwicklung der IT-Landschaft im Werkzeug abbilden zu können, muss es möglich sein, verschiedene Varianten der Anwendungslandschaft zu pflegen, die sich aus der Ist-, mehreren Plan- und einer Soll-Landschaft zusammensetzen. Das repräsentiert den Status quo zum Betrachtungszeitpunkt: Der Plan-Zustand ergibt sich aus genehmigten und laufenden Projekten, die die Anwendungslandschaft bis zu einem bestimmten Datum verändern. Das Soll ist eine langfristige Vision, die einen idealen Ziel-Zustand widerspiegelt und sich aus Strategien ableitet.

Die Fragen, die aus den Interessen abgeleitet sind, wurden wie folgt festgelegt:

- Wie sieht die Anwendungslandschaft heute aus (Ist-Landschaft)?

- Wie wird sie im Januar 2007 aussehen (Plan-Landschaft)?

- Wie sieht das Soll aus?

- Was sind die Unterschiede zwischen der Ist- und der Plan-Landschaft im Januar 2006?

- Welches sind die Gründe, die zu den Veränderungen der Ist- zur Plan-Landschaft führen?

- Welche Projekte müssen initiiert werden, um von der Ist-Landschaft zur Soll-Landschaft zu gelangen, und entsprechen die Änderungen denen in den Plan-Landschaften?

Die Simulation dieses Szenarios verlangt also nach geeigneten Visualisierungen, um die Veränderung beschreiben zu können. Eine der prominentesten Darstellung für Anwendungslandschaften ist eine so genannte "Prozessunterstützungskarte", die auf der x-Achse die Geschäftsprozesse eines Unternehmens aufträgt und unter den Geschäftsprozessen die Anwendungssysteme positioniert, die diesen Geschäftsprozess unterstützen. Die y-Achse enthält in unserem Fall zusätzlich die Organisationseinheiten des Unternehmens, um den Einsatz unterschiedlicher Anwendungssysteme für den gleichen Geschäftsprozess in den einzelnen Organisationseinheiten zu verdeutlichen.

Die weiteren Szenarien unserer Studie beschäftigen sich mit Themen wie "Traceability and Strategy Management", in dem simuliert wird, wie Strategien mit Zielen, Projekten und Anwendungssystemen zusammenhängen, oder "Infrastructure Management", in dem der Support mehrerer relationaler Datenbank-Management-Systeme über die Zeit in Zusammenhang mit den nützlichen Anwendungssystemen gebracht wird.

Wir sehen die Enterprise Architecture als den Klebstoff zwischen verschiedenen und zumeist existierenden Management-Bereichen im Unternehmen: Das Business Process Management (BPM) modelliert die Geschäftsprozesse des Unternehmens, die von der Enterprise Architecture verwendet werden, um die Anwendungslandschaft hinsichtlich der Prozessunterstützung zu analysieren. Der IT-Betrieb interessiert sich insbesondere für verwendete Technologien, deren Verfügbarkeit, die Betriebskosten etc. Diese Informationen sind für die Enterprise Architecture relevant, um Veränderungen, die sich im IT-Betrieb ergeben, mit dem Geschäft in Beziehung zu setzen und die IT-Unterstützung zu steuern.

Die Ergebnisse der Studie wurden von uns in zwei Kiviat-Diagrammen (Spinnen-Diagramme) für jedes Werkzeug zusammengefasst; sie spiegeln dessen Fähigkeiten hinsichtlich spezifischer Funktionalität wider, beispielsweise Visualisierung, Reporting, Meta-Modellierung, Import/Export-Fähigkeiten, und Fähigkeiten hinsichtlich der Aufgabenbewältigung im Enterprise Architecture Management wie das oben skizzierte "Landscape Management".

Den Werkzeugen gemein war, dass alle über Mehrbenutzerfähigkeit verfügen und entsprechend Mechanismen für transaktionales Verhalten implementiert haben. Schwächen zeigten sich erstaunlicherweise bei der Fähigkeit, Anfragen (engl. Query) an das Repository zu stellen. Die Structured Query Language (SQL) erlaubt es beispielsweise, Ergebnisse zu aggregieren und Summen über Aggregate zu bilden. Dies wurde zum Zeitpunkt der Studie von keinem Werkzeug vollständig unterstützt, jedoch konnte beobachtet werden, dass diese Kritik von den Herstellern aufgenommen wurde und einige ihre Query-Engines gerade entsprechend erweiterten.

Hersteller reagieren auf Kritik

Hinsichtlich der Fähigkeiten, Enterprise Architectures zu visualisieren, waren die Ergebnisse der Hersteller sehr unterschiedlich: Zwar konnten die Werkzeuge viele unserer geforderten Diagramme erstellen, jedoch entsprach die gewünschte Semantik der Visualisierung nicht den Daten im Repository. Bei der oben geschilderten Prozessunterstützungskarte muss beispielsweise eine ternäre Beziehung zwischen Prozessen, Organisationseinheiten und Anwendungssystemen aufgebaut werden, um die Daten korrekt zu speichern. (Ein Ternär-System ist ein System, das drei verschiedene Werte oder Zustände annehmen kann.) Einige Werkzeuge kannten zwar die Positionierung entlang einer x- oder y-Achse, jedoch wurden im Repository einzelne Beziehungen zwischen Prozess-Anwendungssystem und Anwendungssystem-Organisation abgelegt, was zu Fehlern führt. Aber es waren auch Fortschritte erkennbar, ein namhafter Hersteller hat auch dies entsprechend in seinem Werkzeug implementiert.

Ein entscheidender Punkt bei der Auswahl eines Werkzeugs ist die gewünschte Methodik für das Enterprise Architecture Management. Einige der untersuchten Werkzeuge verfügen über eine detaillierte Methodik, die aufzeigt, welche Schritte abzuarbeiten sind, welche Modelle wie verwendet werden etc. Andere Werkzeuge bieten zwar einen größeren Freiheitsgrad, verzichten aber dabei auf eine detaillierte Methodik, die vom Anwender verlangt, entweder eine Methodik selbstständig zu entwickeln oder eine existierende Methodik, die nicht Teil des Werkzeugs ist, auszuwählen. Hier muss der Anwender entscheiden, ob die vorgegebene Methodik eines Werkzeugs für ihn passt oder ob er sich selbst eine Methodik zusammenstellt. Da es derzeit noch keine Standard-Methodik für das Enterprise Architecture Management gibt, wird sich hier in Zukunft noch einiges bewegen.

Dass der Markt für Werkzeuge des Enterprise Architecture Managements stark in Bewegung ist, war bereits während der Studienlaufzeit zu erkennen. Beispielsweise wurde Popkin von Telelogic gekauft, und das Werkzeugs Metis (ehemals Computas) wechselte zu Troux Technologies.

Auch in Zukunft befindet sich dieser Markt sicherlich noch im Wandel, was sich auch durch die Akquirierung von Mercury durch Hewlett Packard zeigt. Mercury hat in seinem Produktportfolio auch Werkzeuge, die beispielsweise das automatische Auffinden von Anwendungssystemen ermöglichen. Somit sind diese Werkzeuge als Datenlieferanten für ein umfassendes Enterprise Architecture Management von großem Interesse. Auch IBM hatte zuvor bereits Micromuse akquiriert, das im Infrastruktur-Management als interessanter Datenlieferant für das Enterprise Architecture Management angesehen werden darf.

Doch was derzeit einem umfassenden Ansatz und auch Werkzeug für das Enterprise Architecture Management entgegensteht, ist das Fehlen von klaren Schnittstellen zwischen den einzelnen Werkzeugen: Welche Daten liefert ein BPM-, welche ein Infrastrukturmanagement-und welche ein Projektportfoliomanagement-Werkzeug? Und wer hat die Hoheit über welche Daten?

Wer hat die Datenhoheit?

Interessant bleibt also, wie sich die einzelnen Werkzeuge aus unterschiedlichen Management-Bereichen weiterentwickeln werden und ob sich Integrationsansätze abzeichnen. Die Integration würde nicht nur die Datenqualität für das Enterprise Architecture Management verbessern, sondern es ebenso ermöglichen, Live-Daten auf hohen Abstraktionsebenen zu verwenden. Wäre es für Sie nicht interessant, auf einen Blick zu sehen, welche Anwendungssysteme im letzten Quartal mit welchem Erfüllungsgrad den SLAs entsprochen haben, um dies vielleicht mit einer Verrechnung auf Prozessebene zu verbinden?

Daher forscht der Lehrstuhl für Informatik 19 (sebis) weiter an diesen Themen und wird auch in Zukunft versuchen, praxisrelevante Ergebnisse zu erzielen, um das Management von Enterprise Architectures voranzubringen. Beispiele für aktuelle Themen sind die Sicht auf Enterprise Architectures, das Vorgehen bei der Etablierung und der Aufbau eines Enterprise Architecture Managements oder auch die Bewertung von Anwendungslandschaften.

Prof. Dr. Florian Matthes ist Leiter des Lehrstuhls für Informatik 19 (sebis), Technische Universität München.

André Wittenburg, ist Mitarbeiter am Lehrstuhl für Informatik 19 (sebis), Technische Universität München.