In Unternehmen können mehrere tausend Anwendungssysteme im Einsatz sein, deren Gesamtheit inklusive ihrer Verbindungen als Anwendungslandschaft bezeichnet wird. Die einzelnen Systeme existieren nicht zum Selbstzweck; sie unterstützen Geschäftsprozesse, sodass die Beziehung zwischen den betrieblichen Systemen und den Geschäftsprozessen, den produzierten Gütern etc. eine wichtige Information darstellt. Ändert sich ein Geschäftsprozess, so ist häufig auch die unterstützende Software zu adaptieren. Wird ein neues Produkt eingeführt, so ist oftmals eine neue Applikation zu bauen, oder ein existierende muss erweitert werden.

Doch die Informationen über die Beziehungen zwischen Systemen, Produkten und Geschäftsprozessen reichen nicht aus, um eine Anwendungslandschaft zu steuern. Von der Informationstechnologie (IT) wird verlangt, möglichst flexibel auf Änderungen zu reagieren und trotz hoher Flexibilität stets effizient und effektiv zu sein - dies sowohl im Hinblick auf Kosten als auch auf die angebotene Funktionalität. Soll diese Forderung nach Flexibilität bei hoher Effizienz und Effektivität erreicht werden, so bedarf es einer Betrachtung des gesamten Unternehmens inklusive seiner Strategien und Ziele.

Diese Verbindungen zwischen den verschiedensten Elementen in einem Unternehmen bildet die Dokumentation der Enterprise Architecture (Unternehmensarchitektur) ab. An der Technischen Universität München (TUM) verstehen wir die Dokumentation der Enterprise Architecture als modellhafte, kohärente und ganzheitliche Abbildung des Unternehmens, die nicht nur die Informationstechnologie, sondern ebenso betriebswirtschaftliche Elemente umfasst. Die Dokumentation beinhaltet dabei nicht nur die einzelnen Elemente der Unternehmung selbst, wie beispielsweise die Organisationsstruktur, die Geschäftsprozesse, die Anwendungen und die Infrastrukturelemente, sondern ebenso ihre Verbindungen und Querschnittselemente, wie Strategien und Ziele, Projekte und Programme, Architekturen und Richtlinien sowie Kennzahlen und Metriken.

Um die Enterprise Architecture sinnvoll zu verwenden, bedarf es zusätzlich eines Prozesses: des Enterprise Architecture Managements (EAM). Dieser kontinuierliche und iterative Prozess soll die existierende und geplante IT-Unterstützung in einem Unternehmen kontrollieren und verbessern. Ziel ist eine von Geschäft und IT gemeinsame Vision, die dazu dient, die gegenseitige Ausrichtung von Geschäft und IT zu optimieren.

Werkzeuge für das Enterprise Architecture Management

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 entwickeln werden und das am Lehrstuhl für Informatik 19 der TUM durchgeführt wird, werden in Zusammenarbeit mit zahlreichen Industriepartnern wie BMW Group, Deutsche Börse Systems, Deutsche Post, HVB Information Services, Münchener Rück, Siemens, T-Com existierende Darstellungen von IT-Landschaften untersucht, die auch einen Teil der Enterprise Architecture darstellen. Einige der untersuchten Darstellungen werden aus Mangel an geeigneten Werkzeugen zur Erzeugung der Visualisierungen manuell oder semi-automatisch erstellt und gepflegt.

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 Szenarios 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 zur Analyse der Unterstützung von Aufgaben des Enterprise Architecture Managements. Diese Szenarios wurden in Kooperation mit unseren Industriepartnern entwickelt und von Mitarbeitern des Lehrstuhls im Labor simuliert und evaluiert mit dem Ziel, zu detaillierten Aussagen über die Werkzeuge zu gelangen.

Da sich die Dokumentation der einzelnen Szenarien in der 338 Seiten langen und in englischer Sprache verfassten Studie über 34 Seiten erstreckt, wird an dieser Stelle nur ein wesentliches Szenario aus dem Bereich Aufgaben des Enterprise Architecture Mangement mit dem Namen "Landscape Management" vorgestellt. Der Aufbau aller sieben Szenarien aus diesem Bereich ist gleichartig und besteht aus den Interessen (engl. Concerns), den aus den Interessen 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 (siehe Kasten: SoKaKauf).

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-Managements-Systeme über die Zeit in Zusammenhang mit den nützlichen Anwendungssystemen gebracht wird.

Da sich das Enterprise Architecture Management in zahlreiche Aufgabenbereiche zergliedert, ist die entscheidende Frage, auf welchem Detailniveau die Elemente in der Enterprise Architecture aufgenommen werden. Ein Anwendungssystem wird sicherlich nicht auf der Ebene von Methodensignaturen, wie es in UML der Fall ist, analysiert, sondern lediglich auf einer abstrakten Architekturebene, die es erlaubt, die Fragen, die beim Management der Enterprise Architecture auftreten, zu beantworten. Dies kann sich beispielsweise auch auf die verwendete Softwarearchitektur und die verwendeten Middleware-Technologien beziehen, da diese Fragestellungen in einem Gesamtkontext der Anwendungslandschaft beispielsweise auch IT-Strategien hinsichtlich der zu verwendenden Technologien beeinflussen.

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.

Ergebnisse der Studie

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.

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 obigen 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 verschiedenen 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 durchzuführen 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 selbsrstä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, sind klare Schnittstellen zwischen den einzelnen Werkzeugen: Welche Daten liefert ein BPM-Werkzeug, welche ein Infrastrukturmanagementwerkzeug und welche ein Projektportfoliomanagementwerkzeug? Und wer hat die Hoheit über welche Daten?

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, Life-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.

In einer Studie der Technischen Unviversität München wurden im vergangenen Jahr folgende Tools für das Enterprise Architecture Management (EAM) untersucht. 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.).