Thomas Allweyer

lT-Management

Grundlagen und
Perspektiven für
den er.folgreichen
Einsatz von lT im
Unternehmen
 !r
oder neue kommen hinzu. Auch das Aufkommen neuer Bedrohungen oder die Entwick-
lung und Anwendung neuer Technologien kann dazu führery dass andere Maßnahmen
7 Enterprise-Architecture-Management
erforderlich sind, um existierende Vorgaben nach wie vor zu erfüllen, Diese Entwick-
Unter der Architektur eines Systems versteht man seinen prinzipiellen Aufbau: Aus wel-
Iungen müssen beobachtet ]l/erden, §odass rechtzeitig darauf reagiert und die Compli
chen einzelnen Komponenten besteht das System, und wie hängen sie zusammen?
ance aufrechterhalten werden kann.
In der IT lassen sich Architekturen auf verschiedenen Ebenen finden. So besitzt jedes
Der Vollständigkeit halber sei noch einmal darauf hingewiesen, dass die beschriebenen
Softwaresystem eine Architektur, die seine innere Struktur beschreibt. Dazu gehören
Aufgaben der IT-Compliance nicht isoliert, sondern in enger Abstimmung rnit dem un-
etwa die Aufteilung in verschiedene Schichtery wie Präsentation, Anwendungslogik und
ternehmensweiten Compliance-Management, dem Risikomanagement, der Maßnah-
Datenhaltung, oder die Unterteilung in verschiedene fachliche Module.
men- und Investitionsplanung und anderen lT-Mana5;ement-Aktivitäten durchgeführt
werden sollten. Eine Enterprise-Architecture (EA) oder Unternehmensarchitektur beschreibt die Zusam-
menhänge verschiedener wesentlicher Aspekte eines Unternehmens, wie z.B. Produkte,
Geschäftsprozesse und Aufbauorganisation - und die hierfür eingesetzte Informations-
technik in Form von Anwendungssystemen, Technologien und Infrastruktur.
Da es sowohl um die {achliche Strukturierung als auch um die unterstützende Informa-
tionstechnik geht, müssen die Unternehmensführung, die verschiedenen Fachabteilun-
gen und der IT-Bereich die Unternehmensarchitektur letztlich gemeinsam entwickeln.

Dennoch ist das Thema Enterprise-Architecture-Management (EAM) in der Praxis vor-

rangig im IT-Bereich angesiedelt und fokussiert vor allem auf die Planung und Entwick-
lung der IT-Systeme. Insbesondere große Unternehmen verfügen über eine Vielzahl ver-
schiedener Anwendungen und T'echnologien, die nur schwer zu überblicken sind. Das
IT-Management benötigt daher aktuelle Verzeichnisse und ggf. grafische Darsteliungen
der eingesetzten Systeme, ihrer wesentlichen Eigenschaften und ihrer Zusammenhänge.
So möchte man beispielsweise wissen, welche Anwendungssysteme auf welchen Ser-
vern laufen und welche Schnittstellen eine Anwendung zu welchen anderen Systemen
hat. Ohne derartige Informationen wird es beispielsweise schwierig, die Ablösung eines
älteren Systems durch ein neues zu planen.

Ein solcher Lrberblick über die IT-Landschaft ist zwar hilfreich, reicht für deren gezielte
Planung und Weiterentwicklung aber nicht aus. Hierfür ist eine Verbindung zur fachli-
chen Ebene erforderlich - auch als ,,Business-Architecture" oder Geschäftsarchitektur
bezeichnet. So11 beispielsweise ejn bestimmter Geschäftsprozess geändert werden, so
muss man wissen, welche Systeme in diesem Prozess eingesetzt werden und daher ggf.
angepasst werden müssen.

Häufig arbeiten die für die Business-Architecture zuständigen Manager und Experten
mit anderen Darstellungen und Werkzeug;en als sie in der IT für das Enterprise-Archi-
tecture-Management verwendet werden. So werden etwa für das Geschäftsprozessma-
nagement Prozessmodellierungswerkzeuge eingesetzt, nlj;t denen Abläufe detailliert
grafisch dargestellt und analysiert werden können. Im Enterprise-Architecture-Manage-
ment genügt hingegen meist eine grobe Übersichtsdarstellung. Dafür wird hier die In-
formation benötigt, welche IT-Systeme in welchen Prozessen eingesetzt werden. Es sollte

104 105
durch geeignete Vorgehensweisen bei der Anderung von Prozessen sichergestellt wer-
den, dass die im EAM und im Prozessmanagement verwendeten Prozessdokumentatio-
nen immer zusammenpassen.
In jedem Fall ist eine enge Zusammenarbeit zwischen der fachlichen Ebene und den oft-
mals im IT-Bereich angesiedelten EAM-Verantwortlichen notwendig.
7.1 Ziele und Aufgaben
Die wesentliche Aufgabe des Enterprise-Architecture-Managements (EAM) ist es, Trans-
parerrz herzustellen und die benötigten Informationen für alle Bereiche des IT-Manage-
ments bereitzustellen. So ist das EAM insbesondere eine wesentliche Grundiage für die
Entwicklung der IT-Strategie.
Um beispielsweise eine Analyse der Anwendungen nach ihrem Strategie- und Wertbei-
trag vornehmen zu können, wie dies in Kapitel 4.4.5 beschrieben wurde, muss man wis-
sen, über welche Anwendungssysteme das Unternehmen verfügt, wozu sie genau einge-
setzt werclen, welche Kosten damit verbunden sind usw. Müssen diese Informationen
erst erhoben werden, so benötigt man für eine solche Analyse Tage oder Wochen. Ver-
fügt man hingegen über eine gut gepflegte EAM-Datenbasis, sr"r können solche Auswer-
tungen und Diagramme auf Knopfdruck erzeugt werden. Beispiele weiterer Auswertun-
gen finden sich in Kapitel 7.4.
Indem die Zusammenhänge zwlschen der Geschäftsarchitektur und den Informations-
systemen beschrieben werden, bildet das EAM die Voraussetzung für das Business-IT-
Alignment, das sicherstellt, dass die IT die Unternehmensziele unterstützt und einen
größtmöglichen Nutzen für das Unternehmen bringt (vgl. Kapitel 4).
Eine gez:ielte Weiterentwicklung der IT-Landschaft ist nur möglich, wenn man die ver-
schiedenen Systeme und ihre Funktionen kennt, und wenn man weiß, wie sie zusam-
menspielen und welche Geschäftsprozesse sie unterstützen. So kann man beispielsweise
feststellen, ob es Systeme gibt, deren Funktionalitäten sich zu großen Teilen überschnei-
den. In solchen Fällen ist es oftmals sinnvoll, einige dieser Systeme abzuschaffen. Durch
eine solche Konsolidierung der Systemlandschaft lassen sich oftmals Kosteneinsparun-
gen erzieien, aber auch weitere Vorteile, wie z. B. geringere Datenredundanzen.
Auch die schnelle Umsetzung von Innovatlonsvorhaben gemäß dem Innovate-Design-
Transform-Paradigma (vgi. Kapitel 3.1.3) erfordert es, dass man die vorhandenen Sys-
teme und Architekturen kennt. Nur wenn dies der Fall ist, ist es möglich, neue Systeme
und Entwicklungen in die bestehende Systemlandschaft zu integrieren und somit bei-
spielsweise dafür zu sorgen, dass die Daten eines neuen Web-basierten Angebots in dem
vorhandenen Abrechnungssystem des Unternehmens weiterverarbeitet und entspre-
chende Rechnungen erstellt werden.
106
Zt den Aufgaben des EAM gehört nicht nur das Sammeln der betreffenden lnft»rn'ra t itr
nen, sondern auch deren Analyse und Aufbereitung, unter anderem in Form verscltit'
dener Arten von Diagrammen (vgl. Kapitel 7.4).Zudem stellt das EAM Planungsinstrtr
mente für die künftige Entwickiung der Unternehmensarchitektur bereit, etwa zur Defi-
nition gewünschter Sollzustände zu verschiedenen Zeitpunkten und die Planung der
hierfür erforderlichen Vorhaben (vgl. Abbildung 9 in Kapitel 4.4.6).
Eine weitere Aufgabe des Architekturmanagements ist es, geeignete Vorgaben für die
Architektur aufzustellen uncl dafür zu sorgen, dass sie auch eingehalten werden. Hier-
durch soII erreicht werden, dass stimmige EntscheidunS;en getroffen werden und dass
die in clen verschiedenen IT-Projekten entwickelten Lösungen zusammenPassen. Derar-
tige Vorgaben reichen von grundlegenden Prinzipien, die Teil der IT-Strategie sind (vgl.
Kapitel 4.4.3), über Architekturstile wie z, B. Microservices, bis zu konkreten technischen
Festlegungen wie die einheitliche Verwendung bestimmter Programmiersprachen oder
Middleware-Technologien.
Zum EAM gehärt in diesem Zusammenhang auch die Beratung der verschiedenen IT-
Projekte hinsichtlich Architekiur-relevanter Fragestellungen. Manche Architekturent-
scheidungen mögen sich zwar für das jeweilige Projekt eignen, sind aber aus Sicht der
Gesamtarchitektur nachteilig.
Ein Beispiel: Es sollen Technokrgien verwendet werden, die sonst im Unternehmen nicht
vorkommen. Dies führt untcr anderem zu Problemen bei der Integration mit anderen
Systemen sowie zu zusätzlichem Aufwand bei Administration und Support, weil die
Mitarbeiter sich mit der betreffenden Techncllogie nicht auskennen und erst geschult
werden müssen. Etwas anderes ist es, wenn es sich um eine neue Technologie handelt,
die erprobt und künftig auch für andere Projekte genutzt werden soll. Soiche Fragestel-
lungen können von den für das EAM zuständigen Mitarbeitern beantwortet werden.
Es können sich auch aus konkreten Projekten neue Anforderungen an die Unterneh-
mensarchitektur ergeben. Dann müssen die Architekturvorgaben entsprechend modifi
ziert werden.
Das Architekturmanagement leistet zudem einen ganz wesentlichen Beitrag zur Gover-
nance der IT und des gesamten Unternehmens (vgl. Kapitel 6). Einerseits stellt es eine
wichtige Informatic.rnsbasis dar, andererseits kümmert es sich darum, dass geeignete Ar-
chitekturvorgaben aufgestellt und eingehalten werden. Mit der Architekturdokumenta-
tion kann das Unternehmen auch zeigen, dass es Compliance-Anforderungen einhält.
Um beispielsweise nachweisen zu können, dass Datenschutzvorgaben für Kundendaten
eingehalten werdery muss dokumentiert sein, in welchen Systemen Kundendaten verar-
beitet werden.
107
7.2 Struktur und !nhalte einer Enterprise-Architecture Geschäftsarchitektur

Abbildung 25 zeigt typische Inhalte einer Unternehmensarchitektur. Für jede Teilarchi

_w
<<liesciif,!hro:ess\]
J

