Embed Size (px)
Citation preview
Westfälische Wilhelms-Universität Münster
Ausarbeitung
Enterprise Architecture Management
im Rahmen des Seminars Software Management
Stephan Schneider
Themensteller: Prof. Dr. Herbert Kuchen
Betreuer: Dipl.-Medienwiss. Susanne Gruttmann
Institut für Wirtschaftsinformatik
Praktische Informatik in der Wirtschaft
II
Inhaltsverzeichnis
1 Einführung ................................................................................................................. 3
2 Enterprise Architecture Management ........................................................................ 4
2.1 Definitionen und Abgrenzung ............................................................................ 4
2.2 Architekturpyramide .......................................................................................... 5
2.3 Management der Unternehmensarchitektur ....................................................... 7
2.4 Motivation und Ziele ........................................................................................ 10
3 Enterprise Architecture Management Tools ............................................................ 11
3.1 Voraussetzungen für die Tool-Unterstützung von EAM ................................. 11
3.2 Prozessabdeckung und Funktionen eines EAM-Tools .................................... 13
3.3 Marktübersicht EAM-Tools ............................................................................. 18
4 Fallstudie SEB Bank ................................................................................................ 21
4.1 Skizzierung ....................................................................................................... 21
4.2 Planungsmodell der SEB Bank ........................................................................ 21
4.3 Zusammenfassung der Fallstudie ..................................................................... 24
5 Zusammenfassung/Fazit/Ausblick ........................................................................... 25
A Softwarekarten ......................................................................................................... 26
B Informationsmodell .................................................................................................. 28
Literaturverzeichnis ........................................................................................................ 29
Kapitel 1: Einführung
3
1 Einführung
„In the 21st century, IT architecture will be the defining factor – the factor that
separates the winners from the losers“[Za96].
1987 wurde der Begriff Enterprise Architecture zum ersten Mal von John Zachman im
IBM System Journal in dem Artikel „A Framework for Information Systems
Architecture“ geprägt. Darin skizzierte er seine Vision von der Enterprise Architecture
als den entscheidenden Faktor, die steigende Zahl von vernetzten Systemen verwalten
zu können.
In der Realität kann die steigende Komplexität der IT von Unternehmen oftmals nicht
mehr bewältigt werden. Dies resultiert aus der Tatsache, dass Unternehmen Software
nur für eine bestimmte Abteilung kaufen oder entwickeln. Mit der Zeit führt dies
zwangsläufig zu einer heterogenen Anwendungslandschaft. Viele verschiedene
Systeme, damit verbundene redundante Daten und mehrfache Implementierungen der
gleichen Funktionalität sind die Probleme mit denen Unternehmen zu kämpfen haben.
Die Beherrschung der Komplexität der eigenen IT ist jedoch eine wesentliche
Voraussetzung für die Flexibilität des Unternehmens. Unternehmen sind gefordert sich
auf den Wandel der Märkte einzustellen und ihn auch aktiv zu beeinflussen. Schnelle
Reaktion auf den Wandel ist aber nur möglich, wenn ein Unternehmen weiß, wie seine
IT-Architektur die Geschäftsarchitektur unterstützt. Denn nicht selten bedeutet Wandel
die Restrukturierung IT-gestützter Geschäftsprozesse.
Enterprise Architecture (EA) und Enterprise Architecture Management (EAM) sollen
dem Unternehmen einen Ansatz zur Strukturbildung geben, um der Komplexität Herr
zu werden.
Diese Arbeit untergliedert sich in fünf Kapitel. Nach der Einführung werden die
Begriffe EA und EAM mithilfe der Architekturpyramide und den zugehörigen
Prozessen intensiv theoretisch beleuchtet und motiviert. In Kapitel 3 wird der Bogen zur
Praxis gespannt, indem Voraussetzungen zur EAM-Tool-Unterstützung genannt
werden. Auf den Funktionsumfang von erhältlichen Tools und die aktuelle
Marktsituation für EAM-Tools wird in den folgenden Kapiteln eingegangen.
Abgerundet wird der Praxisteil mit der Fallstudie der strategischen Planung der SEB-
Gruppe, die einen EAM-Ansatz verfolgt.
Kapitel 2: Enterprise Architecture Management
4
2 Enterprise Architecture Management
2.1 Definitionen und Abgrenzung
Für den Begriff Enterprise Architecture Management besteht keine einheitliche
Definition. Stattdessen gibt es eine Vielzahl von Definitionen, die Ähnlichkeiten und
Unterschiede aufweisen sowie auch im Detaillierungsgrad erheblich voneinander
abweichen. In diesem Kapitel wird deshalb der Begriff Enterprise Architecture
Management auf die Bedeutung seiner Bestandteile untersucht und verschiedene
Definitionen von Enterprise Architecture Management vorgestellt. Abschließend wird
anhand der Modelle der Architekturpyramide eine gemeinsame Definition
herausgearbeitet, die als Basis für die vorliegende Arbeit dient.
In der Informationstechnologie wird der Architekturbegriff in unterschiedlichen
Kontexten benutzt, z. B. IT-Architektur, Systemarchitektur. Der IEEE Standard
1471-2000 definiert IT-Architektur als „fundamental organization of a system,
embodied in its components, their relationships to each other and the environment, and
the principles governing its design and evolution” [IE00]. Dern erweitert diese
Definition auf mehrere Systeme [De03]. Festzuhalten bleibt also, das eine IT-
Architektur eine abstrakte, ganzheitliche Betrachtung der Struktur eines oder mehrerer
Systeme mit Planungs- oder Dokumentationscharakter ist.
Um den Unterschied zwischen einer IT-Architektur und einer Unternehmensarchitektur
(engl. Enterprise Architecture) zu verdeutlichen, wird häufig der Unterschied zwischen
einer Gebäudearchitektur und einer Stadtplanung als Analogie benutzt. Im Vergleich
zur Architektur im klassischen Sinn wird hier eine zentrale Stelle als Plan- und
Steuerungsorgan eingesetzt. Das Ziel ist einheitliche, langfristige Vorstellungen zur
Gesamtentwicklung der Stadt mit Blick auf regionale, soziale, wirtschaftliche und
politische Aspekte zu schaffen. Übertragen auf die Unternehmensarchitektur bedeutet
das, dass sich die Unternehmensarchitektur nicht mit einer Anwendung, sondern mit der
gesamten Anwendungslandschaft auseinandersetzt. Dabei müssen eine Vielzahl von
Interessen im Unternehmen berücksichtigt werden. Organisatorisch gesehen ist die
Kapitel 2: Enterprise Architecture Management
5
Unternehmensarchitektur auch in der Nähe zum CIO1 angesiedelt, sie hat also einen
planenden und steuernden Charakter.
Lankhorst definiert eine Unternehmensarchitektur als „a coherent whole of principles,
methods and models that are used in the design and realization of an enterprises
organizational structure, business processes, information systems and infrastructure”
[La05]. Welche Prinzipien, Methoden und Modelle dies sind, zeigt Dern in dem Modell
der Architekturpyramide, um das Artefakt Unternehmensarchitektur zu definieren.
2.2 Architekturpyramide
Das Artefakt Unternehmensarchitektur ist aus mehreren Einzelartefakten
zusammengesetzt.
Abb. 1: Architekturpyramide [De06]
Ausgangspunkt für die Ableitung einer Unternehmensarchitektur ist die
Unternehmensstrategie. Diese existiert meist nicht in Dokumentenform, sondern
definiert sich meist über Business Treiber oder ist in Unternehmenszielen
operationalisiert. Business-Treiber bestimmen die fundamentale geschäftliche
1 Chief Information Officer
Geschäfts-
architektur
Informations-
architektur
IT-Architektur
IT-Basisstruktur
Strategie
Pro
jektp
ortfo
lio
Kapitel 2: Enterprise Architecture Management
6
Ausrichtung eines Unternehmens und seine Geschäftsfelder. Sie werden in der
Geschäftsarchitektur definiert.
Die Geschäftsarchitektur definiert die Prozessarchitektur der Geschäftsprozesse eines
Unternehmens. Sie umfasst den Informationsbedarf sowie die notwendigen Funktionen
zur Durchführung der Geschäftsprozesse. In der Organisationsarchitektur wird die
Aufbau- und Ablauforganisation zur optimalen Durchführung der Geschäftsprozesse
strukturiert.
Ausgehend von der Geschäftsarchitektur schafft die Informationsarchitektur eine
gemeinsame geschäftliche und technologische Sicht für eine wertorientierte Gestaltung
der Anwendungslandschaft eines Unternehmens. Sie umfasst die systematische
Aufstellung und Bewertung der Informationssysteme eines Unternehmens (IS-Portfolio)
im gegenwärtigen (Ist-IS-Portfolio) und zukünftigen Status (Soll-IS-Portfolio).
Die IT-Architektur ist die strukturierende Abstraktion existierender oder geplanter
Informationssysteme. Diese Abstraktion schafft die gemeinsame
Kommunikationsplattform aller an der Gestaltung von Informationssystemen
Beteiligten, um so die Planbarkeit und Steuerbarkeit der Gestaltung realer, miteinander
kommunizierenden Entitäten der IT eines Unternehmens zu ermöglichen. Sie umfasst
die fachliche Architektur, die Softwarearchitektur, die System- und
Sicherheitsarchitektur sowie den zugeordneten Softwareentwicklungsprozess.
Als IT-Basisstruktur wird die Menge aller Hardware- und systemnahen
Softwarekomponenten verstanden, die die Laufzeit- und Managementumgebung für
Entwicklung, Test und Produktion von Informationssystemen bilden. Diese
Komponenten werden zu Basisplattformen gruppiert und bilden die Zielplattform von
Informationssystemen.
Das IT-Projektportfolio ist die Menge aller Projekte, die notwendig sind, um die
Anwendungslandschaft eines Unternehmens auf der Grundlage der definierten
Informationsarchitektur in einen definierten Soll-Zustand zu überführen.
Keller unterscheidet zudem zwischen der IT-Unternehmensarchitektur und der
Unternehmensarchitektur [Ke07]. Die IT-Unternehmensarchitektur ist dabei der Teil der
Unternehmensarchitektur, den die IT-Funktion im Unternehmen ausmachen darf, ohne
dabei in den Kompetenzbereich einer anderen Unternehmenseinheit einzudringen. Im
Kapitel 2: Enterprise Architecture Management
7
Idealfall sind aber IT-Unternehmensarchitektur und Unternehmensarchitektur identisch
und einheitlich organisiert.
2.3 Management der Unternehmensarchitektur
Mit der Entwicklung der Architekturpyramide ist eine statische Sicht auf ein
Unternehmen erreicht. Ein Unternehmen verhält sich jedoch wie ein komplexer
Organismus. Alle Bestandteile der Architekturpyramide sind nur Momentaufnahmen
eines dynamischen Systems. Besonders deutlich wird dies am IS-Portfolio. In einem
großen Unternehmen reflektiert das IS-Portfolio immer nur einen Ist-Zustand, der sich
im permanenten Wandel befindet. Sowohl den Wandel in der Informationstechnologie
als auch in der Produktpalette des Unternehmens soll das EAM unterstützen. Daher
werden im Folgenden eine Reihe von Prozessen im Unternehmen aufgeführt und
definiert, die eine Rolle für das EAM spielen und den dynamischen Charakter
unterstreichen.
Aus dem Prozess der Entwicklung der IT-Strategie sollten sich eine Anwendungs-, IT-
Architektur- und Infrastrukturstrategien ergeben. Eine IT-Strategie muss aus der
vorgegebenen Geschäftsstrategie abgeleitet werden. Die Anwendungsstrategie umfasst
die Festlegung eines Bündels strategischer Systeme, die die Performance des
Unternehmens steigern oder erhalten. Zusammen mit einem strategischen
Maßnahmenplan wird sie genutzt, um den Prozess des IS-Portfoliomanagements
auszulösen. Die IT-Architekturstrategie stellt Regeln zum Einsatz und zum
Management von Technologien und Ressourcen einschließlich der wichtigsten IT-
Prinzipien fest.
Als Geschäftsprozessmanagement bezeichnet man das aktive Betreiben eines
Geschäftsprozessmodells zur Gestaltung aller im Unternehmen ablaufenden
Geschäftsprozesse einschließlich ihrer Schnittstellen nach außen.
Der Prozess IS-Portfoliomanagement wird durch Veränderungen und Anforderungen
innerhalb und außerhalb eines Unternehmens ausgelöst. Innerhalb des Prozesses werden
die Auslöser in ihrer Wirkung auf das IS-Portfolio anhand von ausgewählten
Dimensionen analysiert und bewertet. Daraus werden Beschreibungen des Soll-IS-
Portfolios abgeleitet. Als Hilfsmittel zur Visualisierung der IS-Portfolioanalyse werden
Softwarekarten verwendet.
Kapitel 2: Enterprise Architecture Management
8
Der IT-Architekturmanagement-Prozess liefert Architekturplanungen, IT-Architekturen
und Architekturanalysen, die auf die Weiterentwicklung des Ist-IS-Portfolios und die
dahinterliegenden Geschäftsprozesse ausgerichtet sind. Auslösende Anforderungen
entstehen im IS-Portfoliomanagement oder werden übergreifend von anderen
Stakeholdern ausgelöst.
Der Prozess des IT-Projektportfoliomanagement definiert, analysiert und bewertet die
IT-Projekte, die zur Überführung des Ist- in das Soll-IS-Portfolio durchgeführt werden.
Nachdem nun einige wichtige Prozesse im Unternehmensumfeld aufgeführt wurden,
stellt sich die Frage, wie sie sich zum EAM verhalten. In der Literatur findet man keine
eindeutige Zuordnung der Prozesse zum EAM. Deshalb werden mehrere Definitionen
aufgeführt, was EAM umfassen kann.
Dern sieht einerseits die Verzahnung des IT-Architekturmanagements mit dem IS-
Portfoliomanagement und dem IT-Projektportfoliomanagement als EAM. Andererseits
schreibt er im Vorwort von [De06], dass EAM die Verzahnung des IT-
Architekturmanagements mit der strategischen IT-Planung beschreibt.
Keller führt fünf wesentliche Prozesse des EAM auf: Ableitung der IT-Strategie,
Anwendungsportfolio-Management, Modellierung der Unternehmensarchitektur,
Entwicklung und Durchsetzung von Richtlinien, Monitoring des Projektportfolios und
Projektbegleitung.
Sebis [Se08] zählt Strategie-Management, Portfolio-Management, Architektur-
Management und Synchronisations-Management als Module im EAM-Prozess. Die
Abbildungen 2, 3 und 4 vergleichen diese theoretischen Ansätze, indem die
Entsprechungen in den verschiedenen Modellen farblich gekennzeichnet sind.
Abb. 2: EAM-Prozesse nach Dern [De06]
Geschäfts-
architektur
Kapitel 2: Enterprise Architecture Management
9
Abb. 3: EAM-Prozesse nach Keller [Ke07]
Abb. 4: EAM-Prozesse nach sebis [Se08]
Im Gegensatz zu den anderen beiden Autoren gibt es in [Se08] auch eine direkte
Definition des Begriffs Enterprise Architecture Management als einen kontinuierlichen
iterativen Prozess, der die existierende und geplante IT-Unterstützung für ein
Unternehmen kontrolliert und verbessert. Dieser Prozess berücksichtigt sowohl die IT
des Unternehmens als auch Geschäftsprozesse, Geschäftsziele und Strategien mit dem
Ziel eine umfassende und integrierte Sicht auf das Unternehmen zu generieren.
Festzhuhalten bleibt, dass die Planung und die Steuerung der Enterprise Architecture
die Hauptaufgabe des Enterprise Architecture Management ist. EAM sollte dabei die
Ausrichtung der IT-Funktion an der Unternehmensstrategie unterstützen.
Kapitel 2: Enterprise Architecture Management
10
2.4 Motivation und Ziele
Eine Anwendungslandschaft eines Unternehmens besteht mitunter aus 100-1000
vernetzten Anwendungen. Die Komplexität dieser Anwendungslandschaft ergibt sich
aus den Beziehungen der Anwendungen untereinander. Da die Beziehungen zwischen
den Anwendungssysteme auf allen Unternehmensarchitekturebenen meist unzureichend
dokumentiert ist, kann die IT oft nicht mit der Dynamik des Geschäfts mithalten. Die
Motivation des EAM ist deshalb eine nachhaltige Dokumentation der Anwendungen
mit ihren Eigentümern und den daraus abgeleiteten Rechten und Pflichten zu erstellen,
geeignete Modelle zur Bildung eines gemeinsamen Vokabulars zur Kommunikation zu
schaffen, sowie Abstraktionen zur Beherrschung der inhärenten Komplexität in Form
von Visualisierungen zu schaffen und dabei die Anforderungen sämtlicher Stakeholder
zu balancieren.
Externe Treiber für das EAM sind z. B. der Markt und Regularien wie SOX, CCA,
Basel II, KonTraG, Solvency II, die Vorgaben des Gesetzgebers für Unternehmen
darstellen. Interne Treiber für EAM sind z.B die vom Vorstand oder Fachbereichen bei
der IT-Organisation geforderte effektivere, schnellere und wirtschaftliche
Geschäftsunterstützung.
Kurzfristig können mit einem repository-basierten EAM Mehrkosten durch konsistente
Datenhaltung vermieden werden. Zudem erzeugt EAM Wissen über das Inventar an
Anwendungen.
Mittelfristige Ziele sind z. B. Kosteneinsparungen durch Identifizierung von
redundanter Funktionalität im Unternehmen. Dies wird konkret durch gezieltes IS-
Portfoliomanagement erreicht, so dass z. B. eine Anwendung zum Anfang des nächsten
Jahres abgeschaltet werden kann.
Langfristige Ziele sind sicher die Reduzierung der Komplexität der
Anwendungslandschaft mit Blick auf eine optimale Unterstützung des Unternehmens
durch die IT und die Erzeugung von Transparenz. Das bedeutet, dass Informationen
bezüglich der IT-Unterstützung im Unternehmen, die von verschiedenen Stakeholdern
benötigt werden, schnell geliefert werden können, sowie immer auf dem aktuellen Stand
sind. Im Idealfall kann die IT durch EAM Potentiale aufzeigen, die durch die
Unternehmensstrategie genutzt werden können. Dies wird dann im simultanen
Engineering der Geschäftsmodelle und IT-Unterstützung umgesetzt.
Kapitel 3: Enterprise Architecture Management Tools
11
3 Enterprise Architecture Management Tools
3.1 Voraussetzungen für die Tool-Unterstützung von EAM
Um eine EAM-Unterstützung implementieren zu können, ist zunächst ein
unternehmensweites einheitliches Verständnis der Unternehmensarchitektur nötig.
EA-Frameworks wie Zachman [Za08] und TOGAF [TO03] machen Vorschläge für den
Aufbau und die Organisation der Enterprise Architecture, den Aufbau und die
Etablierung der EAM-Prozesse, sowie die Verbindung der Artefakte der Enterprise
Architecture in einem Framework. Nichtsdestotrotz fehlt es den Frameworks an einem
integrierten Informationsmodell, welches die verschiedenen Ebenen und Prozesse
verbindet.
Ein Informationsmodell ist das immaterielle Abbild des betrieblichen Objektsystems
aus Sicht der in diesem verarbeiteten Informationen für Zwecke des
Informationssystem- und Organisationsgestalters [BS04]. Im Kontext des EAM handelt
es sich bei den betrieblichen Objekten um für das EAM relevante Objekte. Im Anhang
findet sich ein Beispiel für so ein Informationsmodell im EAM-Kontext in UML-
Notation. Dieses Modell wurde aus dem EAM-Pattern-Katalog2 von sebis entwickelt.
Der Katalog ist durch eine Umfrage mit Praxispartnern entstanden, die EAM einsetzen.
Die Umfrage zeigt die Interessen für verschiedene Stakeholder auf, die in den Bereich
des EAM fallen. Daraus werden Aktivitäten abgeleitet, die die Interessen adressieren.
Softwarekarten (Viewpoints) unterstützen die Stakeholder bei der kollaborativen
Durchführung der Aktivitäten. Zur Generierung dieser Softwarekarten sind bestimmte
Informationen nötig, die dann als Fragment mit in das Informationsmodell einfließen.
Um das Informationsmodell mit Daten zu füllen, die bereits im Unternehmen existieren,
bieten EAM-Tools eine Reihe von Schnittstellen zu einer Vielzahl anderer Systemarten
von verschiedenen Herstellern. Darin besteht auch die zentrale Herausforderung für den
EAM-Prozess: Informationen auf einem aktuellen und konsistenten Stand zu halten.
Zum Vergleich: Eine IT-Asset-Datenbank allein konsistent zu halten ist schon eine
schwere Aufgabe. Ein EAM-Tool benötigt daraus nur einen relevanten Auszug. Diesen
in der Praxis manuell zu erfassen, wird immer zu mangelnder Aktualität führen.
2 Vgl. http://srvmatthes8.informatik.tu-muenchen.de:8083/wikis/eam-pattern-catalog/home
Kapitel 3: Enterprise Architecture Management Tools
12
Theoretisch muss ein Tool für EAM mit Daten aus allen Ebenen der
Unternehmensarchitektur automatisch versorgt werden, um die Probleme der
Stakeholder adressieren zu können. Dafür müssen die in Kapitel 2.3 aufgeführten
Prozesse im Unternehmen implementiert sein und eine dauerhafte Zusammenarbeit von
Geschäftsarchitekten, IT-Architekten, Projektmanagern etc. gewährleistet sein. In
diesem Fall können gepflegte Daten in den existierenden Informationssystemen im
Unternehmen für das EAM genutzt werden (Abb. 5).
Abb. 5: Datenaufbereitung und –nutzung für EAM [Se08]
Durch Konsolidierung der Daten in ein abstraktes Modell kann dann eine einheitliche
Sicht generiert werden:
Geschäftsprozessdaten sind in BPM-Tools wie ARIS-Toolset, Corporate
Modeler, Mega Process oder ähnlichen zu finden
Applikationsdaten, ihre Komponenten, Interfaces, etc. findet man in Software-
Modellierungstools (Rational Software Architect oder Together Control Center)
IT-Service-Management-Prozesse organisiert nach ITIL, MOF oder COBIT
werden in einer Datenbank gehalten
Informationen über Geräte und Systeme, Verbindungen zwischen Hardware und
Informationssystemen, Up- und Downtimes werden in IT-Asset-Management-
Systemen wie Open View, Tivoli und SMS gesammelt
Kapitel 3: Enterprise Architecture Management Tools
13
Projektplanungs- und Business-Intelligence-Daten sind in Systemen wie SAP
Business Warehouse und MS Project enthalten
Praktisch wird man aber ein integriertes Informationssystem für die Unterstützung der
IT-Funktionen, das den Integrationsgrad eines ERP-Systems in Handels- oder
Produktionsunternehmen hat, noch nicht auf dem Markt finden
3.2 Prozessabdeckung und Funktionen eines EAM-Tools
In diesem Abschnitt wird ein Überblick gegeben, welche Prozess- und Funktionsblöcke
ein EAM-Tool umfassen kann und wie diese die in Kapitel 2 beschriebenen
Prozessmodelle abdecken. Als Referenz wird das Funktionsblockmodell des EAM-
Tools planningIT von alfabet genutzt, das in [Se08] den größten Abdeckungsgrad
erreicht hat (Abb. 6). Im Vergleich mit den EAM-Modellen aus Kapitel 2 fällt auf, dass
es zusätzliche Blöcke gibt. Sie gehören zu den sonstigen Planungs- und
Betriebsfunktionen einer IT-Unterstützungsfunktion. Diese sind das logische IT-
Repository und das Value Management. Das logische IT-Repository ist die
Modellbasis, durch die ein IS-Portfolio-Management erst möglich wird. Hier werden
Daten aus dem IT-Asset-Management in eine vereinfachte Sicht transformiert.
Abb. 6: Funktionsblöcke von planningIT [Ke07]
Kapitel 3: Enterprise Architecture Management Tools
14
Bevor die spezifischen EAM-Aufgaben beschrieben werden, die ein EAM-Tool
abdecken sollte, werden die Visualisierungsmöglichkeiten von Zusammenhängen im
Unternehmen, die auf einer semantischen Basis fundieren, aufgezeigt. Das Kernartefakt
bildet dabei die Anwendungslandschaft. Sie muss in drei Zuständen berücksichtigt
werden: Der Ist-Zustand repräsentiert den aktuellen Zustand der
Anwendungslandschaft; der Plan-Zustand einen zukünftigen Status der Landschaft, der
zu einer bestimmten Zeit modelliert wurde und der Soll-Zustand den Status, der auf
lange Sicht erreicht werden soll.
Die Visualisierung der Anwendungslandschaft nach verschiedenen Kriterien ist der
Softwarekartographie zuzuordnen. Ihr Ziel ist komplexe Anwendungslandschaften im
Unternehmen systematisch darzustellen und damit die Beschreibung, Bewertung und
Gestaltung von Anwendungslandschaften zu verbessern. Lankes et al haben in einer
Untersuchung [LMW05] verschiedene Typen von Softwarekarten identifiziert.
Abb. 7: Typen von Softwarekarten [Ke07]
Zunächst unterscheiden sie zwischen Softwarekarten mit Kartengrund und ohne
Kartengrund. Entscheidend ist die geographische Position der Elemente bei
Softwarekarten mit Kartengrund; bei Karten ohne Grund spielt sie keine Rolle. Es
werden drei verschiedene Typen von Softwarekarten mit Kartengrund unterschieden:
Cluster-, Prozessunterstützungs- und Intervallkarten. Im Anhang finden sich Beispiele
für solche Softwarekartentypen.
In Clusterkarten bilden logische Einheiten, z. B. Funktionsbereiche oder
Organisationbereiche, die Basis der Ordnung. In diese beliebig anzuordnenden
Einheiten werden die zugehörigen Anwendungssysteme eingesetzt.
Softwarekarte
mit Kartengrund ohne Kartengrund
Clusterkarte Prozess-
unterstützungskarte
Intervallkarte
Kapitel 3: Enterprise Architecture Management Tools
15
Die Prozessunterstützungskarte verortet die dargestellten Elemente an den
Geschäftsprozessen und an möglichen weiteren organisatorischen Ausprägungen. Die
Geschäftsprozesse werden auf der Abszisse und auf der Ordinate z. B.
Organisationseinheiten, Systemklassen oder Zeitintervalle eingetragen.
Bei der Intervallkarte werden auf der Abszisse die Zeit und auf der Ordinate z. B. IS-
Systeme, IT-Projekte oder Organisationseinheiten eingetragen. Sie orientiert sich stark
an Gantt-Diagrammen.
Softwarekarten ohne Kartengrund sind z. B. UML-Diagramme. Sie dienen in erster
Linie der Strukturierung von Problemen und nicht der Darstellung der
Anwendungslandschaft im Unternehmen.
IS-Portfoliomanagement
Ein Tool sollte eine Funktion zum Management der Anwendungslandschaft enthalten
und mithilfe von Softwarekarten die Anwendungslandschaft visualisieren können.
Ausgehend von den Daten des Ist-Zustands sollten verschiedene
Weiterentwicklungsvarianten modelliert werden können. Die Daten des aktuellen
Zustands und aller zukünftigen Zustände sollten historisierbar sein, um Vergleiche
herstellen zu können.
Projektportfoliomanagement
Das Projektportfoliomanagement sammelt und dokumentiert die Anforderungen, die aus
Business und IT stammen, und verknüpft sie mit den betreffenden Elementen der
Unternehmensarchitektur. Daraus werden Projekte der nächsten Planungsperiode
generiert. Bei vielen EAM-Tools wird das Projektportfoliomanagement noch mit dem
Synchronisationsmanagement verknüpft. Das Synchronisationsmanagement adressiert
Fragen im Zusammenhang mit auftretenden Interdependenzen, wenn zwei oder mehr
Projekte dasselbe IS modifizieren. Fragen, die das Projektportfoliomanagement
beantwortet, sind:
Wie hoch sind die Kosten für welchen Projektvorschlag?
Wie hoch ist der erwartete ROI3 für welchen Projektvorschlag?
Welche IS werden verändert, neu erstellt, abgeschaltet von welchen Projekten?
Welche Prozesse und organisatorische Einheiten sind von den Änderungen
betroffen, weil sie das IS nutzen, das vom Projektvorschlag verändert wird?
3 Return on Investment
Kapitel 3: Enterprise Architecture Management Tools
16
Welche Projektvorschläge haben die höchste Priorität?
Welche Projekte betreffen dieselbe organisatorische Einheit?
Welche Interdependenzen existieren zwischen Projekten?
Welche Auswirkungen hat die Verzögerung eines bestimmten Projekts und
welche Zeitpläne müssen dann wie angepasst werden?
Strategiemanagement
Das Strategiemanagement kümmert sich um die Ausrichtung der EAM-Aktivitäten an
der Unternehmensstrategie. Es analysiert, wie weit eine Strategie auch umgesetzt wird,
indem Objekte der Planung mit Objekten der dokumentierten Strategie verknüpft
werden. Dadurch soll es auch möglich sein, von einem bestimmten Objekt mit einem
hohen Detaillierungsgrad die Strategie zurückzuverfolgen, die zu seiner Erstellung
geführt hat. Fragen, die das Strategiemanagement beantwortet, sind:
Welche Strategie führt zu welchen Zielen?
Sind alle Ziele erreicht worden?
Welche organisatorischen Einheiten haben ihre Ziele nicht erreicht?
Welche Projekte unterstützen welche Ziele?
Welche Anforderungen sind welchen Zielen zugeordnet?
Geschäftsprozessmanagement
Geschäftsprozesse und -objekte sowie der Austausch der Geschäftsobjekte zwischen IS
werden im Geschäftsprozessmanagement betrachtet. Fragen, die das
Geschäftsprozessmanagement beantwortet, sind:
Welche Geschäftsobjekte werden von welchem IS erstellt, modifiziert oder
gelöscht?
Welches IS tauscht welche Geschäftsobjekte über welches Interface aus?
Welches IS hält die Master-Copy von welchem Geschäftsobjekt?
Welche Geschäftsprozesse werden manuell ausgeführt?
IT-Architekturmanagement
Das IT-Architekturmanagement beschäftigt sich mit der Einführung und
Implementierung von Architektur-Blueprints, die die IT-Architektur von IS
standardisieren. Auf diesen Architektur-Blueprints sollen zukünftige IS basieren und
Kapitel 3: Enterprise Architecture Management Tools
17
bereits laufende IS sollen an sie angepasst werden. Fragen, die das IT-
Architekturmanagement beantwortet, sind:
Welche IT-Architekturen werden in welchen Anwendungsdomänen verwendet?
Welche der existierenden IT-Architekturen sollte beibehalten werden und
welche sollten ersetzt werden?
Welche Architekturelemente umfassen die verwendeten IT-Architekturen?
Welche der Anwendungssysteme benutzen welche Architekturelemente?
Welche Auswirkungen hat die Ersetzung einer Architektur / eines
Architekturelements?
Infrastrukturmanagement
Das Infrastrukturmanagement behandelt die IT-Infrastruktur des Unternehmens. Die
Infrastruktur umfasst z. B. Datenbanken und Middleware-Systeme. Fragen, die das
Infrastrukturmanagement beantwortet, sind:
Welche Datenbanken werden benutzt?
Welches IS nutzt welche Datenbanken?
Wie hoch sind die Kosten für den Betrieb der Datenbank?
Welche Datenbanken werden ersetzt und welche IS sind davon betroffen?
Welche organisatorischen Einheiten hosten das betroffene IS?
Anforderungsmanagement
Im Anforderungsmanagement treten Anforderungen in verschiedenen Formen auf: In
Form der Unternehmens- und der IT-Strategie und in Form von
Veränderungsprogrammen, die entweder eine Vielzahl von Anwendungssystemen
(Umbau eines kompletten Geschäftsprozess) oder nur ein einzelnes IS betreffen.
Welche Anforderungen wurden gestellt?
Welche IS sind von den einzelnen Anforderungen betroffen?
Welche Anforderungen können in ein Projekt integriert werden?
Welche Projektvorschläge resultieren daraus?
Zu diesen funktionalen Anforderungen kommen weitere nichtfunktionale
Anforderungen an ein EAM-Tool hinzu. Da ein Unternehmen ein vorgefertigtes
Informationsmodell kaum vollständig nutzt, sind Anpassungsmöglichkeiten des
Metamodells wünschenswert. Genauso ist die Erweiterbarkeit der Funktionalität, der
Kapitel 3: Enterprise Architecture Management Tools
18
Visualisierungen und der Reports ein weiteres Kriterium. Ein EAM-Tool wird nur
erfolgreich eingesetzt werden können, wenn es ähnlich wie ein ERP-System fast jeder
Mitarbeiter der IT nutzt. Also muss ein EAM für den Mehrbenutzerbetrieb konzipiert
sein. Auch bei einer Vielzahl von Benutzern sollte es immer noch performant sein und
eine gute Usability bieten. Wie in den Anforderungen gesehen, muss ein EAM-Tool
Schnittstellen in viele Richtungen besitzen und auch gut integriert werden. Dafür sollten
die Schnittstellen einfach anzupassen und erweiterbar sein.
3.3 Marktübersicht EAM-Tools
EAM-Tools sind eine relativ neue Art von Software. Die Hersteller dieser Tools
entwickelten ursprünglich Tools für einen anderen Bereich. Um den Erfordernissen des
EAM zu entsprechen, wurden die Tools um Funktionalität erweitert und angepasst,
Dabei variiert der Funktionalitätsumfang aufgrund der unterschiedlichen Auffassung
von EAM stark.
Werkzeuge des Umfangs von planning-IT stellen leider noch die Minderheit dar. Häufig
wird nur ein Teil der EAM-Funktionalität als Aufsatz auf bestehende Lösungen, die zu
anderen Zwecken entworfen wurden, implementiert.
Als Herkunft der Tools kann man drei verschiedene Richtungen unterscheiden:
1) Tools für Projektarchitekten: Bei diesen Tools wurden die Beziehungen von
Komponenten zueinander modelliert.
2) BPM-Tools besitzen schon die Funktionalität Geschäftsprozesse auf IT-Systeme
abzubilden, daher liegt eine Erweiterung der Funktionalität zur EAM-
Unterstützung nahe.
3) Meta-Werkzeuge sind Toolsets, mit denen man u.a. beliebig viele graphische
Editoren und Anwendungen bauen kann. Durch Hinterlegung eines Metamodells
und weiterer Anpassungen entsteht ein Werkzeug für eine bestimmte
Anwendung.
Eine allgemein anerkannte Kategorisierung der Tools gibt es noch nicht. Die evaluierten
Tools in [Se08] lassen sich jedoch nach ihren unterschiedlichen Ansätzen
kategorisieren. Dabei kann man zwischen einem Metamodellierungsansatz, einem
methodengetriebenen, einem prozessgetriebenen und einem integrativen Ansatz
unterscheiden.
Kapitel 3: Enterprise Architecture Management Tools
19
Beim Metamodellierungsansatz kann das Metamodell an die individuellen Ansprüche
angepasst werden. Berichte und Visualisierungen können an das adaptierte Metamodell
ebenfalls angepasst werden. Dies ist der flexibelste Ansatz, jedoch verursachen die
Anpassungen natürlich erheblichen Entwicklungsaufwand. ADOit von BOC GmbH,
Troux von Troux Technologies und System Architect von Telelogic gehören zu diesem
Typ.
Der methodengetriebene Ansatz basiert auf einer vordefinierten und dokumentierten
Methodik. Er ermöglicht keine Anpassungen des Metamodells, um die Methodik zu
erhalten. Die ARIS Plattform von IDS Scheer verfolgt so einen Ansatz.
Der prozessgetriebene Ansatz ist eine Erweiterung des methodengetriebenen Ansatzes,
der z. B. von planningIT von alfabet umgesetzt wird. Er erweitert die Methodik um eine
zeitliche Dimension zu einem Managementprozess. Dieser verknüpft die verschiedenen
Module in einem Vorgehensmodell. Auch hier ist die fehlende Flexibilität des
Metamodells eine Einschränkung.
Der Schwerpunkt des integrativen Ansatzes liegt auf der Wiederverwendung von
verschiedenen Datenquellen. Durch fortgeschrittene Transformationsfähigkeiten werden
die Datenquellen in ein einheitliches Modell verknüpft, integriert und aggregiert. Der
Nachteil dieses Ansatzes ist die Anpassbarkeit der Report- und
Visualisierungsmöglichkeiten. Adaptive EAM von Adaptive Inc. ist ein Vertreter dieser
Art von EAM-Tools.
Diese Ansätze sind jedoch nicht disjunkt: Es sind auch Kombinationen mehrerer
Ansätze möglich, deren Abdeckung unterschiedlich stark realisiert wird. Eine gute
Kombination wäre ein Tool, das eigentlich ein Meta-Werkzeug ist und somit vom
Lieferanten an den Kundenbedarf angepasst werden kann, aber mit einem vorgefertigten
Metamodell und mit vorgefertigten Grafiken ausgeliefert wird [Ke07].
Insgesamt kann man beobachten, dass der Markt für EAM derzeit stark wächst und
gleichzeitig noch stark fragmentiert ist. Kleinere Hersteller sind mit ihren Lösungen
noch sehr stark vertreten, so dass man in Zukunft von einer Konsolidierung ausgehen
kann, wenn große Firmen wie vor ein paar Monaten IBM die kleineren EAM-Hersteller
aufkaufen.
Kapitel 3: Enterprise Architecture Management Tools
20
Abb.8: Marktanalyse der Hersteller von EAM-Tools (Quelle: Gartner Inc.)
Kapitel 4: Fallstudie SEB Bank
21
4 Fallstudie SEB Bank
4.1 Skizzierung
In der Fallstudie wird das strategische Planungsmodell der SEB Gruppe, ein weltweit
agierender, führender nordeuropäischer Finanzdienstleister mit Deutschland als
Heimatmarkt, beschrieben. Um den Bebauungsplan (IT-Target) jeder Division und auf
Gruppenebene zu beschreiben, wird eine Softwarekarte als Visualisierung für die
konzernweite IS-Landschaft genutzt. Der darauf aufsetzende IT-Plan stimmt das IT-
Target auf die Finanz- und Ressourcenplanung ab und formuliert einen strategischen
Maßnahmenplan zur Entwicklung der Anwendungslandschaft in einem Zeithorizont
von 3 Jahren.
4.2 Planungsmodell der SEB Bank
Die Aufbauorganisation der SEB Gruppe folgt einer Struktur, die nach Kundengruppen
und Produkten zu Divisionen zusammengefasst ist. Jede dieser strategischen
Geschäftseinheiten umfasst eine Organisationseinheit „IT-Strategy & Enterprise
Architecture“, die den EAM-Prozess divisionsintern durchführt. Eine gruppenweit
agierende IT-Dienstleistungsorganisation übernimmt die Systementwicklung, den
Betrieb und die Wartung von IS und IT-Basisinfrastruktur. Den divisionsübergreifenden
EAM-Prozess übernimmt ein CIO.
Abb. 9: Divisionale Struktur [De06]
Im Rahmen des jährlichen Planungsprozesses definiert der CIO Rahmenbedingungen,
Meilensteine und Ergebnistypen und aggregiert die Soll-IS-Portfolios der einzelnen
Divisionen zum gruppenübergreifenden IT-Target und einer 3-Jahres-IT-Planung.
Kapitel 4: Fallstudie SEB Bank
22
Zur Erfassung des gesamten IS-Portfolio in einer einheitlichen Beschreibung wird eine
Clusterkarte, hier „IS-Domain-Map“ genannt, verwendet. Sie stellt die
Anwendungslandschaft funktional abstrahiert und nach Domänen geordnet dar. Sie wird
zur Vorbereitung der jährlichen IT-Planung durch den CIO und den IT-
Unternehmensarchitekten aus der Einheit „IT-Strategy & Enterprise Architecture“ der
einzelnen Divisionen fortgeschrieben.
Abb. 10: Abgrenzung strategischer Handlungsfelder [De06]
Zur Identifizierung von strategischen Handlungsfeldern (Abb.10) und letztendlich zur
Ermittlung des IT-Targets werden zunächst die aus einem Business Treiber einer
Division abgeleiteten strategischen Anforderungen an die IS-Unterstützung ermittelt
(IS-Bedarf). Hier wird das Handlungsfeld „Optimierung Retail-Plattformen“
abgegrenzt. Eine Ist-Analyse dieses strategischen Handlungsfelds mit Unterstützung der
Business Treiber unter Berücksichtigung des Lebenszyklus und des technischen
Zustands der Systeme wird durchgeführt. Aufbauend auf den Erkenntnissen der
Analyse, den IS-Bedarfen sowie den geltenden Architekturprinzipien wird eine Soll-
Definition, die einen Ausschnitt des IT-Targets darstellt, erarbeitet.
Kapitel 4: Fallstudie SEB Bank
23
Abb. 11: Ist-Analyse für das Handlungsfeld „Optimierung Retail-Vertriebsplattform“
[De06]
Abb. 12: Soll-Definition für das Handlungsfeld „Optimierung Retail-
Vertriebsplattform“ [De06]
Die Festlegung von Maßnahmen zur Erreichung des IT-Targets in Form von IT-
Vorhaben und IT-Projekten unter Berücksichtigung des aktuellen IT-Projektportfolios
und der dabei wirkende Investitionsstrategie ist Aufgabe der 3-Jahres-IT-Planung.
Die getroffenen Maßnahmen zur Umsetzung des Handlungsfelds „Optimierung Retail-
Plattform“ sind in Abb. 14 hervorgehoben.
Kapitel 4: Fallstudie SEB Bank
24
Abb. 13: Strategischer Maßnahmenplan für die 3-Jahres-Planung [De06]
4.3 Zusammenfassung der Fallstudie
Die EAM-Prozesse sind bei der SEB-Gruppe sehr gut nachzuvollziehen. Zunächst wird
die Unternehmensstrategie genutzt, um die Business Treiber auf
Geschäftsarchitekturebene abzuleiten. Davon ausgehend werden die strategischen
Handlungsfelder im IS-Portfolio (Informationsarchitektur) identifiziert. Die SEB
scheint aber bisher noch auf eine EAM-Tool-Unterstützung zu verzichten. Solange die
Anzahl an IS noch manuell zu verwalten ist, ist dies auch nicht nötig. Ein Tool könnte
jedoch durch automatische Generierung der Clusterkarten und Planszenarien das
Aufstellen des IT-Targets sowie die Identifizierung der strategischen Handelsfelder in
Form von Prozessunterstützungskarten erleichtern. Durch die Nachhaltung der
strategischen Anforderung und den von ihnen ausgelösten Veränderungen könnte
ebenfalls das Controlling profitieren.
Kapitel 5: Zusammenfassung/Fazit/Ausblick
25
5 Zusammenfassung/Fazit/Ausblick
In dieser Arbeit wurde das Enterprise Architecture Management als ein Prozess zur
Planung und Steuerung der Enterprise Architecture vorgestellt. Da die Enterprise
Architecture als Ausgangsbasis dient, wurde im Kapitel 3 die Notwendigkeit eines
Informationsmodell erläutert, auf dessen Grundlage Tools das EAM in der Praxis
unterstützen können. Diese müssen einen beträchtlichen Funktionsumfang bieten. Dies
ist bei der Mehrheit der erhältlichen Tools nicht der Fall, da sie Weiterentwicklungen
von Metatools, Geschäftsprozessmodellierungswerkzeugen oder Tools für
Projektarchitekten sind. Aufgrund dieser Tatsache dominieren noch kleine Hersteller
den Markt für EAM-Tools. Sobald aber die angebotenen Tools einen ausgereifteren
Stand erreichen, kann man davon ausgehen, dass größere Hersteller durch Aufkäufe in
den Markt drängen.
Die Fallstudie zeigt, dass Bedarf für solche EAM-Tools in großen Konzernen besteht,
um die strategische IT-Planung durchzuführen. Wenn EAM-Tools einen
entsprechenden Reifegrad erreicht haben, kann man auch davon ausgehen, dass EAM-
Tools in Zukunft für die IT-Planung ähnlich wichtig werden wie ERP-Systeme für die
Business-Planung. Dies wird auch von der Einstellung des CIOs abhängen, ob er in
seiner IT-Abteilung nur die Betonung auf das Kostenmanagement legt oder die IT auch
eine Rolle für die Geschäftsseite spielen soll.
Beispiele für deutsche Unternehmen, die bereits aktiv EAM betreiben, findet man bei
den DAX-notierten Unternehmen BMW, Deutsche Bahn oder Siemens. Ob diese
Unternehmen sich durch den Faktor EAM, wie es Zachman formuliert hat, zu den
Gewinnern des 21. Jahrhunderts zählen dürfen, bleibt abzuwarten.
Anhang A: Titel von Anhang 1
26
A Softwarekarten
Clusterkarte [Se08]
Prozessunterstützungskarte [Se08]
Anhang A: Titel von Anhang 1
27
Intervallkarte [Se08]
Anhang B: Titel von Anhang 2
28
B Informationsmodell
Informationsmodell eines fiktiven Unternehmens im EAM-Kontext [Se08]
Literaturverzeichnis
29
Literaturverzeichnis
[BS04] Jörg Becker, Reinhard Schütte: Handelsinformationssysteme, 2.Auflage,
dpunkt, 2004.
[Ke07] Wolfgang Keller: IT-Unternehmensarchitektur, 1.Auflage, dpunkt, 2007.
[La05] Marc Lankhorst: Enterprise Architecture at Work: Modelling,
Communication and Analysis, 1.Auflage, Springer, 2005.
[De06] Gernot Dern: Management von IT-Architekturen, 2.Auflage, Vieweg, 2006.
[IE00] IEEE Std 1471-2000: IEEE Recommended Practice for Architectural
Description of Software-Intensive Systems, IEEE, 2000.
[LMW05] Josef Lankes, Florian Matthes, André Wittenburg: Softwarekartographie:
Systematische Darstellung von Anwendungslandschaften, 7. Internationale
Tagung Wirtschaftsinformatik, Physica, 2005.
[Se08] Software Engineering for Business Informations Systems: Enterprise
Architecture Management Tool Survey 2008, TU München, 2008.
[TO03] The Open Group: TOGAF Enterprise Edition, The Open Group,2003.
[Za87] John A. Zachman: A Framework for Information Systems Architecture, IBM
Systems Journal, vol. 26, 276-292, IBM Publication G321-5298, 1987.
[Za96] John A. Zachman: Enterprise Architecture: The Issue of the Century,
Database Programming and Design Magazine, Miller Freeman, 1997.
[Za08] The Zachman Institute for Framework Advancement: Enterprise Architecture:
A Framework. http://www.zifa.com (Framework Overview); Abruf 07.11.2008
Hinweis: Die unten angeführte Erklärung wird nur bei Bachelor- oder Diplomarbeiten
benötigt, nicht jedoch bei Seminarausarbeitungen. Bei Bachelorarbeiten ist
darauf zu achten, dass das Wort „Diplomhausarbeit“ durch „Bachelor-
Abschlussarbeit“ ersetzt wird.
Ich versichere hiermit, dass ich meine Diplomhausarbeit <Titel der Arbeit>
selbstständig und ohne fremde Hilfe angefertigt habe, und dass ich alle von anderen
Autoren wörtlich übernommenen Stellen wie auch die sich an die Gedankengänge
anderer Autoren eng anlegenden Ausführungen meiner Arbeit besonders gekenn-
zeichnet und die Quellen zitiert habe.
Münster, __________ _____________________________