tektur sind zentrale Objekttypen und Beziehungen angegeben. Die verwendeten Ebenen
Fäkturierung
und Inhalte finden sich so oder ähnlich in den meisten Veröffentlichungen, Standards
und EAM-Softwaretools wieder (vgl. u. a. [Ha16], [OG18a], [OG19], [Ti20b]). Das Meta-
modell ist jedoch vergleichsweise stark vereinfacht, Für die Darstellung wurde cler Mo- Anwendungs-
delliemngsstandard ArchiMate verwendet (vgl. Kapitel 7.5.2). landschaft
lur
Abbildung 26 illustriert die Anwendung des Metamodells anhand einiger konkreter
Beispiele, wie sie in einem Unternehmen vorkommen könnten.

§oftware-
infrastruktur

<<lechnoklüia!: 0
Fibu-Standard-
Softwareprodukt

Abbildung 25: Beispiele für die lnhalte einer Enterprise-Architecture-Dokumentation

Im Zentrum der Geschäftsarchitektur finden sich meist die Geschäftsprozesse oder al-
ternativ die Geschäftsfähigkeiten (Capabilities, vgl. Kapitei 7.3). Hinzu kommen dier art
den Geschäftsprozessen beteiligten Organisationseinheiten und die Produkte, die rrrit-
hilfe der Geschäftsprozesse erstellt werden. Neben physischen Produkten kann es siclr
auch um Dienstleistungen handeln. Zur Realisierung der Geschäftsfähigkeiten tragt'rr
Geschäftsprozesse, Organisationseinheiten und Anwendungssysteme bei'

Geschäftsprozesse nutzen und erzeugen Daten, die auf der Ebene der Geschäftsarclri
tektur als relativ grobgranulare Geschäftsobjekte abgebildet werden. In Abbildurrg 2t,

Abbildung 25: Einfaches Metamodell für die Enterprise-Architecture-Dokumentation

108
sind als Beispiele zwei Geschäftsprozesse dargestellt. Die Projektabwicklung erzeugt un-
ter anderem das Geschäftsobjekt ,,Projektabrechnung", das vom Fakturierungsprozess
genutzt wird.
Geschäftsprozesse werden meist von Anwendungssystemen unterstützt. Diese gehören
zur Ebene der Anwendungslandschaft. Dort werden insbesondere auch die Schnittstel-
Ien zwischen den Anwendungssystemen betrachtet, zudem die von den Anwendungs-
systemen verwalteten und über die Schnittstellen ausgetauschten Daten. In Abbildung
25 wird nicht zwischen Geschäftsobjekten und Daten der Anwendungsebene unterschie-
den. Daher wurden die Geschäftsobjekte auf der Trennlinie zwischen der Geschäfts- und
der Anwendungsebene eingezeichnet. Im Beispiel von Abbildung 26 enthäli das für die
Projektabwicklung genutzte Anwendungssystem ,,PVS-X" die Projektabrechnungen
und übermittelt sie an das Anwendungssystem ,,FIBIJO7", wozu es die von diesem Sys-
tem bereitgesteilte Schnittstelle,,AB-IF" nutzt.
Für die Anwendungssysteme, Schnittstellen und Geschäftsobjekte kännen verschiedene
Softwaretechnologien genutzt werden. Hierzu gehören etwa Programmiersprachen,
Standardsoftware-Pakete, Datenbanken, ÜTbertragungsprotokolle usw. So nutzt die An-
wendung PVS-X unter anderem die Programmiersprache Java und eine MySQL-Daten-
bank. Die Schnittstelle ,,AB-IF" basiert auf der REST-Architektur, Grundlage für das An-
wendungssystem,,FIBUOT" ist ein Standardsoftwareprodukt.
eine IT-Leistung zu erbringen, wie etwa die Bereitsteliung einer Anwendung oder die
Installation eines PCs. Das Management von IT-Services wird in Kapitel 8 ausführlicher
beschrieben.
Der für die obigen Abbildungen verwendete Modellierungsstandard ArchiMate (vgl.
Kapitel 7.5.2) bietet hierfür entsprechende Konstrukte an. Dabei können Services auf
allen Ebenen modelliert werden. Anstatt Geschäftsprozesse direkt mit den genutzten
Anwendungssystemen zu verbinden, modeliiert man die Anwendungssysteme als An-
bieter von ,,Anwendungsservices". Die Geschäftsprozesse nutzen dann diese Anwen-
dungsservices. Nach dem gleichen Prinzip werden Infrastrukturelemente als Anbieter
von Infrastrukturservices modelliert, die dann von Anwendungssystemen genutzt wer-
den.
In Abbildung 27 wurde diese Modellierung für einen Teil des Beispieis aus Abbildung
26 angewandt. Das Anwendungssystem ,,Pvs-x" realisiert nun u. a. die zwei services
,,Projektverwaltung" und ,,Proiektreporting", die von dem GeschäftsProzess ,,Projektab-
wicklung" genutzt werden. Das TechnolclS;ie-Element ,,MySQL" realisiert den Techno-
logieservice ,,Speicherung", der nun wiederum vom Anwendungssystem ,,PYS-X" m
Speicherung seiner Daten genutzt wird.

Auf der untersten Ebene sind die Elementc dcr Betriebsinfrastruktur abgebitdet. Dabei
handelt es sich im wesentlichen um Computer, weitere Hardwarekomponenten und
systemsoftware, wie z. B. Betriebssysteme. In dem Beispiel wird gezeigt, auf welchen
bef Lrtzr rür I tLr AnWendUngS-
Servern die genannten Technologien und die darauf aufsetzenden Anwendungssysteme lrenr.nzt

laufen.

In der Praxis werden die im obigen Metamodell aufgeführten objekttypen häufig um

weitere Objekttypen ergänzt und auch weiter untergliedert. So lassen sich Geschäftspro-
zesse in Teilprozesse aufteilen, und Anwendungssysteme können aus kleineren Anwen-
dungskomponenten bestehen. Auch ist es etwa möglich, dass ein Anwendungssystem
mehrere Geschäftsprozesse unterstützt oder umgekehrt ein Geschäftsprozess von meh-
reren Anwendungssystemen unterstützt wird.

Je nach Unternehmenssituation und Anforderungen an die Architekturdokumentation o. ,'.,.., I Software-

sind die aufgeführten Beziehungen weiter zu differenzieren. Werden beispielsweise für
ein und denseiben Prozess ie nach Organisationseinheiten oder Kundengruppe unter-
schiedliche Anwendungssysteme eingesetzt, so kann es nützlich sein, die ,,unterstützt"-
Beziehung in Abbildung 25 um Informationen über die Organisationseinheit oder die reals,Ei I

Kundengruppe zu ergänzen.
<<Technologi6>5 C
Jenach Anforderungen kann es sinnvoll sein, weitere Inhalte in das Metamodell aufzu- MySQL
nehmen. Beispielsweise könnte man einen Objekttyp ,,IT-Service" aufnehmen. Mit des-
sen Hilfe könnte man darstellery welche systeme, Prozesse etc. zusammenspielen, um Abbildung 27: Modellierung von Services in ArchiMate

110 111
Diese Art der Modeilierung ist umständlicher und bringt zunächst einmal nicht viel
Mehrwert, wenn die bestehenden Verbindungen nur um zusätzliche Service-Objekte
ergänzt werden. Interessant wird die explizite Modellierung von Services im Zusam-
menhang mit Service-orientierten Architekturen, bei denen anstelle von Anwendungs-
systemen cin Irortfolio von Services verwaltet werden muss. Hier entfallen dann die An-
wendungssysteme. Stattdessen wird für die einzelnen Services dargestellt, welche Tech-
nologien sie nutzen oder auf welche anderen Services sie zugreifen.
Auch bei der Nutzung von Cloud-Computin5; besitzt man selbst keine eigenständigen
Systeme, sonclern bezieht Infrastruktur-Services oder fachlich ausgerichtete Services von
einem Anbieter. Diese Services lassen sich gut mithilfe des Service-Symbols rnodellieren.
lnsgesamt sollte man aber kein zu umfangreichcs Metamodell verwendet werden, da die
Modellc sonst sehr komplex und damit schwer verständlich werden. Zudem wird es
sehr aufwendig, die Modelle zu erstellen und zu pflegen.
Croß werden viele Entcrprise-Architecture-Modellc ohnehin, da gr(ißere Untcrnehmen
über Hunderte oder J'ausende von Anwendungen und entsprechend vicle Technologie-
und Infrastrr-rkturkomponcnten verfügen. Derartige Modelle lassen sich nur mithilfc ge-
eigneter Softwarewcrkzeuge verwalten. In grafischen Modellen werden dann irnmer nur
Ausschnitte clargestellt. Beispielsweise kann man Diagramme erstellen, die nur Inhalte
einer Architekturebene cnthalten, oder nur die Beziehungen einiger ausgewählter An-
wendungssystcmc.
Solchc EAM-Werkzeuge können zu den verschiedenen Objekten und Beziehungen auch
noch zahlreiche weitere Attribute speichern, wie z. B.
. Be'schreibungcn
o Verantwortlichkeiten
o Kosten
o Herstcller, Lizenzmodcll, ...
e Bewertungery z. B. hinsichtlich Nutzen, ,,Gesundheitszustand", Erweiterbar-
keit, Schutzbedarf ...
o Status
. Nutzungszeitraum
Nicht alle Attribute sind für jeden Objekttyp sinnvoll. So wlrd man für Geschäftsobjekte
eine andere Auswahl an Attributen verwenden als für Anwendungssysteme.
Bei dem Punkt ,,Bewertungen" in der obigen Attributliste handelt es sich um Einschät-
zungen der ieweiligen Verantwortlichen und weiterer Stakeholder. Der ,,Gesundheits-
zustand" eines Systems hängt davon ab, wie viele Probleme es damit gibt. Beispielsweise
hat ein System, bei dem häufig Fehler oder Abstürze auftreten, einen schlechten Gesund-
heitszustand. In einem solchen Fall sollte über eine grundlegende Überarbeitung oder
Ablösung dieses Systems nachgedacht werden.
1r2
Status und Nutzungszeitraum slnd für die zeitliche Planung nützlich. So kann hinterlegt
werden, ob sich ein System noch in Planung, in der Pilotphase, im produktiven Einsatz
oder in Ablösung befindet.
7.3 Geschäftsfähigkeiten
Die oberste Ebene in Abbildung 25, die Geschäftsarchitektur, dient der Beschreibung
fachlicher Zusammenhänge. Hierbei stehen c.rftmais die Geschäftsprozesse, also die be-
trieblichen Abläufe, im Fokus. Eine Prozesslandkarte kann als Überblicksdarstellung
zum Einstieg in die Enterprise-Architecture verwendet werden. Im Zentrum stehen da-
bei die Kernprozesse, die die Produkte und Dienstleistungen erstellen. I-Iinzu kommen
Unterstützungs- und Managementprozesse. Von der Landkarte aus kann man zu detail-
lierten Prozessdarstellungen und zu weiteren verbundenen Inhalten navigieren, z.B. zu
den bearbeiteten Geschä{tsobjekten oder den unterstützenden Anwendungssystemen.
In Kapitel 3.2 wurden die Prozesse des IT-Managements in Form einer Irrozesslandkarte
dargestellt.
Tcilweise werden in der Geschäftsarchitektur stattdessen die sogenannten Geschäfts-
fähigkeiten (cnglisch ,,Business Capabilities") in den Mittelpunkt gestellt. Mit ihnen
wird beschrieben, was eln Unternehmen tun kann. Zu den Fähigkeiten eines Unterneh-
mens gehört beispielsweise, dass es Produkte herstellen kann, oder dass es Kunden-
beziehungen managen kann. Während ein Geschäftsprozess beschreibt, zuie ein be-
stimmtes Ergebnis erreicht wircl, geht es bei Geschäftsfähigkeiten nur darum, I.t)as das
Unternehmen kann.
Zur Realisierung von Geschäftsfähigkeiten werden somit Geschäftsprozesse benötigt.
Hinzu kommen Mitarbeiter und Organisationseinheiten, IT-Systeme, Informationen
und weitere Ressourcen (vgl. [OG18b]). Entsprechend enthält das in Abbildung 25 ge-
zeigte Metamodell mehrere ,,realisiert"-Beziehungen, die von den Objekttypen Ge-
schäftsprozess, Organisationseinheit bzw. Anwendungssystem zur Geschäftsfähigkeit
verlaufen. Die für eine Geschäftsfähigkeit benätigten Informationen sind in Form der
Geschäftsobjekte indirekt über deren Verbindung zu den Geschäftsprozessen zugeord-
net.
Abbildung 28 zeigt die oberste Ebene einer ,,Capability-Map" , wie sie in einer Versiche-
rung aussehen könnte. Die darin aufgeführten Geschäftsfähigkeiten sind recht grob-gra-
nular. Sie lassen sich weiter unterteilen. So könnte die Geschäftsfähigkeit ,,Schadensab-
wicklung" aus den folgenden detaillierteren Fähigkeiten bestehen: ,,Schadensmeldung
erfassen", ,,Schaden bewerten", ,,Schaden regulieren". Auch diese Fähigkeiten können
weiter unterteilt werden, sodass eine mehrstufige Hierarchie entsteht.
113
 Ein Grund für die Verwendung von Capability-Maps als oberste Gliederungsstruktur
besteht darin, dass die Geschäftsfähigkeiten und ihre Struktur recht stabil sind, wohin-
gegen etwa die Geschäftsprozesse öfter geändert werden.

[L ""lliU Üherflüssig werden Prozessmodeile dadurch allerdings nicht. Der Unternehmenserfolg

Produklmana0ement Nlarketin0

,"*-e G"-*;ml hängt nicht nur davon ab, welche Fähigkeiten prinzipiell vorhanden sind, sondern auch,
t- "*T:l_J wie gut diese umgesetzt sind. Insofern müssen die Prozesse auf allen Ebenen betrachtet
KundenbetreuLing
und ständig verbessert werden. Der Zusammenhang zwischen Prozessen und Fähigkei-
Vertrags- und Schadelrsmanagement
ten ist wechselseitig: Prozesse können Fähigkeiten realisieren, und für die Durchführung
a-,---;m aln*"rE)
I ll beziehunos- | I üs- I a,.,.*;;d-)
a-v","s.rfil
teDenszvK
I'IIäDWICKIUNOI I I
der Prozesse werden wiederum Fähigkeiten benötigt.
L--:'":--, [-rye"ü'-, \._l'a"ag:rylJ \_____'
-/
fi;.q*m f K,"d;fE) Die zuletzt genannte Abhängigkeit - Prozesse benötigen Fähigkeiten - wurde nicht in
i der I I daten- |
a-;;"-*_l a-;;;;El
I veruatt"ung ll veaaltung das Metamodeil aus Abbildung 25 eingezeichnet. Ebenso ist dort kein Objekttyp für be-
t-!ry!v:J [-rare:ry-J I

triebliche Funktionen vorhanden. Selbstverständlich lässt sich das Metamodell entspre-

chend erweitern. Dadurch steigen allerdings die Komplexität und der Modellierungs-
a;jElf-;;Ji:;ä';",*ll
Unterstutzuno

a's,"ü,-:h e a-;;; A a.--;; dl f|_- dl
| "",*J*:;",*l [ "f:ä::"'*ll
.n5,1,"","^*ll ,,!:ii;1,?;'*l
lrrv'""g"'"''Fl
Abbildung 28: Vereinfachte Capability-Map einer Versicherung (in Anlehnung an Ita17])
Für die Identifikation und Strukturierung von Geschäftsfähigkeiten gibt es keine allge-
meingültigen Regeln. Für manche Branchen gibt es beispielhafte Capability-Maps, an
denen man sich beim Aufbau des eigenen Modells orientieren kann. Letztlich sollte aber
die individuelle Situation und Strategie des Unternehmens berücksichtigt werden. Ar-
beiten Fachabteilungen und IT beim Aufbau der Capability-Map zusammen, so entste-
hen hierdurch ein einheitliches Verständnis und ein gemeinsamer Bezugsrahmen für die
Weiterentwicklung von Organisation und IT.
Geschäftsfähigkeiten weisen viele Gemeinsamkeiten mit betrieblichen Funktionen auf.
Funktionen fassen die Aktivitäten eines Unternehmens nach verschiedenen I(riterien zu-
sammen/ z, B. nach Art der Tätigkeit oder den bearbeiteten Objekten. Beispieie für typi-
sche betriebliche Funktionen sind ,,Yertrieb",,,Einkauf" oder ,,Technik". Auch sie kön-
nen hierarchisch in detaillierte Funktionen untergliedert werden. In einer Funktionshier-
archie können die gleichen Unterfunktionen an mehreren Stellen vorkommen.
Beim Aufbau einer Hierarchie von Geschäftsfähigkeiten orientiert man sich hingegen
nicht an den aktuell durchgeführten Tätigkeiten, sondern an den zur Erreichung der Un-
ternehmensziele benötigten Fähigkeiten. Bei der Unterteilung einer Fähigkeit wird ge-
fragt, welche detaillierten Fähigkeiten zu ihrer Umsetzung benötigt werden. Jede Fähig-
keit findet sich nur an genau einer Stelle in der Fähigkeitshierarchie (vgI. [La17]).
Beim Aufstellen einer solchen Fähigkeitshierarchie werden zudem alle benötigten Fähig-
keiten aufgenommen * auch solche, über die das Unternehmen derzeit noch nicht oder
nicht im erforderlichen Maß verfügt. Hieraus lässt sich Verbesserungspotenzial identi-
fizieren.
aufwand. Daher muss man abwägen, ob der Nutzen durch die zusätzlichen Informatio-
nen dies gerechtfertigt. Zudem werden insbesondere Inhalte aus der Geschäftsarchi
tektur vielfach bereits in anderen Modellen und Tools verwaltet, z. B. in Prozessmodei-
Iierungswerkzeugen. Dann bietet es sich an, in geeigneter Weise auf die dort vorhan-
denen lnhalte zu verlinken.
Geschäftsfähigkeiten werden häufig als Basis für Analysen verwendet. Auf detaillierter
Ebene können die Fähigkeiten etwa zum Vergleich und zur Auswahl von Standardsoft-
ware-Lösungen herangezogen werden. Dabei wird für iedes zur Auswahl stehende
Softwaresystcm untersllcht, wie gut es die einzelnen Fähigkeiten unterstützt, die für den
entsprechenden Anwendungsbereich relevant sind. Das Vorgehen zur Auswahl von
Standardsoftware wird in Kapitel 9.1 genauer beschrieben.
Capability-Maps können für Lrberblicksdarstellungen von Analyseergebnissen genutzt
werden. Hierzu bewertet man die detaillierten Fähigkeiten oder die zugehärigen Ge-
schäftsprozesse, IT-Systeme etc. und aggregiert die erhaltcnen Kennzahlen in geeigneter
Weise über die Hierarchie der Fähigkeiten. Auf der obersten Ebene werden dann in der
Capability-Map die Geschäftsfähigkeiten je nach Ergebnis unterschiedlich eingefärbt. Im
einfachsten Fall beschränkt man sich auf die Farben grün, gelb und rot - je nachdem, ob
die Werte innerhalb oder außerhalb des gewünschten Bereichs liegen.
Derart eingefärbte Capabiliiy-Maps werden auch als ,,Heatmaps" bezeichnet' Ahnilcn
wie auf dem Wärmebild eines Gebäudes die schlecht isolierten Stellen sichtbar werden,
sind hier die problematischen Geschäftsfähigkeiten deutlich hervorgehoben (v91.
[Ke17]). So geht aus Abbildung 29 hervor, wie effizient die Geschäftsfähigkeiten umge-
setzt sind. Bei den dunkel gefärbten Geschäftsfähigkeiten herrscht besonders großer Ver-
besserungsbedarf. Zur Analyse und zur Entwickiung von Verbesserungsvorschlägen
kann man die Modellhierarchie soiange nach unten durchgehen, bis man zu den Fähig-
keiten, Geschäftsprozessen, Rollen usw. gelangt, die zu der schlechten Bewertung füh-
ren.

114 115
 angezeigt. Was für die jeweilige Fragestellung nicht relevant ist, wird ausgeblendet. Die
Inhalte der verschiedenen Diagramme werden mithilfe eines EAM-Tools konsistent ge-
halten. Andert rnan etwa den Namen eines Objekts, das in mehreren Diagrammen ange-
Produklmanagement zeigtwird, so wird er automatisch in allen Diagrammen aktualisiert.
|.__-,
t__I_:_J t "'yi3*i
l r-;;Bl f*------*.*-;EI
Lir::'' ..1
Es müssen auchnicht all diese Diagramme individuell modelliert werden. Viele EA-Sys-
teme können Diagramme automatisch generieren und somit verschiedene Aspekte der
Kundenbelreuhfig Enterprise-Architecture visualisieren.
I Managemonffil
der *l
I v"nrl"b:k*19, a-;;*dl
|
a-n*d*a.)
II bezrehungs l
Pflegt man für die einzelnen Architektur-Elemente Angaben wie Kosten oder die stra-
t \_, ___
".,r,,-o L.3139:!:gJ tegische Bedeutung, so kann man auch weitergehende Analysen durchführen und die
f-;;
- 'y1 l
t_
E'r
l'- ^*,,,3",
[_!gSt_-l
.".q
f--X,jx;f-El
I manasemenr J
Ergebnisse in verschiedener Form darstellen, beispielsweise als Entscheidungsgrund-
Iage für die Entwicklung der IT-Strategie. So können viele EAM-Systeme Heatmap-
Darstellungen erzeugen. Ein Beispiel zeigt Abbildung 29. Ebenso lassen sich Portfolio-
Unt6rstiltzung

---"-jfl "."Elf
-;;.d-lt-,*El[-;;-Elf --*,*;m][-_m Darstellungen generieren, bei denen die Anwendungssysteme nach ihrem Strategie- und
f
*;;;;;ä,-l Wertbeitrag in dem Schema aus Abbildung 8 (Kapitel 4.4.5) angeordnet werden.
t-j,t.,:lls_, I man'gement
| | | -'j;:",i."*l tffA"] [-1-:n*"*j
Häufig werden auch Bebauungspläne wie in Abbildung 30 verwendet. Dieses Bcispiel
Etlitienzt f] nu, f mittel ffi schrecht zeigt, welche Anwendungssysteme die verschiedenen Geschäftsprozesse unterstützcn.
Abbildung 29: Heatmap auf Basis der Capabili§-Map aus Abbildung 28 In senkrechter Richtung sind die Anwendungssysteme zudem nach den verantwortli-
chen Organisationseinheiten angeordnet.
Je nach Bewertungskriterium kann man unterschiedliche Heatmaps erstellen. So kann
man etwa bewerten, wie gut die lT-Unterstützung für die einzelnen Fähigkeiten ist. An-
Ge6chäftsprozesse
dere Kriterien sind z. B. die Kosteneffi zienz oder die Einhaltung von Compiiance-Anfor-

Lmmm@tm
derungen (vgl. Kapitel 6.5). Vertrieb Marketing

7.4 Analysen und Visualisierungen

Verwaltet man die Inhalte der Unternehmensarchitektur mit einem geeigneten EAM-
Tr*t
l5 -[ f----nlf---fl]
I ncrec ll cor.r
l-"ll--'l
Tool, so kann man die diversen Elemente mit ihren Attributen und Beziehungen in ver- lü El I

schiedenster Weise durchsuchen, analysieren und visualisieren. So lässt sich bei einer l$51
gut gepflegten EAM-Datenbasis beispielsweise sehr schnell herausfinden, welche Ge- C I(J I

schäftsprozesse von der Veränderung eines bestimmten Anwendungssystems betroffen

sind. Ebenso kann man erkennen, zwischen welchen systemen es überlappende Funk-
y
ü lt,
lc
5 l€:l
I
I
f,
FIS
tionalitäten gibt, in welchen Systemen welche Daten verwaltet werden usw. E
y ITEI
€ l= El R 3,3
Die meisten EAM-Systeme ermöglichen es, entsprechende Auswertungen interaktiv zu
täot
H tä-J
erstellen oder durch vordefinierte bzw. selbst programmierter Reports zu generieren.
Neben tabellarischen Darstellungen können die Inhalte und Auswertungsergebnisse
auch auf verschiedene Arten visualisiert werden.
2 la
lc
le:[
ls
I
I
[---fll
Et I ACrAc I

lE ?l
Eine Art der visualisierung sind grafische Modelle, ähnlich wie in Abbildung 26. Wie
bereits in Kapitel 7.2 ausgefilhrt, wird man meist eine ganze Reihe von Diagrammen
erstellen, die jeweils einen Ausschnitt aus der Gesamtarchitektur enthalten. Je nach Ziel-
ls6l
tö__l l-,,1
Lesencte: f]rrt flc*p{ant ILangfristis
setzung eines Diagramms werden nur bestimmte Typen von Objekten und Beziehungen
Abbildung 30: Bebauungsplan der lT-Unterstützung für das Geschäft (nach [Ha16])

116
 r
Anwendungssysteme werden häufig mit firmeninternen Kürzeln bezeichnet. Diese sind
hier fiktiv, Sie sind zudem mit Release-Nummern versehen, denn häufig sind unter-
schiedliche Releases derselben Systeme parallei im Einsatz. Schließlich wurden die Sys-
teme gemäß ihrem Pianungsstatus unterschiedlich eingefärbt. So sieht man, welche Sys-
teme aktuell im Einsatz sind (,,Ist"), welche gemäß aktueller Planung in nächster Zeit
eingeführt werden (,,Geplant") und welche langfristig anvisiert sind (,,Langfristig").
Eine solche Grafik macht es beispielsweise sichtbar, wenn fast jede Organisationseinheit
ein anderes System für ein und dieselbe Aufgabe verwendet. In einem solchen Fall sollte
man prüfen, ob man diese Systeme nicht zu einem einzigen System konsolidieren kann.
Auch sieht manbeispielsweise, wie viele unterschiedliche Systeme innerhalb eines einzi-
gen Prozesses genutzt werden. Sind es zu viele, so führen die zwischen diesen Systemen
auftretenden Brüche bei der Prozessabwicklung unter anderem zu aufwendigen und
fehlerträchtigen Mehrfacherfassungen sowie zu redundanten Daten, die nur schwer
In Abbitdung 31 findet sich ein Beispiel eines eher technisch attsgt't tr'lrlllt'rr llcbauungs-
plans. Er verdeutlicht, welche Technologien aus welchen teclrnist'lrt'rr l)ttrrr,iltcn ln den
einzelnen Anwendungssystemen eingesetzt werden. Auch hicratrs l,trru'tt riir'lt ttnter an*
derem Konsolidierungs- und Modernisierungserfordernisse crnrillt'lrr irr tlrt'scm Fall
auf technischeBausteinebezogen.AlsKriteriumfürdieunterschicr.llit'lrl Iiirrl,rrlrttr-rgder
Technologien wurde in diesem Fall der Freigabestatus bzgl. der Kottlot rrrll,tl zrr IJtrtcr-
nehmens-Standards gewählt. Bei nicht-konformen Technologien solllr' 1ir'1,r'r111 wt:rtlcn,
ob und wann sie ggf. ersetzt werden können,
Ais weiteres Beispiel zur Visualisierung von EA-Inhalten ist in Abbiklrrrrli llll rttr Irrlirr-
mationsflussdiagramm dargestellt, Hier sieht man/ welche AnwentlttttlSry:rlltt tt' litt t lit'
Verwaltung welcher Geschäftsobjekte zuständig sind, und welche Ccst'lr,illsolrlcl.lt'zwi-
schen weichen Anwenriungssystemen ausgetauscht werden. Aus Cr(irtrllrt rl,'r lll,r'r'
sichtlichkeit sind jeweils nur die wichtigsten Geschäftsobjekte eingozciclrrrt'l ,

konsistent zu halten sind. Weiße Flecken im Bebauungsplan können auf Bereiche man-
gelnder IT-Unterstützung hindeuten.
Je nach Fragestellung lassen sich Bebauungspläne mit ganz unterschiedlichen Dimensio-
nen und Inhalten erzeugen. So könnte man etwa auf fachlicher Ebene ein Diagramm
erstellen, das die Frage beantwortet, welches Geschäftsobjekt von welchem Informa-
Da sich die IT-Landschaft ständig ändert, sollten zu den einzelnen Systorrr|rr ,rrr( lr /i'rl
liche Informationen hinterlegt werden, wie z, B. Entwicklungsbeginn, l3t'lillrrr rlr't l'tlol
phase und Zeitpunkt der Produktivsetzung. Die verschiedenen Vorhab('lr l,tilttt,'tt ,l,rttrt
in ihrer zeitlichen Reihenfolge in einem Gantt-Chart (Balkenplan) dargt'slt'lll rv,'t,lltt
Ein Beispiel findet sich in der oberen Hälfte von Abbildung 9 in Kapile I 4 .'l r, lt t, l,'t r r

tionssystem in welchem Geschäftsprozess genutzt wird. kann der Zustand der Architektur zu verschiedenen Zeitpunkten visttalisit't I tv,'r( 1,'n,

wie dies in der unteren Hälfte von Abbildung 9 angedeutet ist.

Technische Domänen

lnfrastruktur-Software
rs4 fl
r_:::- ---l
l"*i"':5
rsz fl
O
r---*-]
I Einkaufskonditioneh I

I Lieferanlen I
BS 2000

rs3 s.]

I Versandaufträge I

I Kunden.Lleferdaten I

Abbildung 32: lnformationsflussdiagramm (nach [Ha16l)

118
 Y

I ti,' . .trrr l rrt r t t'ittigc wenige Beispiele für mögliche Auswertungen und Visualisierungen
1,
'
n l' ?/\ lr r lra ltcn, wie sie von den meisten EA-Tools angeboten werden. Welche lnhalte
l'r'[)ll('g[ und welche Auswertungen erstellt werden sollten, hängt von den jeweiligen
liitrsa tzszenarien und den konkreten Fragestellungen ab. Es sollte daher bei der Auswahl
det zu dokumentierenden Inhalte und der verwendeten Analysemethoden konkret ge-
prüft werden, welche Informationsbedarfe vorliegen und welchen Nutzen die entspre-
chenden InJormationen bringen.

7.5 Frameworks
Esexistiert eine Reihe von Frameworks, an denen sich Unternehmen beim Aufbau ihres
Enterprise-Architecture-Manag;ements orientieren können. Besonders weit verbreitet
sind die zwei von dem Industriekonsortium ,,The open croup,, entwickelten Frame-
works TOGAF und ArchiMate, TOGAF beschreibt clie verschiedenen Aspekte, Inhalte
und Vorgehensweisen des EAM. ArchiMate definiert eine grafische Notati6n, mit der
Unternehmensarchitekturen modelliert werden können. Die beiden Frameworks ergän-
zen sich, können jedoch auch unabhängig voneinander eingesetzt werden.

7.5.1 TOGAF

Im Zentrum von TOGAF (,,The open Group Architecture Framework,,) steht cler Archi-
tektur-Entwicklungszyklus aus Abbildung 33. Er fasst die wichtigsten EAM-Aufgaben
zusammen.
Zur Vorbereitung müssen die benötigten Architekturfähigkeiten aufgebaut werden.
Hierzu gehört es unter anderem, die organisatorischen Voraussetzungen zu schaffen
und geeignete Methoden und Vorgehensweisen einzuführen. Gegenstand der phase A,
,,Architekturvision", ist es, die mit dem EAM verfolgten Ziele und clen hierdurch erwar-
teten Nutzen für clas Unternehmen zu definieren.
In den Phasen B bis D werden die Inhalte der verschiedenen Architekturebenen entwi-
ckelt. Diese entsprechen im Wesentllchen den in Kapitel 7.2yerwend,eten Ebenen, wobei
die ,,Informationssystemarchitektur" mit der Anwendungslandschaft aus Abbildung 25
vergleichbar ist, und die ,,Technologiearchitektur" die Ebenen der Softwareinfrastruktur
und der Betriebsinfrastruktur zusammenfasst.
In Phase E werden Vorhaben zur Weiterentwicklung der Architektur identifiziertbzw.
vorgeschlagene IT-Projekte aus Architektursicht bewertet. Ergebnis von Phase F ist eine
Roadmap mit der zeitlichen Planung der verschiedenen Vorhaben. Letztlich sind dies
Inhalte der IT-strategie, das EAM liefert hierfür die notwendigen Informationen und
Entscheidungsgrundlagen.
Schließlich spielt das EAM auch für die konkreten Implementierungsprojekte eine Rolle,
indem es diese Projekte aus Architektursicht berät und sicherstellt, dass Architekturvor-
gaben eingehalten werden (Phase G),
Abbildung 33: Der TOGAF Architektur-Entwicklungsryklus (nach [OG1 8a])
Gegenstand von Phase H ist schließlich das Architekturmanagement selbst. Es muss si-
chergestellt werden, dass der Architektur-Entwicklungszyklus und das Framework an-
gewandt und die EAM-Fähigkeiten des Unternehmens weiterentwickelt und an geän-
derte Anforderungen angepasst werden.
Im Zentrum des Zyklus steht das Anforderungsmanagement, das sich um die Identifi-
kation und die Umsetzung von Anforderungen an die Untemehmensarchitektur küm-
mert. Diese Anforderulrgen sind in allen Phasen des Entwicklungszyklus zu berück-
sichtigen.
Der Kreislauf stellt iediglich eine grobe inhaltliche Reihenfolge der Phasen dar. In der
Praxis wird die Architektur kontinuierlich weiterentwickelt, und der Kreislauf wird für
unterschiedliche Bereiche und mit verschiedenem Umfang vielfach parallel durchge-
fiihrt.
Neben der ausführlichen Erläuterung des Architektur-Entwicklungsyzklus beschreibt
die TOGAF-Spezifikation [OG18al zahlreiche weitere Aspekte einer Enterprise-Archi-
tecture. Dazu gehört unter anderem ein Metamodell, das dem aus Abbildung 25 ähnlicl;
aber wesentlich umfangreicher ist.
Weitere Inhalte betreffen verschiedene Prinzipien, Methoden, Hilfsmittel und Doku-
mente. Schließlich werden auch organisatorische Aspekte wie Rollen, Verantwortlich-
keiten und EAM-Prozesse erläutert.

120
121.
 Y
TOGAF ist ein sehr umfangreiches Framework, das für den praktischen Einsatz erst an
die spezifischen Bedürfnisse des jeweiligen Unternehmens angepasst werden muss.
7.5.2 ArchiMate
Für die Darstellungen in Abbildung 25 bis Abbildung 27 wurde der Notationsstandard
ArchiMate verwendet [OG19j. Hierbei wurde allerdings nur ein kleiner Ausschnitt des
gesamten Sprachumfangs genutzt. Mit insgesamt knapp 60 unterschiedlichen Symbolen,
zwischen denen zahlreiche verschiedenartige Beziehungen angelegt werden können, ist
auch ArchiMate sehr umfangreich.
Zudem gibt es oftmals mehrere unterschiedliche Möglichkeiten, einen bestimmten Sach-
verhalt darzustellen. Daher muss man ArchiMate an seine eigenen Bedürfnisse anpas-
sen, indem man die Symbolpalette einschränkt und festlegt, welche Inhalte mit welchen
Symbolen und Beziehungstypen abgebildet werden.
Einige ArchiMate-Symbole sind der UML (,,UniIied Modeling Language", [OMG1Z])
entnommen, die aus der objektorientierten Softwareentwicklung bekannt ist. Beispiele
sind die in Abbildung 25 verwendeten Symbole für Komponenten (hier für Anwen-
dungssystem-Komponenten genutzt), Schnittstellen und ,,Knoten" (hier als Betriebs-
infrastrukturelement bezeichnet). ArchiMate beschränkt sich jedoch auf die architektur-
relevanten Inhalte, Gegebenenfalls können ArchiMate-Modelle durch UMl-Modelle er-
gänzt werden. Zumeist wird dies im Rahmen von Software-Entwicklungsprojekten ge-
schehen, wenn z. B. die nur grob spezifizierten Datenobjekte für die Implementierung
detailliert ausgearbeitet werden müssen.
Auch für andere Anwendungsgebiete wird man ArchiMate um weitere Notationen er-
gänzen. So enthält ArchiMate einen Objekttyp ,,Geschäftsprozess". Möchte man einen
solchen Geschäftsprozess genauer analysieren oder ihn automatisieren, so muss man
seinen Ablauf detailliert modellieren. Hierzu benötigt man eine spezielle Prozessmodel-
lierungsnotatic'rn, wie z. B. den Standard BPMN (,,Business Process Model and Nota-
tion", [OMG]"31). Eine ausftiLhrliche Einführung in BPMN findet sich in [4,120].
Der große Sprachumfang von ArchiMate rührt zum einen daher, dass nicht nur die ty-
pischen Enterprise-Architecture-Ebenen aus Abbildung 25 abgedeckt werden. Vielmehr
stellt ArchiMate auch Modellierungskonstrukte für die strategische Unternehmensebene
und die physische Ebene der Produktion und Logistik zur Verfügung. Zum anderen las-
sen sich auch projektbezogene Inhalte modellieren, wie z. B. Arbeitspakete oder zu er-
stellende Dokumente (,,Deliverables").
Prinzipiell kann es nützlich sein, auch derartige Aspekte zu modellieren. So kann z. B.
abgebildet werden, welche Anwendungen zu welchen Unternehmenszielen beitragen,
oder welche Systeme von welchen Projekten betroffen sind, Andererseits muss auch
hierbei der Nutzen gegen den unter umständen recht großen zusatzaufwand abgewo-
t22
gen werden. In der Praxis beschränken sich die meisten lJnternehtrrt'tr lrt'i rlll Morlrl
lierung eher auf die typischen Ebenen Geschäftsarchitektur, Anwendutrgt'l) (rrr(l lrrlr,r
struktur.
Die zweite Ursache für den großen Sprachumfang besteht darin, dass ArchiMatt't'irrt'
sehr detaiilierte Modellierung erlaubt. So stehen etwa auf der Ebene der Anwendungs
landschaft nicht nur Anwendungskomponenten und Schnittstellen zur Verfügung, son-
dern auch Anwendungsfunktionen, Anwendungsservices, Anwendungsereignisse und
weitere. Hieraus müssen je nach Anforderungen und darzustellenden Sachverhalten die
geeigneten Symbole ausgewählt werden. Viele Unternehmen kommen mit einem relativ
kleinen Ausschnitt aus dem gesamten Sprachumfang ztrecht, vergleichbar dem aus
Abbildung 25.
Für eine genaue Darstellung der kompletten ArchiMate-Notation wird auf das Spezifi-
kationsdokument [oG19] und die einschlägige Literatur verwiesen, z.B. lLalTl, [wi17].
7.6 EAM im Spannungsfeld von Stabilität und Agilität
Herkömmliche EAM-Ansätze stehen oftmals in dem Ruf, vergleichsweise aufwendig
und bürokratisch zu sein und damit der erforderlichen Agilität der IT im Wege zu ste-
hen. Und in der Tat ist es recht arbeitsintensiv, eine umfassende Architekturdokumen-
tation zu erstellen und aktuell zu halten. Neue lT-Projekte müssen vielerorts langwierigc
Genehmigungs- und Abstimmungsverfahren mit den EAM-Verantwortlichen durchlau-
fen. Damit soll sichergestellt werden, dass einheitliche Architekturstandards eingehalten
werden und die neuen Lösungen sich möglichst gut in die bestehende Systemlandschaft
einfügen. Hierdurch kann es passieren, dass sich digitale Transformationsprojekte aus-
gebremst und eingeschränkt fühlen, weil sie beispielsweise keine freie Hand bei der Aus-
wahl neuer Technologien haben.
Andererseits profitieren auch Innovationsprojekte, die mit hoher Geschwindigkeit
durchgeführt werden, von einem gut funktionierenden Enterprise-Architektur-Manage-
ment. So können geeignete technische Plattformen zur Entwicklung und Ausführung
von Anwendungen bereitgestellt werden, auf denen sich sehr schnell neue Funktiona-
Iitäten umsetzen lassen. Neue Projekte müssen dann keine eigene Infrastruktur aufbau-
In aller Regel müssen neue Lösungen mit bestehenden Systemen integriert werden, z' B.
um neu entwickelte elektronische Dienstleistungen gemeinsam mit den bereits existic-
renden Produkten abrechnen zu kijnnen. Hierfür ist es von großem Vorteil, wenn dic'
existierende Systemlandschaft gut dokumentiert ist. Auch kann ein wirksames Architek-
turmanagement dafür sorgen, dass einheitliche Schnittstellen geschaffen werden. Nettt'
Lösunp;en lassen sich dann einfach und schnell mit den existierenden Systemen verbin
den.
12'\
Nicht zuletzt muss sichergestellt werden, dass auch Innovationsprojekte die Anforde-
rungen an Compliance und Sicherheit erfüllen. Auch hierfür ist ein Architekturrnanage-
ment erforderlich, das geeignete Vorgaben entwickelt und überprüft. Die Dokun-renta-
tion der Architektur ist aus Compliance-Sicht ebenfalls wichtig. Möchte man beispiels-
weise sicherstellen, dass mit Kundendaten nachweislich rechtskonform umgegangen
wird, so muss man zunächst einmal wissen, wo überall Kundendaten gespeichert und
verarbeitet werden. Ohne eine gut gepflegte Architekturdokumentation müssen solche
In.form.ationen erst mühsam erhoben werden.
Um diese Aufgaben erfüllen zu können ohne die benötigte Agilität einzuschränken,
muss sich das Enterprise-Architecture-Management selbst verändern. So wird in [Cb18]
gefordert, das EAM stärker läsungsorientiert zu gestaiten. Es sollte weniger eine Kon-
troliinstanz darstellen, die die Einhaltung von Regeln überprüft, sondern eher eine bera-
tcncle Rolle einnehmen. Hierzu müssen die EAM-Verantwortlichen frühzeitig auf die
Projekte zugehen und ihnen geeignete Methoden zur Verfügung stellen. Im Vorder-
grund steht dabei die Unterstützung der Innovationsteams beim Erreichen ihrer Ziele.
Die Teams sollen in die Lage versetzt werden, eigenständige Architekturentscheidungen
z,Lttreffen, die konsistent mit dem Großen und Ganzen sind.
Dabei spielt clas Feedback aus den Projekten eine wichtige Rolle, um die Enterprise-Ar-
chitecture mit ihren Standards und Rcgeln ständig weiterzuentwickeln und an die Be-
dürfnisse der Projekte anzupassen, In Projekten gesammelte Erfahrungen sollen genutzt
und weiteren Projekten zur Verfügung gestellt werden.
Insbesondere sollten sich nicht nur einige Spezialisten mit dem Thema Architekturma-
nagement beschäftigen. Vielmehr sollte architektonisches Denken möglichst in cler ge-
samten Organisation verbreitet werden, sodass bei Planungen und Entscheidungen in
Business und IT imrner auch die Konsequenzen für die gesamte Unternehmensarchitek-
tur mitberücksichtigt werden.
124
8 IT-Servicemanagement
Unter einem IT,Service wird ganz allgemein eine Leistung verstanden, die mithilfe von
lnformationstechnik erbracht wird, Leistungsempfänger können externe oder interne
Kunden sein. Es kann sich um unterschiedliche Arten von Leistungen handeln (vgl.
[Ax1e]):
r Lieferung eines Gegenstandes
Der Kunde bekommt beispielsweise einen Server oder ein Mobilteiefon geliefert.
Die Verantwc'rrtun6; für den Gegenstand und seine Nutzung liegen anschließend
komplett beim Kunden selbst.
. Zugang zu Ressourcen
Beispiele sind eine Lizenz zur Nutzung einer Software auf einem Arbeitsplatz-
rechner, dje Bereltstellung eines E-Mail-Accounts oder eines Zugangs zu einer be-
triebswirischaftlichen Anwendung.
. Serviceaktionen, d. h, Erbringen von Dienstleistrrngen
Hierzu gehört etwa die Installation und Einrichtung eines Computers am. Arbeits-
platz, die Behebung von Störungen oder die Programmierung eines individuellen
Reports zur Auswertung von Kennzahlen.
Ein Service kann auch mehrere solcher Einzellelstungen bündeln. So gehören zum Ser-
vice ,,Bereitstellung und Support eines Arbeitsplatz-Computers" einerseits der Arbeits-
platz-Computer und die hierfür benötigte Software mit den erforderlichen Lizenz,en,
andererseits auch Serviceaktionen wie die Anlieferung und der Aufbau des Computers,
die Installation der Software und die Behebung von Störtu-rgen.
Aufgabe des lT-Servicemanagements ist es, die lT-Services zu definieren, sie umzusct-
zen und dafür zu sorgen, dass sie mit der erforderlichen Qualität erbracht werden. lrr
der Prclzesslandkarte in Kapitel 3 (Abbildung 2) umfasst dies die drei Kernprozessc ,,lT-
Services definieren", ,,IT-Systeme entwickeln" und ,,IT-Services erbringen". Das I'l' Scr-
vicemanagement spielt somit eine zentrale Rolle, uncl es bestehen enge Verkniipfrttrgt'tt
mit elnem Großteil der anderen Prozesse im IT-Management. So etwa mit dem l'l'-Str,r-
tegie-Prozess, in dern bereits grob festgelegt wird, welche IT-Services mithilfc wt'lcltt'r'
Systeme angeboten werden und welche Projekte hierfür aufgesetzt werden.
IT-Services sollten so gebildet und zugeschnitten werden, dass sie den Kttrrtlt'tt cittr'rt
konkreten Nutzen bringen. Die Gesamtheit aller angebotenen Services wittl itt t'tttt'ttr
Serwicekatalog aufgeführt, aus dem die Kunden die gewünschten Servict's atts',v,tltlt'tt
und bestellen können, Es solite daher überlegt und mit den Kunden besprocltt'r t vvt'r't lt'rt,
was sinnvolle Einträge in einem solchen Katalog - und damit sirurvollc I l-St'tvr,'r's
sind. So werden die meisten Endanwender in den Fachabteilungen wcnig lttlt'tr':'r,r'rl.t
ranhaben,einenServicezurBereitstellungvonRechenzeitauf einemSt'rvt't zttl,tt, ltr'tt
tr,rrtrl.
-auchwenndieseinenotwendigeLeistungdarstellt,dievomlT-Bert'icht't'lrt,trltl
l ,lr