suchung zu COBIT und ITIL - Koordinierungs

Autoren: 

Abschlussbericht 

Wissenschaftliche Untersuchung zur „Integration der COBIT und 

ITIL Standards mit der Rahmenarchitektur IT-Steuerung Bund“ 

Prof. Dr. Ulrich Frank 

Dr. Stefan Strecker 

Dipl.-Wirt.-Inf. Heiko Kattenstroth 

Dipl.-Wirt.-Inf. David Heise 

(BA-Nr.: 0369/10) 

Lehrstuhl für Wirtschaftsinformatik und Unternehmensmodellierung 

Institut für Informatik und Wirtschaftsinformatik (ICB) 

Universität Duisburg-Essen 

Universitätsstr. 9 

45141 Essen 

Tel.: +49-201-183-4041, Fax: +49-201-183-4011 

E-Mail: ulrich.frank@uni-due.de 

18. März 2011

Abschlussbericht BA-Nr. 0369/10 - 2- 

Überblick über die Studie aus Sicht des BMI 

Von Oktober 2010 bis Mai 2011 führte der Lehrstuhl für Wirtschaftsinformatik und Unternehmensmodellierung 

der Universität Duisburg-Essen unter Leitung von Professor Doktor Ulrich 

Frank die wissenschaftliche Untersuchung zur „Integration der COBIT und 

ITIL Standards mit der Rahmenarchitektur IT-Steuerung Bund“ durch. Die Studie wurde vom 

Bundesministerium des Innern (BMI) vom Referat IT-Steuerung Bund (IT 2) beauftragt und 

begleitet. 

Das Ziel der Studie war es, festzustellen, ob die zwei Rahmenwerke IT Infrastructure Library 

(ITIL) und Control Objectives for Information and Related Technology (COBIT) an die Rahmenarchitektur 

IT-Steuerung Bund (RA) „anschlussfähig“ sind. Unter Anschlussfähigkeit 

verstehen die Autoren die Frage, ob sich die RA gemeinsam mit den vorgenannten Rahmenwerken 

einsetzen lässt und welche Schwierigkeiten bei diesem gemeinsamen Einsatz 

zu erwarten sind. Weiterhin wurde betrachtet, wie die RA von ITIL und COBIT profitieren 

kann und konkrete Handlungsempfehlungen zur Weiterentwicklung der RA formuliert. Analysiert 

wurden die Ziele, die Begriffe, die Prozesse und die Organisationsstrukturen von 

COBIT, ITIL und der RA. Die Studie erbrachte aus Sicht des BMI zwei grundsätzliche Ergebnisse: 

• Anschlussfähigkeit ist gegeben: Die Rahmenarchitektur IT-Steuerung Bund ist grundsätzlich 

anschlussfähig an COBIT und ITIL. Das heißt beim gemeinsamen Einsatz 

von ITIL und der RA in den IT-Dienstleistungszentren des Bundes sind keine grundlegenden 

Schwierigkeiten zu erwarten. 

• Keine Ad-Hoc Integration von COBIT, ITIL und RA: Obwohl die hier vorliegende Analyse 

zahlreiche Berührungspunkte zwischen COBIT, ITIL und der RA aufzeigt, ist eine 

schnelle Integration der drei Standards weder möglich noch sinnvoll. Es ist vielmehr 

abzuwägen, welche Elemente von COBIT und ITIL in eine IT-Steuerung der Bundesverwaltung 

einfließen sollten. Nach dieser Entscheidung können dann, basierend auf 

dieser Studie, die Begriffe, die Prozesse und die organisatorischen Strukturen dieser 

drei Rahmenwerke einander angeglichen werden. 

Für die Integration von COBIT und ITIL mit der RA, bietet die Studie drei Handlungsoptionen. 

Diese Handlungsoptionen bauen aufeinander auf und sind nach ihrem Aufwand gestaffelt: 

1) Konsolidierende Angleichung: Bei der konsolidierenden Angleichung werden im Wesentlichen 

die Schnittstellen zwischen ITIL, COBIT und der RA betrachtet. Nur in diesen 

Bereichen werden die Ziele, die Begriffe, die Prozesse und die organisatorischen 

Einheiten konsolidiert und angeglichen. Diese relativ einfach herzustellende Angleichung 

übernimmt unreflektiert nicht nur die Stärken sondern auch die Schwächen der 

drei Rahmenwerke. 

2) Vollständige Integration: Die vollständige Integration der drei Rahmenwerke geht weit 

über eine konsolidierende Angleichung hinaus. Ziele, Begriffe, Prozesse und organisatorische 

Einheiten werden umfassend einander angeglichen. Am Ende dieses Prozesses 

steht ein kohärentes Ganzes, das nur noch die Konturen von ITIL, COBIT und 

der RA enthalten wird. Es ist zu erwarten, dass bei einer vollständigen Integration, die 

Schwächen von COBIT, ITIL und der RA gemildert werden können und das Architektur- 

und IT-Service Management insgesamt eine höhere Reife erlangt. 

3) Verzahnung von IT und Organisation: Noch einen Schritt weiter geht die Empfehlung 

einer besseren Verzahnung von Organisation und IT Management, bei dem IT einen 

Wiss. Untersuchung „Integration der COBIT und ITIL Standards mit der RA“ Universität Duisburg-Essen


höheren Stellenwert in der Organisation eingeräumt wird und diese beiden Bereiche 

zusammenwachsen. 

Die Studie hat zwei grundsätzliche Einschränkungen, die bei der Lektüre zu berücksichtigen 

sind: 

1) Die Studie ist eine Analyse der in Anhang B gelisteten Dokumente. Insbesondere bei 

der Betrachtung der Prozesse und der organisatorischen Rollen wurde also nicht 

überprüft, inwieweit die Prozesse und Rollen in der Praxis auch gelebt werden. Diese 

Prüfung hätte den Rahmen der Studie gesprengt. 

2) Die RA hat derzeit noch sehr wenige Prozesse definiert, sodass der Vergleich der 

Prozesse mit COBIT und ITIL entsprechend allgemein ausgefallen ist. Vor diesem 

Hintergrund konnte nur ansatzweise geprüft werden, welche Prozesse aus COBIT 

und ITIL für die RA relevant sind. 

Der vorliegende Bericht ist in sieben Kapitel gegliedert. Die dem Bericht zugrunde liegende 

Methode wird in Kapitel 1 erläutert. Kapitel 2 dient der Einordnung von ITIL und COBIT in die 

Studie. Die Hauptteile bilden die Kapitel 3 (Ziele), Kapitel 4 (Begriffe), Kapitel 5 (Prozesse) 

und Kapitel 6 (organisatorische Elemente). Kapitel 7 enthält einige Schlussbetrachtungen 

sowie eine ausführliche Beschreibung der Handlungsoptionen, die sich aus der Studie ergeben. 

Der ausschließlich an den Ergebnissen interessierte Leser findet in Anhang A eine Liste 

aller Handlungsempfehlungen. Die Anhänge B–O enthalten sämtliche Detailinformationen 

der Studie. 

Dieser Abschlussbericht wurde von der Universität Duisburg-Essen verfasst und trägt eine 

deutlich wissenschaftliche Handschrift. Um einen raschen Überblick über Gegenstand und 

Ziele des Forschungsberichts zu geben, wurde dem Forschungsbericht dieses Kapitel vorangestellt. 

Weiterhin wurde der Studie mit Anhang A eine Übersicht über alle Handlungsempfehlungen 

in Tabellenform hinzugefügt. An wenigen Stellen wurden vom BMI Fußnoten 

eingefügt, um beispielweise einige Hintergründe genauer zu erläutern. Diese Fußnoten sind 

mit dem Akronym „BMI“ gekennzeichnet. An wenigen Stellen wurde der Text neu formatiert. 

Diese kleinen Änderungen wurden nicht deutlich gemacht. 



Zusammenfassung 

Die vorliegende Studie unternimmt eine vergleichende Analyse der Rahmenarchitektur IT- 

Steuerung Bund (RA) mit den Rahmenwerken IT Infrastructure Library (ITIL) und Control 

Objectives for Information and Related Technology (COBIT). Dazu werden zentrale Ziele, 

Begriffe, Prozesse und Organisationsstrukturen vergleichend betrachtet. Die Untersuchung 

ist dabei vor allem auf zwei Ziele gerichtet: Zum einen ist zu klären, ob und inwiefern die RA 

anschlussfähig an ITIL bzw. COBIT ist. Zum anderen sollen Schlussfolgerungen und Handlungsempfehlungen 

für die Weiterentwicklung der RA vor allem mit Blick auf eine Integration 

mit ITIL bzw. mit COBIT aufgezeigt werden. Dabei soll u. a. betrachtet werden, wie eine 

solche Integration vorzunehmen ist und welche Fragen dazu zu beantworten sind. 

Die Studie lässt vier zentrale Schlussfolgerungen zu: 

1) Anschlussfähigkeit besteht: Die Untersuchung verdeutlicht, dass sich die RA grundsätzlich 

anschlussfähig an die Rahmenwerke ITIL und COBIT zeigt. 

2) Anknüpfungspunkte deutlich erkennbar: Die Analyse der Rahmenwerke zeigt zudem, 

dass die RA sowohl zu ITIL als auch zu COBIT deutliche Anknüpfungspunkte hinsichtlich 

zentraler Ziele, Begriffe, Prozesse und Organisationsstrukturen aufweist. 

3) Kritisch-reflektierte Orientierung für Weiterentwicklung der RA: Die Studie kommt zu 

dem Schluss, dass Potenziale für eine gewinnbringende Weiterentwicklung der RA 

durch eine kritisch-reflektierte Orientierung an Zielen, Begriffen, Prozessen und organisatorischen 

Aufbauelementen in ITIL und COBIT bestehen. 

4) Integration ad hoc nicht möglich: Die Studie zeigt allerdings, dass eine Integration der 

RA mit ITIL bzw. mit COBIT ad hoc nicht möglich ist. Vielmehr ist dazu eine sorgfältige 

Rekonstruktion gemeinsamer Konzepte, d. h. die Entwicklung eines gemeinsamen 

semantischen Referenzsystems, und darauf abgestimmter Prozesse und organisatorischer 

Aufbauelemente erforderlich. 

Die Ergebnisse der Analyse führen zu einer Reihe von Empfehlungen zur Weiterentwicklung 

der RA. Sie betreffen Ansatzpunkte zur sinnvollen Erweiterung und Verfeinerung der RA 

durch ergänzende bzw. weiterentwickelte Ziele, Konzepte und Prozesse sowie organisatorische 

Aufbauelemente. Die Studie legt dazu u. a. erweiterte Zielmodelle der RA, ein überarbeitetes 

und konsolidiertes Glossar der RA, konsolidierte Glossare zu ITIL und COBIT, 

integrierte Begriffsnetze zur RA und ITIL sowie zur RA und COBIT und eine kompakte Aufbereitung 

der Prozesse und organisatorischen Aufbauelemente in ITIL und COBIT als 

Grundlage für die Weiterentwicklung der RA vor. Abschließend werden aus der Analyse 

differenzierte Handlungsempfehlungen zur Weiterentwicklung von Zielen, Konzepten, Prozessen 

und organisatorischen Aufbauelementen der RA abgeleitet und um weitergehende 

Empfehlungen vor dem Hintergrund des gegenwärtigen Stands der wissenschaftlichen Diskussion 

ergänzt, die über die Orientierung an ITIL und COBIT hinausgehen. Die Studie 

schließt mit der Darstellung von drei Handlungsoptionen für die Weiterentwicklung, Einführung 

und Nutzung der RA, die auch als Anregung für die strategische Planung des IT- 

Managements dienen. Sie unterscheiden sich hinsichtlich ihrer Zielsetzung, des Aufwands 

und des zu realisierenden Nutzens sowie des jeweiligen organisatorischen Stellenwerts des 

IT-Managements in der Bundesverwaltung. 

Neben diesem Abschlussbericht sind die Ergebnisse der Untersuchung in einem umfangreichen 

Foliensatz sowie zwei DIN A1-Postern dokumentiert, die am 10.03.2011 in Berlin im 

Rahmen des Abschlussworkshops präsentiert und übergeben wurden. 



Inhaltsverzeichnis 

Überblick über die Studie aus Sicht des BMI ........................................................................... 2 

Zusammenfassung ................................................................................................................... 4 

Abbildungsverzeichnis .............................................................................................................. 7 

Tabellenverzeichnis .................................................................................................................. 8 

1 Ziele und Gang der Untersuchung .................................................................................... 9 

2 Einordnung der untersuchten Rahmenwerke ITIL und COBIT ........................................ 11 

3 Untersuchungsbereich Ziele ............................................................................................ 14 

3.1 Analyse der Ziele der RA ....................................................................................... 14 

3.2 Analyse der Ziele der ITIL ...................................................................................... 16 

3.3 Analyse der Ziele der COBIT ................................................................................. 19 

3.4 Schlussfolgerungen und Handlungsempfehlungen ................................................ 23 

4 Untersuchungsbereich Konzepte .................................................................................... 31 

4.1 Rekonstruktion zentraler Begriffe der RA ............................................................... 31 

4.2 Rekonstruktion zentraler Begriffe der ITIL ............................................................. 33 

4.3 Rekonstruktion zentraler Begriffe der COBIT ......................................................... 35 

4.4 Gegenüberstellung ................................................................................................. 37 

4.4.1 Zentrale Begriffe aus RA und ITIL .............................................................. 38 

4.4.2 Zentrale Begriffe aus RA und COBIT ......................................................... 41 


5 Untersuchungsbereich Prozesse .................................................................................... 48 

5.1 Prozesse der RA .................................................................................................... 48 

5.1.1 Ableitung von Diensten aus Geschäftsprozessen ...................................... 49 

5.1.2 Zusammenwirken von IT-Angebot und IT-Nachfrage ................................. 50 

5.2 Prozesse und Vorgehensweisen der ITIL .............................................................. 51 

5.3 Prozesse und Vorgehensweisen der COBIT ......................................................... 52 


5.4.1 Ableitung von Diensten aus Geschäftsprozessen ...................................... 54 

5.4.2 Zusammenwirken von IT-Angebot und IT-Nachfrage ................................. 55 


5.5.1 Übergreifende Handlungsempfehlungen .................................................... 57 

5.5.2 Prozess: Ableitung von Diensten aus Geschäftsprozessen 

(„Diensteableitung“) .................................................................................... 59 

5.5.3 Prozess: Zusammenwirken von IT-Angebot und IT-Nachfrage 

(„Nachfragebündelung“) ............................................................................. 62 



6 Untersuchungsbereich organisatorischer Aufbauelemente ............................................. 66 

6.1 Organisatorische Aufbauelemente der RA ............................................................. 66 

6.2 Organisatorische Aufbauelemente der ITIL ........................................................... 70 

6.3 Organisatorische Aufbauelemente der COBIT ....................................................... 70 



7 Schlussbetrachtung und Handlungsoptionen .................................................................. 78 

Referenzierte Literatur ............................................................................................................ 85 

Anhang A Liste der Handlungsempfehlungen .................................................................... 87 

Anhang B Grundlagen der Studie: Quellenangaben .......................................................... 89 

Anhang C ITIL-Prozesse und ihre Zielsetzungen ............................................................... 91 

Anhang D Grafischer Übersicht über ITIL-Prozesse .......................................................... 95 

Anhang E Ziele und Control Objectives der COBIT-Prozesse ........................................... 96 

Anhang F COBIT-Prozesse und abgeleitete Bezugsobjekte ........................................... 104 

Anhang G Abgeleitete Bezugsobjekte aus Control Objectives und Aktivitäten der 

COBIT-Prozesse ............................................................................................. 112 

Anhang H Verdichtete Ziele der COBIT-Prozesse ........................................................... 116 

Anhang I Glossar zentraler Begriffe der RA .................................................................... 118 

Anhang J Glossar zentraler Begriffe der ITIL .................................................................. 123 

Anhang K Glossar zentraler Begriffe der COBIT .............................................................. 126 

Anhang L Organisatorische Aufbauelemente der RA ...................................................... 133 

Anhang M Organisatorische Aufbauelemente der ITIL ..................................................... 137 

Anhang N Organisatorische Aufbauelemente der COBIT ................................................ 143 

Anhang O Notation der Semantischen Netze ................................................................... 145 



Abbildungsverzeichnis 

Abbildung 1: Zielmodell der RA für das Handlungsfeld „Handlungsfähigkeit“ [Zielmodell] ..... 15 

Abbildung 2: Rekonstruktion der Ziele der IT Infrastructure Library (ITIL) ............................. 17 

Abbildung 3: Rekonstruktion der Ziele von COBIT aus Sicht der IT-Revision ....................... 20 

Abbildung 4: Rekonstruktion der Ziele der von COBIT thematisierten IT-Prozesse aus 

Sicht des IT-Managements ............................................................................. 22 

Abbildung 5: Gegenüberstellung der zentralen Ziele von RA, ITIL und COBIT mit Fokus 

auf das Zielmodell „Handlungsfähigkeit” ......................................................... 28 


auf das Zielmodell „Wirtschaftlichkeit“ ............................................................. 29 


auf das Zielmodell „Hohe Dienstleistungsqualität“ .......................................... 30 

Abbildung 8: Rekonstruktion der zentralen Begriffe und ihrer Zusammenhänge aus der 

Dokumentation der Rahmenarchitektur .......................................................... 32 

Abbildung 9: Rekonstruktion der zentralen Begriffe und ihrer Zusammenhänge aus der 

Dokumentation der ITIL ................................................................................... 34 

Abbildung 10: Zentrale Konzepte der ITIL, die im Folgenden nicht weiter betrachtet 

werden ............................................................................................................ 35 

Abbildung 11: Rekonstruktion zentraler Konzepte von COBIT der Revisions- 

Perspektive ..................................................................................................... 37 

Abbildung 12: Rekonstruktion zentraler Konzepte von COBIT der Management- 

Perspektive ..................................................................................................... 37 

Abbildung 13: Vergleichende Gegenüberstellung zentraler Konzepte in RA und ITIL ........... 39 

Abbildung 14: Vergleichende Gegenüberstellung primärer Konzepte in RA und COBIT: 

Revisions-Perspektive ..................................................................................... 42 

Abbildung 15: Vergleichende Gegenüberstellung primärer Konzepte in RA und COBIT: 

Management-Perspektive ............................................................................... 43 

Abbildung 16: Übersicht über die ITIL-Prozesse .................................................................... 52 

Abbildung 17: Übersicht der COBIT-Prozesse (in Anlehnung an [COBIT-DE], S. 24) ........... 53 

Abbildung 18: Prozesse aus COBIT und ITIL mit Anknüpfungspunkten an den Prozess 

der RA zur Diensteableitung ........................................................................... 60 

Abbildung 19: Prozesse aus COBIT und ITIL mit Anknüpfungspunkten an den Prozess 

der RA zur Nachfragebündelung ..................................................................... 63 

Abbildung 20: Identifizierte Rollen und Gremien der RA und ihre Beteiligung an den 

zentralen Prozessen ....................................................................................... 69 

Abbildung 21: Identifizierte Rollen und Gremien in COBIT .................................................... 71 

Abbildung 22: Beispielhafter Aufbau eines Unternehmensmodells (eigene Darstellung) ...... 83 

Abbildung 23: Übersicht über ITIL-Prozesse (in Anlehnung an ITGI 2008, S. 20) ................. 95 



Tabellenverzeichnis 

Tabelle 1: Notation und Heuristik für Analyse gemeinsamer Konzepte ................................. 38 

Tabelle 2: Prozess – Ableitung von Diensten aus Geschäftsprozessen ................................ 50 

Tabelle 3: Prozess – Zusammenwirken von IT-Angebot und IT-Nachfrage ........................... 51 

Tabelle 4: Prozesse aus ITIL und COBIT mit Anknüpfungspunkten zum Prozess der 

Diensteableitung der RA ................................................................................. 55 

Tabelle 5: Prozesse aus COBIT und ITIL mit Anknüpfungspunkten zum Prozess der 

Nachfragebündelung der RA ........................................................................... 56 

Tabelle 6: Organisatorische Aufbauelemente der RA ............................................................ 69 

Tabelle 7: Gegenüberstellung organisatorischer Aufbauelemente ........................................ 75 

Tabelle 8: Dokumente, die der Rekonstruktion der RA zugrunde liegen ............................... 90 

Tabelle 9: ITIL-Prozesse und ihre Zielsetzungen ................................................................... 94 

Tabelle 10: Ziele und Control Objectives der COBIT-Prozesse aus der Domäne „Plan 

and Organise“ (PO) ......................................................................................... 98 

Tabelle 11: Ziele und Control Objectives der COBIT-Prozesse aus der Domäne 

„Acquire and Implement“ (AI) ........................................................................ 100 


„Deliver and Support“ (DS) ............................................................................ 102 


„Monitor and Evaluate“ (ME) ......................................................................... 103 

Tabelle 14: COBIT-Prozesse und abgeleitete Bezugsobjekte ............................................. 111 

Tabelle 15: Abgeleitete Bezugsobjekte aus den Control Objectives und Aktivitäten der 

COBIT-Prozesse ........................................................................................... 115 

Tabelle 16: Verdichtete Ziele der COBIT-Prozesse ............................................................. 117 

Tabelle 17: Glossar zentraler Begriffe der RA ...................................................................... 122 

Tabelle 18: Glossar zentraler Begriffe der ITIL .................................................................... 125 

Tabelle 19: Glossar zentraler Begriffe von COBIT ............................................................... 132 

Tabelle 20: Organisatorische Aufbauelemente der RA ........................................................ 136 

Tabelle 21: Organisatorische Aufbauelemente der ITIL ....................................................... 142 

Tabelle 22: Organisatorische Aufbauelemente der COBIT .................................................. 144 


Abschlussbericht BA-Nr. 0369/10 - 9 - 

1 Ziele und Gang der Untersuchung 

Die wissenschaftliche Untersuchung zur „Integration der COBIT und ITIL Standards mit der 

Rahmenarchitektur IT Steuerung Bund“ zielt darauf, die konzeptuelle und prozessuale Anschlussfähigkeit 

der Rahmenarchitektur IT-Steuerung Bund (RA) an die Rahmenwerke IT 

Infrastructure Library (ITIL) in der derzeit aktuellen Version 3 und Control Objectives for 

Information and Related Technology (COBIT) in der derzeit aktuellen Version 4 kritischreflektiert 

zu analysieren. Weiter sollen aus dieser Analyse wissenschaftlich fundierte Handlungsempfehlungen 

für den praktischen Einsatz und die Weiterentwicklung der RA entwickelt 

werden. 

Die drei untersuchten Ansätze RA, ITIL und COBIT, werden in der vorliegenden Studie als 

Methoden interpretiert. Der Untersuchung liegt dabei ein allgemeiner Methodenbegriff zugrunde. 

Unter einer Methode wird allgemein ein systematisches, planmäßig auf ein Ziel 

ausgerichtetes Verfahren zur Lösung einer Klasse von Problemen verstanden, das zu „technischer 

Fertigkeit bei der Lösung theoretischer und praktischer Aufgaben führt“ (Lorenz 

1995, S. 876). Eine Methode besteht mindestens aus einer sprachlichen Struktur und mindestens 

einer darauf abgestimmten Vorgehensweise (Frank 2006, S. 22). Ausgehend von 

diesem Methodenbegriff erfolgt eine Integration durch gemeinsame Begriffe (konzeptuelle 

Integration), und korrespondierende Vorgehensweisen, die auf die gemeinsamen Konzepte 

verweisen (prozessuale Integration). 

Die vorliegende Studie untersucht daher anhand zentraler Ziele, Begriffe, Prozesse und 

Organisationsstrukturen, ob und inwiefern die RA anschlussfähig 1 an ITIL bzw. COBIT ist 

und erörtert Potentiale einer gewinnbringenden, weitergehenden konzeptuellen wie prozessualen 

Integration der RA mit ITIL bzw. COBIT. Im Fokus der Studie steht dabei die paarweise 

Gegenüberstellung der RA mit ITIL bzw. der RA mit COBIT. Anderweitige Überlegungen 

etwa der Integration von ITIL und COBIT sind nicht Bestandteil der Studie (siehe dazu bspw. 

ISACA und itSMF 2008). Aus Gründen der sprachlichen Vereinfachung bezieht sich die 

Rede vom „Vergleich der drei Ansätze“ somit immer auf diese beiden Paarvergleiche. Die 

Analyseziele im Einzelnen umfassen: 

1) Vergleich der Zielstellungen der drei Ansätze. Dazu werden die expliziten und – soweit 

nachvollziehbar – impliziten Zwecke und Ziele sowie intendierte Nutzungsszenarien 

analysiert und zueinander in Beziehung gesetzt. 

2) Vergleich der drei Ansätze hinsichtlich ihrer begrifflichen Kompatibilität. Dazu werden 

Begriffsanalysen durchgeführt und die inhaltlichen Beziehungen zwischen zentralen 

Konzepten untersucht. 

3) Vergleich der drei Ansätze im Hinblick auf ihre prozessuale Kompatibilität. Dazu werden 

zentrale Prozesse identifiziert und auf inhaltliche Überschneidungen, Widersprüche 

und Integrationsmöglichkeiten hin untersucht. 

4) Vergleich der drei Ansätze in Bezug auf die Kompatibilität der organisatorischen Aufbauelemente. 

Dazu werden zentrale Organisationsstrukturen (z. B. Rollen und Gremien) 

der drei Ansätzen identifiziert und auf inhaltliche Überschneidungen, 

Widersprüche und Integrationsmöglichkeiten hin untersucht. 

1 BMI: Unter Anschlussfähigkeit verstehen wir die Frage, ob die RA gemeinsam mit den Rahmenwerken ITIL und 

COBIT eingesetzt werden kann, ohne dass es dabei zu Inkonsistenzen kommt. In diesem Bericht wurden Inkonsistenzen 

bzgl. der Zielstellungen, der Begrifflichkeiten, der Prozesse sowie der Aufbauorganisation von COBIT, 

ITIL und der RA untersucht. 



Zur Durchführung der Studie wurde eine allgemeine Methode zur Evaluation von Artefakten 

für den Vergleich von Rahmenwerken adaptiert (Frank 2000). Die Untersuchungsmethode 

besteht aus einem Bezugsrahmen, der durch die vier Foki Ziele, Begriffe, Prozesse und 

Organisationsstrukturen konstituiert ist und aus einem iterativ durchlaufenen Vorgehensmodell. 

Die Analyse der drei Ansätze erfolgt anhand von Primärquellen und ausgewählter Sekundärliteratur 

(Anhang A enthält eine Aufstellung der untersuchten Quellen) in mehreren, 

iterativ durchlaufenen Schritten der Identifikation, Interpretation, Rekonstruktion und Gegenüberstellung 

zentraler Ziele, Begriffe, Prozesse und Organisationsstrukturen. Diese vier 

Untersuchungsbereiche werden auf Gemeinsamkeiten, Überschneidungen, Ähnlichkeiten 

und Identitäten sowie Widersprüche, Lücken und Divergenzen hin untersucht und interpretiert. 

Dabei treten aufgrund von unklaren, vagen, unvollständigen oder inkonsistenten Spezifikationen 

in den Dokumentationen der drei Ansätze Interpretationsspielräume auf, die nicht 

endgültig ausgeräumt werden können. Dem begegnet die vorliegende Studie dadurch, dass 

Interpretationsspielräume als solche kenntlich gemacht und durch eine entsprechende 

Kommentierung erläutert werden. 

Das vorliegende Dokument fasst die Ergebnisse der Analyse gegliedert nach den vier Untersuchungsbereichen 

Ziele, Begriffe, Prozesse und Organisationsstrukturen zusammen. Die 

Untersuchungsbereiche werden jeweils in gleicher Reihenfolge der behandelten Ansätze 

analysiert: Zunächst wird die RA untersucht, dann ITIL und anschließend COBIT. Abschließend 

erfolgt ein Zwischenfazit zum jeweiligen Untersuchungsbereich mit einer zusammenfassenden 

Einschätzung der Schlussfolgerungen und Handlungsempfehlungen. Am Ende 

des Dokuments wird eine Schlussbetrachtung vorgenommen. Die Darstellung der Untersuchungsergebnisse 

verweist auf einen umfangreichen Anhang. Im Anhang sind u. a. im Rahmen 

der Studie konsolidierte und erweiterte Glossare und Übersichten über Ziele, Prozesse 

und Organisationsstrukturen aufgeführt. Zur Darstellung der Untersuchungsergebnisse 

kommen neben natürlich sprachlichen Beschreibungen tabellarische Übersichten und semiformale 

Beschreibungsansätze (semantische Netze) zum Einsatz. Die verwendete Notation 

dieser Begriffsnetze ist in Anhang O erläutert. 



2 Einordnung der untersuchten Rahmenwerke ITIL und COBIT 

Die IT Infrastructure Library (ITIL) wird seit 1989 von der britischen „Office of Government 

Commerce“ (OGC 2 ) im Auftrag der britischen Regierung entwickelt. Ausgangspunkt für die 

Entwicklung der ITIL war die Beobachtung, dass mit steigender Diffusion von Informations- 

und Kommunikationstechnik die Durchführung der (Geschäfts-)Prozesse in Organisationen 

zunehmend auf die Unterstützung durch Informationssysteme angewiesen ist. Zugleich 

wurde festgestellt, dass sich über verschiedene Organisationen (Unternehmen und Behörden) 

hinweg gleichartige Prozesse und Strukturen etabliert hatten, um die Leistungen der IT- 

Organisation zu erbringen. Aus der Analyse „erfolgreicher“ IT-Organisationen ist ein Bündel 

an Empfehlungen entstanden, das als „good practice“ für das Management von IT- 

Dienstleistungen ([Service Strategy], S. 8) in der mittlerweile dritten Version in der Praxis 

Verbreitung gefunden hat (für einen Überblick über den gegenwärtigen Implementierungsstand 

in der Unternehmenspraxis vgl. Marrone und Kolbe 2011). 

Den inhaltlichen Kern von ITIL (Version 3) bilden eine Reihe von Publikationen, die von der 

OGC herausgegeben werden [Service Strategy; Service Design; Service Transition; Service 

Operation; Continual Service Improvement]. Die Publikationen beschreiben verschiedene 

Aspekte des Managements – d.h. der Planung, der Realisierung, des Betriebs und der 

Überwachung – der Dienstleistungen von IT-Organisationen. Während in Version 2 der ITIL 

der Fokus mit Prozessen wie z. B. „Incident Management“, „Problem Management“ und 

„Change Management“ noch primär auf der Gewährleistung eines möglichst störungsfrei 

laufenden operativen IT-Betriebs lag, liegt mit der dritten Version ein Rahmenwerk vor, das 

das Management von IT-Dienstleistungen über ihren gesamten Lebenszyklus – von Entwurf 

über Umsetzung und Betrieb bis zur Einstellung – betrachten möchte und somit auch auf 

planerische Aspekte [Service Design; Service Strategy] gerichtet ist. 

Darüber hinaus existiert eine Vielzahl weiterer Publikationen zu ITIL von Autoren aus Wissenschaft 

und Praxis (z. B. van Bon 2009). ITIL ist Grundlage der Norm ISO ISO/IEC 20000, 

die aus dem britischen Standard BS 15000 entwickelt wurde. Die Zertifizierung einer IT- 

Organisation kann derzeit nach ISO/IEC 20000-1:2005 (Teil 1 aus dem Jahr 2005) erfolgen. 

Die Control Objectives for Information and Related Technology (COBIT) werden seit 1993 

entwickelt. Die erstmalige Veröffentlichung in der Version 1.0 erfolgte im April 1996 durch die 

„Information Systems Audit and Control Foundation“ (ISACF) als damalige Forschungseinrichtung 

der „Information Systems Audit and Control Association“ (ISACA 3 ). Die ISACA wird 

maßgeblich dominiert von Mitarbeitern der sogenannten „BigFour“-Wirtschaftsprüfungsgesellschaften 

(KPMG, PWC, Deloitte Touche Tohmatsu, Ernst & Young). Ihre Mitglieder 

sind mehrheitlich IT-Revisoren und in der IT-Prüfung (IT-Auditing) tätige Wirtschaftsprüfer. 

Die ISACA bietet ihren Mitgliedern kostenpflichtige Schulungen und Zertifizierungen an und 

ist an der Entwicklung von Prüfungsstandards beteiligt. Nach Version 2 (April 1998) und 

Version 3 (Juli 2000) veröffentlichte das „IT Governance Institute“ (ITGI 4 ) – als 1998 gegründetes 

Nachfolgeinstitut der ISACF – im Dezember 2005 COBIT in der Version 4.0. Eine 

Übersetzung der Version 4.0 in die deutsche Sprache durch KPMG Österreich aus dem Jahr 

2006 liegt vor. In der Folge wird COBIT in einigen Details überarbeitet und im Mai 2007 in 

2 vgl. http://ogc.gov.uk 

3 http://www.isaca.org 

4 http://www.itgi.org/ 



der Version COBIT 4.1 veröffentlicht, zu der derzeit keine offizielle deutsche Fassung vorliegt. 

5 

Den inhaltlichen Kern der COBIT (Version 4.1) bildet die Publikation [COBIT]; begleitet von 

einer Reihe von ergänzenden Dokumenten (u. a. Vorgehensmodelle zur Prüfungsdurchführung 

(siehe u. a. Gaulke 2010, S. 12 sowie [COBIT-DE], S. 195f, ITGI 2007a). Darüber hinaus 

existiert eine Vielzahl weiterer Publikationen der ISACA, des ITGI, der dazugehörigen 

Landesverbände und davon unabhängiger Autoren aus Wissenschaft und Praxis, bspw. 

auch Mappings zwischen COBIT und der ITIL (ISACA und itSMF 2008; ITGI 2007) sowie 

ergänzende Rahmenwerke für IT-bezogene Investitionen (ISACA 2008) und Risiken (ISACA 

2009). 

Die Primärquellen rücken seit der ersten Version der COBIT den spezifischen Fokus der IT- 

Revision (interne Revision und Wirtschaftsprüfung) in den Mittelpunkt. Entstehungshintergrund 

der COBIT bilden verschiedene U.S.-amerikanische Rechnungslegungsstandards des 

„Public Company Accounting Oversight Board“ (PCAOB) und Prüfungsstandards des „American 

Institute of Certified Public Accountants“ (AICPA) sowie deren Anwendung im Rahmen 

der Wirtschaftsprüfung (v. a. Jahresabschlussprüfung) zur Ermittlung einer möglichen Beeinträchtigung 

der Ordnungsmäßigkeit der Rechnungslegung durch Informations- und Kommunikationstechnik. 

Diese Revisionsperspektive hat im Zuge des Sarbanes-Oxley-Act of 2002 

(SOX) und seiner „Section 404“ („SOX 404“) für IT-Organisationen in der Jurisdiktion dieser 

Rechtsvorschriften (z. B. auch für deutsche Unternehmen, die in den USA börsennotiert 

sind) erheblich an Bedeutung gewonnen. Mit der Version 4 werden auch allgemeiner gefasste 

Empfehlungen für das IT-Management formuliert (z. B. es sollte ein „Strategic IT Plan“ 

erstellt werden), deren Bezug zur ursprünglichen Revisionsperspektive deutlich weniger 

offensichtlich ist (siehe dazu auch Strecker 2009). 

Sowohl ITIL als auch COBIT sind im Zeitverlauf zu umfangreichen Rahmenwerken angewachsen. 

Während ITIL im Kern auf die Realisierung eines IT-Service-Managements (ITSM) 

und die Gestaltung und Durchführung des IT-Betriebs gerichtet ist, dient COBIT zur Sicherstellung 

der Einhaltung gesetzlicher und weiterer regulatorischer Anforderungen (im Sinne 

einer IT-Compliance) im Rahmen der IT-Revision (IT-Auditing, Wirtschaftsprüfung). Beide 

Rahmenwerke unterscheiden sich hinsichtlich ihrer Ziele, der verwendeten Terminologie 

(Begriffe) und insbesondere hinsichtlich der vorgeschlagenen Prozesse und Organisationsstrukturen. 

Ferner sind sie vor ihren deutlich unterschiedlichen Entstehungshintergründen 

und den damit verbundenen spezifischen Interessen der beteiligten Akteure zu interpretieren. 

Im Vergleich mit den Empfehlungen in ITIL (die rund 1500 Seiten Umfang aufweisen) ist 

auffällig, dass die Spezifikation der COBIT deutlich weniger umfangreich (die Spezifikation 

umfasst rund 200 Seiten) und deutlich weniger konkret ausfällt, zum Beispiel fehlen weitgehend 

notwendige Details zu Gestaltungsempfehlungen. Beispielsweise wird nicht näher 

ausgeführt, welche Inhalte der oben angeführte „Strategic IT Plan“ thematisieren muss bzw. 

soll. Sehr ausführlich sind in der COBIT-Spezifikation die sog. „Control Objectives“ beschrieben. 

Ein „Control Objective“ kann dabei als ein für einen Revisor prüfbaren Sachverhalt 

aufgefasst werden (z. B. ein „Strategic IT Plan“ liegt vor oder das Gremium „IT steering 

committee“ existiert). 6 

5 Da Versionen 4.1 und 4.0 in weiten Teilen deckungsgleich sind und 4.1 nicht auf Deutsch vorliegt, wird an 

geeigneter Stelle auch auf die deutsche Version 4.0 verwiesen [COBIT-DE]. 

6 Damit ist insofern ein intendierter Zustand (ein Ziel oder „objective“) verbunden als bei Vorliegen eines zu 

prüfenden Sachverhalts davon ausgegangen wird, dass eine mögliche Beeinträchtigung der Ordnungsmäßigkeit 

der Rechnungslegung durch Informations- und Kommunikationstechnik gemindert wird. In diesem Zusammenhang 

ist wenig überraschend, dass COBIT gegenüber ITIL eine deutlich differenziertere Beschreibung von Ver- 



Die Dokumentation zu ITIL wie COBIT betont ihre Interpretation als Rahmenwerke, die für 

konkrete Anwendungszwecke in Organisationen anzupassen seien. ITIL wie COBIT sind 

demnach darauf gerichtet, einen Rahmen vorzugeben, der einer spezifischen Anpassung für 

eine Organisation bedarf. Allerdings wird in den untersuchten Dokumentationen keine Anleitung 

geliefert, wie diese Anpassung erfolgen könnte oder, idealerweise, sollte. Auch hier 

liefert der Entstehungshintergrund eine Erklärung: Beide Rahmenwerke sind nicht nur Gegenstand 

von Konsolidierungsbemühungen vordergründig „neutraler“ Organisationen, sondern 

vor allem Grundlage für Beratungsprodukte einschlägiger Beratungsunternehmen. 

Damit stehen diejenigen, die die Entwicklung der beiden Rahmenwerke maßgeblich vorantreiben 

in einem Interessenskonflikt zwischen Offenlegung konkreter Handlungsweisen und 

dem bewussten Offenlassen konkreter Empfehlungen, um im Anschluss Beratungsgeschäft 

zu generieren. Darüber hinaus dürfen aufgrund der relativ vagen, abstrakten Aussagen der 

Rahmenwerke berechtigte Zweifel angemeldet werden, ob den Autoren eine differenzierte 

und damit anspruchsvolle Auseinandersetzung mit der Varianz und Kontingenz organisationaler 

Wirklichkeit überhaupt gelingen würde. 7 

antwortlichkeiten der definierten Rollen aufweist (z. B. eine Rolle kann „zuständig“ - responsible oder „verantwortlich“ 

- accountable - im Sinne der rechnungslegungsrelevanten Gesetzgebung sein), da diese Prüfung für haftungsrechtliche 

Fragen von hoher Relevanz ist. 

7 BMI: Die sich daraus ergebenen Konsequenzen für die Bundesverwaltung werden ausführlich in Kapitel 7 

(insbes. Punkt 6 auf S. 81) diskutiert. 



3 Untersuchungsbereich Ziele 

Die in dieser Untersuchung betrachteten Rahmenwerke RA, ITIL und COBIT sind vor ihren 

unterschiedlichen Entstehungshintergründen, den damit verbundenen spezifischen Interessen 

der beteiligten Akteure und insb. den jeweils mit ihrer Entwicklung und ihrem Einsatz 

verfolgten Zielen zu interpretieren. Die Untersuchung beginnt daher mit einer vergleichenden 

Analyse der mit der RA verbundenen Zwecke und Ziele mit denen von ITIL und COBIT. Die 

Zwecksetzungen und Ziele der drei Ansätze liefern die entscheidenden Hinweise für eine 

Positionierung relativ zueinander und liefern gleichzeitig Referenzpunkte für ihre Rekonstruktion 

etwa im Hinblick auf das Nachvollziehen von Entwurfsentscheidungen, die den Ansätzen 

zugrunde liegen. Hierzu werden zunächst die Ziele der RA identifiziert und analysiert. Darauf 

aufbauend werden jeweils die Ziele von ITIL und COBIT untersucht. Dabei wird auf die Terminologie 

der RA bzw. der für die RA spezifizierten Ziele zurückgegriffen. Für die Analyse 

der Anschlussfähigkeit bzw. der Integrationspotentiale der Ansätze im Hinblick auf die Zielsetzungen 

(bspw. zu Identifizierung gemeinsamer oder widersprüchlicher Ziele) werden in 

einem zweiten Schritt Schlussfolgerungen gezogen, Handlungsempfehlungen abgeleitet und 

integrierte Zielmodelle entwickelt. 

Zur besseren Unterscheidung werden Ziele im Text kursiv gesetzt. Die Ziele sind in der 

Terminologie der Ziele der RA verfasst und auf die Konzeptualisierung aus dem Zielemodell 

[Ziele] abgestimmt. Ziele, die sich ITIL und/oder COBIT, nicht jedoch der RA zuordnen lassen, 

werden durch den Zusatz ITIL bzw. COBIT kenntlich gemacht. 

3.1 Analyse der Ziele der RA 

Die „IT-Steuerung Bund“ ist eine Initiative zur Stärkung der IT-Organisation des Bundes. Sie 

ist darauf gerichtet, dem zunehmenden Stellenwert und der zugleich steigenden Komplexität 

von Informationstechnologie in den Bundesbehörden Rechnung zu tragen. Hierfür wurden 

verschiedene Handlungsfelder identifiziert, die darauf zielen, serviceorientierter gegenüber 

dem Bürger zu werden, Innovationen zu fördern, die Handlungsfähigkeit zu bewahren und 

die Effizienz des IT-Einsatzes zu steigern [Konzept]. Im Zentrum der Maßnahmen stehen 

insbesondere die Bündelung und Konsolidierung der Nachfrage nach IT-Dienstleistungen 

einerseits und des Angebots an IT-Dienstleistungen andererseits. Wesentlicher Schritt hierfür 

ist auch die Konsolidierung verschiedener, z. T. behördlich individueller IT-Dienstleister 

zu drei IT-Dienstleistungszentren (DLZ-IT) des Bundes sowie insbesondere die Entwicklung 

einer „Rahmenarchitektur IT-Steuerung Bund“ (RA), die im Fokus dieser Untersuchung steht 

[Umsetzungsplan]. 

Die RA dient als Instrument, um den Abgleich von Angebot und Nachfrage von IT- 

Unterstützung vor dem Hintergrund der Ziele der Initiative zu unterstützen. Sie stellt einen 

übergeordneten Rahmen für die Strukturierung der IT-Landschaft des Bundes zur Verfügung. 

Hierbei wird von zwei Perspektiven ausgegangen: 

• Einerseits die Geschäftsperspektive, zu der die behördlichen Prozesse und Aufbaustrukturen 

zur Erreichung der Ziele des Bundes bzw. der Bundesbehörde gehören. 

• Andererseits die komplementäre IT-Perspektive, in der die IT-Systeme, ihre Hard- 

und Software und die Daten – die IT-Leistungserstellung – im Vordergrund stehen. 

Die RA zielt darauf, diese Perspektiven in einen Zusammenhang zu setzen. Hierfür bietet sie 

eine Integrations- und Vermittlungsschicht zwischen geschäftlichen und informationstechni- 



schen Perspektiven und somit zwischen Angebot und Nachfrage nach IT-Dienstleistungen 

an. 

Darüber hinaus ist die Rahmenarchitektur eingebettet in einen organisatorischen Kontext, 

der ihre Anwendung erleichtern soll: Ein zentrales Architekturmanagement übernimmt die 

Vermittlung zwischen den Akteuren der Perspektiven und stellt Methoden(teile) – insbesondere 

eine sprachliche Struktur zur Beschreibung von Angebot, Nachfrage und den vermittelnden 

Diensten – bereit, um die gegenseitige Abstimmung zu erleichtern. Die RA stellt 

damit ein Instrument dar, mit dem „gemeinsame Begriffe und Strukturen zur Unterstützung 

einer effizienten ressortübergreifenden Zusammenarbeit geschaffen“ und die Kommunikation 

unter den verschiedenen Beteiligten unterstützt werden soll ([Grundlagen], S. 3). 

Durch die strukturierte Erfassung und Abstimmung von Nachfrage und Angebot an IT- 

Unterstützung soll u. a. Redundanz verringert, Transparenz geschaffen und Komplexität in 

der Betrachtung der Zusammenhänge zwischen Geschäfts- und IT-Sicht reduziert werden. 

Die RA verfolgt drei Hauptzielsetzungen, die im Folgenden als Handlungsfeld bezeichnet 

werden: 

1) Handlungsfähigkeit: Die Bundesverwaltung setzt ihre IT so ein, dass sie stets nachweisbar 

in der Lage ist, ihren gesetzlichen Auftrag zu erfüllen. 

2) Wirtschaftlichkeit: Die Bundesverwaltung betreibt und entwickelt ihre IT jederzeit unter 

Beachtung des Prinzips der Wirtschaftlichkeit und Sparsamkeit. 

3) Hohe Dienstleistungsqualität: Die IT-Systeme sind so gestaltet, dass die Arbeitsabläufe 

bestmöglich unterstützt werden. 

Diese Ziele werden in einem Zielmodell detaillierter dargestellt und durch Angabe von Gewichtungen 

und Beeinflussungsrichtungen näher beschrieben. Für eine bessere Übersichtlichkeit 

wird das Zielmodell den drei Handlungsfeldern entsprechend in drei Teilmodelle 

zerlegt betrachtet und grafisch dargestellt. Ein Teilmodell entspricht somit einem Ausschnitt 

aus dem Zielmodell. 

Für das Handlungsfeld Handlungsfähigkeit findet sich ein Ausschnitt aus dem Zielmodell in 

Abbildung 1; die vollständige Beschreibung der Ziele und ihren Abhängigkeiten findet sich 

zusammen mit den vollständigen Zielmodellen in [Ziele]. 

+ 

Zukunftsfähigkeit 

+ 

Innovations- 

Management 

Verkürzung der 

Einführungsdauer 

('time to market') 

+ 

Fachliche Integration 

+ 

Effizienz 

++ 

Effektivität 

++ 

++ 

Beherrschbarkeit der 

Prozesse 

Standardisierung und 

Optimierung der 

Prozesse 

++ 

Prozessorientierung 

Interoperabilität 

Wiederverwendung 

Agilität 

Handlungsfähigkeit 

++ ++ + ++ ++ 

+ 

+ 

+ 

++ 

+ 

+ 

++ 

++ 

Flexibilität 

Zuverlässigkeit 

Optimierung von 

Entwicklung, Betrieb, 

Wartung und 

Administration 

Standardisierung von 




Abbildung 1: Zielmodell der RA für das Handlungsfeld „Handlungsfähigkeit“ [Zielmodell] 

Wiss. Untersuchung „Integration der COBIT und ITIL Standards mit der RA“ Universität Duisburg-Essen 

- 

- 

++ 

++ 

+ 

++ 

++ 

Sicherheit 

++ 

Gewährleistung des 

Schutzbedarfs 

+ 

++ 

+ 

+ 

+ 

Reduzierung der 

Komplexität 

Rechtskonformität 

+ 

Transparenz für IT- 

Spezialisten 

+ 

+ 

Hohe 

Dienstleistungsqualität 

Schneller IT-Service 

Stabilität der IT- 

Systeme 

++ 

+


Durch die strukturierte Erfassung und Beschreibung der IT-Leistungsnachfrage und des IT- 

Leistungsangebots lassen sich mit der RA eine Vielzahl an Anwendungsszenarien unterstützen. 

Typische Anwendungsszenarien sind etwa: 

• die Identifikation von (zu unterstützenden) Diensten aus den Geschäftsprozessen der 

Behörden 

• die Identifikation von Diensten aus bestehenden IT-Lösungen und IT-Komponenten 

• die Ableitung von bereitzustellenden IT-Lösungen und IT-Komponenten aus den 

Diensten 

• Planung der zeitlichen Entwicklung des IT-Angebots und der zugehörigen Implementierung 

Zielgruppen der Rahmenarchitektur sind damit sowohl die verschiedenen Akteure in den 

DLZ-IT des Bundes (z. B. IT-Leiter, IT-Experten) bzw. die in den Bundesbehörden für den IT- 

Einsatz verantwortlichen Mitarbeiter (z. B. ressortspezifische IT-Beauftragte) als auch die 

Fachanwender der geschäftlichen Seite sowie das Architekturmanagement, das als Schnittstelle 

und Vermittler zwischen geschäftlicher und technischer Perspektive steht. 

3.2 Analyse der Ziele der ITIL 

Zu Zielen des Ansatzes finden sich in der ITIL-Dokumentation kaum Aussagen. Aus der 

Funktion von ITIL als Rahmenwerk können übergeordnete Ziele abgeleitet werden. So kann 

ITIL weithin als Ansatz aufgefasst werden, mit dem die Transparenz über die Aktivitäten der 

IT-Organisation gefördert und die Komplexität der Steuerung der IT-Organisation reduziert 

werden kann (Ziel: Reduzierung der Komplexität). Es ist zu rekonstruieren, dass der Ansatz 

darauf gerichtet ist, verschiedenen Akteuren einer IT-Organisation (z. B. IT-Leiter, IT- 

Experten) und externen IT-Lieferanten einen einheitlichen und konsistenten Begriffsapparat 

zu bieten (Ziel: KommunikationITIL) und damit ein einheitliches Verständnis über die Rolle der 

IT-Organisation als „Lieferant“ einerseits und die des Fachanwenders als „Kunde“ andererseits 

zu fördern (z. B. von Bon 2009, S. 15; [Service Strategy], S. 75). Mit ITIL soll offenbar 

eine wirtschaftliche und zweckmäßige Erbringung von IT-Leistungen erreicht und dabei eine 

hohe Qualität der IT-Leistungserstellung gewährleistet werden (z. B. Böttcher 2010, S. 1; 

Ziel: Standardisierung von Entwicklung, Betrieb, Wartung und Administration). Der Einsatz 

von ITIL verspricht, die IT-Dienstleistungen und ihre Erbringung an den Anforderungen des 

Geschäfts auszurichten, da zentrale Konzepte und Prozesse des Ansatzes auf eine Abstimmung 

der IT-Dienstleistungen an den „Erwartungen“ des Kunden ausgerichtet sind (z. B. 

[Service Design], S. 72). 

Ein explizites Zielsystem ist in der ITIL-Dokumentation nicht zu finden. Lediglich die Ziele 

Utility (Zweckmäßigkeit) und Warranty (Einsatzfähigkeit) von Services 8 (]Service Strategy], 

S. 18ff.) sowie die Kundenorientierung ([Service Strategy], S. 75) werden in der Primärliteratur 

explizit als übergeordnete Ziele von ITIL und den ITIL-Prozessen genannt. Konkret operationalisiert 

wird von diesen Zielen einzig die „Warranty“. Sie ist gegeben, wenn ein Service 

„genau dann verfügbar ist, wenn es benötigt wird, und zwar in einer ausreichenden Kapazität 

oder Menge und mit einer zuverlässigen Kontinuität und Sicherheit“ ([Service Strategy], S. 

19f.). Eine weiterführende Operationalisierung oder Verfeinerung (oder eine weitergehende 

Beschreibung), insbesondere der anderen beiden Ziele, erfolgt in der ITIL-Spezifikation nicht. 

8 Unter Utility versteht ITIL den (positiven) Beitrag eines Services auf die Durchführung der Geschäftsprozesse; 

Warranty beschreibt die angemessene Verfügbarkeit etwa mit Blick auf Kapazität und Sicherheit. Siehe Abschnitt 

4.4.1 für eine Gegenüberstellung der Konzepte Service (ITIL) und Dienst (RA). 



Den Zielen „Utility“ und „Warranty“ lassen sich die in der RA verwendeten Ziele Effektivität 

und Effizienz der IT-Leistungserstellung zuordnen. 

Neben diesen explizit angeführten übergeordneten Zielen lässt sich für ITIL eine Reihe impliziter 

Ziele identifizieren, die aus den Zwecksetzungen der verschiedenen ITIL-Prozesse 

abgeleitet werden können. So wird z. B. für den ITIL-Prozess „Incident Management“ die 

Zwecksetzung „schnellstmögliche Wiederherstellung von unerwartet beeinträchtigten oder 

unterbrochenen Services, um die Auswirkungen auf das Business zu minimieren“ ([Service 

Operations], S. 53f.) formuliert, aus der die Ziele Zuverlässigkeit, Stabilität der IT-Systeme 

und Schneller IT-Service abgeleitet werden können. Für derartige Zuordnungen wurden die 

ITIL-Prozesse hinsichtlich ihrer in den Primärquellen explizit angegebenen Zwecksetzungen 

analysiert. Da die Zwecksetzungen der Prozesse auf unterschiedlichen Abstraktionsniveaus 

beschrieben werden bzw. für einige Prozesse keine Beschreibung ihrer Zwecksetzung in 

ITIL gegeben wird, sind die so identifizierten Ziele der ITIL-Prozesse jedoch Rekonstruktionen, 

die mit Interpretationsspielräumen verbunden sind. Um Transparenz über die Zwecksetzungen 

der Prozesse und der abgeleiteten Ziele zu schaffen, wird in Anhang C als 

Ergebnis der Rekonstruktion eine Übersicht über die mit den ITIL-Prozessen verknüpften 

Zwecke sowie daraus abgeleitete Ziele gegeben und Ziele der ITIL auf die Ziele der RA 

übertragen. 

In Abbildung 2 werden die genannten expliziten, übergeordneten Ziele und die impliziten 

Ziele grafisch visualisiert. Ziele, die nur in ITIL und nicht in der RA genannt werden, sind 

durch den Vermerk ITIL“ gekennzeichnet. Da Zusammenhänge zwischen Zielen in ITIL – mit 

Ausnahme der Operationalisierung von „Warranty“ (s.u.) – nicht expliziert werden, sind die 

dargestellten Beziehungen aus den Zielmodellen der RA in vereinfachter Form übernommen. 

Zugleich ist anzunehmen, dass die Zusammenhänge zwischen den Zielen je nach konkreter 

Ausgestaltung von ITIL in der Organisation variieren; Gewichtungen der Zielbeziehungen, 

wie sie für die RA vorliegen, lassen sich ebenfalls nicht ableiten. Deshalb werden die in der 

Terminologie der RA rekonstruierten Ziele der ITIL in vereinfachter Form, d.h. ohne Gewichtungen, 

abgebildet. Abbildung 2 erhebt dabei keinen Anspruch auf Vollständigkeit. Es ist 

einerseits möglich, dass weitere Ziele aus den ITIL-Prozessen abgeleitet werden können. 

Andererseits können mit der konkreten Ausgestaltung und Umsetzung von ITIL in einer 

Organisation auch andere und weitere, in Abbildung 2 nicht aufgeführte Ziele verfolgt werden. 

Effektivität 

+ 


+ 

Angebotsransparenz für 

Endnutzer 

Standardisierung von Entwicklung, 

Betrieb, Wartung und Administration 

+ 

Kommunikation 


Komplexität 

Abbildung 2: Rekonstruktion der Ziele der IT Infrastructure Library (ITIL) 


ITIL 

Effizienz 

+ + 

Zuverlässigkeit Stabilität 

+ + 

+ 



Wartung und Administration + 


Kundenorientierung 


Sicherheit 

+ 

Kontinuität 

+ + 



Spezialisten


• Die fachliche Integration soll in ITIL durch die Ausrichtung von Services an den Anforderungen 

des Kunden gefördert werden; hierauf zielen insbesondere die Service Strategy 

und Service Design Prozesse „Service Portfolio Management“, „Demand Management“, 

„Service Catalogue Management“ und „Service Level Management“ ab. 

• Die Zuverlässigkeit soll durch verschiedene ITIL-Prozesse gefördert werden, u. a. „Service 

Level Management“, „Capacity Management“ sowie den Service Operations, den 

Service Transition Prozessen und dem Continual Service Improvement. 

• Die Stabilität der IT-Systeme steht bei „Availability Management“ und „Capacity Management“ 

sowie verschiedenen Service Operations und Service Transition Prozessen im 

Vordergrund. 

• Ein schneller IT-Service soll durch „Incident Management“, „Event Management“ und 

„Request Fulfilment“ adressiert werden. Unter „IT-Service“ wird an dieser Stelle von der 

RA eine störungs-behebende Organisationseinheit (vergleichbar zum „Help Desk“ in ITIL) 

verstanden. Der Begriff des „IT-Service“ besitzt in ITIL eine abweichende Bedeutung. 

Siehe hierzu die terminologische Analyse in Abschnitt 4.4.1 

• Die Angebotstransparenz für Endnutzer soll durch das „Service Catalogue Management“ 

hergestellt werden. 

• Die Optimierung von Entwicklung, Betrieb, Wartung und Administration wird explizit durch 

das Continual Service Improvement angestrebt. 

• Das „Service Asset and Configuration Management“ zielt darauf die Transparenz für IT- 

Spezialisten zu verbessern. 

• Schließlich wird die Sicherheit als Ziel angeführt. Dedizierte Prozesse hierzu sind etwa 

das „Access Management“ sowie das „Information Security Management“. 

• Ein nicht im Kontext der RA aufgeführtes Ziel, das dediziert von ITIL adressiert wird, ist 

die Gewährleistung einer Kontinuität ITIL (i.S. eines Katastrophen-Managements). ITIL 

schlägt hierfür das „IT Service Continuity Management“ vor. 

• Die in Abbildung 2 dargestellten Beziehungen zwischen den Zielen zeigen, dass die 

verschiedenen ITIL-Prozesse, wenngleich i. d. R. indirekt, zur Effektivität und Effizienz 

der IT-Leistungserstellung beitragen. Explizit auf diese beiden Ziele gerichtet sind das 

„Service Portfolio Management“ und das „Service Catalogue Management“ (Effektivität), 

die eine Ausrichtung der IT an den Kunden zur Unterstützung seiner „Kunden-Assets“ fokussieren, 

sowie das „Financial Management“ (Effizienz), das eine stetige Bewertung der 

IT-Leistungserstellung mit Blick auf das Kosten-Nutzen-Verhältnis fordert. 9 

Von der ITIL wird eine Vielzahl von Anwendungsszenarien unterstützt. Im Fokus stehen 

dabei Szenarien um den Lebenszyklus von Services, zum Beispiel 

• die ökonomische Bewertung einer Entwicklung oder Änderung eines Services 

• der Aufbau eines Service-Katalogs 

• die Planung von Änderungen an Services und ihrer Distribution 

• die Behebung einer Störung während des IT-Betriebs 

Hierfür werden in der ITIL-Dokumentation in unterschiedlichem Umfang typische (empfehlenswerte) 

Konzepte, Vorgehensweisen, beteiligte Rollen/Positionen und zusätzliche Hilfestellungen 

(z. B. Artefakte, Instrumente, Informationsquellen) beschrieben. 

Vor diesem Hintergrund werden in ITIL als Zielgruppen in erster Linie Personen, die für die 

Planung, Realisierung, Betrieb und Überwachung von Dienstleistungen der IT-Organisation 

9 Das Prinzip der Wirtschaftlichkeit und die Sparsamkeit (Definition des Ziels Wirtschaftlichkeit der RA, [Ziele]) 

steht dagegen in ITIL nicht im Vordergrund; Sparsamkeit wird in ITIL nicht thematisiert. 



zuständig sind, angeführt – und somit vor allem Leitern der IT-Organisation (z. B. CIO, IT- 

Manager) und den operativ Ausführenden (z. B. IT-Experten). Fachanwender oder Manager 

auf der Geschäftsseite werden in ITIL nicht explizit als Zielgruppe angeführt. 

3.3 Analyse der Ziele der COBIT 

COBIT versteht sich als Sammlung von „good practices“, die auf dem Konsens von (IT- 

Revisions-) Experten beruhen und unabhängig von Branche und eingesetzter Technik vordergründig 

dazu dienen sollen, Unternehmen bei Aufgaben der IT-Governance zu unterstützen. 

Dabei fällt IT-Governance nach dem Verständnis von COBIT in den 

Verantwortungsbereich von Führungskräften und Leitungs- und Kontrollgremien und besteht 

aus „Führung, Organisationsstrukturen und Prozessen, die sicherstellen, dass die Unternehmens-IT 

dazu beiträgt, die Organisationsstrategie und -ziele zu erreichen und zu erweitern.“ 

([COBIT-DE], S. 6). 10 Damit verbunden werden als Ziele von COBIT folgende Punkte 

explizit genannt ([COBIT-DE], S. 7): 

• Ausrichtung der IT an Unternehmenszielen und Erfordernissen des Kerngeschäfts, 

• Realisierung des versprochenen Nutzens der IT-Investitionen, 

• verantwortungsvoller Umgang mit IT-Ressourcen und 

• angemessenes Management von IT-Risiken. 

Vor dem Hintergrund der Entstehungsgeschichte, der Verwendung in der Praxis und der 

Struktur von COBIT sind diese Ziele jedoch zu relativieren. Dies wird im Folgenden erläutert. 

Jeder in COBIT behandelte IT-Prozess ist mit einem übergeordneten „Control Objective“ 11 

verbunden, das durch ein oder mehrere nachgelagerte „Control Objectives“ konkretisiert und 

um die Nennung konkreter Konzepte (z. B. „IT Strategic Plan“), Vorgehensweisen (z. B. 

„Analysiere Programm-Portfolios und manage Projekt- und Service Portfolios.“) sowie eine 

Menge fest definierter organisatorischer Rollen und ihrer Verantwortlichkeiten ergänzt wird. 

Hierbei versteht COBIT ein Control Objective als „… eine Aussage über das gewünschte 

Ergebnis oder den zu erreichenden Zweck, der mit der Umsetzung von in bestimmten Aktivitäten 

integrierten Controls (engl.: control procedure) erreicht werden soll. Die Control 

Objectives von COBIT sind Minimalanforderungen für eine wirksame Steuerung jedes IT- 

Prozesses“ ([COBIT-DE], S. 17). Ein Control kann sich dabei auf Richtlinien, Verfahren, 

Praktiken und Organisationsstrukturen beziehen, „die entwickelt wurden, um ausreichende 

Sicherheit zu geben, dass die Unternehmensziele erreicht werden und dass unerwünschte 

Ereignisse verhindert oder erkannt und korrigiert werden“ ([COBIT-DE], S. 17). Durch Checklisten-artige 

Prüfungen hinsichtlich des Vorliegens der in den Control Objectives genannten 

Konzepte, Vorgehensweisen und Rollen soll ihre Einhaltung bzw. Umsetzung (durch einen 

Revisor oder Wirtschaftsprüfer) ermittelt werden. 

Ein „Control Objective“ kann dabei als ein für einen Revisor prüfbaren Sachverhalt aufgefasst 

werden (z. B. ein „Strategic IT Plan“ liegt vor, das Gremium „IT Steering Committee“ 

existiert). Damit ist insofern ein intendierter Zustand (ein Ziel oder „objective“) verbunden, als 

bei Vorliegen eines zu prüfenden Sachverhalts davon ausgegangen wird, dass eine mögliche 

Beeinträchtigung der Ordnungsmäßigkeit der Rechnungslegung durch Informations- und 

Kommunikationstechnik gemindert wird. Durch die Vorgabe von „Control Objectives“ und 

deren Verortung in den (aus Sicht der COBIT-Herausgeber für eine IT-Organisation typi- 

10 Auf eine tiefergehende Diskussion zum Thema IT-Governance und der zugehörigen Aufgaben wird an dieser 

Stelle verzichtet (für weiter gehende Überlegungen siehe z. B. Strecker 2009). 

11 Eine Übersicht über die Prozesse und den jeweiligen Control Objectives findet sich in Anhang C. 



schen und zu empfehlenden) IT-Prozessen zielt COBIT somit darauf, Organisationen bei der 

Sicherstellung der Einhaltung gesetzlicher und weiterer regulatorischer Anforderungen zu 

unterstützen. Dies wird durch Richtlinien zur IT-Revision unterstützt. Diese Zielsetzung von 

COBIT ähnelt dem Ziel der Rechtskonformität der RA. Bei COBIT steht insbesondere die aus 

Wirtschaftsprüfungssicht verlässliche Anwendung von Informationstechnologie bzw. die 

Prüfung und Sicherstellung der Ordnungsmäßigkeit der RechnungslegungCOBIT (Stichwort 

„IT-Compliance“) im Vordergrund (Gaulke 2010, S. 10f.; [COBIT], S. 6). Dies wird in der RA 

nicht explizit berücksichtigt. 

In diesem Zusammenhang ist COBIT auch darauf ausgerichtet, eine einheitliche und (möglichst) 

konsistente Terminologie zur Beschreibung von IT-Organisationen für deren Mitarbeiter 

und vor allem für prüfende IT-Revisoren bzw. Revisions-Berater zu formulieren und 

dadurch die KommunikationCOBIT zu erleichtern und zu verbessern ([COBIT], S. 8). Eine 

Darstellung der übergeordneten Ziele der COBIT findet sich in Abbildung 3. 

Revisionsbezogene 

Ziele 

von COBIT 

Abbildung 3: Rekonstruktion der Ziele von COBIT aus Sicht der IT-Revision 

Neben diesen auf die Unterstützung der IT-Revision bezogenen Zielen scheint COBIT mit 

der aktuellen Version eine weitere Kategorie an Zielen verstärkt zu adressieren: die Unterstützung 

des IT-Managements. Durch die Anreicherung der in COBIT beschriebenen IT- 

Prozesse, etwa mit Ziel- und Leistungsindikatoren sowie mit Reifegraden, scheint sich 

COBIT von Seiten der Herausgeber zunehmend als allgemeines Rahmenwerk für das IT- 

Management zu verstehen. Die genannten Aspekte sind für die IT-Revision von nachgelagerter 

Relevanz. Dabei wird insbesondere das Ziel hervorgehoben, die IT-Organisation an 

den Anforderungen des Geschäfts auszurichten (Ziel: Fachliche Integration) (Gaulke 2010, 

S. 15; [COBIT], S. 12ff.). 

Aus Sicht der Gutachter adressiert COBIT nicht die konkrete Ausgestaltung der IT- 

Organisation, bspw. in Form detaillierter Prozesse und Instrumente, sondern übergeordnete 

Managementaufgaben und die Identifikation von Handlungsbedarfen. Diese Einschätzung 

wird durch die Aussagen der ISACA und des itsmf zur „Aufgabenteilung“ zwischen COBIT 

und ITIL gestützt, die deutlich werden lässt, das zukünftig COBIT und ITIL sich verstärkt 

ergänzen sollen ([COBIT], S. 9, 28; ITGI 2008, S. 6f.). In Kurzform: COBIT fokussiert auf das 

Was, weniger auf das Wie: Die in COBIT gegebenen Vorgaben und Anforderungen an das 

IT-Management – bspw. der Forderung nach der Definition eines strategischen IT-Plans 

(PO1 12 ) oder der Definition und des Managements von Service-Levels (DS1) – beziehen sich 

auf das Vorliegen bzw. die Existenz von prüfbaren Dokumenten und Organisationsstrukturen 

(es soll ein „Strategic IT Plan“ vorliegen). Konkrete Vorgaben zur Gestaltung der IT- 

Organisation und der vorgeschlagenen Instrumente (z. B. wie dieser „Strategic IT Plan“ 

inhaltlich gestaltet sein sollte) werden nicht thematisiert. COBIT abstrahiert von weiteren 

Ausführungen zu Prozessen, Konzepten, Aufbaustrukturen und technischen Mitteln von IT- 

Organisationen. 

12 COBIT verwendet eine durchgängige Systematik für die Kennzeichnung der Prozesse und Control Objectives: 

PO kennzeichnet die Phase „Plan and Organise“, die Nummer verweist auf den Prozess. PO1 steht damit für den 

Prozess Nr. 1 „Define a Strategic IT-Plan“ aus der Phase (auch „Domäne“ genannt) „Plan and Organise“. 



Vor dem beschriebenen Hintergrund lassen sich die von COBIT bzw. mit dem Einsatz von 

COBIT verfolgten Ziele in zwei Kategorien unterteilen (vgl. [COBIT-DE], S. 9; [COBIT], S. 8): 

1. Primäres Ziel von COBIT ist die Unterstützung der IT-Revision durch Sicherstellung 

der Prüfbarkeit im Sinne der Wirtschaftsprüfung für den IT-Einsatz in Organisationen 

bzw. Erfüllung der Anforderung an ein internes Kontrollsystem über die IT (nach 

COSO bzw. SOX 404). Daraus abgeleitet werden die revisions-bezogenen Ziele Einhaltung 

gesetzlicher und weiterer regulativen Anforderungen (Rechtskonformität) 

bzw. Prüfung und Sicherstellung der Ordnungsmäßigkeit der Rechnungslegung und 

die Unterstützung der Kommunikation. Diese Ziele sind in Abbildung 3 als primäre 

Zielsetzungen von COBIT dargestellt. Das Ziel der Rechtskonformität findet sich auch 

in der RA. Für die Ziele der Prüfung und Sicherstellung der Ordnungsmäßigkeit der 

Rechnungslegung und der Kommunikation finden sich hingegen keine äquivalenten 

Ziele in der RA. 

2. Darüber hinaus kann als weitere Kategorie von Zielen die Unterstützung des IT- 

Managements verstanden werden, indem die in COBIT genannten Grundprinzipien 

(z. B. Ableitung der IT-Ziele aus den Unternehmenszielen, Messung der Zielerreichung/Performanz) 

und die Ausführungen zu den in COBIT behandelten IT- 

Prozessen als Gestaltungsempfehlungen für IT-Organisationen aufgefasst werden. 

Hierzu lassen sich konkrete Ziele ableiten, die mit den in COBIT thematisierten IT- 

Prozessen verfolgt werden. So benennt COBIT für jeden IT-Prozess eine Reihe von 

Zielen, die sich in IT-, Prozess- und Aktivitätsziele untergliedern und die mit der Umsetzung 

dieses Prozesses verfolgt werden sollen. Für diese Ziele werden jeweils 

Kennzahlen zur Messung der Zielerreichung vorgeschlagen. Die Rekonstruktion dieser 

Ziele von COBIT in der Terminologie der Rahmenarchitektur ist jedoch mit einigen 

Unwägbarkeiten verbunden, da die IT-Prozesse, ihre Ziele und die in den IT- 

Prozessen referenzierten Artefakte (z. B. „IT Strategic Plan“) in der Dokumentation zu 

COBIT nicht näher ausgeführt werden und somit Spielraum für Interpretationen bieten. 

Einen Überblick über die Ziele aller in COBIT behandelten IT-Prozesse findet 

sich in Anhang D, deren Abstimmung auf die Terminologie und die Ziele der RA – sofern 

möglich – findet sich in Anhang H. Folgende Ziele werden in COBIT genannt, 

denen sich keine korrespondieren Ziele der RA zuordnen lassen. In Klammern ist ein 

verdichtetes Ziel, das im weiteren verwendet wird, zusammen mit der Nummer des 

entsprechenden COBIT-Ziels aus Anhang H angegeben: 

1. „Reagiere auf Anforderungen der Governance entsprechend der Geschäftsführungsvorgaben“ 

(Prüfung und Sicherstellung der Ordnungsmäßigkeit 

der RechnungslegungCOBIT , COBIT-Ziel Nr. 2) 

2. „Beschaffe und erhalte IT-Skills, die der IT-Strategie entsprechen“ 

(MitarbeiterkompetenzCOBIT, COBIT-Ziel Nr. 9) 

3. „Sicherstellung gegenseitig zufriedenstellender Lieferantenbeziehungen“ (Zufriedenstellende 

LieferantenbeziehungenCOBIT, COBIT-Ziel Nr. 10) 

4. „Schaffe Klarheit über Geschäftsauswirkungen der Risiken von IT-Zielen und 

IT-Ressourcen“ (RisikotransparenzCOBIT-Ziel Nr. 18) 

5. „Setze Projekte pünktlich und im Budgetrahmen und unter Einhaltung der 

Qualitätsstandards um“ (Termin- und budgetgerechte ProjekteCOBIT, COBIT- 

Ziel Nr. 25) 

Abbildung 4 stellt den Versuch dar, die Ziele der in COBIT vorgeschlagenen IT-Prozesse in 

Terminologie und Konzeptualisierung der RA zu rekonstruieren. In COBIT werden weder 

Zielbeziehungen noch Gewichtungen definiert. Die Beziehungen in Abbildung 4 entstammen 



daher meist in vereinfachter Form dem Zielmodell der RA. Ziele, die nicht in der RA benannt 

werden, sind durch den Hinweis „COBIT“ kenntlich gemacht. Beziehungen von „reinen“ 

COBIT-Zielen basieren auf Interpretationen der COBIT-Dokumentation. 

Rekonstruierte Ziele der in COBIT thematisierten IT-Prozesse 

Abbildung 4: Rekonstruktion der Ziele der von COBIT thematisierten IT-Prozesse aus Sicht des IT- 

Managements 

Durch den Mangel an Zielbeziehungen, der Vielzahl an Zielen der IT-Prozesse und ihrer 

Unbestimmtheit lassen sich die in COBIT genannten Ziele nicht als ein kohärentes und konsistentes 

Zielsystem verstehen. 

Aus den Zielsetzungen von COBIT lassen sich insbesondere folgende Anwendungsszenarien 

ableiten: 

• Prüfung eingesetzten Informations- und Kommunikationstechnik auf ihre Beeinträchtigung 

der Ordnungsmäßigkeit der Rechnungslegung, 

• Beurteilung des Reifegrads der in COBIT behandelten IT-Prozesse zur Aufdeckung 

von Verbesserungspotenzialen, 

• Strategische Ausrichtung der IT an Unternehmenszielen und -strategie, sowie 

• Aufbau und Anwendung von Kennzahlensystemen zur Messung der Zielerreichung 

und der Performanz der Leistungserstellung. 

Vor dem Hintergrund der identifizierten Ziele und der möglichen Anwendungsszenarien 

lassen sich drei Zielgruppen von COBIT identifizieren: Im Vordergrund der prüfungsbezogenen 

Sichtweise stehen einerseits interne wie externe Revisoren und Wirtschaftsprüfer, die 

COBIT als Rahmenwerk zum Aufbau und zur Überprüfung des internen Kontrollsystems 

(IKS) mit Blick auf den IT-Einsatz nutzen. Andererseits – nicht zuletzt aufgrund der u.U. 

persönlichen Haftung bei Betrugsfällen aufgrund fehlender IKS – steht die Geschäftsführung 

von Unternehmen im Fokus. Aus Perspektive des Management-Fokus von COBIT lassen 

sich vor allem Leiter der IT-Organisation (z. B. CIO, IT-Manager) identifizieren, die für die 

Planung, Realisierung, Betrieb und Überwachung von Dienstleistungen (IT-Services) der IT- 

Organisation zuständig sind und bspw. auf die beschriebenen Prozesse zurückgreifen 

([COBIT], S. 10). 



3.4 Schlussfolgerungen und Handlungsempfehlungen 

Dieser Abschnitt stellt Auffälligkeiten, Beobachtungen und Schlussfolgerungen aus der Analyse 

zusammen und entwickelt auf Grundlage dieser Analyseergebnisse Handlungsempfehlungen 

für die RA. Zunächst werden generelle Beobachtungen diskutiert. Anschließend wird 

näher auf das Zielsystem der RA und die Paarvergleiche RA-ITIL und RA-COBIT eingegangen. 

Eine bereits thematisierte zentrale Beobachtung betrifft den Grad der Explikation von Zielen. 

Während für die RA ein explizites Zielsystem formuliert ist, lassen sich sowohl für ITIL als 

auch für COBIT Zielsetzungen weitgehend nur durch Interpretation des Betrachters rekonstruieren; 

ein Zielsystem mit explizit beschriebenen Zielbeziehungen findet sich nicht. Das ist 

insofern problematisch, als dies nicht nur einer vergleichenden Analyse der Ziele im Wege 

steht, sondern insbesondere bei der Umsetzung und Anwendung dieser beiden Ansätze von 

Anwendern verlangt, diese Lücke eigenständig zu füllen. Die Ergebnisse der vorliegenden 

Analyse bieten hier allerdings eine Unterstützung an, in dem explizite und implizite Ziele von 

ITIL und COBIT differenziert rekonstruiert werden. 

H-1 Handlungsempfehlung: Zieldissonanzen deutlicher thematisieren 

Das Zielsystem der RA suggeriert durch die Angabe unidirektionaler, gewichteter Beziehungen 

zwischen Zielen vor allem Konsistenz und Kohärenz des Zielsystems. Dabei fällt auf, 

dass einige offensichtliche Zieldissonanzen nicht explizit berücksichtigt sind. Beispielsweise 

muss Wiederverwendung nicht die Flexibilität erhöhen, sondern kann sie sogar behindern. 

Das hängt wesentlich davon ab, welche Abstraktions- (und damit: Anpassungs-) konzepte 

mit den wiederverwendbaren Artefakten verbunden sind. Prozessstandardisierung muss 

nicht die fachliche Integration fördern, wobei zunächst eine differenziertere Konzeptualisierung 

von fachlicher Integration zu entwickeln wäre. Dass Standardisierung Flexibilität fördert, 

ist ohne weitere Differenzierung und ohne die Explikation damit verbundener Annahmen 

kaum haltbar. 

Weitere wichtige Zielkonflikte werden nicht adressiert, z. B. zwischen enger und loser Kopplung 

und zwischen Wiederverwendungskomfort und Wiederverwendungsreichweite im Hinblick 

auf die Ziele der RA Interoperabilität, Wiederverwendung und Angemessene Vielfalt. 

Hier empfiehlt sich eine explizite und differenzierte Erläuterung zum Zielsystem, die Annahmen 

offenlegt, potenzielle Zieldissonanzen diskutiert und die Zielbeziehungen begründet. 

Dabei ist aus Sicht der Gutachter zu berücksichtigen, dass alle drei untersuchten Ansätze 

nach aktuellem Stand der Forschung der Berücksichtigung von mehreren, z.T. komplementären, 

z.T. konfliktären Zielen bedürfen. Es empfiehlt sich also den Umstand zu betonen, 

dass es sich um ein mehrdimensionales Zielsystem handelt, das neben (formalen) Organisationszielen 

wie Effektivität und Effizienz auch Humanziele (z. B. Mitarbeiterzufriedenheit) und 

Sachziele (z. B. Integration und Termineinhaltung) explizit berücksichtigt. 

Darüber hinaus erscheinen im Kontext der RA übergeordnete (z.T. dem politischen Willensbildungsprozess 

unterworfene) Zielsetzungen von Bedeutung zu sein, die derzeit nicht im 

Zielsystem der RA explizit berücksichtigt sind. Hier ist zu fragen, inwiefern der Verzicht auf 

eine explizite Berücksichtigung die Erreichung der Ziele der RA gefährden könnte und ob 

sich bspw. im Diskurs mit übergeordneten Gremien und Stellen eine Einbindung der Ziele 

der RA erzielen ließe. 



H-2 Handlungsempfehlung: Ziele operationalisieren 

In der RA findet keine weitere Operationalisierung der Ziele statt. In COBIT und eingeschränkt 

auch in ITIL werden zumindest Prozessen Ziele zugeordnet, auch wenn die Zielsetzungen 

im Einzelnen durchaus kritisch zu hinterfragen sind. Ein Beitrag zu einer weiter 

gehenden Präzisierung der Ziele der RA könnte durch eine Zuordnung von Zielen zu Prozessen, 

zu Organisationseinheiten oder zu Diensten erfolgen. Denkbar wäre auch die weitere 

Verfeinerungen der Zielmodellierung durch Konzepte für Entscheidungen und 

Handlungen. Die Potenziale des Konzepts Maßnahme in der Zielmodellierung scheinen hier 

noch nicht ausgereizt. Der mit einer derartigen Operationalisierung der Ziele verbundene 

Mehraufwand ist dann im Lichte des zu vermutenden Gewinns an Nachvollziehbarkeit und 

Transparenz zu bewerten. Dabei ist auch an Indikatoren zur Einschätzung und Beurteilung 

des Ausmaßes an Zielerreichung zu denken. Im Gegensatz zu COBIT (und teilweise auch 

ITIL) finden sich in der RA derzeit nur rudimentäre Angaben zu solchen Indikatoren (Kennzahlen; 

siehe dazu auch Abschnitte 4.4.2 und 4.5). Aus Sicht der Gutachter sollten dabei die 

Grenzen der sinnvollen „Messbarkeit“ ebenso wie dysfunktionale Effekte aus einem unreflektierten 

Einsatz von Kennzahlen beachtet werden. 

H-3 Handlungsempfehlung: Zielsystem präzisieren 

Einige der im Zielsystem der RA vorgesehenen Ziele bedürfen nach Ansicht der Gutachter 

einer Präzisierung. Zwar geht die Rahmenarchitektur in Bezug auf den Detailgrad an Zielsetzungen 

an vielen Stellen deutlich über ITIL und COBIT hinaus. Dennoch gibt es nach unserer 

Einschätzung –unabhängig von ITIL und COBIT – folgenden Korrekturbedarf: 

• Die gegenwärtigen Konzeptualisierungen der Ziele Handlungsfähigkeit, Effizienz und 

Effektivität sowie Wirtschaftlichkeit sind insbesondere zu überdenken: Wirtschaftlichkeit 

und Effizienz werden im allgemeinen Sprachgebrauch üblicherweise synonym 

verwendet, wobei sich sofort die Frage nach der Konkretisierung eines Wirtschaftlichkeitskonzepts 

stellt, das für die RA sinnvoll einsetzbar ist. Klassische ökonomische 

Definitionen (z. B. Ertrag/Aufwand) erscheinen wenig brauchbar; eine bessere Orientierung 

liefern ggfs. erweiterte Wirtschaftlichkeitskonzepte wie sie etwa von Picot et 

al. (2003), S. 569ff. vorgeschlagen werden. 

• Das Ziel der Handlungsfähigkeit ist sowohl in der wissenschaftlichen Literatur als 

auch in der Praxis des IT-Managements unüblich und nach unserer Kenntnis bislang 

nicht als explizites übergeordnetes Ziel zu finden. Zugleich werden in der Praxis angeführte 

Ziele (z. B. „Steigerung des Erfolgsbeitrags der IT“), so problematisch sie 

auch sein mögen, nicht angeführt. Gleichzeitig finden sich gängige übergeordnete 

Zielsetzungen (z.B. Effektivität und Effizienz) in der RA nicht als solche vorkommen. 

Hier empfiehlt es sich zum einen deutlicher herauszustellen, aus welchen Gründen 

die Ziele Effektivität und Effizient benannt werden und wie sie zu interpretieren sind. 

Denn klassische betriebswirtschaftliche Konzeptualisierungen von Effektivität und Effizienz 

sind für eine Behörde ohne weitere Präzisierung nicht operational. (Gemeinhin 

wird einem Unternehmen Gewinnstreben als Ziel unterstellt und davon werden die 

Ziele Effektivität und Effizienz abgeleitet). 

• In ähnlicher Wendung bleibt das Ziel schneller IT-Service aufgrund seiner Formulierung 

vage (was bedeutet „schnell“?). Offenbar steht vielmehr das Ziel der Termineinhaltung 

(bspw. von in vertraglichen Vereinbarungen festgelegten Fristen) im 

Vordergrund, das derzeit nicht explizit genannt wird; in der Literatur jedoch hervorgehoben 

wird (z. B. bei Krcmar 2005, S. 420ff.). 



Insgesamt erscheint eine Weiterentwicklung des Zielmodellierungsansatzes ratsam, um u. a. 

zwischen Zielen der RA (d.h. Zielen des Architekturmanagements), übergeordneten („Formalzielen“) 

und nachgelagerten Zielen („Sachzielen“) explizit zu differenzieren. Die erläuterten 

Mehrdeutigkeiten wichtiger Ziele gefährden eine angemessene Interpretation des 

Zielsystems. Die Präzisierung des Zielsystems scheint daher insbesondere angeraten, um 

mit den vielfältigen, verschiedenen Gruppen an Akteuren, die mit ITIL und/oder COBIT arbeiten 

(z. B. aus den DLZ-IT des Bundes, aus dem Bundesrechnungshof), in einen Diskurs 

treten zu können. Die z.T. erheblichen Abweichungen von üblicherweise im IT-Management 

oder in der Betriebswirtschaftslehre vorzufindenden Zielen und Zielstrukturierungen könnten 

eine derartigen Austausch und Diskurs mit den Beteiligten beeinträchtigen. 

H-4 Handlungsempfehlung: Zielsystem um weitere Ziele ergänzen 

Das Zielsystem der RA enthält derzeit einige Ziele nicht, die für das Architekturmanagement 

von Bedeutung sein könnten bzw. gemäß der ITIL und COBIT Literatur von Bedeutung sein 

sollten. Dazu zählen u. a.: 

• KundenorientierungITIL: das in ITIL formulierte Ziel der Kundenorientierung findet sich 

in Teilen im Ziel der hohen Dienstleistungsqualität der RA wieder. Jedoch ist die Betonung 

eine andere. So steht bei der Kundenorientierung die allgemeine Ausrichtung 

am Kunden und dessen Interessen im Vordergrund. Das Ziel der hohen Dienstleistungsqualität 

subsumiert als strategisches Handlungsfeld zahlreiche Aspekte: u. a. 

bestmögliche Unterstützung der Arbeitsabläufe, schneller und sicherer Zugriff auf benötigte 

Prozesse, Informationen und Dienstleistungen, schnelle Behebung von Störungen. 

Das Ziel der RA betont daher stärker Qualitätsaspekte als die Ausrichtung 

am Kunden. Die Aufnahme eines entsprechenden Ziel erscheint daher empfehlenswert. 

• KontinuitätITIL: Weiterhin wird das Ziel der Kontinuität in ITIL betont, das im Zielsystem 

der RA nicht explizit erwähnt, gleichzeitig jedoch von erheblicher Bedeutung für die 

mit der RA verfolgten Ziele (insb. den Zielen der Handlungsfähigkeit, der Stabilität der 

IT-Systeme und der Zuverlässigkeit) zu sein scheint. 

• Sicherstellung der Ordnungsmäßigkeit der RechnungslegungCOBIT: Auch das Primärziel 

von COBIT der Sicherstellung der Ordnungsmäßigkeit der Rechnungslegung wird 

derzeit nicht im Zielsystem der RA verortet. Ob und inwieweit Fragen der Rechnungslegung, 

Revision und Wirtschaftsprüfung für die IT der Bundesverwaltung eine Rolle 

spielen, ist an dieser Stelle nicht zu beantworten und sollte nachfolgend sorgfältig untersucht 

werden. Der Bundesrechnungshof „prüft die Rechnung sowie die Wirtschaftlichkeit 

und Ordnungsmäßigkeit der Haushalts-und Wirtschaftsführung“ (Art. 114 Abs. 

2 Satz 1 und 2 Grundgesetz) und somit auf der Grundlage deutscher Gesetzgebung 

und Rechtsprechung. Ob und inwieweit ein Rahmenwerk, dass auf der Grundlage eines 

U.S.-amerikanischen Rechtsformenverständnisses entwickelt wurde, für deutsche 

Bundesbehörden von Bedeutung ist, bleibt ebenfalls zu klären. 

• KommunikationITIL&COBIT: Das sowohl von ITIL als auch COBIT verfolgte Ziel der Förderung 

einer besseren Kommunikation zwischen den beteiligten Gruppen wird derzeit 

nicht explizit in der RA berücksichtigt. Die Aufnahme wird vor dem Hintergrund der 

Heterogenität der beteiligten Akteure der Bundesverwaltung und damit verbundenen 

Kommunikationsproblemen empfohlen. Auf die Bedeutung eines gemeinsamen Begriffsverständnisses 

wird in Kapitel 4 näher eingegangen. 

• MitarbeiterkompetenzCOBIT: Die Qualifikation und Kompetenz von Mitarbeitern („IT 

Skills“, COBIT-Ziel Nr. 9) markiert einen Aspekt, der in der RA nicht explizit Erwäh- 



nung findet. Die Bedeutung von qualifizierten und motivierten Mitarbeitern für ein erfolgreiches 

Architekturmanagement bzw. für eine erfolgreiche Organisation allgemein 

steht außer Frage. 

• RisikotransparenzCOBIT: Ähnliches gilt für die Transparenz über Risiken aus dem IT- 

Einsatz und ihrem in Bezug auf die Erreichung von Zielen (COBIT-Ziel Nr. 18). Die 

Identifikation von und der systematische Umgang mit Risiken nimmt in COBIT eine 

zentrale Rolle ein. 

• Zufriedenstellende LieferantenbeziehungenCOBIT: COBIT betont ein zufriedenstellendes 

Lieferantenmanagement insbesondere vor dem Hintergrund der mit der Nutzung 

von externen Leistungen verbundenen Risiken (Ausfall des Lieferanten, etc.). 

• Termin- und budgetgerechte ProjekteCOBIT: Im Kontext der RA findet sich zudem kein 

dediziertes Ziel, das auf (IT-)Projekte gerichtet ist (COBIT-Ziel Nr. 25); im Rahmen 

von Architekturmanagement ist allerdings anzunehmen, dass Projekte eine wichtige 

Abstraktion darstellen. Dies spiegelt sich bspw. bereits im Konzept der Maßnahme 

der Zielmodellierung wieder. Die Ausgestaltung von COBIT ist jedoch sehr allgemein 

gehalten, so dass eher auf andere Ansätze zum Projektmanagement (z. B. PMBoK 13 ) 

zurückgegriffen werden sollte. Die Berücksichtigung von termin- und budgetgerechten 

Projekten im Zielmodell der RA wird vor dem Hintergrund des COBIT-Ziels empfohlen. 

Die konkrete Realisierung von Projekten bzw. deren Management ist dagegen 

nicht Gegenstand von COBIT. 

Darüber hinaus lassen sich weder in ITIL noch in COBIT Ziele identifizieren, die dediziert auf 

die Konzepte Unternehmensarchitektur, IT-Architektur oder ein Architekturmanagement 

gerichtet sind oder dieses erwähnen. 

Auf der Metaebene wird nach Einschätzung der Gutachter mit dem Zielsystem der RA ein 

besonderes Ziel verfolgt, das derzeit ebenfalls noch nicht expliziert ist: das Ziel einer ausgeprägten 

Zielorientierung. Die „Stakeholder“ der RA sollen durch das explizite und im Vergleich 

mit ITIL und COBIT sehr differenzierte Zielsystem der RA offenbar dazu angeregt 

werden, Ziele wahr- und ernst zu nehmen und Ziele als Orientierung für ihr Reden und Handeln 

einzusetzen. Eine ähnliche Form der Ausrichtung an Zielen und Strategien betont 

COBIT, bspw. in Form der Zielhierarchien und der Zuordnung von Zielen zu den IT- 

Prozessen. Wenn die Einschätzung für die RA zutrifft, bietet es sich an, diese Zielorientierung 

explizit hervorzuheben und ihre Funktion zu betonen. 

Fazit 

Das derzeitige Zielsystem der RA weist einen hohen Grad an Differenzierung und Explikation 

auf, der z. T. deutlich über die Angaben zu Zielen von ITIL und COBIT hinausgeht. Die RA 

berücksichtigt bspw. die Ziele Mitarbeiterzufriedenheit, Integration und Wiederverwendung, 

die in COBIT & ITIL keine Rolle spielen. Das vorliegende Zielsystem eignet sich daher nach 

Einschätzung der Gutachter als hervorragenden Ausgangspunkt für eine gezielte Weiterentwicklung. 

Die vergleichenden Analysen und die anschließend vorgestellten integrierten Zielmodelle 

zeigen die prinzipielle Anschlussfähigkeit des Zielsystems der RA an die Ziele von ITIL und 

COBIT. Um den Anschluss des Zielsystems der RA an ITIL und COBIT zu fördern, sind die 

genannten Handlungsempfehlungen zu berücksichtigen, wobei der Anschluss an COBIT 

eine grundlegende Auseinandersetzung mit dem Ziel der Ordnungsmäßigkeit der Rechnungslegung 

im Kontext der Bundesverwaltung bedingt. 

13 Project Management Body of Knowledge, siehe http://www.pmi.org/PMBOK-Guide-and-Standards.aspx 



Um die Anschlussfähigkeit der RA an die beiden untersuchten Rahmenwerke noch stärker 

zu konturieren, werden nachfolgend drei Zielmodelle abgebildet, die das bestehende Zielsystem 

der RA mit rekonstruierten Zielen von ITIL und COBIT verknüpfen. Dazu werden die in 

den Abschnitten 3.1 bis 3.3 rekonstruierten Ziele zueinander in Beziehung gesetzt. Ausgangspunkt 

bilden die strategischen Handlungsfelder der RA Handlungsfähigkeit (Abbildung 

5), Wirtschaftlichkeit (Abbildung 6) und hohe Dienstleistungsqualität (Abbildung 7). Für jedes 

dieser strategischen Handlungsfelder ist in der entsprechenden Abbildung eine Teildarstellung 

des Zielmodells dargestellt. Die Zielmodelldarstellung basiert auf der Methode zur Zielmodellierung 

[Zielmodellierung]. Ziele werden dementsprechend als Rechtecke mit runden 

Ecken und Zielbeziehungen als Pfeile dargestellt. Für die bessere Übersichtlichkeit der Darstellung 

wurden jedoch die subjektiven Zielwichtigkeiten entfernt. Ziele der RA, die auch von 

ITIL oder COBIT angeführt werden, sind mit einer entsprechenden Markierung „ITIL“ bzw. 

„COBIT“ versehen. 



Abbildung 5: Gegenüberstellung der zentralen Ziele von RA, ITIL und COBIT mit Fokus auf das Zielmodell 

„Handlungsfähigkeit” 



++ Wirtschaftlichkeit 

+ 

++ 

Effizienz 

++ 

ITIL COBIT 

++ 

+ 

++ 

+ 

Stärkung des 

Wettbewerbs von 

Herstellern und 

Lieferanten 

++ 

++ 

++ 

Beherrschbarkeit der 

Prozesse 

Standard- 

Komponenten und - 

- - 

Produkte nutzen 

COBIT 

+ + 

Stärkung der DLZ-IT 

des Bundes 

Nutzung von 

Skaleneffekten bei der 

Beschaffung 

+ 

Reduzierung redundanter 

IT-Lösungen 

+ 






+ 


Komplexität 

Agilität 

+ 

-- 

-- 



+ 

+ 

Ressourcenschonung 

Angemessene Vielfalt 


„Wirtschaftlichkeit“ 


- 

+ 

++ 

++ 

Wiederverwendung 

+ 

+ 

++ 

++ 

Umwelt- und 

Klimaschutz 

++ 

Zuverlässigkeit Schneller IT-Service 

Flexibilität 

Angebotstransparenz 

ITIL COBIT ITIL COBIT 

für Endnutzer 

Interoperabilität 


Spezialisten 

++ ++ - 

+ 



+ 

+ 





+ 

- 

+ 


+


Hohe 

Dienstleistungsqualität 

++ 

-- 

++ + 


Systeme 


Reduzierung 

redundanter IT- 

Lösungen 

+ 

-- 

Angemessene Vielfalt 


+ 


Komplexität 


++ 


+ 

++ 

IT-Arbeitsplätze sind 

attraktiv 

+ 


+ ++ 

für Endnutzer 


+ 






„Hohe Dienstleistungsqualität“ 

Da die Zielsysteme von ITIL und COBIT deutlich weniger expliziert sind als dies für die RA 

gilt, lassen sich keine Zielbeziehungen und Gewichtungen für die Zielesysteme von ITIL und 

COBIT rekonstruieren. Auf Wunsch des Bedarfsträgers wurden die Einflussstärken der Zielbeziehungen 

aus den zugrundeliegenden Zielmodellen der RA übernommen. Nach Einschätzung 

der Autoren sind die dargestellten Zielzusammenhänge daher im Hinblick auf die 

Übertragbarkeit auf die Ziele von ITIL und COBIT notwendigerweise mit einem erheblichen 

Interpretationsspielraum verbunden und können je nach gewähltem Anwendungszweck und 

-szenario auch deutlich unterschiedlich ausfallen. Die integrierten Zielmodelle sind daher als 

Arbeitsgrundlage für weitere, der Studie nachgelagerte Überlegungen intendiert und nicht als 

abgeschlossene und in sich geschlossene Zielmodelle zu interpretieren. 


- 


Rechtskonformität 


+ 


Spezialisten 

+ 





ITIL ITIL 

++ 

+ 

+ 

+ 

Flexibilität Wiederverwendung 

Sicherheit 

COBIT


4 Untersuchungsbereich Konzepte 

Die Integration von Ansätzen setzt gemeinsame Konzepte voraus. Deshalb werden hier die 

in der RA, in ITIL bzw. COBIT verwendeten zentralen Begriffen in Beziehung gesetzt. Dazu 

sind verschiedene Schritte erforderlich. Zunächst werden in einem ersten Schritt jeweils die 

zentralen Konzepte aus den drei Ansätzen rekonstruiert. Dies geschieht jeweils in Form 

eines Glossars (Beschreibung der Konzepte) in Verbindung mit semantischen Netzen (Erfassung 

der Zusammenhänge). 14 In einem zweiten Schritt werden die erstellten Glossare 

und semantischen Netze von ITIL und COBIT denen der RA gegenüberstellt und zueinander 

in Beziehung gesetzt. 

Dabei wird insbesondere berücksichtigt, welche Konzepte in den jeweiligen Ansätzen auf 

welcher Abstraktionsebene und in welchem Detaillierungsgrad verwendet werden. Übereinstimmende 

und widersprüchliche Konzepte werden identifiziert und dokumentiert. Dieses 

Vorgehen zielt darauf ab, ein möglichst kohärentes und konsistentes Begriffssystems für die 

RA zu erarbeiten. Darauf aufbauend kann dann die Anschluss- und Integrationsfähigkeit mit 

den Begriffssystemen von ITIL bzw. COBIT ermittelt werden. 

4.1 Rekonstruktion zentraler Begriffe der RA 

Die Rekonstruktion der zentralen Begriffe der RA basiert auf den vorgelegten Dokumenten 

zur RA (vgl. Anhang A). Zum einen erfolgt eine Analyse der textuellen Beschreibung der 

Rahmenarchitektur in diesen Dokumenten. In Abstimmung mit dem Bedarfsträger wurden 

dabei zentrale Begriffe identifiziert und ihre Beziehungen zueinander festgehalten. Zum 

anderen wurden die in den analysierten Dokumenten bereits vorhandenen Glossare zusammengeführt. 

Weiterhin wurde das so konsolidierte Glossar um Begriffe der RA ergänzt, die 

für die Analyse wesentlich waren. Auf Basis dieser Zusammenführung werden drei Analyseschritte 

durchgeführt: 

• Bisher in den Glossaren der RA nicht aufgeführte, jedoch als relevant identifizierte 

Begriffe werden um eine (vorläufige) Definition ergänzt, sofern diese aus der Dokumentation 

der RA entnommen werden kann. 

• Begriffe der RA werden auf abweichende Definitionen überprüft; dies betrifft insbesondere 

Begriffe, die in mehreren Glossaren, d.h. in unterschiedlichen Dokumenten 

der RA, definiert werden. 

• Die Definitionen werden auf inhaltliche Konsistenz und auf Kohärenz zu anderen Begriffen 

der RA überprüft, bspw. zur Aufdeckung von Synonymen. 

Das bereinigte Glossar ist dem Bericht in Anhang I angehängt. Dabei sind vom Bedarfsträger 

als (für die Untersuchung) irrelevant eingestufte Begriffe nicht mehr aufgeführt. 

Neben Vagheiten von Begriffen und Mehrdeutigkeiten in den Begriffsdefinitionen (Roelcke 

2010, S. 68ff.) ist auch die Verwendung von (möglichen) Synonymen auffällig. Wenngleich 

diese im Kontext einer natürlich-sprachlichen, textuellen Beschreibung der Rahmenarchitektur 

eine spezifische Funktion erfüllen (sprachlich-rhetorische Abwechslung für den Leser), 

empfiehlt es sich für eine Konzeptualisierung der Rahmenarchitektur und ihren Vergleich mit 

14 Semantische Netze (Begriffsnetze) dienen der visuell überschaubaren und an der natürlichen Sprache orientierten 

Erfassung von Begriffen und ihren Beziehungen. Dazu wird ein gerichteter Graph verwendet, in dem 

Knoten Begriffe und Kanten Beziehungen darstellen (siehe Anhang N ). Teilweise werden gestrichelte Linien zur 

Verfeinerung von Beziehungen verwendet. 



ITIL und COBIT die zentralen Begriffe der RA eindeutig zu definieren, einzuordnen und 

abzugrenzen. Als Synonyme wurden vom Bedarfsträger aus der Liste der potentiellen Synonyme 

die folgenden Begriffe identifiziert: 

• Aufgabe, fachliche Aufgabe, Fachaufgabe, Verwaltungsaufgabe, geschäftliche Aufgabe 

• Geschäftlicher Prozess, Verwaltungsprozess, Kernprozess 

• IT-Lösung, IT-System 

Nach der Rekonstruktion und Abstimmung der zentralen Begriffe und ihrer wesentlichen 

Zusammenhänge ergibt sich das in Abbildung 8 dargestellte Begriffsnetz. Das Netz fokussiert 

auf die Konzepte, die Bestandteil der Rahmenarchitektur sind. Nicht dargestellt sind 

Begriffe, welche die Anwendung der Rahmenarchitektur begleiten, etwa im Hinblick auf die 

organisatorische Aufbaustruktur (z. B. Rollen wie „Lösungsarchitekt“) oder auf die Einbettung 

der Rahmenarchitektur in den Kontext der IT-Steuerung Bund (z. B. „Planungsinstrument“). 

Der Darstellung liegen darüber hinaus weitere, mit dem Bedarfsträger abgestimmte Annahmen 

zu Grunde: 

• Die Differenzierung in Basis, Fach und Querschnitt (-Aufgaben, -IT und -Dienste) ist 

nicht wesensbestimmend, d.h. die Beschreibungsmerkmale für z. B. Basis-, Fach- 

und Querschnitts-Dienste sind identisch. Es handelt sich somit um kontextspezifische 

Attributierungen (Rollen), die je nach Betrachter (i.S. Behörde) vorgenommen werden. 

Beispielsweise handelt es sich beim Dienst „Reisekosten abrechnen“ um einen 

Querschnittsdienst aus dem Blickwinkel eines Ministeriums. Aus dem Blickwinkel des 

Bundesverwaltungsamt, die diesen Dienst anbieten, handelt es sich jedoch um einen 

Fachdienst. Aus der Sichtweise der RA ist die Beschreibung des Dienstes „Reisekosten 

abrechnen“ unabhängig vom Blickwinkel (Ministerium vs. Bundesverwaltungsamt) 

aber identisch. 

• Die Begriffe IT-Angebot, IT-Nachfrage, Dienstedomäne und Aufgabenbereich sowie 

Basis-, Fach- und Querschnitts-IT dienen im Wesentlichen der Gruppierung (der angebotenen/nachgefragten 

Dienste, der Dienste, der Aufgaben,…) und besitzen keine 

darüber hinausgehende Bedeutung. 

• Bei den verschiedenen Modellen (z. B. Geschäfts-, Dienst- oder technisches Modell) 

handelt es sich um Sichten auf die Rahmenarchitektur. 

Dienstedomäne 

gruppiert in 

Dienstekatalog 

Diensteklasse 

verwaltet in 

gruppiert in 

Aktivität Teil von 

Prozess 

benötigt 

Funktionalität 

bündelt 

Dienst 

realisiert durch 

Diensterealisierung 

IT-Lösung basiert auf IT-Komponente 

interagiert mit 

Abbildung 8: Rekonstruktion der zentralen Begriffe und ihrer Zusammenhänge aus der Dokumentation 

der Rahmenarchitektur 

Im Mittelpunkt der Rahmenarchitektur stehen insbesondere die Konzepte Dienst und Diensterealisierung. 

Ein Dienst steht für eine Menge an Anforderungen (auch: Funktionalitäten), 


nutzt 

erbracht durch 

erbracht durch 

nutzt 

besteht aus 

besteht aus 

Hardware Software


welche die Geschäftsseite an die IT-Unterstützung stellt; die Beschreibung der Anforderungen 

erfolgt dabei losgelöst von technischen Details. Die technisch orientierte Beschreibung 

der Anforderungen erfolgt stattdessen in der Diensterealisierung; die Beschreibung der 

Diensterealisierung ist bereits auf eine Implementierung durch Informationstechnologie gerichtet, 

die die abstrakter gehaltenen, in Terminologie der Geschäftsseite formulierten Anforderungen 

– den Dienst – erfüllt. Die konkrete Implementierung einer Diensterealisierung wird 

durch IT-Lösungen (auch: IT-System), die wiederum aus IT-Komponenten bestehen, oder 

direkt durch einzelne IT-Komponenten erbracht. Eine IT-Komponente kann Hardware 

und/oder Software sein. Zur Strukturierung von Diensten können diese in Diensteklassen – 

und diese wiederum zu Dienstedomänen – gruppiert werden. 

Die Konzepte IT-Leistung sowie verbindliche Vereinbarung werden in den Dokumenten zur 

RA erwähnt ([Grundlagen], S. 15), bisher jedoch noch nicht näher eingeordnet. Ebenso 

werden im Metamodell [Metamodell] noch die Konzepte IT-Produkt und IT-Dienstleistung 

angedeutet. Sie werden an dieser Stelle lediglich der Vollständigkeit halber aufgeführt, bleiben 

für die weitere Analyse aber unberücksichtigt. 

4.2 Rekonstruktion zentraler Begriffe der ITIL 

Der Rekonstruktion zentraler Begriffe der ITIL liegen die genannten Kernpublikationen der 

OGC zu Grunde. Es handelt sich insgesamt um rund 1500 Seiten Dokumentation verteilt 

über 5 Handbücher. Für die Rekonstruktion wird für jeden ITIL-Prozess ein semantisches 

Netz entwickelt. Diese Netze enthalten die Ergebnisse der Begriffsanalyse in Form von 

zueinander in Beziehung stehenden zentralen Konzepten. Die Analyse der Konzepte in ITIL 

ist wie auch die Analyse der Ziele mit Ungenauigkeiten und Interpretationsspielräume verbunden. 

Daher stellen die rekonstruierten Netze notwendigerweise immer eine Interpretation 

durch die Rekonstrukteure dar. In einem Zwischenschritt der Rekonstruktion ergeben sich 

somit mehrere detaillierte semantische Netze, die jeweils die Konzepte eines Prozesses der 

ITIL (z. B. Incident Management Prozess) und ihre Beziehungen beschreiben. Erst bei der 

Zusammenführung der einzelnen Netze über die Fokussierung auf gemeinsam verwendete 

Konzepte entsteht ein Netz, das überblicksartig ein Gesamtbild von ITIL zeichnet. Das Netz 

ist in Abbildung 9 dargestellt. Es ist in zweifacher Hinsicht eine Vereinfachung, die vor dem 

Hintergrund der Zielsetzung der Untersuchung vorgenommen wird: 

1. In der ITIL-Dokumentation findet sich eine Reihe von unbestimmten – d.h. mehrdeutigen 

oder vagen – Begriffen. Einerseits können sich diese Unbestimmtheiten aus der 

Zielsetzung von ITIL ergeben, Gestaltungsempfehlungen für den IT-Betrieb über alle 

Branchen und Unternehmensausprägungen hinweg zu geben und dabei als Kommunikationsinstrument 

zwischen den verschiedenen Beteiligten (auch unterschiedlicher 

IT-Organisationen) zu dienen. Unbestimmtheiten können hierbei den Zweck erfüllen, 

„[in einer Fachdiskussion] zur Herstellung eines einheitlichen Kenntnisstandes zunächst 

sehr unbestimmt zu bleiben und dann im weiteren Verlauf der Diskussion zu 

immer präziseren Formulierungen überzugehen“ (von Hahn 1998, S. 379). Andererseits 

können die Unbestimmtheiten Folge einer inkonsistenten Begriffsverwendung, 

etwa aufgrund der Vielzahl beteiligter Autoren an den Publikationen sein (z. B. die 

Begriffe „IT-Asset“ und „Service-Asset“); in diesem Fall werden die Unbestimmtheiten 

unter Wahl bestimmter Annahmen nachfolgend ausgeräumt. 

2. Konzepte, die ein niedriges Abstraktionsniveau besitzen und mit Blick auf IT- 

Organisationen bereits sehr detailliert sind (z. B. „Statement of Requirement“, „Information 

Security Policy“) werden ausgeblendet; sie werden nicht als zentrale Begriffe 



aufgefasst. Sie entfalten ihre Bedeutung bei der konkreten Implementierung von ITIL 

in einer Organisation und sind daher inhaltlich sehr weit von dem in der RA adressierten 

Abstraktionsniveau entfernt. 

Eine Auflistung der Kernbegriffe sowie ihre offiziellen Definitionen aus der ITIL finden sich in 

Anhang K ergänzt um zusätzliche Kommentierungen. 

Das Netz in Abbildung 9 zeigt die zentralen Konzepte der ITIL. 15 Im Mittelpunkt von ITIL steht 

der Service (auch IT Service), der die Schnittstelle zwischen Geschäftssicht mit den Geschäftsprozessen 

und (Unternehmens-) Zielen einerseits und der IT-Sicht mit den Daten, 

(Software-) Anwendungen und der technischen Infrastruktur (z. B. Hardware, Betriebssysteme, 

Netzwerk) andererseits darstellt. Ein Service repräsentiert eine Leistung der IT- 

Organisation, die für die Geschäftsseite einen Nutzen generiert. Dabei liegt dem Service- 

Begriff eine weite und unbestimmte Definition zugrunde. Ein Service ist in ITIL definiert als 

„Möglichkeit, einen Mehrwert für Kunden zu erbringen, indem das Erreichen der von Kunden 

angestrebten Ergebnisse erleichtert oder gefördert wird“ (z. B. [Service Design], S. 13f.). 

Eine Auflistung aller geplanten bzw. aller umgesetzten und in Umsetzung befindlichen Services 

wird in der Service-Pipeline bzw. im Service-Katalog vorgenommen, die zusammen 

das Service-Portfolio – das (geplante) Angebot – der IT-Organisation darstellen. Services 

können dabei in Service-Linien strukturiert und in verschiedenen Abstufungen (etwa im 

Hinblick auf Qualität, Verfügbarkeit etc.) angeboten werden (Service Levels). Ein Service 

besteht aus Komponenten, die einerseits andere Services sein können (in der Abbildung 

wird hiervon abstrahiert) oder andererseits durch Daten, Anwendungen oder Infrastruktur- 

Elemente realisiert sein können. Um die Erwartungen von Service-Abnehmern sowie die 

Verpflichtungen des Service-Erbringers (etwa aus rechtlichen Gründen) zu fixieren, werden 

nachdrücklich Vereinbarungen empfohlen: Service Level Agreement (SLA) bezeichnet eine 

Vereinbarung zwischen IT-Organisation und dem Diensteabnehmer, Operational Level Agreement 

(OLA) innerhalb der IT-Organisation und Underpinning Contracts (UC) zwischen IT- 

Organisation und ihren externen (Dienstleistungs-) Lieferanten. 

Serviceportfolio 

bilden 

bilden 

Servicelinie 

strukturiert in 

Service Package 

strukturiert in 

Servicekatalog 

Servicepipeline 

Ziel 

Bestandteil von 

Bestandteil von 

unterstützt 

Business- 

Prozess 

unterstützt 

Abbildung 9: Rekonstruktion der zentralen Begriffe und ihrer Zusammenhänge aus der Dokumentation 

der ITIL 

15 Grundlage der Rekonstruktion von ITIL ist die deutsche Übersetzung. Einige der Begrifflichkeiten sind jedoch 

auch dort nicht übersetzt (z.B. „Event“, „Incident“); um Verzerrungen zu vermeiden werden deshalb auch in dieser 

Studie nicht übersetzt. 


Service 

besteht aus 

Komponente 

besitzt 

SLA 

abhängig von/ 

nutzt 

kann sein 

kann sein kann sein kann sein 

Daten Anwendung Infrastruktur 

UC 

erfüllt 

besitzt 

Anforderung 

OLA 

Produkt 

Service Levels


Darüber hinaus werden in ITIL zusätzliche Abstraktionen und detailliertere Konzepte genutzt, 

von denen in Abbildung 9 aus Gründen der Übersichtlichkeit abstrahiert wird (siehe auch 

Anhang J): 

• Von organisationsexternen Lieferanten bezogene Komponenten werden auch als 

Produkt bezeichnet. 

• Eine von den IT-Experten in der IT-Organisation als zusammengehörig aufgefasste 

Kombination von Daten, Anwendung und Infrastruktur kann auch als IT-System bezeichnet 

werden. 

• Elemente (gleich welcher Art) der IT-Organisation, die als besonders relevant angesehen 

werden, werden als IT-Assets angesehen; gleiches gilt für Elemente der Geschäftsseite 

(Assets). 

• Services können im Zuge des Angebots im Service-Katalog gruppiert in Form von 

Service Packages angeboten werden; unterschieden werden in einem Service 

Package dabei Core Services als Kernbestandteile des Paket-Angebots und unterstützende 

Services, die z. B. als Aufwertung des Angebots dienen. 

• Als Abstraktion über materielle wie immaterielle Produktionsfaktoren wird der Begriff 

Ressource genutzt. 

• In der Dokumentation zum Service-Design wird an einigen wenigen Stellen der Begriff 

der Servicelösung verwendet ([Service Design] , S. 33f. und 49ff.), der das Ergebnis 

eines Service-Entwicklungsprozesses kennzeichnet; dieser Begriff wird in ITIL 

jedoch nicht weiter verwendet. 

Weiterhin in ITIL genutzt werden die Begriffe Anforderung, welche die Geschäftsseite an die 

IT-Unterstützung stellt und die ein entsprechender Service erfüllen muss, sowie Standard, 

der sowohl in technischer Hinsicht (z. B. Speicher- oder Austauschformate) als auch in betriebswirtschaftlicher 

Sicht (z. B. Prozessqualität-Bewertungsansätze) genutzt wird. 

ITIL nennt eine Reihe von weiteren Konzepten, die zwar als zentrale Konzepte angesehen 

werden können, jedoch aufgrund ihres Abstraktionsniveaus nicht näher im Fokus der Studie 

stehen und nicht weiter betrachtet werden. Eine Übersicht dieser Konzepte wird in Abbildung 

10 gegeben (grau gefärbte Begriffe dienen nur zum Verständnis des Netzes). 

Verfügbarkeit 

Kapazität 

weist auf 

weist auf 

Kontinuität weist auf 

besitzt 

Konfiguration 

stellt dar 

Baseline 

arbeitet auf 

Komponente 

ist ein 

betrifft 

Service 

ist ein 

Configuration Item 

Release resultiert aus 

ist ein 

betrifft 

SLA/OLA/UC 

Change 

beeinträchtigt 

beeinträchtigt 

Abbildung 10: Zentrale Konzepte der ITIL, die im Folgenden nicht weiter betrachtet werden 

4.3 Rekonstruktion zentraler Begriffe der COBIT 

Die zentralen Begriffe aus COBIT werden auf Basis der genannten Kernpublikation rekonstruiert 

[COBIT; COBIT-DE]. Die mit der Rekonstruktion verbundene Interpretation der Begriffe 

in COBIT und deren Zusammenhänge sind – deutlicher noch als bei ITIL – mit 


Incident 

verursacht 

Problem 

erzeugt 

deutet auf 

deutet auf 

deutet auf 

Event


erheblichen Herausforderungen verbunden, da die Begriffe in COBIT nicht näher definiert 

sind. Damit bleiben die Relevanz und Bedeutung zahlreicher Begriffe unklar bzw. unbestimmt 

(z. B. „Strategic IT-Plan“, „IT Service Portfolio“). Darüber hinaus nimmt COBIT keine 

Unterscheidung zwischen Kernkonzepten und ergänzenden Konzepten vor, die sich vor dem 

Hintergrund der aus 34 thematisierten IT-Prozessen resultierenden Begriffsvielfalt für die 

vorliegende Untersuchung empfiehlt. Es ist daher notwendig, eine eigene Differenzierung 

zwischen Kernkonzepten und ergänzenden (sekundären) Konzepten zu entwickeln. 

Entsprechend der Unterscheidung der Ziele und Sichtweisen von COBIT in die Sichtweise 

der IT-Revision bzw. die Sichtweise der Management-Unterstützung können die Begriffe in 

COBIT wie folgt eingeteilt werden: 

• Prüfungsbezogene Konzepte: Zur dieser Gruppe werden alle Kernkonzepte gerechnet, 

die auf die Unterstützung der Wirtschaftsprüfung gerichtet sind. Eine Darstellung 

der Kernkonzepte dieser Gruppe findet sich in Abbildung 11. Im Mittelpunkt steht dabei 

das Control Objective als zentrales Konzept. Jedes Control Objective ist auf ein 

Unternehmensziel gerichtet, dessen Erreichung durch IT-Risiken bedroht wird. Diesen 

Risiken sollen mit der Umsetzung von in Aktivitäten integrierten Controls (bspw. 

Richtlinien, Verfahren, Praktiken und Organisationsstrukturen) verhindert oder erkannt 

und korrigiert werden ([COBIT-DE], S. 17).Organisatorische Rollen haben definierte 

Verantwortlichkeiten für die Aktivitäten. Letztere dienen wiederum der 

Sicherstellung der Einhaltung der Control Objectives. Geprüft werden die Control 

Objectives im Rahmen eines Audits. Aktivitäten beziehen sich i. d. R. auf Bezugsobjekte. 

Diese Bezugsobjekte können von unterschiedlicher Art sein. Ein Bezugsobjekt 

ist dabei als Abstraktion über dynamische und statische Aspekte (bspw. Instrumente, 

Methoden, Prozesse, Dokumente, Verantwortlichkeiten) eines Unternehmens bzw. 

dessen IT-Organisation zu verstehen. Die Aktivität „Erstelle einen strategischen IT- 

Plan“ aus dem Prozess „Define a Strategic IT Plan (PO1)“ betrifft bspw. das Bezugsobjekt 

„Strategic IT-Plan“. Darüber hinaus werden die Konzepte Bezugsobjekt und 

Aktivität mit denen der managementbezogenen Kernkonzepte verknüpft. 

• Managementorientierte Konzepte: Zur dieser Gruppe lassen sich Konzepte mit Fokus 

auf die Unterstützung des IT-Managements zählen. Dargestellt sind diese Konzepte 

in Abbildung 12. Im Mittelpunkt steht hier der IT-Prozess, der als zentrales Element 

diesen Bereich strukturiert: So dient ein IT-Prozess der Erreichung eines oder mehrerer 

IT-Ziele, die durch die Unternehmensziele bestimmt werden. Die Erreichung der 

Ziele durch den IT-Prozess wird durch Kennzahlen gemessen. Ein IT-Prozess besitzt 

einen Reifegrad zur Einschätzung seines Implementierungsstands und der Identifizierung 

von Verbesserungspotenzialen. Jeder IT-Prozess ist genau einer der vier Domänen 

planen, bauen, betreiben und überwachen zugeordnet. Ein IT-Prozess 

erzeugt Informationen (Output) und verwendet IT-Ressourcen als Input. Diese IT- 

Ressourcen untergliedern sich in Informationen, Anwendungen, Infrastruktur und 

Personal. 16 Der IT-Prozess wird durch Aktivitäten näher beschrieben. Diese Aktivitäten 

dienen auch der Verknüpfung mit der prüfungsbezogenen Sichtweise von COBIT. 

In COBIT werden Aktivitäten lediglich durch eine Bezeichnung (z. B. „Analyse programme 

portfolios and manage project and service portfolios“) und die Zuordnung 

von Verantwortlichkeiten beschrieben. Weitere Informationen wie beispielsweise eine 

Detailbeschreibung der Aktivität sind nicht vorgesehen. Die Zuordnung von Verant- 

16 Die Gesamtheit der IT-Prozesse und der IT-Ressourcen in Form von Informationen, Anwendungen, Infrastruktur 

und Personal werden COBIT als „Unternehmensarchitektur für IT“ bezeichnet [COBIT-DE, S. 15]. Eine weitergehende 

Konzeptualisierung geschieht nicht, sodass der Architekturbegriff nicht weiter berücksichtigt wird. 



wortlichkeiten zu Aktivitäten wird über sog. RACI-Matrizen (Respnsible = verantwortlich, 

Accountable = rechenschaftspflichtig, Consulted = konsultierend, Informed = zu 

informieren) realisiert. 

Abbildung 11: Rekonstruktion zentraler Konzepte von COBIT der Revisions-Perspektive 

Abbildung 12: Rekonstruktion zentraler Konzepte von COBIT der Management-Perspektive 

Über die Kernkonzepte hinaus wird in den Beschreibungen der Prozesse und ihrer Aktivitäten, 

sowie den jeweiligen Control Objectives auf zahlreiche weitere Begriffe Bezug genommen. 

Diese werden in COBIT jedoch meist nicht näher erläutert. Vielmehr finden sich 

Aussagen der Form, dass bspw. das IT-Serviceportfolio aktualisiert werden soll. Wie dieses 

IT-Serviceportfolio umgesetzt werden soll, wird nicht erläutert. Diese Konzepte werden hier 

als sekundär betrachtet und in den semantischen Netzen als Bezugsobjekte dargestellt. Die 

aus den Aktivitäten und den Control Objectives der COBIT-Prozesse rekonstruierten Bezugsobjekte 

sind tabellarisch im Anhang F erfasst. Nähere Beschreibungen zu den Bezugsobjekten 

finden sich im Glossar zu COBIT in Anhang K. 

4.4 Gegenüberstellung 

Auf der Grundlage der Rekonstruktionen der zentralen Begriffe und ihrer Beziehungen in 

Form der semantischen Netze und der begleitenden Glossare können die zentralen Konzepte 

der Ansätze gegenübergestellt werden. Damit ist die Intention verbunden, Anknüpfungspunkte 

für die Weiterentwicklung der RA im Hinblick auf Konzepte in ITIL bzw. COBIT zu 



identifizieren. Die Gegenüberstellung erfolgt in grafischer Form. Dazu wird folgende Notation 

verwendet: 

Notationssymbol Beschreibung 

Blauer, eckiger, durchgezogener Rahmen: Das Konzept findet 

im anderen Ansatz keine Berücksichtigung. 

Roter, eckiger, gestrichelter Rahmen: Das Konzept findet in 

der RA keine Berücksichtigung. 

Grüner, runder, durchgezogener Rahmen: Das Konzept wird 

in der RA weniger differenziert konzeptualisiert 

Gelber, runder, gestrichelter Rahmen: Das Konzept ist in der 

RA differenzierter konzeptualisiert 

Ohne Rahmen, unterstrichen: Das Konzept ist in beiden 

Ansätzen in gleicher Detaillierung zu finden. 

Tabelle 1: Notation und Heuristik für Analyse gemeinsamer Konzepte 

Tendenzielle 

Anschlussfähigkeit 

Für die Ermittlung der tendenziellen konzeptuellen Anschlussfähigkeit der RA mit COBIT und 

ITIL ergeben sich folgende vier Heuristiken (siehe Spalte „Anschlussfähigkeit“ in Tabelle 1): 

1) Konzepte, die nur in einem Ansatz beschrieben werden, sind sehr wahrscheinlich 

(++) in dem anderen Ansatz anschlussfähig. Ein Konzept, was beispielsweise nur 

in ITIL existiert, kann sehr wahrscheinlich mit geringem Aufwand in die RA übernommen 

werden. 

2) Konzepte, die in der RA weniger ausführlich konzeptualisiert sind, besitzen Interpretations- 

bzw. (Aus-)Gestaltungsspielraum und sind damit voraussichtlich anschlussfähig 

(+) an konkreter ausgestaltete Konzepte in COBIT bzw. ITIL; 

3) Konzepte, die in der RA differenzierter konzeptualisiert sind und somit eine spezifischere 

(eingeschränktere) Bedeutung haben, können dagegen von organisationsspezifischen 

Umsetzungen von ITIL und COBIT des Bundes abweichen; eine 

Anschlussfähigkeit ist damit tendenziell nur bedingt (o) gegeben und ist näher zu prüfen. 

4) Bei gleich detaillierten Konzepten liegt keine Tendenz vor; hier muss in jedem Fall auf 

inhaltliche Anschlussfähigkeit geprüft werden (?). 

Die tendenzielle Anschlussfähigkeit wird jeweils durch ein Vergleich der Konzeptualisierungen 

näher untersucht, bei dem es ggf. zu abweichenden Ergebnisse kommen kann. Beispielweise 

kann bei der näheren Untersuchung zweier gleich detaillierter Konzepte 

(Heuristik 4) festgestellt werden, dass die Anschlussfähigkeit ohne Einschränkungen gegeben 

ist (++). 

Im Folgenden werden die Konzepte der RA den Konzepten aus ITIL bzw. COBIT im Detail 

gegenübergestellt. 

4.4.1 Zentrale Begriffe aus RA und ITIL 

Eine grafische Gegenüberstellung von RA und ITIL erfolgt in Abbildung 13. 

Prozess: Sowohl in der RA als auch in ITIL werden Prozesse als „Abfolge von Aktivitäten“ 

definiert, in denen Dienste (RA) bzw. Services (ITIL) zur Unterstützung genutzt werden können. 

Im Fokus stehen dabei in beiden Ansätzen Prozesse, die in den Fachabteilungen ausgeführt 

werden („Geschäftsprozesse“). Ein Kontrollfluss wird in beiden Ansätzen unterstellt; 


++ 

++ 

+ 

o 

?


die Möglichkeit der Modellierung von Prozessen, etwa mit Kontrollflussdiagrammen in der 

Notation Ereignisgesteuerter Prozessketten, wird nur in der RA erwähnt. Ob auch Prozesse 

der IT-Organisation – sog. IT-Prozesse – damit adressiert werden, ist sowohl in der RA als 

auch in ITIL unklar. 

Zwischenfazit: Die Konzepte stimmen überein. Anschlussfähigkeit im Hinblick auf die 

Geschäftssicht, insbesondere die Prozesse, ist gegeben (Anschlussfähigkeit: ++). 

Abbildung 13: Vergleichende Gegenüberstellung zentraler Konzepte in RA und ITIL 

Dienst: Zentrales Konzept beider Ansätze ist der Dienst, der in ITIL mit Service, in der RA 

mit Dienst und Diensterealisierung bezeichnet wird. In ITIL ist der Begriff des Service trotz 

seiner zentralen Bedeutung für das Rahmenwerk unbestimmt und sehr weit gefasst. Es 

bleibt offen, auf welchem Abstraktionsniveau (grob oder detailliert), aus welcher Perspektive 

(Geschäfts- oder technische Sicht) und mit welchem Inhalt (Beschreibung einer Anforderung, 

einer Lösung, …) ein Service zu beschreiben ist. Eine eventuelle Einschränkung des Servicebegriffs 

obliegt der ITIL einsetzenden Organisation. Hinweise oder eine Anleitung für 

eine solche Präzisierung gibt ITIL jedoch nicht. In der Rahmenarchitektur wird das Konzept 

des Dienstes mit der Zweiteilung Dienst und Diensterealisierung adressiert. Ein Dienst in der 

RA ist eine Menge von Anforderungen; eine Diensterealisierung ist die IT-technische Unterstützung 

eines Dienstes. Damit ist das Diensteverständnis in der RA differenzierter als in 

ITIL. Es liegt eine spezifische (eingeschränktere) Bedeutung zu Grunde. 

Zwischenfazit: Die Konzepte weichen erheblich voneinander ab. Die Gegenüberstellung 

der Dienste-Konzepte in RA und ITIL führt dabei zu einem ambivalenten Ergebnis: 

Einerseits kann der Service-Begriff in ITIL aufgrund seiner Unbestimmtheit auch die 

Konzeptualisierung des Dienste(realisierungs)-Begriffs der RA umfassen. Zugleich ist es 

allerdings möglich, dass in ITIL Services definiert werden, die nicht der spezifischen 

Konzeptualisierung von Dienst bzw. Diensterealisierung in der RA entsprechen. Eine 

Anschlussfähigkeit ist somit nur bedingt gegeben (Anschlussfähigkeit: o). 



Dienstekatalog: Verfügbare oder zukünftige Dienste werden in der Rahmenarchitektur im 

Dienstekatalog gelistet; in ITIL entspricht dies dem Servicekatalog. Die Gesamtheit aller 

Dienste – auch der geplanten, die jedoch noch nicht umgesetzt werden sollen oder können – 

wird in der RA im Dienstmodell (siehe Glossar zur RA, Anhang I), in ITIL (zusammen mit 

eingestellten Diensten) im Serviceportfolio verwaltet. In ITIL wird darüber hinaus noch die 

Servicepipeline vorgeschlagen; diese beinhaltet nur die geplanten Dienste und richtet sich in 

erster Linie an Akteure der IT-Organisation (z. B. IT-Experten). ITIL empfiehlt, für die Entwicklung 

und den Betrieb von Diensten Vorlagen für die Dienstbeschreibung zu nutzen, 

konkretisiert dies jedoch nicht weiter. In der RA werden Steckbriefe für Dienste konkret vorgeschlagen; 

eine Ausgestaltung für den Dienstekatalog (z. B. [Service Design], S. 259) gibt 

es noch nicht. 

Zwischenfazit: Die grundlegenden Überlegungen, die mit dem Dienstekatalog in der 

RA und dem Servicekatalog in ITIL verbunden sind, sind sehr ähnlich. Allerdings gibt es 

in der RA für die Servicepipeline keine Entsprechung, und es ist unklar, inwiefern in der 

RA auch eingestellte Dienste verwaltet werden. Die in ITIL geforderten Vorlagen zur 

Dienstebeschreibung werden in der RA – mit Ausnahme des Katalogs – konkretisiert. 

Eine Anschlussfähigkeit ist somit nur unter bestimmten Bedingungen gegeben. Eine Anschlussfähigkeit 

beim Dienstekatalog ist gegeben, sofern sich (1) eine “Dienstepipeline” 

jederzeit aus dem Dienstemodell ableiten lässt und (2) eingestellte Dienste weiterhin im 

Dienstekatalog, im Dienstemodell oder einer anderen Datenquelle auffindbar sind (Anschlussfähigkeit: 

o). 

Dienstegruppierung: Während in ITIL zur Gruppierung von Diensten Service Packages und 

Servicelinien angeboten werden, werden in der RA Dienste zu Diensteklassen und Dienstedomänen 

zusammengefasst. In der RA wird hierfür eine thematische Zusammengehörigkeit 

unterstellt. In ITIL bleibt offen, nach welchem Kriterium die Zusammenfassung erfolgen soll. 

Zudem sind die Konzepte Service Package und Servicelinie im Detail nicht eindeutig definiert 

(siehe Anmerkung im Glossar zu ITIL in Anhang J). 

Zwischenfazit: Eine Anschlussfähigkeit ist gegeben. Es empfiehlt sich jedoch, mit 

ITIL-Anwendern (z. B. die DLZ-IT des Bundes) über ihre Konkretisierung, etwa auch mit 

Blick auf die Gruppierungskriterien, von Service Package, Servicelinie und damit zusammenhängenden 

Konzepten zu sprechen und die Anschlussfähigkeit im Einzelfall zu 

prüfen bzw. diesbezüglich ein gemeinsames Begriffsverständnis aufzubauen (Anschlussfähigkeit 

+). 

Vertragliche Vereinbarung: Um die Bedingungen des Diensteaustauschs zwischen Dienste-Anbieter 

und Dienste-Nachfrager zu regeln, werden in ITIL dediziert verschiedene Konzepte 

für vertragliche Vereinbarungen (Service Level Agreement (SLA), Operational Level 

Agreement, (OLA) und Underpinning Contract (UC)) vorgeschlagen. In der RA wird die verbindliche 

Vereinbarung erwähnt, jedoch nicht näher konzeptualisiert. 

Zwischenfazit: Die RA erscheint durch das nicht näher bestimmte Konzept der vertraglichen 

Vereinbarung prinzipiell an ITIL anschlussfähig. Die RA könnte sich sogar für 

eine weitere Konzeptualisierung an der aus ITIL orientieren; dies sollte jedoch mit Blick 

auf den besonderen bundesbehördlichen Kontext der RA geprüft werden (Anschlussfähigkeit: 

+). 

IT-Lösung, IT-Komponente: In der RA werden unter IT-Lösungen (auch mit IT-System 

bezeichnet) die konkreten Implementierungen von Diensten aufgefasst. IT-Lösungen stellen 



dabei „zusammengehörige“ IT-Komponenten (z. B. Software und/oder Hardware) dar. In ITIL 

wird eine ähnliche Begrifflichkeit verwendet: Zusammengehörige Komponenten (Daten, 

Anwendungen, Infrastruktur) können als IT-System bezeichnet werden – wenngleich dieser 

Begriff nicht zum Kernrepertoire von ITIL gehört und bis auf wenige Ausnahmen in den Publikationen 

nicht verwendet wird (vgl. Abschnitt 4.2). Zugleich ist die Verwendung des (IT-) 

System-Begriffs in ITIL widersprüchlich (vgl. z. B. Verwendung in [Service Design, z. B. 

S. 114] gegenüber [Service Transition, S. 86]).). Es ist zu vermuten, dass die Begriffe Anwendung 

(ITIL)/Software (RA) bzw. Infrastruktur(ITIL)/Hardware(RA) eine ähnliche Semantik 

aufweisen. 

Zwischenfazit: Eine Anschlussfähigkeit scheint gegeben zu sein. 17 Gleichzeitig sind 

diese Begrifflichkeit von zentraler Bedeutung, da sie zu den Grundbegriffen von IT- 

Organisationen gehören. Insbesondere der Komponenten- und der Infrastruktur-Begriff 

können bei unterschiedlichen IT-Experten verschieden belegt sein. Es empfiehlt sich 

deshalb, sämtliche dieser Basisbegriffe – sowohl aus RA als auch aus ITIL – zu definieren, 

einzuordnen und dabei ggf. auch als synonym zu kennzeichnen (Anschlussfähigkeit 

+). 

Anforderung, Funktionalität: Die Begriffe Anforderung und Funktionalität werden in der RA 

differenziert definiert. Sie stellen zudem zentrale Begriffe für die Terminologie der RA, etwa 

auch zur Definition anderer Konzepte, dar. In ITIL wird der Begriff der Anforderung an vielen 

Stellen verwendet. Obwohl der Begriff im Glossar der ITIL-Primärliteratur definiert wird, ist 

seine Verwendung in diesen Publikationen unterschiedlich; seine Einordnung und Abgrenzung, 

beispielsweise im Hinblick auf Begriffe wie Service und (Geschäfts-)Prozess, bleibt 

unklar. Der Begriff Funktionalität gehört nicht zum Repertoire von ITIL. 

Zwischenfazit: Die grundlegenden Überlegungen zur Anforderung in ITIL scheinen 

ähnlich der entsprechenden Begrifflichkeit in der RA zu sein. Allerdings können sich aus 

der Unbestimmtheit in ITIL auch abweichende Interpretationen des Begriffs ergeben – 

zur Begrifflichkeit in der RA einerseits wie auch zu eventuell anderen Interpretationen der 

Anforderung in ITIL andererseits. Eine Anschlussfähigkeit ist somit nur bedingt gegeben. 

Gleichzeitig birgt die Unbestimmtheit in ITIL das Risiko von Missverständnissen innerhalb 

von ITIL(-Anwendern). Es scheint deshalb vielversprechend, das differenzierte Begriffsverständnis 

von Anforderung und Funktionalität aus der RA auch für die ITIL- 

Anwendungen des Bundes (z. B. in den DLZ-IT des Bundes) zu übernehmen. (Anschlussfähigkeit 

o für Anforderung, ++ für Funktionalität) 

4.4.2 Zentrale Begriffe aus RA und COBIT 

Die Gegenüberstellung zentraler Begriffe der RA mit Begriffen aus COBIT folgt dem gleichen 

Vorgehen, das auch der Gegenüberstellung mit den Begriffen aus ITIL zugrunde liegt. So 

werden auf Grundlage der rekonstruierten zentralen Begriffe, ihrer Beziehungen dargestellt 

in Form semantischer Netze und der begleitenden Glossare (Anhang J) die zentralen Konzepte 

der Ansätze vergleichend gegenübergestellt. 

In grafischen Gegenüberstellungen werden zentrale Konzepte aus der RA und COBIT gemäß 

des Detailierungsgrades ihrer Konzeptualisierung im Vergleich mit dem jeweils anderen 

Ansatz eingeordnet. Die Gegenüberstellung erfolgt ausgehend von der RA, d.h. ihre Terminologie 

liegt der Gegenüberstellung zugrunde. Es werden dazu die Notation und Heuristik 

verwendet, wie sie in Abschnitt 4.4 beschrieben sind. 

17 BMI: Die am Anfang von Abschnitt 4.4 eingeführten Heuristiken können hier nicht angewendet werden. 



Im Folgenden werden zunächst die Konzepte der RA mit Konzepten der Revisions- 

Perspektive aus COBIT gegenübergestellt (vgl. Abschnitt 4.3). Die grafische Darstellung 

findet sich in Abbildung 14. 

Ziel 

Risiko 

Legende: 

 

 

 

sichert Erreichung von 

dient Vermeidung von 

Control Objective 

geprüft durch 

Audit 

Konzept ist in RA weniger 

ausführlich dokumentiert 

Konzept existiert in beiden Ansätzen 

in gleicher Detaillierung 

Konzept findet in RA keine 

Berücksichtigung 

dient Einhaltung von 

 

 

Aktivität 

Konzept ist in RA ausführlicher 

dokumentiert 

Konzept findet in COBIT keine 

Berücksichtigung 

Abbildung 14: Vergleichende Gegenüberstellung primärer Konzepte in RA und COBIT: Revisions- 

Perspektive 

Aktivität: Eine Aktivität ist sowohl in der RA als auch COBIT Bestandteil eines Prozesses. In 

COBIT werden im Gegensatz zur RA keine näheren Angaben zu den Merkmalen einer Aktivität 

gemacht. 

Zwischenfazit: Eine Aktivität weist in der RA eine spezifischere Semantik auf und 

steht nicht im Widerspruch mit COBIT. Die Anschlussfähigkeit ist bedingt gegeben (Anschlussfähigkeit: 

o). 

Verantwortlichkeit: Das Konzept der Verantwortlichkeit nimmt in COBIT eine zentrale Rolle 

ein. Es wird zwischen vier Verantwortlichkeiten (zuständig, verantwortlich, konsultiert, informiert) 

unterschieden, die für die Zuweisung von Rollen zu den einzelnen Aktivitäten verwendet 

werden. In der RA wird keine durchgängige Verwendung von Verantwortlichkeiten 

vorgenommen. Im Prozess der Nachfragebündelung (Abschnitt 5.4.2) werden zwar die vier 

Verantwortlichkeiten aus COBIT um zwei weitere Verantwortlichkeiten (Mitarbeit, Qualitätsprüfend) 

ergänzt und im Rahmen des Prozesses verwendet, jedoch gehört dieser Prozess 

nicht uneingeschränkt zur RA und die verwendeten Verantwortlichkeiten entsprechend daher 

nicht notwendigerweise Festlegungen der RA. Vielmehr sind diese Festlegungen noch nicht 

getroffen worden. Aus diesen Gründen wird das Konzept Verantwortlichkeit in Abschnitt 4.1 

nicht als Konzept der RA aufgeführt. 

Zwischenfazit: Einerseits wird das Konzept Verantwortlichkeit in der RA differenzierter 

ausgestaltet, andererseits nicht durchgängig verwendet Das Verständnis und die Verwendung 

des Konzepts Verantwortlichkeit stimmt zwischen COBIT und RA grundsätzlich 

überein. Sofern die Verantwortlichkeiten der RA auf die Verantwortlichkeiten in COBIT 

abbildbar sind und bleiben, d.h. auf die vier dort definierten Verantwortlichkeiten eindeutig 

zurückgeführt werden können und Verantwortlichkeiten durchgängig und konsistent in 

der RA verwendet werden, ist die Anschlussfähigkeit an COBIT zu erwarten (Anschlussfähigkeit: 

+). 

Rolle: In COBIT wird über die Zuordnung von Aktivitäten und Verantwortlichkeiten hinaus, 

keine differenzierte Betrachtung oder Verwendung des Konzepts Rolle vorgenommen. So 


für 

Verantwortlichkeit 

hat 

Rolle


findet sich keine Beschreibung der Rollen in COBIT, die über eine Benennung und knappe 

Charakterisierung hinausgeht. In der RA werden die Rollen differenzierter beschrieben. Das 

Konzept Rolle ist sowohl in COBIT als auch der RA eng an das Konzept der Verantwortlichkeiten 

gebunden. 

Zwischenfazit: Das Konzept Rolle wird in der RA differenzierter betrachtet als in 

COBIT. Die grundlegende Übereinstimmung ist mit COBIT jedoch gegeben, sodass von 

einer bedingten Anschlussfähigkeit im Hinblick auf das Konzept Rolle ausgegangen werden 

kann (Anschlussfähigkeit: o). 18 

Control Objective, Audit, Risiko: Die weiteren Konzepte der Revisions-Perspektive 

(Control Objective, Audit, Risiko) werden in der RA zum gegenwärtigen Zeitpunkt nicht betrachtet. 

Für die weitere Betrachtung ist grundsätzlich zu klären, inwiefern insb. die Unterstützung 

von Audits für die RA relevant ist. Es sind jedoch keine grundlegenden 

Widersprüche zu erkennen, die einer Weiterentwicklung der RA um diese Konzepte entgegenstehen. 

Zwischenfazit: Da die Konzepte bisher in der RA nicht berücksichtigt werden und es 

keine Widersprüche mit existierenden Konzepten gibt, ist die Anschlussfähigkeit gegeben 

(Anschlussfähigkeit: ++). In Bezug auf die Unterstützung für Audits ist die Notwendigkeit 

und Sinnhaftigkeit zu prüfen. Die Berücksichtigung von allgemeinen Control Objectives 

im Kontext von Prozessen und Anwendungen (Process Controls und Application Controls) 

stellt ggf. eine Bereicherung der RA dar. Dazu sind die in COBIT vorgeschlagenen 

Control Objectives hinsichtlich des spezifischen Kontextes der RA zu überprüfen. Die 

Aufnahme des Konzepts Risiko in die RA zur Erfassung von Risiken, die mit dem IT- 

Einsatz verbunden sind, erscheint angebracht. 

Im nächsten Schritt werden die Konzepte der RA mit primären Konzepten der Management- 

Perspektive aus COBIT gegenübergestellt. Die grafische Darstellung findet sich in Abbildung 

15. 

Abbildung 15: Vergleichende Gegenüberstellung primärer Konzepte in RA und COBIT: Management- 

Perspektive 

18 BMI: Die am Anfang von Abschnitt 4.4 eingeführten Heuristiken können hier nicht angewendet werden. 



Prozess und IT-Prozess: Sowohl in der RA als auch in COBIT werden Prozesse als Abfolge 

von Aktivitäten konzeptualisiert. Während in der RA primär Geschäftsprozesse und deren 

Anforderungen an eine IT-Unterstützung betrachtet werden, sind in COBIT vornehmlich IT- 

Prozesse, d.h. Prozesse der IT-Leistungserbringung sowie allgemeine IT- 

Managementprozesse (z. B. die strategische IT-Planung), Gegenstand der Betrachtung. 

COBIT verwendet das Konzept Prozess nur oberflächlich im Sinne einer Sammlung von 

Aktivitäten und zugeordneten Verantwortlichkeiten; Kontrollflüsse werden nicht betrachtet. 

Zwischenfazit: Die Unterschiede sind inhaltlicher Art und bergen keine konzeptuellen 

Differenzen: Ein (IT-)Prozess ist eine Abfolge von Aktivitäten. Zur Vermeidung von Irritationen 

empfiehlt sich für die RA die Unterscheidung zwischen Geschäftsprozessen, die 

durch IT unterstützt werden, und IT-Prozessen, die der Erbringung dieser Unterstützung 

dienen. Die Anschlussfähigkeit ist gegeben. (Anschlussfähigkeit: +). 

Dienst: Den Konzepten des Dienstes und der Diensterealisierung in der RA steht das Konzept 

des IT-Service in COBIT gegenüber. Dabei stellt ein IT-Service in COBIT die Unterstützung 

der Prozesse durch die IT dar, d.h. sie werden durch die IT (sowohl intern als auch 

extern) erbracht und in Geschäftsprozessen verwendet. Eine nähere Differenzierung bzw. 

Strukturierung nimmt COBIT nicht vor. 

Zwischenfazit: Das Konzept IT-Service ist in COBIT wesentlich weiter gefasst als das 

Zusammenspiel der Konzepte Dienst und Diensterealisierung in der RA. Diese Zweiteilung 

der RA findet sich in COBIT nicht wieder. Letztlich bleibt die Semantik des Konzepts 

in COBIT unklar. Die Betrachtung der Anschlussfähigkeit kommt daher zu einem ähnlichen 

Ergebnis wie bei der Gegenüberstellung von ITIL und der RA: Einerseits kann der 

IT-Service-Begriff in COBIT aufgrund seiner Unbestimmtheit auch die Konzeptualisierung 

des Dienste(realisierungs)-Begriffs der RA umfassen. Zugleich ist es allerdings möglich, 

dass in COBIT IT-Services definiert werden, die nicht der spezifischen Konzeptualisierung 

von Dienst bzw. Diensterealisierung in der RA entsprechen. Die Anschlussfähigkeit 

ist daher nur bedingt gegeben (Anschlussfähigkeit: o). 

IT-Komponente / IT-Ressource: In COBIT ist das Konzept IT-Ressource sehr weit gefasst. 

So werden IT-Ressourcen in Prozessen der IT-Organisation eingesetzt, um die Unternehmensziele 

zu erreichen. Dabei wird in COBIT zwischen Anwendungen, Informationen, Infrastruktur 

und Personal als Arten von IT-Ressourcen unterschieden. Demgegenüber findet 

sich in der RA das Konzept IT-Ressource nicht direkt wieder. Dort wird insb. die Erbringung 

der technischen Leistung stärker strukturiert (IT-Komponente, IT-Lösung, etc.). Im Gegensatz 

zu COBIT wird dabei jedoch der Einsatz von Personal und Information nicht explizit 

berücksichtigt. Die Unterscheidung in der RA zwischen Hardware und Software stimmt weitgehend 

mit den Konzepten Infrastruktur und Anwendung überein, wenn auch die letzten 

Begriffe in COBIT wesentlich grobgranularer als in der RA verwendet werden. 

Zwischenfazit: Das Konzept IT-Ressource aus COBIT kann, beschränkt auf Software 

und Hardware, als das Konzept IT-Komponente in der RA interpretiert werden. Somit 

stimmen die Konzepte zwar nicht direkt überein, lassen sich aber ineinander überführen: 

Die Gesamtheit der IT-Lösungen und IT-Komponenten lassen sich als IT-Ressourcen 

auffassen. Für eine weitergehende Anschlussfähigkeit sollte der Einsatz von Personal 

und von Informationen als Teil der IT-Lösungen und –Komponenten dediziert durch entsprechende 

Konzepte in der RA berücksichtigt werden (Anschlussfähigkeit: o). 



Ziel: Das Konzept Ziel wird in der RA – insb. im Zusammenhang mit der Methode zur Zielmodellierung 

– sehr differenziert verwendet. Ziele werde dabei nach ihrer Priorität unterschieden. 

Maßnahmen (im Sinne von strategischen IT-Projekten) werden Zielen zugeordnet 

und dienen deren Erreichung. Dies soll durch Kennzahlen gemessen werden. Zwischen den 

Zielen werden sowohl unterstützende wie auch behindernde Zielbeziehungen unterschieden. 

Ebenfalls werden schwache und starke Zielbeziehungen in der RA differenziert. In COBIT 

wird das Konzept Ziel weniger differenziert verwendet. Ziele werden in COBIT in einer Hierarchie 

angeordnet, in der die Ziele einer untergeordneten Kategorie durch die übergeordneten 

Ziele bestimmt werden (Unternehmensziele bestimmen IT-Ziele, diese bestimmen 

Prozessziele, welche wiederum Aktivitätsziele bestimmen). 19 Die so abgeleiteten Ziele werden 

in Bezug zu den COBIT-Prozessen gesetzt. Neben dieser Hierarchie werden in COBIT 

keine weiteren Beziehungen zwischen Zielen berücksichtigt. 

Zwischenfazit: Grundsätzliche Widersprüche sind zwischen der RA und COBIT im 

Hinblick auf das Konzept Ziel nicht zu erkennen. Die unterschiedlichen Strukturierungen 

stehen orthogonal zueinander. So wäre bspw. zu evaluieren, ob die Zuordnung von Prozessen 

(im Sinne einer stärkeren Operationalisierung) zu Zielen, die sie beeinflussen, in 

die RA aufgenommen werden sollte. Dies mag zu mehr Transparenz über Ziele und Zielzusammenhänge 

und die Bedeutung der Prozesse beitragen (siehe auch Abschnitt 3.4). 

Die Anschlussfähigkeit im Hinblick auf das Konzept Ziel ist zu erwarten (Anschlussfähigkeit: 

+). 

Kennzahl: Kennzahlen werden in der RA weniger differenziert als in COBIT konzeptualisiert. 

So dienen Kennzahlen in der RA zwar ebenfalls der Messung der Zielerreichung, werden 

aber nicht näher spezifiziert. Es finden sich in der RA nur wenige Vorschläge für Kennzahlen. 

20 In COBIT wird hingegen zwischen „lead indicators“ (bezogen auf aktuelle Performanz) 

und „lag indicators“ (bezogen auf Ergebnis, nachgelagert) unterschieden und es werden für 

jeden IT-Prozess und den zugeordneten Ziele eine Reihe von Kennzahlen vorgeschlagen. 

Darüber hinaus sieht COBIT die Angabe der Einheit, der Frequenz der Erhebung, des Zielwertes, 

der Erhebungsmethode und der Art der Interpretation vor. Diese Details werden 

jedoch für die Kennzahlen in COBIT nicht vollständig angegeben. Zusammenhänge zwischen 

Kennzahlen werden in COBIT indirekt über die Zuordnung zur Zielhierarchie abgebildet. 

Zwischenfazit: Die Konzeptualisierung von Kennzahlen geht in COBIT weit über die 

der RA hinaus. Widersprüche deuten sich nicht an. Die von COBIT vorgeschlagenen Attribute 

können als Input für eine Weiterentwicklung des Konzepts Kennzahl dienen. Die 

Anschlussfähigkeit ist zu erwarten (Anschlussfähigkeit: ++). 

Reifegrad: Das Konzept Reifegrad findet zurzeit in der RA keine Berücksichtigung. In 

COBIT dienen Reifegradmodelle der Bewertung der 34 IT-Prozesse. Dies dient der Einschätzung 

des Implementierungsstands und der Identifizierung von Verbesserungspotenzialen. 

Zwischenfazit: Reifegrade werden in der RA derzeit nicht betrachtet. Für die Ergänzung 

der RA um Reifegradmodelle können die in COBIT vorgeschlagenen Reifegradmo- 

19 BMI: Die Frage, inwieweit das Erreichen der untergeordneten Ziele zum Erreichen der übergeordneten Ziele 

beiträgt wird in COBIT nicht explizit thematisiert. Es ist aber zu vermuten, dass implizit davon ausgegangen wird, 

dass die Erreichung der Unterziele ein Mittel zur Erreichung der Oberziele darstellt. 

20 Die Kennzahlen der RA befinden sich zum Zeitpunkt der Erstellung des Dokuments in der Entwicklung und 

wurden an dieser Stelle hier nicht mit berücksichtigt. 



delle als Grundlage dienen. Die Anschlussfähigkeit an COBIT ist gegeben (Anschlussfähigkeit: 

++). 

Domäne: Die RA unterscheidet zurzeit keine Phasen bzw. Domänen. In COBIT sind diese 

Domänen an generische Lebenszyklusphasen angelehnt und strukturieren die IT-Prozesse 

und damit auch die Control Objectives in COBIT. Dabei wird der Lebenszyklus von IT- 

Investitionen betrachtet. 

Zwischenfazit: Die Aufnahme von Domänen bzw. Phasen in die RA sollte prinzipiell 

möglich sein und die Anschlussfähigkeit ist zu erwarten (Anschlussfähigkeit: ++). Es ist 

dabei jedoch zu bestimmen, wovon der Lebenszyklus betrachtet wird und wie dieser zu 

anderen Lebenszyklen in Bezug steht (bspw. von IT-Ressourcen, IT-Services, Projekten 

etc.). Die Strukturierung der Inhalte der RA (Prozesse und Methoden, Artefakte, etc.) entlang 

eines generischen Lebenszyklus mag zu einem besseren Verständnis und zu einer 

klareren Struktur beitragen. Dabei ist jedoch zu beachten, dass sich die Prozesse der RA 

sich nicht immer nur auf eine einzelne Phase beziehen. 


Hinsichtlich der Konzepte der RA und der Konzepte in ITIL und COBIT sind keine eklatanten 

Widersprüche aufgefallen, was für die grundsätzliche Anschlussfähigkeit der RA auf konzeptueller 

Ebene an ITIL und COBIT spricht. Die Rekonstruktion der Semantik zentraler Konzepte 

ist allerdings in allen drei untersuchten Ansätzen mit erheblichen Herausforderungen 

verbunden: Semantik und Begriffsverständnis weisen für die untersuchten Konzepte erhebliche 

Interpretationsspielräume auf, die auf Vagheiten, Unterspezifiziertheit und Unbestimmtheit 

zurückzuführen ist. Für die Weiterentwicklung der RA mit Blick auf einen Anschluss an 

ITIL und COBIT ist jeweils zu entscheiden, wie mit der Unterspezifiziertheit von Konzepten in 

ITIL und COBIT umzugehen ist. Ergänzend zu den bereits zuvor unter „Zwischenfazit“ eingeführten 

Überlegungen sind aus Sicht der Gutachter bei der konzeptuellen Integration der RA 

mit ITL und COBIT die folgenden drei Aspekte besonders zu berücksichtigen: 

1) Potenziale eines gemeinsamen begrifflichen Referenzsystems ausbauen und ausschöpfen; 

2) Zentrales Konzept „Dienst“ weiterentwickeln; 

3) Weitere Konzepte gezielt in die RA aufnehmen 

Diese Aspekte werden im Folgenden detaillierter beschrieben. 

H-5 Handlungsempfehlung: Potenziale eines gemeinsamen begrifflichen (semantischen) 

Referenzsystems ausbauen und ausschöpfen 

Mit der Entwicklung und Pflege eines Glossars für zentrale Begriffe im Kontext der RA ist 

bereits ein erster wichtiger Schritt zur Schaffung einer gemeinsamen Sprachbasis unternommen 

worden. Das Glossar sollte insbesondere ausgebaut werden, um Begriffe, die 

bewusst von denen in ITIL und COBIT abweichen (z. B. differenzierter sind), zu erläutern; 

dabei empfiehlt sich, die Begriffe mit den Begründungen für die Abweichungen anzureichern. 

Dadurch wird eine differenzierte begriffliche Anschlussfähigkeit hergestellt. 

Die vorliegenden Analyseergebnisse bieten für die Ergänzung des RA Glossars eine gehaltvolle 

Grundlage, die allerdings verfeinert und ausgebaut werden müsste. Die Semantik der 

Konzepte der RA ist derzeit natürlich-sprachlich beschrieben. Im Metamodell findet sich nur 

vereinzelt formale Semantik einzelner Konzepte (Attribute, Datentypen). Das Metamodell 

beschreibt vorrangig Beziehungstypen zwischen Sprachkonzepten. Die daher auftretenden 



Interpretationsspielräume könnten zusätzlich zu Glossaren durch eine Anreicherung des 

Metamodells der RA um eine formale Semantik der Konzepte deutlich präzisiert werden. 

Gleichzeitig sollte eine Unterstützung durch ein Modellierungswerkzeug vorbereitet werden: 

Ein Werkzeug ist einerseits die Voraussetzung für die komfortable und konsistente Erstellung 

und Pflege von Modellen, andererseits ermöglicht es rechnergestützte Analysen und Transformationen. 

Insgesamt bietet sich aus Sicht der Gutachter ein metamodellbasierter Modellierungsansatz 

besonders an, um künftig auch weiterführende Konzepte etwa zu Strategien 

und IT-Landschaften zu berücksichtigten (siehe Handlungsoptionen in Kapitel 7). 

H-6 Handlungsempfehlung: Zentrales Konzept „Dienst“ weiterentwickeln 

Das zentrale Konzept Dienst ist in der Konzeptualisierung der RA deutlicher differenzierter 

und präziser formuliert als das Konzept Service in ITIL und COBIT. Insbesondere die Differenzierung 

in Dienst und Dienstrealisierung findet sich in ITIL und COBIT nicht; sie erscheint 

jedoch für die Zwecke der RA von erheblicher Bedeutung zu sein und bietet Potenziale, 

gegenüber ITIL und COBIT einen deutlichen differenzierteren Zugang zu erreichen. 

Allerdings weist die gegenwärtige Konzeptualisierung der RA auch Schwächen auf, die an 

einigen Fragen aufgezeigt werden sollen: Wieso sind Dienste und nicht Diensteklassen im 

Dienstekatalog verzeichnet? Aus welchem Grund wird nicht explizit zwischen Diensttyp und 

Dienstinstanz differenziert? Werden Dienstinstanzen oder Diensttypen betrachtet? Sind 

Dienste, die von IT-Experten erbracht werden, nicht Gegenstand der Betrachtung, da sie per 

definitionem keine „fachlichen“ Dienste darstellen? COBIT und ITIL liefert für die Beantwortung 

dieser Fragen jedoch keine Hilfestellung. 

H-7 Handlungsempfehlung: Weitere Konzepte gezielt in die RA aufnehmen 

Die Weiterentwicklung der RA kann sich einer Reihe von Konzepten aus ITIL und COBIT 

zumindest im Sinne von Anregungen bedienen, um offensichtliche Lücken mit Blick auf das 

gegenwärtige Zielsystem (z. B. die fehlende (vertragliche) Vereinbarung als Grundlage zur 

Förderung einer hohen Dienstleistungsqualität) zu füllen. Die Konzeptualisierungen in ITIL 

und COBIT sollten dabei nicht unreflektiert übernommen werden; sie bieten sich jedoch als 

Grundlage für eine weiter gehende Verfeinerung an. In ITIL scheinen insbesondere die Konzepte 

um den Servicekatalog und die vertragliche Vereinbarung für eine nähere Prüfung 

vielversprechend. In COBIT bezieht sich diese Empfehlung auf die Konzepte Control 

Objectives, Audit, Risiko, Personal, Verantwortlichkeit, Reifegrad und Domäne (vgl. Abschnitte 

4.4.1 und 4.4.2). 

Fazit 

Wenig Erfolg versprechend erscheint es aus Sicht der Gutachter, bereits vorliegende, i.d.R. 

differenziertere Konzepte zugunsten eines vordergründigen Anschlusses an ITIL und COBIT 

aufzugeben. Allerdings bietet es sich an, bei der Ergänzung neuer Konzepte zur RA auf die 

Anregungen aus ITIL und COBIT zurückzugreifen und diese für die jeweilige Zwecksetzung 

gezielt zu verfeinern und zu präzisieren. 



5 Untersuchungsbereich Prozesse 

Nach der Analyse statischer Abstraktionen, Ziele und Konzepte, richtet sich der Fokus dieses 

Abschnitts auf die Analyse der begleitenden Prozesse. Dieser Abschnitt untersucht die 

prozedurale Kompatibilität der RA mit Prozessen in ITIL und COBIT. Dazu werden die in 

ITIL, COBIT und der RA definierten bzw. vorgeschlagenen Prozesse jeweils kurz vorgestellt 

und anschließend für die Identifikation von inhaltlichen Überschneidungen, Widersprüchen 

und Integrationsmöglichkeiten gegenübergestellt. 

5.1 Prozesse der RA 

Anhand den zur Durchführung der Studie vorliegenden Dokumenten (siehe Anhang A) lassen 

sich folgende Prozesse und Vorgehensmodelle von Methoden (durch [M] gekennzeichnet) 

identifizieren: 

1. Ableitung von Diensten aus Geschäftsprozessen [M] 

2. Anpassung von Dienstemodell und Dienstekatalog (nur benannt) 

3. Erstellung der Spezifikationen (nur benannt) 

4. Zusammenwirken von IT-Angebot und IT-Nachfrage („Nachfragebündelung“) 

5. Architekturmanagement (nur benannt) 

6. Fortentwicklung strategischer Vorgaben (nur benannt) 

7. Service Level Management 

8. Servicedesk (Störungsmanagement und Bearbeitung von Service-Wünschen) 

9. Prozesse der IT-Steuerung Bund 

10. Zielmodellierung [M] 

Prozesse, welche als Vorgehensmodelle Bestandteile von Methoden sind, werden in der 

Prozessliste mit einem [M] gekennzeichnet. Dazu zählen beispielsweise die beschriebenen 

Vorgehen in der Methode Ableitung von Diensten aus Geschäftsprozessen. 

Tiefe und Umfang der Prozessbeschreibungen weisen ein großes Spektrum auf: während 

die Prozesse 1, 4 und 10 jeweils durch eigenständige Dokumente ([Methode], [Nachfragebündelung] 

und [Zielmodellierung]) ausführlich beschrieben werden, liegen zu den übrigen 

Prozessen nur sehr wenige Informationen vor. Die Prozesse 2 und 3 werden in der Dokumentation 

zu Prozess 1 als anschließende Prozesse ([Methode] S. 29) nur erwähnt und 

knapp charakterisiert. Die Prozesse 5 und 6 hingegen werden nur in den Ausführungen zu 

Prozess 4 bei der Beschreibung von Schnittstellen genannt. Die Zusammenhänge der Prozesse 

1, 2, und 3 bzw. 4, 5, 6 werden durch die Einrückung der entsprechenden Prozesse in 

der obigen Auflistung angedeutet. 

Die Prozesse 7 und 8 fallen in den Verantwortungsbereich der DLZ-IT des Bundes und sind 

eng an ITIL-Prozesse angelehnt. Die Prozesse werden in [Anlage1a] näher ausgeführt. 

Aufgrund der Zuordnung zu den DLZ-IT des Bundes und der offensichtlichen Nähe zu ITIL 

werden sie an dieser Stelle nach Absprache mit dem Bedarfsträger nicht näher untersucht. 

Zu den Prozessen unter Punkt 9 finden sich keine Angaben zu deren genauen Zweck, den 

beteiligten Akteuren oder den einzelnen Aktivitäten. Exemplarisch sind die Prozesse Fortschreibung 

Soll-Bebauungsplanung, Erstellung Transformationsplan, Fortschreibung Dienstekatalog 

und Fortschreibung Rahmenarchitektur zu nennen ([DLZ-IT_Anlage], S. 9). Über 

die Nennung hinaus liegen keine näheren Informationen vor, sodass die genannten Prozes- 



se für die Gegenüberstellung mit Prozessen aus ITIL und COBIT nicht weiter berücksichtigt 

werden können. 

Neben diesen Prozessen der RA existiert eine ergänzende Methode (Prozess 10, [Zielmodellierung]), 

in der ein Vorgehen in Form eines Prozesses zur Modellierung von Zielen im 

Kontext der Rahmenarchitektur beschrieben wird. Dies geschieht ohne die Angabe eines 

konkreten Kontrollflusses. Im Unterschied zu den übrigen Prozessen hat die Methode zur 

Zielmodellierung daher eher den Charakter eines Hilfsmittels bzw. eines Instruments und 

wird ebenfalls in Absprache mit dem Bedarfsträger nicht näher untersucht. 

Für die weitere Untersuchung werden zunächst die Prozesse 1 und 4 näher betrachtet. Dazu 

werden die Prozesse in stark verkürzter Form zusammengefasst, die beteiligten Akteure 

benannt sowie Input und Output identifiziert. Ergänzend dazu werden zentrale Bezugsobjekte 

21 (bspw. Instrumente, Dokumente) und dem Prozess zuordenbare Ziele identifiziert. Die 

Zuordnung von Zielen und Bezugsobjekten zu den Prozessen beruht dabei auf Interpretation, 

da dazu keine konkreten Angaben in der RA vorliegen. 

5.1.1 Ableitung von Diensten aus Geschäftsprozessen 

Dieser Prozess ist Bestandteil einer Methode, die dazu dient, aus gegebenen Geschäftsprozessen 

systematisch benötigte Dienste abzuleiten und mit dem sog. Dienstmodell und dem 

Dienstkatalog abzugleichen. Dazu wird in der Methodenbeschreibung eine Einordnung in 

das V-Modell XT vorgenommen, zwei beteiligte Rollen (Geschäfts- und Lösungsarchitekt) 

vorgestellt und der eigentliche Prozess sowie seine einzelnen Aktivitäten detailliert beschrieben. 

Die Ergebnisse der Ableitung von Diensten aus Geschäftsprozessen – sog. Dienstesteckbriefe 

– dienen als Input für die Folgeprozesse „Anpassungen von Dienstemodell und 

Dienstekatalog“ und „Erstellung der Spezifikationen“. Diese Prozesse sind gegenwärtig noch 

nicht näher spezifiziert. 

Die Methode zur Ableitung von Diensten aus Geschäftsprozessen zielt in der Anwendung 

darauf ab, möglichst alle fachlichen Anforderungen, die sich aus Geschäftsprozessen ergeben, 

in Diensten zu bündeln und eine entsprechende Sammlung von Dienstebeschreibungen 

– den Dienstekatalog – aufzubauen. Dieser Dienstekatalog soll dazu dienen, systematisch 

Lücken in Form noch fehlender Dienste und Funktionalitäten zu entdecken und bereits existierende 

Dienste, bzw. Bestandteile davon, systematisch wiederzuverwenden und weiterzuentwickeln. 

Mit der Fokussierung auf Dienste adressiert der Prozess primär das 

Dienstemodell und ist somit zwischen Geschäfts- und IT-Seite bzw. geschäftlichen Modell 

und dem Dienstemodell einzuordnen. Es sind weder Details der konkreten Erbringung der 

Dienste noch bezüglich deren Verwendung in den zugehörigen Geschäftsprozessen Gegenstand 

der Methode. Der Prozess ist in vereinfachter Form in Tabelle 2 zusammengefasst. 22 

Prozess (1) Ableitung von Diensten aus Geschäftsprozessen 

(„Diensteableitung“) 

Subprozesse/Aktivitäten 1. Identifizieren und Bündeln von Funktionalitäten 

2. Ergänzen von impliziten Funktionalitäten 

3. Gruppieren der Funktionalitäten nach Diensten 

4. Abgleich mit dem Dienstekatalog 

5. Abgleich mit dem Geschäftlichen Modell 

6. Einordnung neuer Funktionalitäten und Dienste 

Akteure • Lösungsarchitekt, 

• Geschäftsarchitekt 

21 Zum Begriff des Bezugsobjekts vgl. Abschnitt 4.3. 

22 Die nähere Betrachtung der Akteure (Rollen und Gremien) erfolgt in Abschnitt 6.1. 



Prozess (1) Ableitung von Diensten aus Geschäftsprozessen 

(„Diensteableitung“) 

Input • Geschäftsprozessmodelle, 

• Geschäftliches Modell, 

• Dienstekatalog 

• Dienstemodell 

Output • Überarbeiteter Dienstekatalog (ggf. mit zusätzlichen Diensten), 

Grundlage für technische Umsetzung 

• Erste Lösungsskizzen für Umsetzung 

• Vollständige Funktionalitätenliste 

• Dienstesteckbriefe 

Bezugsobjekte • Dienstesteckbrief 

• Dienstekatalog 

• Dienstemodell 

• Funktionalitätenliste 

Zugeordnete Ziele • Wiederverwendung von Diensten 

• Systematisches Ableiten von Anforderungen an IT aus Verwaltungsbedarfen 

• Kopplung IT-Geschäft 

Tabelle 2: Prozess – Ableitung von Diensten aus Geschäftsprozessen 

Dem Vorgehen zur Ableitung von Diensten sind die Prozesse Anpassen von Dienstemodell 

und Dienstekatalog und Erstellen der Spezifikation nachgelagert. Ersterer zielt darauf ab, 

aufgrund von Erweiterung und Änderungen der Funktionalitäten das Dienstemodell anzupassen 

oder um neue Dienste zu ergänzen. Dies bedarf der Analyse von Auswirkungen auf 

existierende Inhalte des Dienstemodells und des Dienstekatalogs. Letzterer bezieht sich auf 

die Spezifikation der fachlichen und technischen Konzepte basierend auf den Dienstesteckbriefen 

durch die Architekten. Weitere Angaben über In- und Output, beteiligte Akteure 

oder einzelnen Aktivitäten liegen nicht vor. 

5.1.2 Zusammenwirken von IT-Angebot und IT-Nachfrage 

Dieser Prozess zielt auf die Bündelung der Nachfrage nach ressortübergreifenden IT- 

Produkten 23 und die Herbeiführung entsprechender Angebote durch die DLZ-IT des Bundes. 

Dazu dient die strukturierte jährliche Erarbeitung eines IT-Bedarfskatalogs und eines IT- 

Programmplans aus Sicht der Nachfrager (d.h. den einzelnen Ressorts). Diese Dokumente 

dienen auch als Teilmenge des IT-Rahmenkonzepts des Bundes, das die Grundlage für die 

Aktualisierung des Produktkatalogs der DLZ-IT des Bundes bildet. 

Der Prozess der Bündelung der IT-Nachfrage ist außerdem die Arbeitsgrundlage für den 

Nachfragerbeirat. Der Nachfragerbeirat koordiniert mit diesem Prozess federführend die 

Abstimmung von IT-Angebot und IT-Nachfrage. Eine komprimierte Übersicht über den Prozess 

bietet Tabelle 3. 

Prozess (4) Zusammenwirken von IT-Angebot und IT-Nachfrage 

(„Nachfragebündelung“) 

Subprozesse/Aktivitäten 1. Bedarfserhebung 

2. Umsetzungsvorhaben 

3. Finalisierung Umsetzungsplanung 

4. Ableitung Ergebnisdokumente 

23 Die abweichende Terminologie dieses Prozesses lässt sich (vermutlich) auf die abweichenden Hintergründe 

der für diesen Prozess zuständigen Projektgruppe zurückführen. Ein IT-Produkt kann hier als ein Element einer 

IT-Lösung verstanden werden, bspw. eine Office-Anwendung. Die Betrachtung erfolgt dabei bei einem IT-Produkt 

aus Kundensicht. Die abschließende Begriffsklärung obliegt dem Bedarfsträger. 



Prozess (4) Zusammenwirken von IT-Angebot und IT-Nachfrage 

(„Nachfragebündelung“) 

Akteure • Rat der IT-Beauftragten 

• Nachfragebeirat (federführend) 

• Kundenmanager DLZ-IT des Bundes 

• IT-Beauftragter eines Ressorts 

• Nachfragekoordinator der Ressorts 

• Team Architekturmanagement 

• Team IT-Rahmenkonzept 

Input • Strategische Vorgaben 

• IT-Programmplan /Maßnahmenliste 

• IT-Rahmenkonzept des Bundes 

• Produktkatalog der DLZ-IT des Bundes 

Output • IT-Bedarfskatalog (Zwischenergebnis) 

• Aktualisierter IT-Programmplan / Maßnahmenliste (Beitrag zum IT- 

Rahmenkonzept des Bundes) 

• Aktualisierter Produktkatalog der DLZ-IT des Bundes 

Bezugsobjekte • IT-Maßnahmenliste 

• Ressortübergreifender IT-Bedarfskatalog 

• Vorhabenliste 

• IT-Rahmenkonzept des Bundes 

• Produktkatalog der DLZ-IT des Bundes, 

• Soll-Bebauungsplan 

Zugeordnete Ziele • Fachliche Integration 

Tabelle 3: Prozess – Zusammenwirken von IT-Angebot und IT-Nachfrage 

Der Prozess zum Zusammenwirken von IT-Angebot und IT-Nachfrage steht mit weiteren 

Prozessen in Beziehung. In der Dokumentation wird auf das Architekturmanagement (insb. 

Vorgaben und Input für Weiterentwicklung und Anpassung der Soll-Bebauungsplanung) und 

die Fortentwicklung der IT-Strategie (Input für Fortentwicklung der IT-Strategie) verwiesen 

([Nachfragebündelung], S. 20). Abgesehen von kurzen Einordnungen dieser Prozesse liegen 

dazu keine weiteren Angaben vor. 

5.2 Prozesse und Vorgehensweisen der ITIL 

Die ITIL betrachtet das Management von IT-Dienstleistungen entlang eines Lebenszyklus – 

von Entwurf über Umsetzung und Betrieb bis zur Einstellung. Dazu wird ein Lebenszyklusmodell 

verwendet, das sich in folgende Phasen unterteilt (Die Dokumentation zu ITIL gliedert 

sich entsprechend nach diesen 5 Phasen): 

• Service Strategy (dt. Servicestrategie) 

• Service Design (dt. Serviceentwurf) 

• Service Transition (dt. Serviceüberführung) 

• Service Operation (dt. Servicebetrieb) 

• Continual Service Improvement (dt. Kontinuierliche Serviceverbesserung) 

Für jede Phase wird in der Regel eine Reihe von Prozessen vorgeschlagen, die durch Angabe 

von Aktivitäten, Rollen und möglichen Instrumenten verfeinert werden. Betrachtet werden 

alle der 26 ITIL-Prozesse. Die Zuordnung der in den jeweiligen Dokumenten beschriebenen 

Prozesse zu den einzelnen Phasen ist in Abbildung 16 dargestellt. Dabei ist zu beachten, 

dass der Kern des Lebenszyklus aus den Phasen Service Design, Service Transition und 

Service Operation besteht. Service Strategy liefert Richtlinien und Ziele und wirkt dadurch 



auf alle nachfolgenden Phasen; dedizierte Prozesse lassen sich hier nur vergleichsweise 

wenige finden. Das Continual Service Improvement umfasst die kontinuierliche Verbesserung 

und begleitend damit ebenfalls alle anderen Phasen; Prozesse werden in diesem Dokument 

nicht vorgeschlagen. 

Abbildung 16 stellt eine Vereinfachung dar: die Prozesse in ITIL beziehen sich nicht durchgängig 

auf jeweils nur eine Lebenszyklusphase. Vielmehr werden teilweise Prozesse vorgeschlagen, 

die sich über mehrere Phasen bzw. über den gesamten Lebenszyklus erstrecken, 

wie bspw. das Financial und das Demand Management. Das Financial und Demand Management 

werden zwar in [Service Strategy] beschrieben, beziehen sich jedoch auf den gesamten 

Lebenszyklus. Eine Darstellung, die diesem Sachverhalt Rechnung trägt, findet sich 

in Anhang D. Eine ausführlichere Übersicht über die zentralen Prozesse von ITIL liefert 

Anhang C. 

Service Strategy Service Design Service Transition Service Operation 

Demand Management 

Service Portfolio Management 

Financial Management 

Service Catalogue Management 

Service Level Management 

Capacity Management 

Availability Management 

IT Service Continuity Management 

Information Security Management 

Supplier Management 

Information Security Management 

Supplier Management 

Abbildung 16: Übersicht über die ITIL-Prozesse 

Der Detailgrad der Beschreibungen der ITIL Prozesse unterscheidet sich teilweise stark. 

Während die Prozesse etwa im Bereich der Service Operations (z. B. das Problem Management) 

sehr konkret und unter Angabe von Kontrollflüssen beschrieben werden (z. B. 

[Service Operation], S. 69), sind Angaben im Bereich der Service Strategy deutlich weniger 

konkret. Anstelle von Kontrollflussbeschreibungen der Prozesse treten Beschreibungen von 

allgemeinen Handlungsempfehlungen, bspw. für die Ausgestaltung des Service Portfolio 

Managements ([Service Strategy], S. 141). 

5.3 Prozesse und Vorgehensweisen der COBIT 

In COBIT werden 34 Prozesse unterschieden, die ebenfalls anhand eines einfachen Lebenszyklusmodells 

strukturiert werden. Dabei verwendet COBIT vier Lebenszyklusphasen 

bzw. in der COBIT-Terminologie: vier sog. „Domains“. Folgende Domains werden dabei 

unterschieden: 

1. Plan and Organise (PO): 10 Prozesse 

2. Acquire and Implement (AI): 7 Prozesse 

3. Deliver and Support (DS): 13 Prozesse 

4. Monitor and Evaluate(ME): 4 Prozesse 

Transistion Planning and Support 

Change Management 

Service Asset and Configuration Management 

Release and Deployment Management 

Service Validation and Testing 

Evaluation 

Knowledge Management 

Event Management 

Incident Management 

Problem Management 

Request Fullfillment 

Access Management 

Service Strategy Continual Service Improvement 

Service Strategy 

Eine Übersicht über die vier Domains und die jeweiligen Prozesse bietet Abbildung 17. 



Abbildung 17: Übersicht der COBIT-Prozesse (in Anlehnung an [COBIT-DE], S. 24) 

Jeder Prozess wird durch die Angabe folgender Details beschrieben: 

1. Prozessbeschreibung mit Zielen, zu deren Erreichung der Prozess beitragen soll, und 

einem übergeordneten Control Objective, das die Steuerung des Prozesses sicherstellen 

soll 

2. Beschreibung detaillierterer Control Objectives 

3. Prozessinputs und -outputs (d.h. Abhängigkeiten zu anderen Prozessen) 

4. Verantwortlichkeiten für die einzelnen Aktivitäten 

5. Detailliertere Ziele und zugehörige Kennzahlen 

6. Reifegradmodell 

Dabei ist zu beachten, dass COBIT für Prozesse keine Beschreibung des Kontrollflusses 

angibt. Prozessbeschreibungen benennen lediglich Aktivitäten (bspw. „Link business goals to 

IT-goals“ aus dem Prozess „Define a strategic IT Plan“ PO1), die nicht näher beschrieben 

sondern nur aufgelistet werden. Durch RACI-Matrizen werden tabellarisch Rollen und Gremien 

Verantwortlichkeiten den einzelnen Aktivitäten zugeordnet. RACI steht dabei als Akronym 

für die vier in COBIT unterschiedenen Verantwortlichkeiten: responsible (zuständig), 

accountable (verantwortlich), consulted (konsultiert) und informed (informiert). 

Statt auf der Beschreibung der Aktivitäten und liegt der Fokus stärker auf den Control 

Objectives (insgesamt 210, siehe auch Abschnitt 3.3 und 4.3). Zusätzlich zu den Control 

Objectives der jeweiligen Prozesse schlägt COBIT eine Reihe von ergänzenden, allgemeinen 

Control Objectives für Prozesse und Applikationen vor, z. B. „Process Ownership“ für IT- 

Prozesse und „Transaction Authentication and Integrity“ für Anwendungen. Eine vollständige 

Übersicht über die Prozesse und den zugehörigen Control Objectives von COBIT findet sich 

in Anhang D. 



Sowohl in den Aktivitäten als auch den Control Objectives wird auf unterschiedliche Instrumente 

wie z. B. Dokumente und Modelle verwiesen. Diese Instrumente werden im Folgenden 

als Bezugsobjekte bezeichnet. Die Bezugsobjekte werden in COBIT jedoch nur benannt 

und nicht näher spezifiziert, d.h. COBIT liefert keine detaillierten Beschreibungen oder Vorschläge 

für deren Ausgestaltung. Der Nutzen von COBIT für die Realisierung der Bezugsobjekte 

ist daher eingeschränkt. Als Beispiele lassen sich „Strategic IT Plan“ (PO 1.4), 

„Information Architecture“ (PO 2) oder „Change Request“ (AI6) nennen. Dies spiegelt den 

grundsätzlichen Charakter von COBIT wieder: COBIT fokussiert auf das Was, weniger auf 

das Wie (siehe auch Abschnitt 3.3). 


Ausgehend von den identifizierten und beschriebenen Prozessen der RA werden zusammengehörige, 

d.h. sich überschneidende oder ähnliche, Prozesse aus ITIL und COBIT identifiziert 

und auf mögliche inhaltliche Überschneidungen, Widersprüche und 

Integrationsmöglichkeiten untersucht. Dazu wird wie folgt vorgegangen: Zunächst werden 

Überschneidungen gesucht, die sich direkt aus der Betrachtung der Prozesse und den jeweiligen 

Aktivitäten ergeben (ähnliche Bezeichner, Akteure, Ereignisse etc.). 

Für die Ableitung von weiteren möglichen Anknüpfungspunkten zwischen den Prozessen der 

RA und den Inhalten aus COBIT und ITIL werden die mit den Prozessen verfolgten Ziele und 

im Prozess genutzten Bezugsobjekte (bspw. „IT-Architektur“, „Service-Portfolio“, „Technologie-Standard“, 

etc.) mit berücksichtigt. Dies ist notwendig, um Prozesse zu identifizieren, die 

sich nicht direkt über die beschriebenen Ähnlichkeiten ermitteln lassen. Dieser Betrachtung 

liegt die Annahme zugrunde, dass Prozesse, die auf ähnliche Bezugsobjekte verweisen 

und/oder den gleichen Ziele zugeordnet werden können, Anknüpfungspunkte für die RA 

darstellen. 

5.4.1 Ableitung von Diensten aus Geschäftsprozessen 

Die Analyse der in ITIL und COBIT vorgeschlagenen Prozesse ergibt, dass sich der Prozess 

der RA zur Ableitung von Diensten aus Geschäftsprozessen weder in ITIL noch in COBIT in 

einer unmittelbar vergleichbaren Form wiederfinden lässt. Es lassen sich jedoch Prozesse 

identifizieren, die ähnliche Ziele verfolgen, gemeinsame Bezugsobjekte aufweisen oder 

Teilaspekte des Prozesses adressieren. 

Die Analyse der in ITIL und COBIT beschriebenen Prozesse ergibt somit eine Liste von 

Prozessen, die Anknüpfungspunkte mit dem Prozess der RA zur Ableitung von Diensten aus 

Geschäftsprozessen aufweisen. Die identifizierten Prozesse sind in Tabelle 4 aufgelistet. Um 

Überschneidungen mit der Nummerierung der Prozesse aus der RA zu vermeiden, wird die 

Prozessnummer des betrachten Prozesses der RA (hier Nummer 1) vorangestellt. 

Als Zwischenfazit lässt sich festhalten, dass der betrachtete Prozess in keinem direkten 

Widerspruch zu Prozessen aus ITIL und COBIT steht und weder ITIL noch COBIT ähnlich 

detaillierte Prozessspezifikationen für den betrachteten Bereich aufweisen. Die Anknüpfungspunkte 

des Prozesses der RA an die identifizierten Prozesse in COBIT und ITIL werden 

in Abschnitt 5.5 aufgezeigt. 

Nr. Prozess Quelle Kurzbeschreibung 

1.1 Availability Management 


Service Design 

Soll sicherstellen, dass der Level an Serviceverfügbarkeit bei allen 

Services unter Berücksichtigung der Wirtschaftlichkeit die aktuell 

und zukünftig vereinbarten Business-Bedürfnisse erfüllt oder 

übertrifft. 




1.2 Capacity Management ITIL 


1.3 Change Management ITIL 

Service Transition 

1.4 Financial Management ITIL 


1.5 Information Security 

Management 

1.6 Service Level 

Management 

1.7 Define and Manage 

Service Levels 

1.8 Identify Automated 

Solutions 






DS1 


AI1 

1.9 Manage Changes COBIT 

AI6 

1.10 Manage Performance 

and Capacity 

1.11 Manage the IT- 

Investment 


DS3 


PO5 

Soll sicherstellen, dass in allen Bereichen der IT stets zeitnah eine 

wirtschaftliche und auf die vereinbarten aktuellen und zukünftigen 

Business-Bedürfnisse abgestimmte IT-Kapazität verfügbar ist. 

Dieser Prozess soll sicherstellen, dass Änderungs-Anforderungen 

an IT-Services (Infrastruktur, etc.) von Seiten des Business kontrolliert 

und effizient unter Minimierung von Risiken umgesetzt werden. 

Dazu sind standardisierte Verfahren zur Durchführung von Änderungen 

erforderlich. 

Das Financial Management stellt Informationen für das wirtschaftliche 

und kosteneffektive Service Delivery zu Verfügung. Es soll 

sicherstellen, dass Kosten für IT-Services transparent sind 

Stimmt die IT-Sicherheit auf die Business-Sicherheit ab, damit die 

Informationssicherheit für alle Service- und Service Management 

Aktivitäten effektiv verwaltet und gesteuert werden kann. 

Verhandelt, vereinbart und dokumentiert die geeigneten IT Service 

Ziele mit Vertretern des Business. Anschließend wird die Fähigkeit 

des Service Providers zur Bereitstellung des vereinbarten Service 

Levels überwacht und entsprechende Berichte erstellt. 

Eine effektive Kommunikation zwischen dem IT-Management und 

den Kunden der Services wird durch die dokumentierte Ausgestaltung 

und Vereinbarung von IT-Services und Service Levels unterstützt. 

Dieser Prozess enthält ebenso die Überwachung und die 

zeitnahe Berichterstattung an die Interessensvertreter über die 

Erreichung von Service Levels. Der Prozess soll die Angleichung 

zwischen IT-Services und den entsprechenden Unternehmenserfordernissen 

ermöglichen. 

Der Bedarf an neuen Anwendungen oder Funktionen erfordert eine 

Analyse, um sicherzustellen, dass die Unternehmensanforderungen 

wirksam und wirtschaftlich abgedeckt sind. Dieser Prozess deckt 

die Festlegung des Bedarfs ab, die Berücksichtigung alternativer 

Möglichkeiten, die Überprüfung der technischen und wirtschaftlichen 

Machbarkeit, die Durchführung einer Risikoanalyse sowie 

einer Kosten-/Nutzen-Analyse und das Fällen einer endgültigen 

Entscheidung für eine Eigenentwicklung oder Beschaffung. 

Änderungen an der Infrastruktur und den Anwendungen müssen 

formell auf eine gesteuerte Art und Weise vorgenommen werden. 

Jeder Change (auch an Verfahren, Prozesse, Systemen und 

Service-Parametern) müssen vor der Implementierung aufgezeichnet, 

bewertet und autorisiert sowie nach der Implementierung an 

Hand der geplanten Ergebnisse überprüft werden. 

Das Management der Performanz und Kapazität der IT- 

Ressourcen, bedingt einen Prozess, mit dem periodisch die 

aktuelle Performance und Kapazität der IT-Ressourcen beurteilt 

wird. Dieser Prozess berücksichtigt die Prognose künftiger Bedürfnisse, 

basierend auf den Anforderungen an die Arbeitslast, den 

Speicher und an die Sicherstellung des störungsfreien Betriebs 

(engl.: contingency). 

Es ist ein Framework zum Management der IT-Investitionen 

erforderlich, das Kosten, Nutzen, Priorisierung innerhalb des 

Budgetrahmens, einen formalen Budgetierungsprozess und eine 

Budgetverwaltung umfasst. Die Abstimmung mit den strategischen 

und taktischen IT-Plänen ist erforderlich. Der Prozess zielt darauf 

ab, die Gesamtkosten und den Gesamtnutzen zu identifizieren und 

zu steuern, und notwendige Maßnahmen bei Bedarf initiieren zu 

können. Er soll die wirksame und wirtschaftliche Verwendung von 

IT-Ressourcen ermöglichen. 

Tabelle 4: Prozesse aus ITIL und COBIT mit Anknüpfungspunkten zum Prozess der 

Diensteableitung der RA 

5.4.2 Zusammenwirken von IT-Angebot und IT-Nachfrage 

Die Analyse der ITIL- und COBIT-Prozesse zeigt, dass der Prozess der RA zum Zusammenwirken 

von IT-Angebot und IT-Nachfrage sich ebenfalls nicht in einer vergleichbaren 

Form wiederfinden lässt. Es lassen sich jedoch Prozesse identifizieren, die ähnliche Ziele 

verfolgen, gemeinsame Bezugsobjekte aufweisen oder Teilaspekte des Prozesses adressieren. 

Die Analyse der in ITIL und COBIT beschriebenen Prozesse und ihrer Beschreibungen 



ergibt somit eine Liste möglicher Prozesse, die sich in den Kontext des betrachteten Prozesses 

der RA einordnen lassen und somit Anknüpfungspunkte aufweisen. 

Die identifizierten Prozesse decken sich teilweise mit den in Abschnitt 5.4.1 identifizierten 

Prozessen. Tabelle 5 enthält das Ergebnis des Prozessvergleichs. Bei Prozessen, die schon 

in Abschnitt 5.4.1 beschrieben sind, wird auf die entsprechende Tabelle verwiesen und der 

Bezeichner wird beibehalten. 

Als Zwischenfazit lässt sich festhalten, dass der betrachtete Prozess in keinem direkten 

Widerspruch zu Prozessen aus ITIL und COBIT steht und weder ITIL noch COBIT ähnlich 

detaillierte Prozessspezifikationen aufweisen. Die Anknüpfungspunkte des Prozesses der 

RA an die identifizierten Prozesse in COBIT und ITIL werden in Abschnitt 5.5 aufgezeigt. 


1.2 Capacity Management ITIL 


1.3 Change Management ITIL 


1.4 Financial Management ITIL 


1.8 Identify Automated 

Solutions 


AI1 

1.9 Manage Changes COBIT 

AI6 

1.10 Manage Performance 

and Capacity 

1.11 Manage the IT- 

Investment 


DS3 


PO5 

4.1 Demand Management ITIL 


4.2 Service Catalogue 

Management 

4.3 Service Portfolio 

Management 

4.4 Define a Strategic IT 

Plan 






PO1 

Siehe Tabelle 4 







Das Demand Management zielt auf Gestaltung des Service- 

Angebots in Abstimmung mit den Anforderungen und Erwartung 

des Kunden. Dabei steht die kosteneffiziente und bedarfsgerechte 

Steuerung der Kapazität im Vordergrund. 

Soll sicherstellen, dass ein Servicekatalog erstellt und gepflegt wird, 

der exakte Informationen zu allen operativen Services und zu den 

Services, deren operativer Betrieb vorbereitet wird, enthält. 

Dieser Prozess dient der Bereitstellung eines Serviceangebots in 

Form eines Serviceportfolios, das sowohl den aktuellen als auch 

den zukünftigen Anforderungen der Kunden genügt. Dazu werden 

sowohl strategische als auch fachliche Anforderungen berücksichtigt. 

Die strategische IT-Planung zielt darauf ab die IT-Ressourcen in 

Übereinstimmung mit der Unternehmensstrategie und deren 

Prioritäten zu managen und zu steuern. Der strategische Plan sollte 

das Verständnis der Stakeholder über die Möglichkeiten und 

Grenzen der IT verbessern, die gegenwärtige Performance bewerten 

sowie den Umfang von notwendigen Investitionen ermitteln. 

Tabelle 5: Prozesse aus COBIT und ITIL mit Anknüpfungspunkten zum Prozess der 

Nachfragebündelung der RA 


Die Analyse und Gegenüberstellung der Prozesse der RA mit Prozessen aus ITIL und 

COBIT zeigt, dass keine direkten Überschneidungen und Widersprüche vorliegen. Daher 

deutet sich die Anschlussfähigkeit der Prozesse der RA an die Prozesse aus ITIL und COBIT 

an. Auch wenn keine direkten Überschneidungen vorliegen, lassen sich durch die Prozessanalyse 

eine Reihe von Prozessen aus ITIL und COBIT identifizieren, die Anknüpfungspunkte 

an die Prozesse der RA aufweisen. Auf diese wird im Folgenden näher eingegangen. 

Zunächst stehen jedoch generelle Beobachtungen, Auffälligkeiten und Schlussfolgerungen 

im Fokus. 



5.5.1 Übergreifende Handlungsempfehlungen 

H-8 Handlungsempfehlung: Zusammenhänge zwischen Prozessen verdeutlichen 

Generell werden die Zusammenhänge zwischen den beiden betrachteten Prozessen der RA 

derzeit nicht deutlich. Darüber hinaus werden voneinander abweichende Konzepte verwendet: 

Produkt und Produktkatalog statt Dienst und Dienstekatalog. Diese Unterschiede werden 

nicht explizit gemacht und auch nicht begründet. Die Vermutung liegt hier nahe, dass die 

Prozesse von verschiedenen Gruppen erstellt wurden und es daher zu einem unterschiedlichen 

Begriffsverständnis kommt. 

Die Dokumentation der RA sollte eine klare und nachvollziehbare Einordnung der Prozesse 

vornehmen, insb. sollten Abhängigkeiten (bspw. in Form von Schnittstellen) zwischen spezifizierten 

Prozessen identifiziert und dokumentiert werden. Außerdem ist auf eine einheitliche 

Terminologie bei der Prozessdokumentation zu achten (vgl. auch Handlungsempfehlung 

zum Ausbau des Glossars der RA im Abschnitt 4.5). 

H-9 Handlungsempfehlung: Prozesse in einheitlicher Struktur beschreiben 

Die Beschreibungen der COBIT-Prozesse folgen einer klaren und einheitlichen Struktur, die 

den Umgang mit den Prozessen erleichtert und vermutlich einer der zentralen Erfolgsfaktoren 

des Ansatzes in der Praxis ist. Eine vergleichbar einheitliche Struktur zur Beschreibung 

von Prozessen der RA liegt derzeit noch nicht vor. Sie könnte jedoch nach unserer Einschätzung 

das Verständnis der Prozesse der RA deutlich erhöhen und ihre Anwendung vereinfachen. 

Dafür sollte als Grundlage ein nachvollziehbares und differenziertes Methoden- und 

Prozessverständnis zugrunde gelegt werden. Derzeit wird nicht hinreichend zwischen Methode, 

sprachlicher Struktur und Vorgehensmodell sowie Prozessen differenziert. Die Beschreibungsstruktur 

aus COBIT kann als Vorbild für die RA dienen. 

H-10 Handlungsempfehlung: Prozessbeschreibungen um weitere Aspekte ergänzen 

Die Prozesse der RA können in mehrerer Hinsicht um Aspekte aus COBIT ergänzt werden. 

So könnte die in COBIT vorgeschlagenen Reifegradmodelle („Maturity Models“) als Grundlage 

für den Entwurf entsprechender Reifegrade für die Prozesse der RA dienen. Dies vermag 

bspw. die Identifikation von Verbesserungspotenzialen zu unterstützen (z. B. [COBIT], 

S. 21). 

Darüber hinaus betont COBIT die Definition von Kennzahlen und die Berücksichtigung von 

Risiken. Die Prozesse der RA könnten entsprechend weiterentwickelt werden, bspw. durch 

die Definition von Kennzahlen zur Messung der Zielerreichung des Prozesses im Hinblick auf 

die für den Prozess formulierten Ziele; oder durch die durchgängige Identifikation und Berücksichtigung 

von Risiken, die sich etwa aus den Diensten bzw. ihren Realisierungen für die 

zu unterstützenden Geschäftsprozesse ergeben können. 24 

ITIL bietet weitergehende Empfehlungen bei der Gestaltung der Prozesse. Insbesondere 

führt ITIL Auslöser („Trigger“), Key Performance Indikatoren (Kennzahlen) und kritische 

Erfolgsfaktoren für den überwiegenden Teil der ITIL-Prozesse an. Die jeweiligen Auflistungen 

stellen jedoch nur rudimentäre Vorschläge dar – sie sind weder begründet noch reflektiert. 

Eine unkritische Übernahme empfiehlt sich deshalb nicht; stattdessen scheint es 

ratsam, mit den Beteiligten der RA eigene Kennzahlen u. a. im Diskurs zu entwickeln und 

dabei ihre Zielsetzung („Was soll durch Nutzung der Kennzahl erreicht werden?“) offenzulegen. 

24 Vgl. dazu auch Handlungsempfehlung H-3 im Abschnitt 3.4 (S. 24). 



H-11 Handlungsempfehlung: Grafische Visualisierungen auf Typebene ausbauen 

Grundsätzlich weist die RA im Kern große Ähnlichkeit mit den ITIL-Prozessen Service Asset 

und Configuration Management aus der Phase Service Transition auf. Bei diesem Prozess 

geht es in ITIL um die Verwaltung sämtlicher IT-bezogener Elemente (Services, Verträge, 

Hardware, Software etc.). Hierfür wird eine sog. „Configuration Management Database“ 

(CMDB) vorgeschlagen, deren Fokus auf der Verwaltung von Instanzen der Elemente (z. B. 

konkrete Verträge mit einer konkreten Laufzeit) liegt. 

Die RA bietet demgegenüber wesentliche Abstraktionsvorteile durch die Abstraktion auf 

Typen (z. B. Typen von Verträgen, Typen von Prozessen). Sie ist zudem bereits jetzt mit 

einer anschaulichen grafischen Visualisierung von Sachverhalten auf Typebene versehen 

(Prozessmodelle, Zielmodelle), die einen Beitrag zu den gesetzten Zielen leisten (Komplexitätsreduktion, 

Förderung von Kommunikation und Transparenz etc.). Die Verwendung derartiger 

Abstraktionen bietet insb. für die Integration von ITIL weitergehende Potenziale: So 

könnte bspw. in den ITIL-Prozessen auf die Modelle der RA zugegriffen werden. An vielen 

Stellen bleibt in ITIL offen, in welcher (visuellen) Repräsentation die Informationen über 

Dienste, IT-Lösungen, Prozesse etc. für die unterschiedlichen Akteure aufbereitet werden 

sollen (textuell oder grafisch). Grafische Visualisierungen, wie sie in der RA vorgesehen sind, 

können einen erheblichen Beitrag für eine verbesserte Kommunikation zwischen und innerhalb 

der beteiligten Bereiche (DLZ-IT des Bundes, Architekturmanagement und Ressorts) 

liefern. 

H-12 Handlungsempfehlung: Einbezug von Beteiligten und Betroffenen betonen 

Eine grundlegende Idee in ITIL ist, dass alle (potenziell) an einem Dienst involvierten Akteure 

– auf Geschäftsseite wie auf IT-Seite – stets beteiligt werden, um eigene Ideen oder begründete 

Einwände vorzubringen. Für die RA legt dies eine intensivere Zusammenarbeit zwischen 

Architekturmanagement, DLZ-IT des Bundes und den „Kunden“ in den 

entsprechenden Ressorts nahe, die in Bezug auf Prozesse und Rollenmodelle differenzierter 

zu beschreiben ist – und zwar nicht nur auf Ebene der IT-Strategie (bspw. durch den IT-Rat), 

sondern auch auf der operativen Ebene des IT-Betriebs (z. B. Administratoren). 

H-13 Handlungsempfehlung: Untersuchte Prozesse präzisieren 

Die Betrachtung der Prozesse der RA und deren Gegenüberstellung mit Prozessen aus ITIL 

und COBIT ergibt jeweils eine Reihe von Anknüpfungspunkten. Dabei sind sowohl Änderungen 

an vorhandenen Aktivitäten als auch Aufnahme weiterer Aktivitäten zu evaluieren. So ist 

es zum einen möglich, ausgewählte Anknüpfungspunkte in einer Überarbeitung des Prozesses 

zu konkretisieren, so dass grundlegende Ideen aus ITIL und COBIT übernommen werden 

und auf diesem Weg das Architekturmanagement weiterentwickelt wird. Zum anderen 

werden in einigen ITIL- und COBIT-Prozessen Aktivitäten angeführt, die sich in vergleichbarer 

Form noch nicht in Prozessen der RA finden, deren zu Grunde liegende Ideen jedoch 

einen Beitrag für den Erfolg der RA und des Prozesses liefern können. Es empfiehlt sich 

daher, diese Aktivitäten in den Prozess an geeigneter Stelle zu integrieren. Sofern es in den 

DLZ-IT des Bundes bereits entsprechende Prozesse geben sollte, so sind diese zu berücksichtigen, 

bspw. durch die Definition von entsprechenden Schnittstellen. Im Folgenden werden 

für die beiden untersuchten Prozesse der RA konkrete Weiterentwicklungspotenziale 

aufgezeigt. 



5.5.2 Prozess: Ableitung von Diensten aus Geschäftsprozessen („Diensteableitung“) 

H-14 Handlungsempfehlung: Gremium für Entscheidung des ressortinternen bzw. 

ressortübergreifenden Diensteangebots 

Die Entscheidung, ob die Erbringung von Diensten ressortintern oder ressortübergreifend 

erfolgen soll, wird nicht deutlich einer Rolle oder einem Gremium zugewiesen ([Methode], 

S. 11). Dies sollte vermutlich ein übergeordnetes Gremium entscheiden; es fehlen dazu 

jedoch Bewertungskriterien als Grundlage für diese Entscheidung. Dies verdeutlicht wiederum, 

dass die Abstimmung mit dem Prozess der Nachfragebündelung noch fehlt. Darüber 

hinaus wird durch die ressortinterne Erbringung von Diensten die grundlegende Trennung 

zwischen Angebot und Nachfrage von Diensten zumindest potenziell aufgeweicht. Dies 

deutet an, dass es über Prozesse hinaus eines grundlegenden Regelwerks („Governance- 

Strukturen“) bedarf, in dem bspw. festgelegt wird, wie im Fall von Interessenskonflikten zu 

verfahren ist. 

H-15 Handlungsempfehlung: Identifikation „vergleichbarer Funktionalitäten“ systematisieren 

Darüber hinaus fehlen für die Identifikation „vergleichbarer Funktionalitäten“ 25 derzeit noch 

praktisch anwendbare Kriterien und Hilfestellungen. In der vorliegenden Form ist dies maßgeblich 

von der Kompetenz des Geschäfts- und Lösungsarchitekten abhängig. Eine Konkretisierung, 

etwa durch weitere Leitfäden, scheint empfehlenswert. 

Darüber hinaus stellt sich die Frage, wie notwendige, d.h. nicht ausräumbare, Unterschiede 

von Diensten abgebildet werden und wie die ggf. entstehende Vielfalt an Diensten gehandhabt 

werden soll. Ein Ansatzpunkt wäre die Verwendung von Varianten ([Methode], S. 15). 

H-16 Handlungsempfehlung: Weiterentwicklung des Prozesses „Ableitung von Diensten 

aus Geschäftsprozessen“ 

Der Prozess zur Ableitung von Diensten aus Geschäftsprozessen weist einige Anknüpfungspunkte 

zu ITIL und COBIT auf. Für die Betrachtung der Anknüpfungspunkte ist in Abbildung 

18 der Prozess zur Ableitung von Diensten aus Geschäftsprozessen mit seinen Aktivitäten 

den in Abschnitt 5.4.1 identifizierten ITIL- und COBIT-Prozessen grafisch gegenübergestellt. 

Die identifizierten Prozesse weisen Anknüpfungspunkte mit dem Prozess der RA auf, die im 

Folgenden erläutert werden. Dabei werden zunächst Prozesse betrachtet, die Anknüpfungspunkte 

mit dem gesamten Prozess der Diensteableitung aufweisen. Anschließend werden 

einzelne Aktivitäten der Diensteableitung betrachtet. Zur einfacheren Orientierung wird die 

betrachtete Gruppe an Prozessen mit ähnlichen Anknüpfungspunkten jeweils mit einer roten 

Ziffer kenntlich gemacht (siehe Abbildung 18). In den Erläuterungen zu den identifizierten 

Prozessen wird in Klammern jeweils die Prozessnummer aufgeführt, die auf die Prozessbeschreibung 

in Tabelle 4 verweist. 

25 BMI: vgl. hierzu Abschnitt 3.5.3 (S. 16) in [Methode]. 



RA 



Abbildung 18: Prozesse aus COBIT und ITIL mit Anknüpfungspunkten an den Prozess der RA zur Diensteableitung 

• Gruppe 1 – Gesamter Prozess: In ITIL und COBIT werden verschiedene Prozesse 

vorgeschlagen, die für die Weiterentwicklung des Prozess der Diensteableitung insgesamt 

berücksichtigt werden könnten. 

o Financial Management (1.4): In ITIL wird ein Finanzmanagement vorgeschlagen. 

Services sind demzufolge bei der Planung und Entwicklung wie 

auch zu ihrer Laufzeit stets auf ihre Wirtschaftlichkeit zu prüfen. Dies empfiehlt 

sich auch für die RA bzw. den Prozess der Diensteableitung – insb. vor dem 

Hintergrund der genannten Ziele der Wirtschaftlichkeit und Effizienz mag dies 

eine gewinnbringende Erweiterung darstellen. 

Die konkreteren Hinweise in ITIL, etwa die Nutzung des Return on Investments 

zur Beurteilung der Wirtschaftlichkeit, sollten dagegen kritisch hinterfragt 

werden. Insgesamt erscheinen die Empfehlungen von ITIL zum Financial 

Management allerdings mit Blick auf den gegenwärtigen Stand der Forschung 

bestenfalls rudimentär und nicht reflektiert. Hier sollte auf deutlich weiterentwickelte 

Ansätze etwa aus dem Forschungsgebiet IT-Controlling zurückgegriffen 

werden. 

o Manage the IT-Investment (1.11): Ähnlich dem Financial Management aus 

ITIL schlägt COBIT das durchgängige Management von IT-Investitionen vor. 

Demzufolge sollten u. a. sowohl Kosten- und Nutzenaspekte berücksichtigt als 

auch Abweichungen von erwarteten Kosten und vom erwarteten Nutzen identifiziert 

und evaluiert werden. Über diese allgemeinen und sicherlich grundlegend 

hilfreichen Hinweise hinaus, besteht allerdings auch Ergänzungsbedarf 

durch aktuelle Forschungsergebnisse. Das durch die ITGI entwickelte Rahmenwerk 

ValIT scheint nach gegenwärtigem Stand diese Ergebnisse bedauerlicherweise 

erneut nicht aufzugreifen, sondern das Rad neu zu erfinden. 

o Identify Automated Solutions (1.8): Dieser COBIT-Prozess sieht u. a. die 

durchgängige Identifikation und Berücksichtigung von Risiken für die Geschäftsprozesse 

und von Anforderungen an Sicherheit und Controls vor. Dies 



wird in dem betrachten Prozess der RA derzeit nicht explizit adressiert. Eine 

entsprechende Anpassung des Prozesses der RA ist daher zu untersuchen. 

• Gruppe 2 – Aktivitäten 1 und 2: Die Ableitung von Bedarfen nach IT-Unterstützung 

in Form von Funktionalitäten bietet Anknüpfungsmöglichkeiten an verschiedene ITIL- 

und COBIT-Prozesse, die bspw. in den Aktivitäten 1 und 2 mit berücksichtigt werden 

könnten. 

o Service Level Management (1.6): Sofern vertragliche Vereinbarungen von 

Relevanz sind, so sollten diese frühzeitig bei der Dienste-Ableitung berücksichtigt 

werden. Dies kann bspw. durch die frühzeitige Erfassung von sog. 

„Service Level Requirements“ (SLR) erfolgen (Service Design, S. 76f.). Diese 

SLR dienen in ITIL zum Festhalten von Anforderungen (bspw. hinsichtlich der 

Qualität, Verfügbarkeit und Support des Dienstes) an neue Dienste und werden 

in späteren Phasen in „Service Level Agreements“ (SLA) überführt. Dazu 

sind ggf. die Schnittstellen zu den DLZ-IT des Bundes als Erbringer der Dienste 

zu definieren. 

o Define and Manage Service Levels (1.7): Der COBIT-Prozess sieht ähnlich 

dem obigen ITIL-Prozess des Service Level Managements die frühzeitige Erfassung 

von Anforderungen der Nachfrager an die Erbringung der Dienste in 

Form von Service Level Agreements vor. 

o Capacity Management (1.2): Bei der Ableitung von Diensten aus Geschäftsprozessen 

sollten auch die konkreten Bedarfe i.S. der erwarteten Kapazität 

mit erhoben werden, z. B. Durchführungshäufigkeit des Geschäftsprozesses 

bzw. Nutzungshäufigkeit des Dienstes, evtl. Nutzungsverläufe im Zeitverlauf 

(„Peak times“?), Nutzungsintensität des Dienstes usw. Dies erfordert ggf. die 

Abstimmung mit den DLZ-IT des Bundes und dem dortigen Capacity Management, 

etwa im Hinblick auf die technische Realisierbarkeit oder technischen 

Restriktionen. 

o Manage Performance and Capacity (1.10): Dieser COBIT-Prozess betont 

insb. die Prognose von zukünftigen Bedürfnissen im Hinblick auf die Kapazität 

(auch hinsichtlich zu erwartender und möglicherweise stochastisch auftretender 

Schwankungen in der Nachfrage nach IT-Dienstleistungen). Für die Planung 

der Performanz und der Kapazität in den DLZ-IT des Bundes ist die 

frühzeitige Berücksichtigung von sich abzeichnenden Änderungen und Erweiterungen 

von Diensten notwendig. Die dafür notwendigen Informationen sollten 

bei der Ableitung von Diensten aus Geschäftsprozessen möglichst 

frühzeitig erhoben und kommuniziert werden. 

o Availability Management (1.1): Ähnlich dem Kapazitätsmanagement kann 

die frühzeitige Erfassung von Angaben zur Kritikalität des zu unterstützenden 

Geschäftsprozesses und des Bedarfs an (technischer) Verfügbarkeit bei der 

Diensteableitung erfolgen und als Input für den ITIL-Prozess des Availability 

Managements dienen. Entsprechend der obigen Aussagen, sollten Angaben 

zur Kritikalität eines Dienstes, der Dienstebeschreibung hinzugefügt werden. 

o Information Security Management (1.5): Analog zur Erhebung von Kapazitätsanforderungen 

und der Kritikalität der Dienste können spezifische Sicherheitsbedürfnisse 

(„Security Policies“) bei der Diensteableitung erfasst werden. 

Zum Beispiel wenn die Daten des Prozesses besonderen rechtlichen Auflagen 

unterliegen. Entsprechend der obigen Aussagen, sollten auch Angaben 

zur Sicherheit eines Dienstes, der Dienstebeschreibung hinzugefügt werden. 



• Gruppe 3 – Aktivitäten 5 und 6, Prozess 3: Aus den identifizierten Änderungsbedarfen 

an existierenden Diensten und den Entwürfen für neue Dienste ergeben sich 

u.U. weitreichende Auswirkungen auf und Änderungen am Dienstemodell und 

Dienstekatalog. Für den Umgang mit diesen Änderungen kann ggf. auf Prozesse aus 

ITIL und COBIT zurückgegriffen werden. Dabei ist noch zu bestimmen, welches 

Gremium für die Entscheidung über die Annahme von Änderungen und Ergänzungen 

am Dienstemodell und Dienstekatalog verantwortlich ist [Methode, S. 18]. 

• Change Management (1.3): Dieser ITIL-Prozess zielt auf den angemessenen 

Umgang mit Änderungen („Changes“) an Diensten ab. Dazu sollen Changes in 

einer strukturierten Weise erfasst, bewertet, priorisiert, geplant, getestet, implementiert 

und dokumentiert werden. Darüber hinaus sollen Änderungswünsche der 

Kunden soweit möglich antizipiert werden. Der strukturierte Umgang ist in der RA 

an verschiedenen Stellen notwendig, bspw. bei Änderungen an Diensten, an Modellen 

oder an Prozessen und Methoden. Die Etablierung entsprechender Vorgehensweisen 

in der RA ist daher dringend angeraten. Hierzu sollte der Leitfaden 

zur Ableitung von Diensten aus Geschäftsprozessen nicht nur erklären, wie 

Dienste abgeleitet werden, sondern auch wie diese anzupassen sind. 

• Manage Changes (1.9): Dieser COBIT-Prozess schlägt in ähnlicher Weise wie 

der ITIL-Prozess des Change Managements den strukturierten und geregelten 

Umgang mit Änderungen vor. 

Die Kennzeichnung der Anknüpfungspunkte (rote Kanten in Abbildung 18) macht auch 

kenntlich, an welcher Stelle im Prozess der RA die Anknüpfungspunkte zu den Prozessen 

aus ITIL und COBIT vorgenommen werden kann. Die Prozesse der ersten Gruppe sind 

keinem spezifischen Prozessschritt bei der Diensteableitung zuzuordnen; sie können an 

verschiedenen Stellen eingeordnet werden. Für die Prozesse der zweiten Gruppe bietet es 

sich an, sie in einen der ersten beiden Schritte des RA-Prozesses einzugliedern: Im Zuge 

der Erhebung der Funktionalitäten des Dienstes ließen sich auch die in ITIL und COBIT 

angeführten Aspekte (z. B. Anforderungen an Verfügbarkeiten, Kapazitäten, etc.) ermitteln. 

Die Prozesse der dritten Gruppe weisen Anknüpfungspunkte mit den letzten beiden Prozessschritten 

des RA-Prozesses auf. 

Die konkrete Ausgestaltung der Anknüpfungspunkte hängt letztlich davon ab, in welchem 

Umfang und in welcher Weise die Prozesse aus ITIL und COBIT in den DLZ-IT des Bundes 

gestaltet sind. Werden die entsprechenden Prozesse dort bereits umgesetzt, kann im Zuge 

der Dienstableitung an den o.g. Stellen auf diese Prozesse zurückgegriffen werden (z. B. 

Auslösen des Service Level Management-Prozesses eines DLZ-IT des Bundes, wenn die 

Funktionalitäten erhoben werden). Anderenfalls kann das Architekturmanagement zumindest 

rudimentär die Informationen erheben, um eventuell zu einem späteren Zeitpunkt die Informationen 

wie Kapazitätsanforderungen an das DLZ-IT des Bundes zu übergeben. 

5.5.3 Prozess: Zusammenwirken von IT-Angebot und IT-Nachfrage („Nachfragebündelung“) 

Der Prozess zum Zusammenwirken von IT-Angebot und IT-Nachfrage weist ebenfalls einige 

Anknüpfungspunkte zu ITIL und COBIT auf. Für die Betrachtung der Anknüpfungspunkte ist 

in Abbildung 19 der Prozess zur Nachfragebündelung mit seinen Aktivitäten den in Abschnitt 

5.4.2 identifizierten ITIL- und COBIT-Prozessen grafisch gegenübergestellt. 



RA 



Abbildung 19: Prozesse aus COBIT und ITIL mit Anknüpfungspunkten an den Prozess der RA zur Nachfragebündelung 

Die identifizierten Prozesse weisen Anknüpfungspunkte mit dem Prozess der RA auf, die im 

Folgenden erläutert werden. Dabei werden zunächst Prozesse betrachtet, die Anknüpfungspunkte 

mit dem gesamten Prozess der Nachfragebündelung aufweisen. Anschließend werden 

einzelne Aktivitäten der Nachfragebündelung betrachtet. Zur einfacheren Orientierung 

wird die betrachtete Gruppe an Prozessen mit ähnlichen Anknüpfungspunkten jeweils mit 

einer roten Ziffer kenntlich gemacht. In den Erläuterungen zu den identifizierten Prozessen 

wird in Klammern jeweils die Prozessnummer aufgeführt, die auf die Prozessbeschreibung in 

Tabelle 5 verweist. 

• Gruppe 1 – Gesamter Prozess: In ITIL und COBIT werden Prozesse vorgeschlagen, 

die zu dem Prozess der Nachfragebündelung insgesamt Anknüpfungspunkte 

aufweisen. 

o Service Portfolio Management (4.3), Service Catalogue Management 

(4.2), Demand Management (4.1): Diese ITIL-Prozesse weisen große 

Ähnlichkeit zum Prozess der Nachfragebündelung auf. Die Ausführungen in 

ITIL zu den Prozessen verbleiben allerdings vage und sind sehr kurz gehalten. 

Es werden allerdings einige wenige Instrumente vorgeschlagen, die die 

Prozesse unterstützen sollen. Mehr als Anregungen, bspw. zur Pflege eines 

zentralen Katalogs aller Dienste bzw. Produkte sowie die Planung und Steuerung 

des langfristigen Bedarfs, können diese Vorschläge jedoch nicht liefern. 

Hier besteht insofern erneut Bedarf eine eigene Lösung zu entwickeln. 

o Identify Automated Solutions (1.8): Dieser COBIT-Prozess sieht u. a. die 

durchgängige Identifikation und Berücksichtigung von Risiken für die Geschäftsprozesse 

und von Anforderungen an Sicherheit und Controls vor. Dies 

wird in dem betrachten Prozess der RA derzeit nicht explizit adressiert. Eine 

entsprechende Anpassung des Prozesses der RA ist daher aus Sicht der 

Gutachter zu untersuchen. 



• Gruppe 2 – Aktivitäten 2: Die Planung der Umsetzungsvorhaben bietet Anknüpfungspunkte 

mit folgenden Prozessen aus ITIL und COBIT. 

o Capacity Management (1.2): Bei der Machbarkeitsprüfung der Elemente des 

IT-Bedarfskatalogs wird ein Abgleich mit den Kapazitäten der DLZ-IT des 

Bundes vorgenommen. Hier bestehen Anknüpfungspunkte zum ITIL-Prozess 

Capacity Managements. Es sollte daher klare Schnittstellen geben, die beschreiben, 

wie die entsprechenden Prozesse der DLZ-IT des Bundes in den 

Prozess der Nachfragebündelung integriert werden. Diese fehlen derzeit. 

o Manage Performance and Capacity (1.10): Dieser COBIT-Prozess betont 

insb. die Prognose von zukünftigen Bedürfnissen im Hinblick auf die Kapazität. 

Für die Planung der Performanz und der Kapazität in den DLZ-IT des 

Bundes ist die frühzeitige Berücksichtigung von sich abzeichnenden Änderungen 

und Erweiterungen notwendig. Die dafür notwendigen Informationen sollten 

möglichst frühzeitig erhoben und kommuniziert werden, bspw. in Form von 

Vorhersagen. 

• Gruppe 3 – Aktivitäten 2 und 3: Für die Identifizierung des Finanzierungsbedarfs, 

der Beurteilung der Wirtschaftlichkeit und der Finanzierung bedarf es methodischer 

Unterstützung. Prozesse aus ITIL und COBIT können dazu als Grundlage dienen. 

o Financial Management (1.4): s. o. 

o Manage the IT-Investment (1.11): s. o. 

• Gruppe 4 – Aktivitäten 3 und 4: Aus den identifizierten Änderungsbedarfen an existierenden 

Diensten und den Entwürfen für neue Dienste ergeben sich u.U. weitreichende 

Auswirkungen auf und Änderungen an existierenden Lösungen und bspw. 

dem Produktkatalog. Für den Umgang mit diesen Änderungen kann ggf. auf Prozesse 

aus ITIL und COBIT zurückgegriffen werden. 

o Change Management (1.3): s. o. 

o Manage Changes (1.9): s. o. 

• Gruppe 5 – Prozess 6: Die aus dem Prozess der Nachfragebündelung resultierende 

„gebündelte“ IT-Nachfrage hat u.U. Auswirkungen auf die Fortentwicklung der IT- 

Strategie. 

o Define a Strategic IT-Plan (4.4): Die Berücksichtigung der gebündelten IT- 

Nachfrage bedingt einen entsprechenden Prozess zu (Weiter-) Entwicklung 

der IT-Strategie. Der COBIT-Prozess Define a Strategic IT-Plan kann für einen 

derartigen Prozess Anhaltspunkte liefern. So sollen bspw. strategische 

und taktische IT-Pläne unterschieden und Abhängigkeiten zwischen Unternehmens- 

und IT-Strategie identifiziert werden. Derzeit findet sich in der RA 

kein Bezug zur strategischen Planung. Diese Handlungsoption wird im letzten 

Abschnitt dieses Berichts aufgezeigt und erläutert. 

Die Kennzeichnung der Anknüpfungspunkte (rote Kanten in Abbildung 18) macht auch hier 

kenntlich, an welcher Stelle im Prozess der RA die Anknüpfungspunkte zu den Prozessen 

aus ITIL und COBIT vorgenommen werden kann. Die Prozesse der Gruppen zwei, drei und 

vier sind konkreten Prozessschritten des Nachfragebündelungs-Prozesses der RA zugeordnet. 

Es bietet sich auch hier an, in Zusammenarbeit mit z. B. den DLZ-IT des Bundes zu 

prüfen, inwiefern die Anknüpfungspunkte realisiert werden können (s.o.). 

Die Prozesse der ersten Gruppe sind keinem spezifischen Prozessschritt bei der Nachfragebündelung 

zuzuordnen; stattdessen weisen diese Prozesse allgemein Ähnlichkeit zur Nachfragebündelung 

auf. Hier empfiehlt es sich, den Prozess der Nachfragebündelung mit den 

Prozessen aus ITIL und COBIT zu koordinieren, um redundante Arbeiten zu vermeiden bzw. 



Synergiepotenziale zu nutzen. Da die entsprechenden Prozessbeschreibungen in ITIL und 

COBIT jedoch sehr vage gehalten sind (s.o.), lassen sich ohne nähere Kenntnis der Ausgestaltungen 

in den DLZ-IT des Bundes keine nähere Aussagen hierzu treffen. 



6 Untersuchungsbereich organisatorischer Aufbauelemente 

Anhand der im vorherigen Abschnitt durchgeführten Betrachtung der Prozesse werden in 

diesem Abschnitt Rückschlüsse auf Gemeinsamkeiten und Unterschiede im Hinblick auf die 

organisatorischen Aufbaustrukturen (insb. Rollen, Funktionen und Gremien) der Ansätze 

gezogen. Dieser Vergleich soll mögliche Weiterentwicklungen der RA bezüglich ihrer organisatorischen 

Einbettung aufdecken. Analog zu Abschnitt 5 werden zunächst die aufbauorganisatorischen 

Strukturen von ITIL, COBIT und der RA isoliert betrachtet und kurz 

vorgestellt. 26 Anschließend werden die Strukturen der RA mit denen von ITIL und COBIT 

gegenübergestellt und analysiert. 

6.1 Organisatorische Aufbauelemente der RA 

Aus den zur Verfügung stehenden Dokumenten insbesondere zu den betrachteten Prozessen 

lassen sich insgesamt 12 organisatorische Aufbauelemente identifizieren. Diese sind in 

Tabelle 6 zusammen mit einer kurzen Beschreibung und der Angabe des Typs (Rolle, Gremium) 

aufgeführt. Bei der Beschreibung der organisatorischen Aufbauelemente ist zu beachten, 

dass diese auf einer Dokumentenanalyse beruht. Ob die Rollen bzw. Gremien nach 

diesen Beschreibungen arbeiten, wird in dieser Studie nicht betrachtet. 

Aufbauelement Kurzbeschreibung Typ 

Geschäftsarchitekt 

(Ressort) 

IT-Beauftragte der Bundesregierung 

(BfIT, Bundes- 

CIO) 

Der Geschäftsarchitekt gestaltet die Strukturierung und Darstellung 

der Aufgaben. Er verwendet dazu ein geeignetes, ressortspezifisches 

Architekturmodell, das „kompatibel“ zur Rahmenarchitektur sein sollte. 

Er gibt Impulse für Verbesserungen der Struktur und Organisation 

einerseits und des Bedarfs an IT-Unterstützung andererseits. Er kennt 

die Geschäftsprozesse und Nachfragen nach IT-Unterstützung für 

seinen Aufgabenbereich insbesondere aus Sicht der Fachabteilungen. 

([Methode], S. 9) 

Die für Verwaltungsmodernisierung und IT zuständige Staatssekretärin 

des Bundesministeriums des Innern übernimmt die Rolle der BfIT. 

Sie sitzt dem Rat der IT-Beauftragten sowie der IT-Steuerungsgruppe 

vor. Die BfIT hat u. a. folgende Aufgaben im Kontext des Bundes 

([Konzept], S. 7f.): 

• Ausarbeitung der E-Government-/ IT- und IT-Sicherheitsstrategie 

• Entwicklung von Architektur, Standards und Methoden für die IT 

• Unterstützung des IT-Rats bei der Abstimmung der Angebote der 

IT-Dienstleister 

• Steuerung des IT-Sicherheitsmanagements auf der Grundlage 

der Festlegungen der Bundesregierung 

• Steuerung der Bereitstellung zentraler IT-Infrastrukturen 

• Ausarbeitung von vertraglichen Rahmenwerken und Leitfäden für 

die Beschaffung von IT 

Ferner vertritt die BfIT die Interessen des Bundes im IT-Planungsrat 

IT-Planungsrat Der IT-Planungsrat dient der Bund-Länder-übergreifenden IT- 

Steuerung, d.h. der Koordinierung der Zusammenarbeit von Bund und 

Ländern in Fragen der Informationstechnik. Der Bund wird im IT- 

Planungsrat durch die BfIT vertreten. Die Rahmenarchitektur IT- 

Steuerung Bund fokussiert auf die Bundesverwaltung, weswegen der 

IT-Planungsrat außerhalb der Betrachtung dieser Studie steht, hier 

jedoch der Vollständigkeit halber aufgeführt wird. 


Rolle 

Rolle 

Gremium 

26 Für eine bessere Lesbarkeit wird bei Bezeichnungen organisatorischer Aufbauelemente durchgängig – mit 

Ausnahme der BfIT – die männliche Form verwandt. Die weibliche Form ist selbstverständlich immer mit eingeschlossen.



IT-Steuerungsgruppe 

Kundenmanager 

Lösungsarchitekt 

Nachfragerbeirat (NFB) 

Aufgabe der IT-Steuerungsgruppe des Bundes ist die Verzahnung von 

politischer und haushaltsmäßiger IT-Steuerung. Mitglieder der Steuerungsgruppe 

sind ([Konzept], S. 6f.): 

• die IT-Beauftragte der Bundesregierung (BfIT), 

• der Haushaltsstaatssekretär im Bundesministeriums der Finanzen, 

• der für Informations- und Kommunikationstechnik verantwortliche 

Staatssekretär im Bundesministerium für Wirtschaft und Technologie 

und 

• ein Vertreter des Bundeskanzleramtes. 

Zu den Aufgaben und Rechten der IT-Steuerungsgruppe gehören u. a. 

• Initiativrecht für Aufträge an den Rat der IT-Beauftragten (z. B. 

hinsichtlich Standardfragen, Innovationsvorhaben) 

• Einspruchsrecht bei IT-Rahmenkonzepten und anderen Maßnahmen 

der Ressorts, die den Beschlüssen der IT Steuerungsgruppe 

des Bundes oder des Rates der IT-Beauftragten 

widersprechen 

• Sofern keine Einigung im Rat der IT Beauftragten möglich ist, gibt 

die IT-Steuerungsgruppe nach Konsultation der betroffenen Ressorts 

eine Empfehlung für einen Beschluss des Rates der IT- 

Beauftragten der Ressorts ab 

• Bestätigung des IT-Rahmenkonzepts des Bundes 

• Koordinierung von IT-Großprojekten der öffentlichen Verwaltung 

Die Kundenmanager stellen Ansprechpartner seitens der DLZ-IT des 

Bundes für die Kunden und den Nachfragebeirat da. Sie koordinieren 

in diesem Rahmen ([Nachfragebündelung], S. 16): 

• die Durchführung von Machbarkeitsprüfungen in den DLZ-IT des 

Bundes, 

• die Erstellung von (vorläufigen) Angeboten für Produktentwicklungen 

und Produktänderungen sowie 

• die Erstellung von Produktsteckbriefen im Zuge der Anpassung 

des Produktkatalogs 

Der Lösungsarchitekt entwirft IT-Lösungen. Der Lösungsarchitekt 

sollte Mitarbeiter eines DLZ-IT des Bundes sein, aber auch über einen 

Überblick über die IT-Lösungen der anderen DLZ-IT des Bundes 

verfügen. Er definiert für die IT-Unterstützung von Geschäftsprozessen 

IT-Lösungen sowohl aus geschäftlicher / fachlicher als auch aus 

technischer Sicht. ([Methode], S. 9). Hierzu gehören 

• der Entwurf der gesamten Lösungs- und Komponentenarchitektur, 

• die Abstimmung mit den Bedarfsträgern auf der Grundlage des 

Dienstemodells und 

• die Entwicklung von Strategien zur Implementierung und Integration 

der jeweiligen IT-Lösung. 

Der Nachfragerbeirat setzt sich aus den Nachfragekoordinatoren der 

Ressorts zusammen. Er ist für die 

• Konsolidierung/Bündelung, Priorisierung und Darstellung des 

ressortübergreifenden 

Bedarfskatalog), 

IT-Bedarfs / der IT-Nachfrage (IT- 

• die Erstellung der Umsetzungsvorgaben (im Wesentlichen Fachanforderungen) 

sowie 

• deren Umsetzungsplanung 

verantwortlich. 

Zudem koordiniert der NFB sowohl mit den Ressortvertretern als auch 

den Vertretern der DLZ-IT des Bundes 

• die Klärung der Machbarkeit, des Ressourcenbedarfs und der 

Umsetzungsplanung von ressortübergreifenden IT-Maßnahmen 


• die Abstimmung von ressortübergreifenden Produktentwicklungen, 

Produktänderungen und Produktabkündigungen. ([Nachfragebündelung], 

S.15) 

Gremium 


Rolle 

Rolle 

Gremium



Nachfragekoordinator 

Ressort 

Rat der IT-Beauftragten 

(IT-Rat) 

IT-Beauftragter für Ressort 

(Ressort-CIO) 

Team Architekturmanagement 

Die Nachfragekoordinatoren sind für die Koordinierung und Bündelung 

der ressortinternen IT-Nachfrage zuständig. Zudem vertreten sie die 

Interessen des jeweiligen Ressorts im Nachfragebeirat. ([Nachfragebündelung], 

S. 16) 

Der Rat der IT-Beauftragten beschließt die wesentlichen Vorgaben zur 

ressortübergreifenden Steuerung der IT des Bundes. Er setzt sich aus 

den IT-Beauftragten der Ressorts zusammen. Vorsitzende des IT- 

Rates ist die Beauftragte der Bundesregierung für Informationstechnik. 

Zu den Aufgaben des IT-Rats gehört u. a. ([Konzept], S. 5f.): 

• Beschluss einer abgestimmten E-Government- / IT –Strategie und 

einer IT-Sicherheitsstrategie 

• Ausrichtung der IT-Strategie auf die Strategie der Bundesregierung 

zur Verwaltungsmodernisierung und die vom Ausschuss für 

Organisationsfragen (AfO) beschlossenen Modernisierungsprojekte 

• (Bündelung der ressortübergreifenden IT-Nachfrage unter Berücksichtigung 

der Anforderungen der Organisation) 27 

• Entwicklung von Lösungsmodellen für die Gewinnung und den 

Einsatz von IT-Fachpersonal 

• Festlegung der Architektur, Standards und Methoden für die IT 

der Bundesverwaltung 

• Beschluss des IT-Rahmenkonzepts des Bundes und eines Vorschlages 

für die Etatisierung ressortübergreifender Projekte als 

Grundlage für die Haushaltsverhandlungen. 

• Übergreifendes Portfoliomanagement der DLZ IT des Bundes 

• Neufassung und Weiterentwicklung der IT-Richtlinien 

• (Weiter-) Entwicklung einheitlicher Projektmanagement- 

Standards, -Methoden und -Werkzeuge, Bereitstellung eines zentralen 

Dienstleistungsangebotes hinsichtlich Projektmanagement- 

Unterstützung, Sicherstellung von Qualifizierungsmaßnahmen 

(Fortbildung), Externen Projektcontrolling 

Jedes Ressort bestellt einen zentralen IT-Beauftragten für das gesamte 

Ressort. Er gewährleistet die Übereinstimmung des IT-Einsatzes 

mit den politischen, strategischen und operativen Zielen des Ressorts 

und den IT-Festlegungen der Bundesregierung und vertritt die IT 

seines Ressorts nach außen. Dabei ist er der jeweiligen Leitung des 

Ressorts in dieser Funktion grundsätzlich unmittelbar unterstellt. Zu 

den Aufgaben des IT-Beauftragen gehört u. a. ([Konzept], S. 4f.): 

• Kontrolle der Umsetzung der Standards, strategischen Zielvorgaben 

und der Festlegungen des IT-Rats und der IT- 

• 

Steuerungsgruppe des Bundes. 

Gewährleistung der IT-Sicherheit des Ressorts 

• Erfolgskontrolle bei wesentlichen IT-relevanten Vorhaben des 

Ressorts 

• (Bündelung der IT-Nachfrage des Ressorts). 27 

• Fachaufsicht über die ressortinternen Anbieter von IT- 

• 

Dienstleistungen 

Konsolidierung der Erbringung der IT-Dienstleistungen innerhalb 

des Ressorts 

• Mitwirkung bei allen IT-Budgets des gesamten Ressorts 

Die konkrete organisatorische Gestaltung und Einbettung ist noch 

nicht abschließend geklärt. Daher kann das Team als „Platzhalter“ für 

ein organisatorisches Aufbauelement verstanden werden, das mit 

Aufgaben des Architekturmanagements beauftragt ist ([KoopA], S. 12). 

Zurzeit erfolgt dies auf Ebene von Projektgruppen. 


Rolle 

Gremium 

Rolle 

Gremium 

27 

Per IT-Rats-Beschluss wurde diese Aufgabe zwischenzeitlich an die neu eingeführte Rolle „Nachfragekoordinator“ 

delegiert.



Team IT-Rahmenkonzept Die konkrete organisatorische Gestaltung und Einbettung ist noch 

nicht abschließend geklärt. Daher kann sie als „Platzhalter“ für ein 

organisatorisches Aufbauelement verstanden werden, das mit dem IT- 

Rahmenkonzept des Bundes (bspw. der Fortschreibung) beauftragt ist 

([KoopA], S. 12). Zurzeit erfolgt dies auf Ebene von Projektgruppen. 

Tabelle 6: Organisatorische Aufbauelemente der RA 

Gremium 

Die Zusammenhänge zwischen den Rollen, Gremien und den in Abschnitt 5.1 beschriebenen 

Prozessen der RA werden in vereinfachter Form in Abbildung 20 dargestellt. Dabei 

werden folgende Vereinfachungen vorgenommen: 

• Es werden nur die beiden für diese Untersuchung zentralen Prozesse der Diensteableitung 

und der Nachfragebündelung in aggregierter Form dargestellt. Zu den übrigen 

Prozessen liegen keine ausreichenden Informationen vor. 

• Für eine bessere Übersichtlichkeit wird nicht zwischen unterschiedlichen Verantwortlichkeiten 

von Rollen und Gremien für Prozesse bzw. Aktivitäten innerhalb der Prozesse 

unterschieden. Stattdessen wird die Beziehung „beteiligt an“ verwendet. 

Genauere Angaben finden sich in den jeweiligen Prozessbeschreibungen. 

• Das Ressort X und die zugehörigen Rollen stehen stellvertretend für alle Ressorts 

des Bundes. 

• Wenn eine Rolle oder ein Gremium auf der Kante einer Organisationseinheit modelliert 

wird, so bedeutet dies eine entsprechende Zugehörigkeit zu dieser Organisationseinheit, 

ohne dass die Beziehung näher spezifiziert wird. 

Ressort X 

IT-Planungsrat 

IT-Beauftragter 

Ressort X 

Organisationseinheit 

zugehörig 


Geschäftsarchitekt 

Vertritt Interessen des Bundes in 

Beteiligt an 

Beteiligt an 

Rat der IT- 

Beauftragten 

Nachfragerbeirat 

(NFB) 

Zugehörig zu 

Mitglied und Sprecher von 

Beteiligt an 

Rolle 

IT-Beauftragte der 

Bundesregierung 

(BfIT) 

Beteiligt an 

Beteiligt an 

Zusammenwirken 

von IT-Angebot 

und Nachfrage 

Ableitung von 

Diensten aus 

Geschäftsprozessmodellen 

Legende 

Gremium 

Hat Vorsitz von 

IT-Steuerungsgruppe 

Beteiligt Beteiligt an an 

Beteiligt an 

Beteiligt an 

Team 

Architekturmanagement 

Team IT- 

Rahmenkonzept 

IT-Dienstleistungszentren 

des Bundes (DLZ-IT) 

Abbildung 20: Identifizierte Rollen und Gremien der RA und ihre Beteiligung an den zentralen Prozessen 


Prozess 

Kundenmanager 

Lösungsarchitekt 

Beteiligt an Prozess 

Steht in 

Beziehung zu 

Konkrete 

organisatorische 

Einbettung noch offen 

Konkrete 


Einbettung noch offen


6.2 Organisatorische Aufbauelemente der ITIL 

Die Beschreibung der Prozesse in ITIL (vgl. Abschnitt 5.2) wird ergänzt um eine Vielzahl 

begleitender organisatorischer Aufbauelemente (Rollen und Gremien). Aus der Dokumentation 

zu ITIL sind 76 rekonstruierte organisatorische Aufbauelemente in Tabelle 21 in Anhang 

M zusammengefasst. Diese Vielzahl an Rollen und Gremien ergeben sich aus dem breiten 

Spektrum an betrachteten Prozessen und organisatorischen Aspekten innerhalb der IT- 

Organisation – sowohl in der Breite als auch in der Tiefe. 

In ITIL finden sich meist keine konkreten Angaben zur Ausgestaltung der funktionalen Aufbauorganisation; 

vielmehr beschränkt sich ITIL auf eine prozessorientierte Sichtweise und 

die Nennung und Beschreibung von Rollen und Gremien, die eine IT-Organisation aufweisen 

kann bzw. aufweisen sollte. Neben einer kurzen Beschreibung der jeweiligen Ziele, Tätigkeiten 

und Verantwortungsbereiche werden teilweise auch Beziehungen zu anderen Organisationseinheiten 

aufgezeigt. Es finden sich jedoch nur vereinzelt Angaben zu konkreten Über- 

und Unterordnungsbeziehungen. In [Service Operation] werden bspw. Vorschläge für eine 

mögliche Organisationsgestaltung des Betriebs dargestellt (z. B. lokales, zentrales oder 

virtuelles Service Desk). Ein durchgängiges, d.h. prozess- und lebenszyklusübergreifendes, 

Organisationsmodell ist demnach kein Bestandteil von ITIL (siehe dazu auch ISACA und 

itSMF 2008, S. 62ff.). 

Eine grafische Zuordnung von organisatorischen Aufbauelementen zu Prozessen – analog 

zu Abbildung 20 – erscheint aufgrund der hohen Anzahl an Aufbauelementen und Prozessen 

nicht hilfreich. Vielmehr lässt sich die Vielzahl an beschriebenen Aufbauelementen (teilweise) 

durch die Identifikation von zentralen Elementen und sich wiederholenden Strukturen 

untergliedern: Für nahezu jedes Konzept und für jeden Prozess gibt es einen dedizierten 

Verantwortlichen. So gibt es etwa für jeden Service-Prozess die Rolle eines Prozess-Owners 

und die Rolle eines Prozess-Managers. Während erstere eine eher strategische Rolle bezeichnet, 

bezieht sich letztere auf eine eher taktisch-operative Rolle. 

Die zentralen Elemente der Aufbaustruktur aus ITIL sind in Anhang M tabellarisch aufgelistet. 

6.3 Organisatorische Aufbauelemente der COBIT 

COBIT benennt eine Reihe von Rollen bzw. Funktionen sowohl aus dem Geschäfts- als auch 

dem IT-Bereich. Hervorzuheben ist in diesem Zusammenhang, dass COBIT durch die Verwendung 

von RACI-Matrizen nähere Angaben von Verantwortungsbereichen der Rollen/Funktionen 

für die einzelnen Aktivitäten der Prozesse macht. Dabei steht RACI für: 

responsible (zuständig), accountable (verantwortlich), consulted (konsultiert) und informed 

(informiert). Darüber hinausgehende Definitionen oder Beschreibungen finden sich jedoch 

nur vereinzelt. Einen Überblick über die aus den Prozessen, RACI-Matrizen und den Control 

Objectives identifizierten Rollen und Gremien bietet dazu Anhang N. 

In COBIT finden sich keine definierten Beziehungen i. S. v. Über- und Unterordnungsbeziehungen 

zwischen den einzelnen Rollen und Gremien. Vereinzelt lassen sich diese aus den 

Bezeichnungen – verbunden mit Interpretationen – rekonstruieren, z. B. die Einordnung von 

CEO und CIO. Durch die vage gehaltene Spezifikation der Aufbauelemente und den fehlenden 

dedizierten Beziehungen müssen die beschriebenen Rollen und Gremien daher nebeneinander 

stehen bleiben. Es kann lediglich eine grobe Unterteilung nach Business- und ITorientierten 

Elementen und einer Unterscheidung unterschiedlicher Hierarchieebenen vorge- 



nommen werden. Eine entsprechende Darstellung in Verbindung mit interpretierten Beziehungen 

findet sich in Abbildung 21. 

Hierarchiebene 


Abbildung 21: Identifizierte Rollen und Gremien in COBIT 

Ausgehend von den rekonstruierten organisatorischen Aufbauelementen der RA werden 

Ähnlichkeiten, Widersprüche und Integrationsmöglichkeiten mit Aufbauelementen aus ITIL 

und COBIT analysiert. Dazu werden die Aufgaben, Beschreibungen und Verantwortungsbereiche 

der Rollen und Gremien aus ITIL und COBIT vor dem Hintergrund der Ziele da RA 

interpretiert. Auf dieser Basis werden die Rollen und Gremien der RA und ITIL bzw. COBIT 

in Bezug zueinander gesetzt. 

Die Gegenüberstellung der in ITIL und COBIT vorgeschlagenen organisatorischen Aufbauelemente 

mit denen der RA zeigt, dass sich in ITIL und COBIT nur bedingt korrespondierende 

bzw. ähnliche Rollen und Gremien identifizieren lassen. So finden sich i.d.R. auch keine 

direkten, d.h. im Sinne eine 1:1-Beziehung, zu den Rollen und Gremien der RA korrespondierenden 

aufbauorganisatorischen Elemente in ITIL oder COBIT. Es lassen sich vielmehr 

Strukturen identifizieren, deren Aufgaben und Verantwortungen denen der RA nahe kommen. 

Die Gegenüberstellung der Aufbauelemente aus ITIL und COBIT mit der RA ist in 

Tabelle 7 zusammen mit erklärenden Kommentaren dargestellt. Die Spalte „Quelle“ gibt 

dabei an, ob das Element aus ITIL oder COBIT stammt. Dabei ist die Zuordnung von Aufbauelementen 

der RA zu Aufbauelementen aus ITIL und COBIT nicht eindeutig und überschneidungsfrei. 

So können einerseits zu einem Aufbauelement der RA mehrere 

Aufbauelemente aus COBIT und ITIL zugeordnet werden, und andererseits können Aufbauelemente 

aus COBIT und ITIL mehreren Aufbauelementen der RA zugeordnet werden. Der 

jeweilige Anknüpfungspunkt zwischen den Aufbauelementen wird in der Spalte „Kommentar“ 

erläutert. 



Für die Ermittlung der Anschlussfähigkeit ergeben sich folgende vier Heuristiken: 

• Anschlussfähigkeit 1: Die Aufgaben und Verantwortungsbereiche der betrachteten 

Aufbauelemente überlappen sich teilweise. Für die Weiterentwicklung der Rahmenarchitektur 

bietet sich an zu prüfen, ob es sinnvoll ist, die Abweichungen auszuräumen 

(z. B. durch Ausweitung der Aufgaben der jeweiligen Rolle in der RA). Für eine 

Anschlussfähigkeit in der praktischen Umsetzung im Sinne der Koordination und Abstimmung 

zwischen Architekturmanagement und etwa den DLZ-IT des Bundes empfiehlt 

sich, die Aufgaben und Verantwortungsbereiche zwischen den 

Aufbauelementen – sofern die jeweilige Rolle bzw. das jeweilige Gremium aus ITIL / 

COBIT überhaupt praktisch eingesetzt werden – abzustimmen bzw. klar voneinander 

abzugrenzen. 

• Anschlussfähigkeit 2: Das betrachtete Aufbauelement der RA existiert in ITIL bzw. 

COBIT nicht. Eine Anschlussfähigkeit ist daher insofern gegeben, als keine Überschneidungen 

und somit keine Widersprüchen vorliegen. 

• Anschlussfähigkeit 3: Das betrachtete Aufbauelement der RA findet sich in ITIL bzw. 

COBIT in wesentlich differenzierterer Form, d.h. die Aufgaben und Verantwortungsbereiche 

sind ggf. auf mehrere Rollen und Gremien aufgeteilt. Für die Weiterentwicklung 

der Rahmenarchitektur bietet sich an zu prüfen, ob es sinnvoll ist, die 

Differenzierungen aus ITIL/COBIT zu übernehmen. 

• Anschlussfähigkeit 4: Für einen näheren Vergleich ist das entsprechende Aufbauelement 

in ITIL bzw. COBIT nicht differenziert genug beschrieben. Aussagen zur Anschlussfähigkeit 

können somit nicht getätigt werden. 

Nr. Aufbauelement RA 

1 Geschäftsarchitekt 

(Ressort) 

gegenübergestelltes 

Aufbauelement 

Quelle 



Kommentar 

Business-Architect X Der Fokus liegt bei der Rolle „Business-Architekt“ 

stärker auf Geschäftsprozessen und der Organisation 

als auf der Betrachtung von Funktionalitäten. 

Er entspricht daher der Rolle des 

Geschäftsarchitekten nur bedingt. Ein offensichtlicher 

Widerspruch ist allerdings nicht auszumachen. 

2 IT-Beauftragte der CIO X 

Anschlussfähigkeit: 1 

Die Rolle des CIO wird in COBIT nicht näher 

Bundesregierung 

differenziert und ist für eine Vielzahl an Prozes- 

(BfIT, Bundes-CIO) 

sen verantwortlich und/oder rechenschaftspflichtig. 

Sie weist daher zwar Parallelen mit den 

Rollen BfIT und Ressort-CIO der RA auf, ist 

jedoch insgesamt nicht differenziert genug. 


3 IT-Planungsrat - Zu diesem Gremium findet sich weder in ITIL 

noch in COBIT ein näherungsweise ähnliches 

Gremium. 






Aufbauelement 

Quelle 



Kommentar 

4 IT-Steuerungsgruppe IT-Steering Committee X Dieses Gremium – auch als IT-Lenkungsgruppe 

bezeichnet – ist u. a. für die Vergabe von Prioritäten 

für und das Management von Projekten in 

Abstimmung mit der Unternehmensstrategie 

zuständig. Dies ähnelt der Aufgabe der IT- 

Steuerungsgruppe der „Koordinierung von IT- 

Großprojekten der öffentlichen Verwaltung“. In 

COBIT setzt sich das IT Steering Committee aus 

Vertretern der Unternehmensleitung, der Kerngeschäftsprozesse 

und des IT-Managements 

zusammen. Dies findet sich in der IT- 

Steuerungsgruppe teilweise wieder. Im Hinblick 

auf das Management von Projekten bzw. von 

Portfolios ist eine Überschneidung mit den 

Aufgaben des IT-Rats auszumachen sein. 


5 Kundenmanager - Zu dieser Rolle findet sich weder in ITIL noch in 

COBIT eine näherungsweise ähnliche Rolle. 


6 Lösungsarchitekt 

IT- 

Infrastrukturarchitekt, 


Manager, Servicearchitekt 

X 

Die Aufgaben und Verantwortlichkeiten des 

Lösungsarchitekten finden sich in verschiedenen 

Rollen in ITIL wieder. Dabei fällt insbesondere 

auf, dass die Aufteilung der Zuständigkeiten 

zwischen DLZ-IT des Bundes und den Fachbereichen 

ggf. durch unterschiedliche Rollen aufgegriffen 

werden sollte. So könnte bspw. die Rolle 

eines eher technischen Architekten (bspw. 

ähnlich zum IT-Infrastrukturarchitekt in ITIL) in 

den Verantwortungsbereich der DLZ-IT des 

Bundes fallen, während die Rolle des Service 

Design Managers, eher in den Bereich des 

Architekturmanagements fällt. Der Service 

Design Manager ist verantwortlich für die Gesamtkoordination, 

die Erstellung und die Verwendung 

hochwertige Lösungen für Services und 

Prozesse. Dies ähnelt dem Aufgabenspektrum 

des Lösungsarchitekten der RA, bewegt sich 

aber auf einer eher übergeordneten Ebene. Dies 

ließe sich mit der Verantwortlichkeit für den 

Prozess der Dienstableitung in Verbindung 

bringen. 

Ähnliches gilt für den Servicearchitekten. 


7 Nachfragebeirat (NFB) - Zu diesem Gremium findet sich weder in ITIL 

noch in COBIT ein näherungsweise ähnliches 

Gremium. 





8 Nachfragekoordinator 

Ressorts 

9 Rat der IT- 

Beauftragten (IT-Rat) 

Quelle 




Aufbauelement 

Kommentar 

Business Process X Der Business Process Owner ist für die Identifika- 

Owner 

tion und Definition von Anforderungen zuständig. 

Der Fokus liegt damit nicht direkt auf der Abstimmung 

der Nachfrage, sondern eher auf den 

Anforderungen. Darüber hinaus ist der Process 

Owner in COBIT auch für die Identifikation von 

möglichen Risiken und der Bewertung von 

Entwürfen zuständig. Die Betrachtung von 

Risiken mag mit in den Verantwortungsbereich 

des Nachfragekoordinators aufgenommen 

IT Steering Group X 

werden. 


Die IT Steering Group soll eine enge Abstimmung 

zwischen Strategien und Plänen von Business 

und IT Service Provider sicherstellen. Zu einer IT 

Steering Group gehören nach ITIL Vertreter des 

oberen Managements aus dem Business und 

dem IT Service Provider. Es sind Parallelen zum 

IT-Rat zu erkennen. Jedoch entspricht die Zusammensetzung 

des IT-Rats nicht der der IT- 

Steering Group. Die Abstimmung zwischen 

IT Steering Committee X 

Diensteabnehmer und Diensteerbringer erfordert 

jedoch die Berücksichtigung aller beteiligten 

Gruppen. Dies sollte bei der Weiterentwicklung 

der RA berücksichtigt werden. 


Dieses Gremium – auch als IT-Lenkungsgruppe 

bezeichnet – ist u. a. für die Vergabe von Prioritäten 

für und das Management von Projekten in 

Abstimmung mit der Unternehmensstrategie 

zuständig. Dies ähnelt der Aufgabe des IT-Rats 

des „übergreifenden Portfoliomanagements“. 

IT Strategy Committee X 

Jedoch setzt sich das IT Steering Committee 

nach COBIT aus Vertretern der Unternehmensleitung, 

der Kerngeschäftsprozesse und des IT- 

Managements zusammen. Dies findet sich im IT- 

Rat nicht wieder. Siehe dazu auch den Kommentar 

zur IT Steering Group. Im Hinblick auf das 

Management von Projekten gibt es eine Überschneidung 

mit der IT-Steuerungsgruppe. 


Die Einhaltung der IT-Strategie in Übereinstimmung 

mit der Unternehmensstrategie ist – ähnlich 

zum IT-Rat – auch die Aufgabe des IT 

Strategy Committes. Darüber hinaus soll das IT 

Strategy Committee sicherstellen, dass „IT- 

Governance, als Teil der Corporate Governance 

angemessen adressiert wird“ ([COBIT-DE], S. 

46). Dies gehört nicht zu den Aufgaben des IT- 

Rats, die Relevanz bzw. Auswirkungen der IT- 

Governance für die RA ist jedoch ungeklärt. 





10 IT-Beauftragter für 

Ressort (Ressort-CIO) 

11 Team Architekturmanagement 

12 Team IT- 

Rahmenkonzept 


Aufbauelement 

Quelle 



Kommentar 

IT Architecture Board X Das IT Architecture Board ist für Vorgaben für die 

Architektur zuständig und steuert damit das 

Design der IT-Architektur unter Berücksichtigung 

der Unternehmensstrategie. Die Aufgaben des IT 

Architecture Boards fallen damit in den Verantwortungsbereich 

des IT-Rats. Die Zuständigkeiten 

des Teams Architekturmanagement der RA 

sind diesbezüglich jedoch unklar. 


CIO X Siehe BfIT 

Chief Architect 

X Als Verantwortlicher für die IT-Architektur ist der 

Chief Architect in COBIT (vermutlich) mit ähnlichen 

Aufgaben wie das Team Architekturmanagement 

der RA betraut, bspw. dem Erstellen und 

Pflegen von Architekturen und der Definition von 

Technologie-Standards. Da der genaue Aufgabenbereich 

des Teams Architekturmanagement 

noch nicht definiert ist, kann keine abschließende 

Aussage getroffen werden. 

Es liegen keine konkreten Aufgabenbeschreibungen vor. 

Tabelle 7: Gegenüberstellung organisatorischer Aufbauelemente 


Der Frage nach Anschlussfähigkeit und Potenzialen einer weiter gehenden Integration der 

RA mit ITIL und COBIT mit Blick auf organisatorische Aufbauelemente sind einige Vorüberlegungen 

voran zu stellen: Aus Sicht der Gutachter sind Rollenmodelle, wie sie die RA, ITIL 

und COBIT vorsehen, nur in ihrer Gesamtschau sinnvoll zu interpretieren, da Rollenabgrenzungen 

über Aufgaben und Verantwortlichkeiten i. d. R. aufeinander abgestimmt sind und 

nicht einfach aus ihrem Kontext herausgenommen und anderweitig eingesetzt werden können. 

Eine Rolle ist über ihre Aufgaben und Verantwortlichkeiten definiert und damit von 

anderen Rollen abgegrenzt. Begründungen für die Aufteilung der Aufgaben auf die Rollen 

und Gremien fehlen sowohl in ITIL als auch in COBIT. Die Analyse war folglich auf die Aufdeckung 

von Ähnlichkeiten bei Aufgaben gerichtet (die RA nimmt derzeit keine durchgängig 

verwendete differenzierte Spezifikation von Verantwortlichkeiten vor im Sinne der RACI- 

Matrizen aus COBIT). 

Die Untersuchung zeigt, dass eine direkte Zuordnung der aufbauorganisatorischen Elemente 

auf entsprechende Pendants in ITIL und COBIT im Sinne einer Äquivalenz, d.h. identischen 

Aufgaben und Verantwortlichkeiten, nicht möglich ist. Zudem spiegeln die Rollen der RA 

spezifische organisatorische und politische Randbedingungen wider, die in ITIL und COBIT 

nicht berücksichtigt sind. Die Aufgabendefinitionen der Rollen der RA bewegen sich i. d. R. 

auf einem differenzierteren Niveau als die Rollenbeschreibungen bei ITIL, dagegen ergänzt 

COBIT differenzierte Verantwortlichkeiten einzelner Rollen für einzelne „Control Objectives“. 

H-17 Handlungsempfehlung: Rollenmodell auf Konsistenz und Kohärenz prüfen 

Es gilt als weitgehender Konsens, dass eine möglichst überschneidungsfreie Aufgabenabgrenzung 

und eine möglichst präzise Zuordnung von Verantwortlichkeiten zentrale Erfolgs- 



faktoren für Architekturmanagement-Initiativen darstellen. Zumindest für Rollen und Gremien 

im Einflussbereich des Architekturmanagements (z. B. Geschäftsarchitekt) sollte daher sorgfältig 

überprüft werden, ob die Aufgaben hinreichend präzise und möglichst vollständig beschrieben 

sind und ggfs. ergänzend angeführt ist, was dezidiert nicht Aufgabe einer Rolle 

oder eines Gremiums ist, um Missverständnissen entgegen zu wirken. Dafür erscheint die 

Zusammenarbeit mit der zuständigen Organisationsabteilung unabdingbar. Die Entscheidung 

über Aufgaben und Verantwortlichkeiten einer Rolle bzw. eines Gremiums ist letztlich 

Aufgabe der Organisationsspitze und nach unserem Dafürhalten nicht delegierbar. Die Entscheidung 

ist eng verknüpft mit der Frage nach Governance-Regeln und der Frage, welches 

Gremium diese Regeln vorgibt und welches Gremiums ihre Einhaltung überwacht bzw. 

welche Rolle ihre Einhaltung sicherstellt. 

H-18 Handlungsempfehlung: Rollenmodell der RA um weitere Rollen ergänzen 

Unabhängig von der Konzeptualisierung in ITIL und COBIT empfiehlt es sich aus Sicht der 

Gutachter, das Rollenmodell der RA um weitere Rollen zu erweitern. Dabei können Rollen 

aus ITIL und COBIT als Anregungen dienen. Eine solche Ergänzung wäre die Rolle des 

Dienste-Verantwortlichen, die in ITIL mit der Rolle des Service-Managers eine eindeutige 

Verantwortlichkeit für einen Dienst bestimmt, um einen definierten Ansprechpartner für Kunden 

und Mitarbeiter der IT-Organisation zu haben. Da in ITIL vielfach auf diese Rolle verwiesen 

wird und sie eine zentrale Bedeutung innerhalb der ITIL hat, empfiehlt es sich, bei der 

Ergänzung des Rollenmodells der RA die Konzeptualisierung in ITIL sorgfältig zu prüfen. 

In ähnlicher Weise bestimmt ITIL für jedes IT-Artefakt (einen Dienst, eine konkrete IT- 

Lösung, eine Hardware) einen Verantwortlichen, also z. B. ein Verantwortlicher für den 

Dienst „Kontoauszug drucken“. Ebenso definiert ITIL für jeden Prozess einen Prozess- 

Verantwortlichen. Demnach könnte bspw. die Methode der Diensteableitung oder der Prozess 

Zusammenwirken von IT-Angebot und IT-Nachfrage eindeutig einem Verantwortlichen 

zugewiesen werden, der die Durchführung und die Weiterentwicklung der Methode bzw. des 

Prozesses anleitet, koordiniert und verantwortet. 

Die zentrale Rolle, die Architekturen und Architekturmodelle in der RA einnehmen, bzw. 

einnehmen werden, sollte auch im Rollenmodell berücksichtigt werden. Mit der Unterscheidung 

zwischen Business-Architekt, Service-Architekt und IT-Infrastrukturachitekt bietet ITIL 

eine recht differenzierte Struktur, auf die ggf. zurückgegriffen werden kann ([Design] 2008, S. 

42). Darüber hinaus sollte es klare Strukturen für die Freigabe und Überwachung von Änderungen 

an zentralen Elementen und Abstraktionen der RA, bzw. des Dienstekatalogs geben. 

Ebenso kann geprüft werden, inwiefern die Rolle des Chief Architects aus COBIT in der 

Bundesverwaltung konkretisiert ist. Ggf. kann die Rolle des Chief Architects für die weitere 

Ausgestaltung des Teams Architekturmanagement herangezogen werden. 

Darüber hinaus finden sich in ITIL und COBIT keine dedizierten Rollen und Gremien, die das 

Architekturmanagement betreffen. 

H-19 Handlungsempfehlung: Verantwortlichkeiten ergänzen 

Das Rollenmodell der RA kennt kein differenziertes Verantwortlichkeitskonzept, wodurch 

Zuständigkeiten unklar bleiben, die für das Architekturmanagement von hoher Bedeutung 

sein sollten. So ist z. B. unklar, wer für die Pflege und Entwicklung der Architekturen bzw. 

Modelle verantwortlich ist, wer Änderungen an ihnen gegenzeichnen muss oder welches 

Gremium ein Projektmanagement verantwortet. 



Gleichzeitig ist aus Sicht der Gutachter mit dem gegenwärtigen Aufgabenspektrum des IT- 

Rats, der für Angebot und Nachfrage zuständig zu sein scheint, die Gefahr verbunden, dass 

die angestrebte klare Trennung in Anbieter und Nachfrager von IT-Leistungen aufgeweicht 

wird. Mit Blick auf die in COBIT betonte Ordnungsmäßigkeit der Rechnungslegung stehen 

Fragen der Ausübung von Kontrolle im Gegensatz zur Ausübung von Entscheidung und 

Verantwortung. Unter diesem Gesichtspunkt erscheint die Rolle des Ressort-CIO derzeit 

sowohl das Regelwerk zu formulieren (als mögliches Mitglied im IT-Rat) als auch seine 

Einhaltung zu prüfen, was in Revisionskreisen aus bekannten Gründen (Interessenkonflikte 

usw.) nicht akzeptabel ist. 

Die mit der Änderung an Verantwortlichkeiten verbundenen organisatorischen Fragen stehen 

allerdings außerhalb der RA. Die RA könnte durch ein differenziertes Verantwortlichkeitskonzept 

allerdings eine wertvolle Hilfestellung bei der Analyse von derartigen Fragestellungen 

geben. Aus Sicht der Gutachter sind daher Rollen und Gremien um Verantwortlichkeiten zu 

ergänzen. Dabei sollte sich allerdings nicht auf die aus dem Auditing stammende Konzeptualisierung 

der RACI-Matrizen aus COBIT beschränkt werden (4 Verantwortlichkeiten). Vielmehr 

sollte ein eigenes, durchaus differenzierteres Konzept entworfen werden, das an den 

Zielen der IT-Steuerung Bund und an den besonderen Rahmenbedingungen der RA (Ressorthoheit, 

übergeordnete Planungs- und Haushaltsprozesse, etc.) ausgerichtet ist und ggfs. 

deutlich mehr Verantwortlichkeiten unterscheidet (z. B. „betrifft nachgelagerte Behörde“, „ist 

abhängig von“). 



7 Schlussbetrachtung und Handlungsoptionen 

Die Ergebnisse der vorliegenden Untersuchung deuten grundsätzlich eine Anschlussfähigkeit 

der RA an ITIL bzw. COBIT an, da sich keine grundlegende Diskrepanzen, bspw. in 

Form von Widersprüchen, identifizieren ließen und die Analyse zeigt, dass die drei Ansätze 

unterschiedliche Bereiche des IT-Managements auf unterschiedlichem Abstraktionsniveau 

und mit verschiedenen Mitteln (Instrumente, Artefakte, Strukturen) adressieren. Es liegt also 

nahe zu vermuten, dass nicht nur eine prinzipielle Anschlussfähigkeit besteht, sondern sich 

die RA und ITIL bzw. COBIT mithin gegenseitig ergänzen: Während ITIL beschreibt, welche 

organisatorischen Strukturen (Prozesse, Organisationseinheiten) auf IT-Seite aufzubauen 

sind und COBIT dediziert auf Verantwortlichkeiten der Organisationseinheiten in den Prozessen 

der IT-Organisation eingeht, stellt die RA ein Instrument zur Abstimmung von Angebot 

und Nachfrage an IT-Diensten dar; von der konkreten Implementierung und Erbringung 

von IT-Diensten – dem IT-Betrieb – wird bewusst abstrahiert. Sie beschränkt sich dabei auf 

die Identifikation von Diensten, sowohl aus Geschäfts- als auch aus IT-Sicht. Eine Integration 

der RA und der ITIL stellt darüber hinaus sogar noch in Aussicht, die auf die IT-Perspektive 

ausgerichtete ITIL an die Perspektive der Geschäftsseite weiter anzuschließen und damit 

einen zusätzlichen Beitrag für eine Perspektiven- (und Ressort-) übergreifende Kommunikation 

zu leisten. COBIT verspricht in diesem Zusammenhang durch die Betonung der Ausrichtung 

der IT an den Zielen der Geschäftsseite („Control Objectives“) und durch die 

Beurteilung der Zielerreichung (Kennzahlen, Risiken, Reifegradmodelle) eine bessere Abstimmung 

zwischen IT-Seite und Geschäftsseite. 

Die RA kann ihre intendierte Wirkung allerdings nur dann entfalten, wenn sie breit eingeführt 

wird und als gemeinsame Referenz aller Bundesbehörden Anwendung findet. Dazu gehört 

auch, dass sie im Zeitverlauf weiterentwickelt wird. Der mit der Einführung und Pflege der RA 

verbundene Aufwand ist erheblich. Es ist deshalb angeraten, frühzeitig kritische Erfolgsfaktoren 

zu identifizieren, um ggfs. geeignete Anpassungen vornehmen zu können. Voraussetzung 

für die Integration der RA mit ITIL und COBIT sind übereinstimmende oder 

anschlussfähige inhaltliche Referenzsysteme – also übereinstimmende oder anschlussfähige 

sprachliche Strukturen und Konzepte. Bevor allerdings über die, mit hohem Aufwand verbundene, 

Weiterentwicklung der RA und eines gemeinsamen Referenzsystems entschieden 

wird, sind folgende grundsätzliche Fragen zu klären: 

1. Ist eine spätere Zertifizierung der IT-Organisationen z. B. nach internationalen Normen 

wie ISO/IEC 20000-1:2005 angestrebt? Falls eine solche Zertifizierung angestrebt 

wird, engt sich der Spielraum bei der Integration der RA mit ITIL bzw. COBIT 

deutlich ein: Es sind dann die Anforderungen an die Zertifizierung sorgfältig zu prüfen, 

wobei davon auszugehen ist, dass eine eigenbestimmte, vergleichsweise freie 

Adaption der Rahmenwerke nicht mehr möglich sein wird. 

2. Wie sinnvoll ist es, einzelne Ziele, Konzepte, Prozesse, Aufbauelemente aus ITIL und 

COBIT isoliert und ggf. ohne Adaption zu übernehmen? Nach Ansicht der Gutachter 

erscheint es wenig sinnvoll, wahlfrei Konzepte, Prozesse, Aufbauelemente aus ITIL 

und COBIT ohne entsprechende Anpassungen zu übernehmen. Vielmehr sollten, wie 

in der vorliegenden Studie mehrfach vorgeschlagen, die Elemente in ITIL und COBIT 

als Ideengeber und Anregungen interpretiert werden, um eigene Verfeinerungen dort 

vorgeschlagener Ziele, Konzepte, Prozesse und Aufbauelemente zu entwickeln. Dies 

gilt insbesondere dann, wenn eine spätere Zertifizierung nicht angestrebt wird. 



3. Damit verbunden ist unmittelbar die Frage, wie fein granular man die Ansätze zerlegen 

kann, ohne ihnen „Unrecht“ zu tun. Anders gewendet: Welche „Teile“ lassen sich 

sinnvoll herausgreifen? Die Studie diskutiert dazu sowohl positive Beispiele (etwa 

hinsichtlich der Ziele Kontinuität und Ordnungsmäßigkeit der Rechnungslegung) als 

auch negative Beispiele (etwa die Zerlegung von Rollen in einzelne Aufgaben, die als 

nicht sinnvoll eingeschätzt wird). Hier ist eine Prüfung im Einzelfall erforderlich. Eine 

pauschale Empfehlung ist nicht möglich. 

4. Letztlich steht damit auch die Frage in Zusammenhang, inwieweit ITIL und COBIT an 

organisationsspezifische Eigenheiten angepasst werden können, ohne gegen ihren 

„Geist“ zu verstoßen. Diesbezüglich lässt sich feststellen, dass ITIL und COBIT an die 

individuellen Organisationserfordernisse angepasst werden müssen und sollen, jedoch 

dazu keine Anleitungen enthalten. Der dadurch entstehende Spielraum wird vor 

allem von einschlägig tätigen Beratungsfirmen und Softwareanbietern genutzt, um eigene 

Produkte zu platzieren (siehe dazu z. B. van Bon 2009). Nach Einschätzung der 

Gutachter ist diese Situation äußerst bedenklich, da zu vermuten ist, dass nicht eine 

sorgfältig entwickelte konzeptuelle Grundlage im Vordergrund der Investition stehen 

wird, sondern eine werkzeuggetriebene, möglichst kostengünstige und vor allem 

schnell einzusetzende Lösung – mit problematischen Konsequenzen für ihre langfristige 

Tragfähigkeit. 

5. Grundsätzlich ist zudem aus Sicht der Gutachter zu hinterfragen und intensiv zu diskutieren, 

aus welchen Gründen eine Orientierung der Bundesbehörden dieses Landes 

an Ansätzen aus der ausländischen Praxis überhaupt erfolgen sollte. Dies gilt vor 

allem für COBIT, in Teilen auch für ITIL. Die Verbreitung der Ansätze ist dabei zu relativieren. 

Nach Angaben in Marrone und Kolbe (2011), S. 5 schätzt das IT Governance 

Institute – vermutlich überaus optimistisch – das ITIL einen Verbreitungsgrad 

von rund 25 Prozent und COBIT von rund 14 Prozent aufweist. Es ist also bei Weitem 

nicht so, dass jenseits dieser Ansätze keine anderen Lösungen existieren würden. 

Vor diesem Hintergrund empfiehlt sich nach unserer Einschätzung der verstärkte 

Austausch mit Behörden anderer (EU-) Staaten mit dem Ziel gegenseitige Anregungen 

auszutauschen und länderspezifische Eigenheiten zu identifizieren, um darauf 

aufbauend eine eigene Lösung zu entwickeln. 

6. Damit ist die spezifische Frage verbunden, ob COBIT überhaupt für eine deutsche 

Bundesbehörde geeignet ist. Es ist zu berücksichtigen, dass COBIT auf dem U.S.amerikanischen 

Rechtsformenverständnis von Körperschaften aufbaut und als Folge 

des aus dem U.S.-amerikanischen Rechtsraum stammenden Sarbanes-Oxley-Act 

von 2002 entstanden ist. Inwiefern für deutsche Bundesbehörden eine solche rechtliche 

Grundlage vertretbar/sinnvoll/geeignet sein mag, ist durch den Bedarfsträger zu 

klären. Eine Integration von RA und COBIT in ausgewählten, vom zugrundeliegenden 

Rechtsverständnis weitgehend unabhängigen Aspekten verspricht eine sinnvolle Ergänzung 

der RA zu liefern. Hier ist zum Beispiel an das Konzept der internen Kontrolle 

gedacht, das sich in nahezu übereinstimmender Form auch in den Regelungen des 

Instituts der Wirtschaftsprüfer (IDW) wiederfindet (z. B. im Prüfungsstandard IDW PS 

261 §3.1.2.1). Da allerdings nicht davon auszugehen ist, dass diese Regelungen für 

Bundesbehörden Geltung beanspruchen, ist grundsätzlich zu fragen, auf welcher Basis 

und in welcher Form die als sehr relevante und bedeutend eingeschätzte Frage 

nach Revision, Kontrolle und der Sicherstellung der Einhaltung von rechtlichen Vorschriften 

in die RA einfließen sollte (muss). 



Handlungsoptionen 

Im Hinblick auf zukünftige Handlungsoptionen sind die folgenden Kernergebnisse von zentraler 

Bedeutung: 

1. Ziele von ITIL, COBIT und der Rahmenarchitektur überschneiden sich teilweise, bieten 

aber eine Reihe von Ansatzpunkten für eine sinnvolle gegenseitige Ergänzung. 

2. Die Konzepte, Prozesse und Organisationsstrukturen von ITIL, COBIT und der Rahmenarchitektur 

sind grundsätzlich anschlussfähig. Dabei ist allerdings zu berücksichtigen, 

dass sich die jeweils verwendeten Begriffe hinsichtlich des Abstraktionsniveaus 

und der Bedeutung zum Teil deutlich, zum Teil subtil unterscheiden. 

3. Die organisationsweite Nutzung der drei Rahmenwerke empfiehlt eine Integration im 

Sinne einer einheitlichen Begrifflichkeit, da sonst Friktionen zu erwarten sind. Diese 

Integration betrifft auch Prozesse und Organisationsstrukturen. 

4. Die drei betrachteten Rahmenwerke fokussieren vor allem auf eine zielgerichtete 

Strukturierung des komplexen Gegenstands IT-Management sowie verschiedener mit 

ihm verknüpften Facetten (u. a. IT-Auditing, IT-Risikomanagement, IT-Controlling). 

Die erfolgreiche Einführung und Nutzung eines Rahmenwerks erfordert allerdings ergänzend 

flankierende Maßnahmen. Sie betreffen die Organisationskultur, insbesondere 

den Stellenwert der IT, die Qualifikation von Mitarbeitern in IT und 

Fachabteilungen sowie die Gestaltung effektiver Anreizsysteme. 

Für die weitere Entwicklung ergeben sich verschiedene Handlungsoptionen, die sich hinsichtlich 

ihrer Zielsetzung, des Aufwands und des zu realisierenden Nutzens deutlich unterscheiden. 

Sie werden im Folgenden anhand dreier prototypischer Optionen skizziert. 

Konsolidierende Angleichung: Die drei Rahmenwerke werden soweit zusammengeführt, 

dass die Begrifflichkeiten zumindest in den Schnittstellenbereichen vereinheitlicht werden. 

Auf diese Weise können die betroffenen Akteure das für ihre Domäne am besten geeignete 

Rahmenwerk verwenden. Gleichzeitig wird die wichtige domänenübergreifende Kommunikation 

und Kooperation unterstützt. 

Vorteile: Die Umsetzung kann mit relativ geringem Aufwand erfolgen. Bisherige Investitionen 

in ITIL und COBIT (vor allem: Qualifikationsmaßnahmen, Zertifizierungen, Werkzeuge) bleiben 

weitgehend geschützt. Zudem ist am Arbeitsmarkt eine wachsende Zahl einschlägig 

qualifizierter Arbeitskräfte verfügbar. Unter der Voraussetzung, dass ITIL und COBIT bereits 

eine nennenswerte Akzeptanz erfahren, ist mit relativ geringen Widerständen zu rechnen. 

Risiken: Da ITIL und COBIT weitgehend beibehalten bleiben, werden ihre spezifischen 

Schwächen zementiert. Die Angleichung nur über gemeinsame Schnittstellenbegriffe ist 

zudem mit der Gefahr verbunden, dass die drei Rahmenwerke sich jeweils weitgehend unabhängig 

voneinander entwickeln – sowohl in Bezug auf die Ziele, Konzepte und Maßnahmen 

wie auch im Hinblick der jeweils mitschwingenden spezifischen Fachkulturen. Es 

besteht deshalb das Risiko, dass die intendierte Förderung einer engen und weitgehend 

reibungslosen Zusammenarbeit misslingt – nicht zuletzt besteht das Risiko, das die vorausgesetzte 

Vereinheitlichung der Terminologien nicht in angemessenem Maße vorzunehmen 

ist und die begriffliche Integration scheitert. 

Integration: Die drei Rahmenwerke werden umfassend integriert. Dazu wird ein gemeinsames 

Zielsystem erstellt, das die Zusammenhänge zwischen den Zielen der einzelnen Rahmenwerke 

verdeutlicht. Zudem werden die Terminologien weitgehend in eine gemeinsame 

Referenzterminologie überführt. Prozesse, Vorgehensmodelle und Referenzhandlungsmuster 

werden in einheitlicher Struktur beschrieben und tragen durch Referenzen auf Elemente 



aller jeweils brauchbaren Rahmenwerke zu deren Integration bei. Die drei Rahmenwerke 

bleiben in ihren grundlegenden Konturen erhalten. Es kann aber bei einzelnen Konzepten zu 

deutlichen Änderungen kommen. 

Vorteile: Die Integration der drei Rahmenwerke in ein gemeinsames Rahmenwerk fördert 

eine konsistente, kohärente, besser verständliche und damit effizientere Nutzung. Gleichzeitig 

können auf diese Weise Unebenheiten und Schwächen von ITIL und COBIT ausgeglichen 

werden. Das gemeinsame Rahmenwerk kann allen aus verschiedenen Blickwinkeln 

von am IT-Management beteiligten oder von ihm betroffenen Akteuren als gemeinsame 

Orientierung dienen, wodurch effizienzmindernden Partikularrationalitäten 28 entgegengewirkt 

und auch ein Beitrag zu einer domänenübergreifenden, gemeinsame Ziele betonenden 

Organisationskultur geleistet wird. Damit ist auch eine günstigere Voraussetzung für den 

Entwurf zielführender und konsistenter Anreizsysteme geschaffen. 

Risiken: Die Integration der drei Rahmenwerke erfordert eine Abstraktion auf längerfristig 

tragfähige gemeinsame Konzepte. Dies ist zum einen mit einem erheblichen Aufwand verbunden, 

der den Einsatz entsprechend qualifizierter Fachkräfte erfordert. Zum anderen birgt 

die Integration das Risiko, dass die auch für die Zukunft zu erwartende isolierte Weiterentwicklung 

von ITIL und COBIT einen mehr oder weniger großen Anpassungsaufwand mit sich 

bringt – jedenfalls dann, wenn die Anschlussfähigkeit an beide Rahmenwerke erhalten bleiben 

soll. 

Assimilierte IT: ITIL und COBIT basieren auf der Annahme, dass die Rolle des IT- 

Managements vor allem darin besteht, organisatorische Handlungssysteme effektiv und 

effizient zu unterstützen. Eine solche Interpretation der Rolle von IT in Organisationen erscheint 

zunächst ausgesprochen sinnvoll. Zum einen erscheint es angemessen, die Ziele 

einer Organisation in den Vordergrund zu stellen. Zum anderen wird damit auch ein kultureller 

Wandel befördert: Weg von technikaffinen Akteuren, die gegenüber den Zielen einer 

Organisation weitgehend indifferent sind und nach Maßgabe eigener „hidden agendas“ 

handeln, hin zu verantwortungsbewussten Dienstleistern, die ihre Ziele und Maßnahmen an 

den übergeordneten Organisationzielen ausrichten. Eine solche Trennung der Belange ist 

ein wirksames Mittel zur Bewältigung von Komplexität und hat sich in der gesamtwirtschaftlichen 

Arbeitsteilung bewährt. 

Dessen ungeachtet gibt es gute Gründe dafür, der IT im Allgemeinen, dem IT-Management 

im Besonderen einen höheren Stellenwert in einer Organisation beizumessen. Zum einen 

sind Handlungskomplexe in Organisationen mehr und mehr von IT durchdrungen. Die Bedeutung 

eines zielgerichteten Einsatzes von IT für die Leistungsfähigkeit von Organisationen 

wird also weiter zunehmen. Die Nutzung der Potentiale von IT erfordert i.d.R. eine Reorganisation 

von Handlungssystemen oder – anders gewendet – eine gegenseitige Anpassung. 

Die strategische Planung sollte frühzeitig die Chancen – und Bedrohungen – sehen, die die 

Verfügbarkeit neuer Technologien mit sich bringt (hier sei etwa an biometrische Verfahren 

oder soziale Netzwerke gedacht). Um dies zu erreichen, ist eine enge Verzahnung von IT 

28 BMI: Gemeint ist hier die Tatsache, dass sich bei einer Intransparenz von COBIT und ITIL sowie dessen 

Vagheiten unterschiedliche Wissensstände bei den beteiligten Akteuren ergeben. Mit diesen unterschiedlichen 

Wissensständen können die Akteure ihre eigenen Interessen auf Kosten anderer Akteure durchsetzen. 

Beispiel: Ein Beratungshaus, das ITIL in der Bundesverwaltung einführt, könnte sich sein Wissen zu Nutze 

machen, um beispielsweise ein bestimmtes ITIL Werkzeug einzuführen und daraus möglicherweise Anschlussbeauftragungen 

zu realisieren. Durch die Intransparenz der ITIL Entstehung und der dort enthaltenden Vagheiten 

kann die Bundesverwaltung nur eingeschränkt dieser Situation vorbeugen. 

Die skizzierte Situation führt möglicherweise zur Effizienzminderung auf Seiten der Bundesverwaltung. 

Bei der hier vorgeschlagenen Integration von ITIL, COBIT und der RA erlangt die Bundesverwaltung tiefgründiges 

Wissen über ITIL und COBIT und kann somit deren Integration in die RA besser steuern. 



und Handlungssystem bzw. eine enge Kooperation von IT-Verantwortlichen, fachlich Verantwortlichen 

und der Organisationsspitze erforderlich. Eine solche Kooperation empfiehlt 

eine elaborierte methodische Unterstützung. Als Grundlage dafür sind insbesondere Unternehmensmodelle 

und damit verbunden, Unternehmensarchitekturen geeignet. Sie integrieren 

Modelle des IT-Systems (z. B. Komponentenmodelle, IT-Infrastrukturmodelle, 

Objektmodelle) mit Modellen des Handlungssystems (z. B. Geschäftsprozessmodellen, 

Ressourcenmodelle). Damit fördern Unternehmensmodelle eine zielgerichtete Kooperation 

durch die gemeinsame Berücksichtigung von IT und Handlungssystem. Gleichzeitig unterstützen 

sie spezielle professionelle Perspektiven 29 , da einzelne Modelle (bzw. die korrespondierenden 

Fachsprachen) jenseits einer gemeinsamen Sprachebene weiter verfeinert 

werden können. 

Abbildung 22 illustriert den Aufbau eines Unternehmensmodells mit Abstraktionen für das IT- 

Management. Durch die Ergänzung von Vorgehensmodellen für bestimmte Problemklassen 

wird zudem die Konzeption und Nutzung von Methoden gefördert. Die Qualität der Zusammenarbeit 

wird darüber hinaus durch eine Organisationskultur befördert, die von gemeinsamer 

Verantwortung für das Wohl der Organisation und einer hohen gegenseitigen 

Wertschätzung geprägt ist. 

29 BMI: Mit Perspektive ist hier die Sichtweise der Akteure unterschiedlicher Gruppen gemeint. Ein Organisator 

hat in der Regel eine andere Sichtweise als ein IT-Experte. Beide Akteure haben unterschiedliche Perspektiven, 

die jeweils auch verschiedene Fachsprachen haben können. 



Abbildung 22: Beispielhafter Aufbau eines Unternehmensmodells (eigene Darstellung) 

Vorteile: Die Assimilation der IT-Verantwortlichen unterstützt einen organisatorischen Wandel, 

der zielgerichtet und frühzeitig die Potentiale der IT nutzt. Die Aufwertung der Rolle der 

IT wirkt den heute noch weit verbreiteten Friktionen entgegen, die durch isolierte Zielsysteme 

und Fachkulturen verursacht sind. Langfristig trägt sie dazu bei, dass IT ein im Wortsinn 

selbstverständlicher Bestandteil einer Organisation wird, dessen Grenzen und Möglichkeiten 

auch denjenigen bewusst sind, die nicht unmittelbar mit der Gestaltung und dem Management 

von IT befasst sind. Ein multiperspektivisches Unternehmensmodell bietet damit die 

Chance, Wissen über eine Organisation (und ihre IT) zentral aufzubewahren und vielen 

Akteuren in geeigneter Form zugänglich zu machen. 

Risiken: Der mit der Entwicklung, Einführung und Pflege eines elaborierten Unternehmensmodells 

verbundene Aufwand ist beträchtlich. Die sinnvolle Nutzung eines Unternehmensmodells 

setzt geeignete Werkzeuge voraus, wodurch ergänzender Aufwand für die Auswahl 



und ggfs. Entwicklung erforderlich ist. Zurzeit gibt es noch keine etablierten Standards für 

Sprachen der Unternehmensmodellierung – mit entsprechenden Konsequenzen für den 

Investitionsschutz. 

Mögliche Konsequenzen aus den Handlungsoptionen 

Während die Handlungsoption „assimilierte IT“ die größten Potentiale verspricht, ist ihre 

Realisation mit Hilfe elaborierter Unternehmensmodelle auch mit den größten Risiken verbunden. 

Dabei ist allerdings zu berücksichtigen, dass ein Unternehmensmodell in verschiedenen, 

aufeinander aufbauenden Evolutionsschritten erfolgen kann. So kann sich ein erstes 

Modell auf ein rudimentäres Zielsystem der Organisation, daran anknüpfende Geschäftsprozessmodelle 

sowie korrespondierende Modelle des IT-Systems (Anwendungslandschaft, 

Service-Modell) beschränken. Anschließend kann das Modell bei Bedarf erweitert und verfeinert 

werden. 

Vor dem Hintergrund der Annahme, dass ITIL und COBIT weiterhin eine wichtige Referenz 

darstellen sollen, können die dargestellten Handlungsoptionen auch als Grundlage für eine 

noch zu entwickelnde, evolutionäre Strategie verwendet werden. Dabei ist es wichtig, dass 

beim Anstreben einer frühen Stufe – wie „konsolidierte Angleichung“ – wesentliche Aspekte 

der nachfolgenden Stufe bereits berücksichtigt werden, um eine spätere Weiterentwicklung 

nicht übermäßig zu behindern. 

Die Evolutionsstufen können an ein internes Qualifikationsprogramm und damit verbundene 

Anreize gekoppelt werden, um die sukzessive Weiterbildung der Mitarbeiter zu fördern. 

Damit gehen positive Auswirkungen auf eine von kompetenten Wissensträgern geprägte 

Organisationskultur einher, die allerdings auch zunehmenden Abwerbungsversuchen durch 

die Industrie unterliegen könnten. 



Referenzierte Literatur 

Böttcher 2010 Böttcher, R. (2010): IT-Servicemanagement mit ITIL V3. 2. 

aktualisierte Auflage, Heise, Hannover. 

Frank 2000 Frank, U. (2000): Evaluation von Artefakten in der Wirtschaftsinformatik. 

In: Irene Häntschel und Lutz Heinrich (Hrsg.): Evaluation 

und Evaluationsforschung in der Wirtschaftsinformatik, 

Oldenbourg, München, S. 35-48. 

Frank 2006 Frank, U. (2006): Towards a pluralistic conception of research 

methods in information systems research. ICB-Research Report 

No. 7, Institute for Computer Science and Business Information 

Systems (ICB), Duisburg-Essen University, Essen. 

Gaulke 2010 Gaulke, M. (2010): Praxiswissen COBIT - Val IT - Risk IT: 

Grundlagen und praktische Anwendung für die IT-Governance. 

1. Aufl., dpunkt-Verl., Heidelberg. 

ISACA und itSMF 2008 ISACA; itSMF (2008): ITIL-Cobit-Mapping: Gemeinsamkeiten 

und Unterschiede der IT-Standards. Symposion Publishing 

GmbH 

ISACA 2008 Information Systems Audit and Control Association (ISACA) 

(Hrsg.) (2008): Enterprise Value: Governance of IT Investments 

- The Val IT Framework 2.0, Rolling Meadows. 

ISACA 2009 Information Systems Audit and Control Association (ISACA) 

(Hrsg.) (2009): The Risk IT Framework, Rolling Meadows. 

ITGI 2007a IT Governance Institute (ITGI) (Hrsg.) (2007a): COBIT Control 

Practices: Guidance to achieve control objectives for successful 

IT-Governance. 2nd. Edition, Rolling Meadows. 

ITGI 2007b IT Governance Institute (ITGI) (Hrsg.) (2007b): COBIT Mapping: 

Mapping of ITIL With COBIT 4.0, Rolling Meadows. 

ITGI 2008 IT Governance Institute (ITGI) (Hrsg.) (2008): COBIT Mapping: 

Mapping of ITIL v3 With COBIT 4.1, Rolling Meadows. 

Krcmar 2005 Krcmar, H. (2005) Informationsmanagement, 4. Auflage, Springer, 

Berlin, 

Lorenz 1995 Lorenz, K. (1995) Methode. In: Mittelstraß J (Hrsg) Enzyklopädie 

Philosophie und Wissenschaftstheorie. J. B. Metzeler, Stuttgart, 

S 876–879 

Marrone und Kolbe 2011 Marrone, M. und Kolbe, L. (2011): Einfluss von IT-Service- 

Management-Frameworks auf die IT-Organisation: Eine empirische 

Studie zu Vorteilen, Herausforderungen und Prozessen. 

In: WIRTSCHAFTSINFORMATIK, 53. Jg., Nr. 1, S. 5-19. 

Roelcke 2010 Roelcke, T. (2010): Fachsprachen. 3. Auflage, ESV Verlag, 

Berlin. 



Strecker 2009 Strecker, S. (2009): Ein Kommentar zur Diskussion um Begriff 

und Verständnis der IT-Governance: Anregungen zu einer kritischen 

Reflexion. ICB-Research Report No. 36, Institute for 

Computer Science and Business Information Systems (ICB), 

Universität Duisburg-Essen, Essen 

Strecker ea. 2010 Strecker, S.; Frank, U.; Heise, D. (2010): Toward modeling 

constructs for audit risk assessment: Reflections on internal 

controls modeling. In: Modellierung betrieblicher Informationssysteme 

(MobIS 2010) : Modellgestütztes Management. Dresden, 

S. 131-148. 

van Bon 2009 van Bon, J. (Hrsg.) (2009): Foundations in IT Service Management 

basierend auf ITIL V3, Van Haren, Zaltbommel. 

von Hahn 1998 von Hahn, W. (1998): Vagheit bei der Verwendung von Fachsprachen. 

In: Hoffmann, L.; Kalverkämper, H.; Wiegand, H. E. 

(Hrsg.): Fachsprachen. De Gruyter, Berlin, S. 378–382. 



Anhang A Liste der Handlungsempfehlungen 

Im Folgenden werden alle Handlungsempfehlungen noch einmal zusammengefasst, die in 

Untersuchungsbereichen Ziele, Konzepte, Prozesse und organisatorische Aufbauelemente 

(Kapitel 3–6) beschrieben wurden. Die Liste dient allein der praktischen Arbeit und darf nicht 

getrennt von den inhaltlichen Kapiteln betrachtet werden. 

Nummer 

(Seite) 

Empfehlung Kurzbeschreibung 

Handlungsempfehlungen aus dem Untersuchungsbereich Ziele 

H-1 (S. 23) Zieldissonanzen deutlicher thematisieren 

Die Beziehungen zwischen den Zielen sollte vor allem im 

Hinblick sich widersprechender Ziele weiter präzisiert 

werden. Weiterhin sollten politische Ziel in das Zielmodell 

aufgenommen werden. 

H-2 (S. 24) Ziele operationalisieren Ziele sollten durch die Zuordnung von Maßnahmen und 

Kennzahlen konkretisiert und messbar gemacht werden. 

H-3 (S. 24) Zielsystem präzisieren Die Zieldefinitionen sollten konkretisiert werden. Das 

betrifft insbesondere die Ziele Handlungsfähigkeit, Effizienz, 

Effektivität und Wirtschaftlichkeit (Anpassung an den 

Sprachgebrauch), das strategische Handlungsfeld „Handlungsfähigkeit“ 

(im Allgemeinen kein übergeordnetes Ziel) 

und „schneller IT-Service“ (vage Definition). 

H-4 (S. 25) Zielsystem um weitere Ziele 

ergänzen 

Handlungsempfehlungen aus dem Untersuchungsbereich Konzepte 

H-5 (S. 46) Potenziale eines gemeinsamen 

begrifflichen (semantischen) 

Referenzsystems ausbauen und 

ausschöpfen 

H-6 (S. 47) Zentrales Konzept „Dienst“ weiterentwickeln 

H-7 (S. 47) Weitere Konzepte gezielt in die RA 

aufnehmen 

Handlungsempfehlungen aus dem Untersuchungsbereich Prozesse 

H-8 (S. 57) Zusammenhänge 

Prozessen verdeutlichen 

zwischen 

H-9 (S. 57) Prozesse in einheitlicher Struktur 

beschreiben 

H-10 (S. 57) Prozessbeschreibungen 

weitere Aspekte ergänzen 

um 

H-11(S. 58) Grafische Visualisierungen auf 

Typebene ausbauen 

Das Zielsystem sollte um Ziele aus ITIL und COBIT 

ergänzt werden. Dazu zählen Kundenorientierung, Kontinuität, 

Sicherstellung der Ordnungsmäßigkeit der Rechnungslegung, 

Kommunikation, Mitarbeiterkompetenz, 

Risikotransparenz, Zufriedenstellende Lieferantenbeziehungen, 

sowie Termin- und budgetgerechte Projekte. 

Das Glossar sollte verfeinert, ausgebaut und durch ein 

Metamodell präzisiert werden. Weiterhin sollte das Architekturmanagement 

durch ein entsprechendes Werkzeug 

unterstützt werden. Dieses Werkzeug sollte auf dem 

vorgenannten Metamodell beruhen. 

Die Unterscheidung zwischen Diensteinstanzen und 

Dienstetypen sollte geprüft werden. Weiterhin sollte die 

Abgrenzung der durch IT bereitgestellten Dienste und 

denjenigen Diensten, die nicht von IT bereitgestellt werden, 

überdacht werden. 

Konzepte aus ITIL (z.B. Servicekatalog, vertragliche 

Vereinbarung) und aus COBIT (Control Objective, Audit, 

Risiko, Personal, Verantwortlichkeit, Reifegrad, Domäne) 

sollten in das Glossar/Metamodell aufgenommen werden. 

Zusammenhänge zwischen den bestehenden Prozessen 

der Rahmenarchitektur sollten verdeutlicht werden. 

Prozesse der Rahmenarchitektur sollten in einer einheitlichen 

Modellierungssprache beschrieben werden. 

Die Prozesse der Rahmenarchitektur sollten um die 

Konzepte Reifegrad, Kennzahl, Risiko, Auslöser, Key 

Performance Indicator ergänzt werden. 

Die grafischen Notationen der Rahmenarchitektur sollten 

bei einer Integration mit ITIL und COBIT auf die in diesen 

Rahmenwerken enthaltenen Sachverhalte ausgedehnt 

werden. 



Nummer 

(Seite) 

H-12 (S. 58) Einbezug von Beteiligten und 

Betroffenen betonen 

Empfehlung Kurzbeschreibung 

H-13 (S. 58) Untersuchte Prozesse präzisieren Siehe H-14–H-16 

H-14 (S. 59) Gremium für Entscheidung des 

ressortinternen bzw. ressortübergreifenden 

Diensteangebots 

H-15 (S. 59) Identifikation „vergleichbarer 

Funktionalitäten“ systematisieren 

H-16 (S. 59) Weiterentwicklung des Prozesses 

„Ableitung von Diensten aus 

Geschäftsprozessen“ 

Die betroffenen Akteure der IT-Steuerung Bund sowie der 

DLZ-IT des Bundes sollten als Rollen an den Prozessen 

der RA notiert werden, sodass ihre Mitwirkung in den 

jeweiligen Prozessen geklärt ist. 

Es sollte ein Gremium eingerichtet werden, das klar 

darüber entscheiden kann, ob Dienste ressortintern oder 

ressortübergreifend erbracht werden (Prozess Ableitung 

von Diensten aus Geschäftsprozessen). 

Es sollten klare Kriterien oder Leitfäden definiert werden, 

die den Vergleich von Funktionalitäten systematisieren und 

anleiten (Prozess Ableitung von Diensten aus Geschäftsprozessen). 

Der Prozess „Ableitung von Diensten aus Geschäftsprozessen“ 

sollten durch Elemente von COBIT & ITIL angereichert 

werden. 

Handlungsempfehlungen aus dem Untersuchungsbereich Organisatorische Aufbauelemente 

H-17 (S. 75) Rollenmodell auf Konsistenz und 

Kohärenz prüfen 

H-18 (S. 76) Rollenmodell der RA um weitere 

Rollen ergänzen 

Die Rollen und Gremien im Einflussbereich des Architekturmanagements 

sollten auf Überschneidungsfreiheit und 

Vollständigkeit ihrer Beschreibung geprüft werden. 

Das Rollenmodell sollte um die Rollen „Dienste- 

Verantwortlicher“, „Methodenverantwortlicher“, „Geschäftsarchitekt“, 

„Servicearchitekt“, „IT- 

Infrastrukturarchitekt“ und „Chief Architect“. 

H-19 (S. 76) Verantwortlichkeiten ergänzen Die Zuständigkeiten der einzelnen Rollen sollten durch ein 

klares Verantwortlichkeitskonzept ergänzt und präzisiert 

werden. 



Anhang B Grundlagen der Studie: Quellenangaben 30 

Die folgenden Dokumente bilden die Grundlage für die vorliegende Untersuchung. 

[Anlage1a] 

Abkürzung Quelle 

Auf- und Ausbau DLZ-IT des Bundes – Eckpunkte Prozesse Stufe 1, 

der Projektgruppe Umsetzung Auf- und Ausbau DLZ-IT des Bundes 

[Arbeitsteam] IT-Steuerung Bund, Projektgruppe „Rahmenarchitektur“, Arbeitsteam 

Grundlagen, Arbeitsteamsitzung, 15. September 2010, DRV Bund, 

Berlin, Fassung mit Änderungen aus der Sitzung, Präsentation. 

[Brussels] The Architecture Framework for Federal IT Governance SOA and EAM 

for German Federal Administration, Dr. Christian Mrugalla, German 

Federal Ministry of the Interior, Division Federal IT-Governance, Brussels, 

Feb 17, 2010, Service Oriented Architecture pushed to the limit in 

eGovernment, Präsentation. 

[COBIT] IT Governance Institute (Hrsg.) (2007): COBIT 4.1 - Control Objectives, 

Management Guidelines, Maturity Models, Rolling Meadows 

[COBIT-DE] IT Governance Institute (Hrsg.) (2005): COBIT 4.0 – Deutsche Ausgabe, 

Control Objectives, Management Guidelines, Maturity Models, 

Rolling Meadows (aus dem Original “COBIT 4.0 wurde im Original vom 

IT Governance Institute in englischer Sprache publiziert. Für die Übersetzung 

in die deutsche Sprache zeichnet KPMG Österreich in Wien 

verantwortlich. Die exklusive Genehmigung zur Übersetzung wurde 

vom IT Governance Institute erteilt”.) 

[Diskussionsgrundlage] Frank, U.; Strecker, S.; Heise, D.; Kattenstroth, H.: Vorläufiger Zwischenbericht 

(Diskussionsgrundlage) zur Wissenschaftlichen Untersuchung 

zur „Integration der COBIT und ITIL Standards mit der 

Rahmenarchitektur IT-Steuerung Bund“, Universität Duisburg-Essen. 

[DLZ-IT_Anlage] Anlage zum Beschluss Nr. 48/2010 des Rates der IT-Beauftragten, 

Abschlussbericht Stufe 1 der Projektgruppe Umsetzung Auf- und 

Ausbau DLZ-IT des Bundes 

[Grundlagen] Rahmenarchitektur IT-Steuerung Bund – Grundlagen, Soll- 

[Konzept] 

Beschreibung und Maßnahmen, Laufzeit: 30. Juni 2008 bis 31. Dezember 

2011. 

IT-Steuerung Bund - Konzept des Bundesministeriums des Innern und 

des Bundesministeriums der Finanzen 

[KoopA] Rahmenarchitektur IT-Steuerung Bund, Einen Schritt weiter…, Dr. 

Christian Mrugalla, BMI, Referat IT 2; KoopA ADV, Erfahrungsaustausch, 

Münster, Präsentation. 

[Metamodell] Metamodell zur RA, Version vom 11.11.2010, zur Verfügung gestellt 

von Dr. Andreas Gehlert im Kick-Off-Workshop zur vorliegenden 

Untersuchung 

[Methode] Rahmenarchitektur IT-Steuerung Bund - Methode zur Ableitung von 

Diensten aus Geschäftsprozessen, BMI, Referat IT 2. 

[Nachfragebündelung] Prozess – Zusammenwirken von IT-Angebot und IT-Nachfrage, Arbeitspapier 

der Projektgruppe Umsetzung Auf- und Ausbau DLZ-IT des 

Bundes. 

[Service Design] Office of Government Commerce (OGC) (2008): Service Design. TSO 

(The Stationery Office), London. 

[Continual Service 

Improvement] 

Office of Government Commerce (OGC) (2007): Continual Service 

Improvement. TSO (The Stationery Office), London. 

[Service Operation] Office of Government Commerce (OGC) (2007): Service Operation. 

TSO (The Stationery Office), London. 

[Service Strategy] Office of Government Commerce (OGC) (2007): Service Strategy. TSO 

(The Stationery Office), Norwich. 

Stand 

(Version) 

04.05.2010 

(V 1.0) 

17.09.2010 

17.02.2011 

11.11.2010 

V 1.0 

31.05.2010 

(V 1.0) 

20.06.2008 

(V 1.0) 

ohne Datum 

12.03.2010 

11.11.2010 

09.03.2010 

(V 1.0) 

08.12.2010 

(V 0.17) 

30 Die Beiden Quellen [Konzept] und [Umsetzungsplan] wurden im Kick-Off-Meeting ausgegrenzt. Daher werden 

sie bei der Rekonstruktion der RA nicht näher berücksichtigt. Da sie jedoch Hintergrundinformationen liefern 

werden sie hier der Vollständigkeit halber aufgeführt. 



Abkürzung Quelle 

[Service Transition] Office of Government Commerce (OGC) (2007): Service Transition. 

TSO (The Stationery Office), London. 

[Soll-Bebauungsplan] PLANUNGSINSTRUMENTE DER IT-STEUERUNG BUND, STRUK- 

TUR SOLL-BEBAUUNGSPLANUNG FÜR DIE RAHMENARCHITEK- 

TUR IT-STEUERUNG BUND. 

[Umsetzungsplan] Umsetzungsplan IT-Steuerung Bund, Soll-Beschreibung und Maßnahmen 

Laufzeit: 30. Juni 2008 bis 31. Dezember 2011. 

[Ziele] Ziele einer möglichen IT Strategie der Bundesverwaltung – Arbeitsstand. 

[Zielmodellierung] Dokumentation der Methoden der Rahmenarchitektur IT-Steuerung 

Bund – Zielmodellierung, Andreas Gehlert, BMI, Referat IT 2 

[Zwischenbericht] Frank, U.; Strecker, S.; Heise, D.; Kattenstroth, H.: Zwischenbericht zur 

Wissenschaftlichen Untersuchung zur „Integration der COBIT und ITIL 

Standards mit der Rahmenarchitektur IT-Steuerung Bund“, Universität 

Duisburg-Essen. 

Tabelle 8: Dokumente, die der Rekonstruktion der RA zugrunde liegen 

Stand 

(Version) 

15.07.2010 

(V 1.0) 

20.06.2008 

(V 1.0) 

13.10.2010 

V 0.2.8 

21.12.2010 

(1. Entwurf) 

07.12.2010 



Anhang C ITIL-Prozesse und ihre Zielsetzungen 

Die nachfolgende Auflistung repräsentiert das Ergebnis der Analyse der ITIL-Publikationen 

im Hinblick auf die Ziele, die zu den jeweiligen Prozessen entweder explizit genannt werden 

oder aus den Prozessbeschreibungen, den verwendeten Konzepten und den Richtlinien der 

Prozesse abgeleitet werden können. Grundlage der Analyse ist die Original-Dokumentation 

zu ITIL der OGC; zur Überprüfung der Zielanalyse wird unterstützend auf zusätzliche Fachliteratur, 

die zum Teil von der OGC und von internationalen und nationalen Interessensvertretungen 

wie dem itSMF geprüft und befürwortet ist, zurückgegriffen (z. B. von Bon 2009). 

ITIL-Publikation 


Effektivität 

ITIL-Prozess 

Service 

Catalogue 

Management 

Kurzbeschreibung Verfolgte Ziele 

Service Level 

Management 

Capacity 

Management 

Availability 

Management 

„Stellt sicher, dass ein Servicekatalog 

erstellt und gepflegt 

wird, der exakte 

Informationen zu allen operativen 

Services und zu den 

Services, deren operativer 

Betrieb vorbereitet wird, 

enthält“ 

Effizienz 





Stabilität 

Zielt auf die Unterstützung X X X X 

der Abstimmung (1) des 

Einsatzes von Services auf 

die Geschäftsprozesse und 

(2) der Service-Ziele auf die 

Anforderungen und Erwartung 

des Kunden 

„Verhandelt, vereinbart und Zielt auf die Abstimmung 

dokumentiert die geeigneten und Einhaltung der Service- 

IT Service Ziele mit Vertretern Ziele auf die Anforderungen 

des Business. Anschließend und Erwartung des Kunden 

wird die Fähigkeit des Service 

Providers zur Bereitstellung 

des vereinbarten Service 

Levels überwacht und entsprechende 

Berichte erstellt.“ 

„Stellt sicher, dass in allen Zielt auf die Sicherstellung 

Bereichen der IT stets zeitnah – mit Blick auf die Kapazität 

eine wirtschaftliche und auf –effizienter, stabiler und 

die vereinbarten aktuellen und zuverlässiger Services 

zukünftigen Business- 

Bedürfnisse abgestimmte IT- 

Kapazität verfügbar ist.“ 

„Stellt sicher, dass der Level Zielt auf die Sicherstellung 

an Serviceverfügbarkeit bei – mit Blick auf die Verfüg- 

allen Services unter Berückbarkeit – effizienter, stabiler 

sichtigung der Wirtschaftlich- und zuverlässiger Services 

keit die aktuell und zukünftig 

vereinbarten Business- 

Bedürfnisse erfüllt oder 

übertrifft.“ 

X X 

X X X 

X X X 

Optimierung 


Transparenz für IT-Spez. 

Sicherheit 

Kontinuität




Effektivität 

ITIL-Prozess Kurzbeschreibung Verfolgte Ziele 

IT Service „Stellt sicher, dass die erfor- Zielt auf die Gewährleis- 

Continuity derlichen technischen und tung der Kontinuität der IT- 

Management servicebasierten IT- Leistungserstellung 

Einrichtungen (einschließlich 

Computersystemen, Netzwerken, 

Anwendungen, Daten- 

Repositories, Telekommunikation, 

Umgebung, Technical 

Support und Service Desk) 

innerhalb des vom Business 

geforderten und mit ihm 

vereinbarten Zeitrahmens 

wieder voll einsatzfähig sind.“ 

Information 

Security 

Management 

Supplier 

Management 

Service 

Portfolio 

Management 

Demand 

Management 

Effizienz 



„Stimmt die IT-Sicherheit auf Zielt auf die Sicherstellung 

die Business-Sicherheit ab, der Sicherheit von Daten 

damit die Informationssicherheit 

für alle Service- und 

Service Management Aktivitäten 

effektiv verwaltet und 

gesteuert werden kann.“ 

„Verwaltet und steuert die Zielt auf die Sicherstellung X X 

Supplier und die von ihnen (1) effizienter sowie an (2) 

angebotenen Services, um Kundenerwartungen 

dem Business nahtlos IT ausgerichteter Fremd- 

Services hoher Qualität bei Services 

einem optimalen Kosten- 

Nutzen-Verhältnis zur Verfügung 

stellen zu können.“ 

Dieser Prozess dient der Zielt auf die Gestaltung des X X 

Bereitstellung eines Service- Service-Angebots auf die 

angebots in Form eines Bedürfnisse des Kunden 

Serviceportfolios, das sowohl 

den aktuellen als auch den 

zukünftigen Anforderungen 

der Kunden genügt. Dazu 

werden sowohl strategische 

als auch fachliche Anforderungen 

berücksichtigt. 

(keine offizielle Kurzbeschreibung 

vorhanden) 

Das Demand Management Zielt auf die Gestaltung des X X 

zielt auf Gestaltung des Service-Angebots auf die 

Service-Angebots in Abstim- Anforderungen und Erwarmung 

mit den Anforderungen tung des Kunden 

und Erwartung des Kunden. 

Dabei steht die kosteneffiziente 

und bedarfsgerechte 

Steuerung der Kapazität im 

Vordergrund. 


vorhanden) 



Stabilität 

Optimierung 



Sicherheit 

Kontinuität 

X 

X



Continual Service 

Improvement 


Effektivität 


Financial Das Financial Management Zielt auf die Sicherstellung 

Management stellt Informationen für das der Effizienz von Services 

wirtschaftliche und kosteneffektive 

Service Delivery zu 

Verfügung. Es stellt sich, dass 

Kosten für IT-Services transparent 

sind (keine offizielle 

Kurzbeschreibung vorhanden) 

(keine dedizierten Prozesse) 

Zielt auf die kontinuierliche 

Verbesserung von Zuverlässigkeit 

und Stabilität von 

Services 

Transition 

Planning and 

Support 

Change 

Management 

Service Asset 

& ConfigurationManagement 

Release and 

Deployment 

Management 

Service 

Validation and 

Testing 


vorhanden;) 

Zielt auf die Unterstützung 

der anderen Service 

Transition Prozesse (=kein 

Ziel) 

Dieser Prozess stellt sicher, Zielt auf die Sicherstellung, 

dass Änderungs- dass Änderungen (an 

Anforderungen an IT-Services Services, Komponenten 

(Infrastruktur, etc.) von Seiten etc.) kontrolliert gehand- 

des Business kontrolliert und habt werden 

effizient unter Minimierung von 

Risiken umgesetzt werden. 

Dazu sind standardisierte 

Verfahren zur Durchführung 

von Änderungen erforderlich. 


vorhanden) 

(keine offizielle Kurzbeschrei- Zielt auf die Bereitstellung 

bung vorhanden; Füllung folgt) von Informationen zu IT- 

Elementen und ihren 

Beziehungen untereinander 


vorhanden) 


vorhanden;) 

Evaluation (keine offizielle Kurzbeschreibung 

vorhanden;) 

Zielt auf die Sicherstellung, 

dass neue und geänderte 

Services (1) den Anforderungen 

entsprechen und (2) 

mit Implementierung die 

Zuverlässigkeit weiterhin 

gegeben ist 

Zielt auf die Sicherstellung, 

dass neue und geänderte 

Services die (1) vereinbarte 

Zuverlässigkeit aufweisen 

und (2) stabil sind 

Zielt auf die Prüfung der 

Performance nach einer 

Service-Änderung 

Effizienz 




X 


Stabilität 

X X X 

X 

X X 

X 

Optimierung 



X 

X 

Sicherheit 

Kontinuität



Service Operation 

Effektivität 


Knowledge (keine offizielle Kurzbeschrei- Zielt auf die Informations- 

Management bung vorhanden;) 

versorgung der Stakeholder 

in der IT-Organisation 

(=kein Ziel) 

Event Management 

Incident 

Management 

Problem 

Management 

Request 

Fulfilment 

Access Management 

„Das Event Management Zielt auf die Erfassung von 

überwacht alle Events, die in potenziell für das ITder 

gesamten IT-Infrastruktur Management 

auftreten, um den normalen Ereignissen 

relevanten 

Betrieb überwachen und 

Ausnahmebedingungen 

erkennen und eskalieren zu 

können.“ 

„Das Incident Management Zielt auf eine möglichst 

konzentriert sich auf die schnelle Wiederherstellung 

schnellstmögliche Wiederher- eines ungestörten ITstellung 

von unerwartet Betriebs 

beeinträchtigten oder unterbrochenen 

Services, um die 

Auswirkungen auf das Business 

zu minimieren.“ 

„Das Problem Management Zielt auf die (langfristige) 

umfasst: die Root Cause Sicherstellung eines (1) 

Analysis, um die Ursache für zuverlässigen und (2) 

Incidents zu ermitteln und zu stabilen IT-Betriebs 

lösen, proaktive Aktivitäten, 

um zukünftige Probleme/Incidents 

zu ermitteln und 

zu verhindern, und einen 

Known Error Teilprozess, um 

eine schnellere Diagnose und 

Lösung zu ermöglichen, für 

den Fall, dass weitere 

Incidents auftreten.“ 

„Das Request Fulfilment ist Zielt auf die Erfüllung 

der Prozess, bei dem Service kurzfristig erfüllbarer (nicht- 

Requests (Serviceanträge) – funktionaler)Anforderun- von denen viele kleinere gen 

Changes mit niedrigerem 

Risiko sind – behandelt 

werden.“ 

„Das Access Management ist Zielt auf die Sicherstellung 

der Prozess, bei dem autori- von autorisierten Servicesierten 

Anwendern das Recht Nutzungen 

zur Nutzung eines Service 

erteilt wird, während der 

Zugriff für nicht autorisierte 

Anwender verweigert wird.“ 

Tabelle 9: ITIL-Prozesse und ihre Zielsetzungen 

Effizienz 





Stabilität 

Optimierung 



X X X 

X X X 

X X 

X X 

Sicherheit 

Kontinuität 

X


Anhang D Grafischer Übersicht über ITIL-Prozesse 

Abbildung 23: Übersicht über ITIL-Prozesse (in Anlehnung an ITGI 2008, S. 20) 



Anhang E Ziele und Control Objectives der COBIT-Prozesse 

Die nachfolgende Auflistung repräsentiert das Ergebnis der Analyse der COBIT-Prozesse 

und der zugehörigen Control Objectives im Hinblick auf die Ziele, die zu den jeweiligen Prozessen 

explizit genannt werden. Grundlage der Analyse ist die Original-Dokumentation zu 

COBIT ([COBIT], [COBIT-DE]). 

Prozess 

Control 

Objective 

Name Ziele 

PO1 Define a strategic IT plan • Reagiere auf Geschäftsanforderungen in Überein- 

PO1.1 

PO1.2 

IT value management 

Business-IT alignment 

• 

stimmung mit der Unternehmensstrategie 

Reagiere auf Anforderungen der Governance 

entsprechend der Geschäftsführungsvorgaben 

PO1.3 Assessment of current capability 

and performance 

PO1.4 IT strategic plan 

PO1.5 IT tactical plans 

PO1.6 IT portfolio management 

PO2 Define the information architec- • Optimiere die Verwendung von Information 

ture 

• Integriere die Anwendungen und Technologielö- 

PO2.1 Enterprise information architecture 

model 

• 

sungen nahtlos in Geschäftsprozesse 

Reagiere auf Geschäftsanforderungen in Übereinstimmung 

mit der Unternehmensstrategie 

PO2.2 Enterprise data dictionary and data 

syntax rules 

• Stelle IT-Agilität her 

PO2.3 Data classification scheme 

PO2.4 Integrity management 

PO3 Define the technological archi- • Optimiere IT-Infrastruktur, Ressourcen und Fähigtecturekeiten 

PO3.1 Technological direction planning 

• Beschaffe und unterhalte integrierte und standardisierte 

Anwendungssysteme 

PO3.2 Technological infrastructure plan 

PO3.3 Monitor future trends and regulations 

PO3.4 Technology standards 

PO3.5 IT architecture board 

PO4 Define the IT processes, organi- • Reagiere auf Anforderungen der Governance 

sation and relationships 


PO4.1 IT process framework 

• Reagiere auf Geschäftsanforderungen in Übereinstimmung 


PO4.2 IT strategy committee 


PO4.3 IT steering committee 

PO4.4 Organisational placement of the IT 

function 

PO4.5 IT organisational structure 

PO4.6 Establishment of roles and responsibilities 

PO4.7 Responsibility for IT quality assurance 



Prozess 

Control 

Objective 

Name Ziele 

PO4.8 Responsibility for risk, security and 

compliance 

PO4.9 Data and system ownership 

PO4.10 Supervision 

PO4.11 Segregation of duties 

PO4.12 IT staffing 

PO4.13 Key IT personnel 

PO4.14 Contracted staff policies and 

procedures 

PO4.15 Relationships 

PO5 Manage the IT investment • Verbessere die Kosteneffizienz der IT und ihren 

PO5.1 Financial management framework 

Beitrag zum Unternehmenserfolg 

• Stelle Transparenz von und Verständnis für IT- 

PO5.2 Prioritisation within IT budget 

Kosten, Nutzen, Strategie, Richtlinien und Service 

PO5.3 

PO5.4 

IT budgeting 

Cost management 

Levels sicher 

• Stelle sicher, dass die IT eine kosteneffiziente 

Servicequalität, eine kontinuierliche Verbesserung 

PO5.5 Benefit management 

und Bereitschaft für zukünftige Veränderungen 

zeigt 

PO6 Communicate management aims 

and direction 

PO6.1 IT policy and control environment 

PO6.2 Enterprise IT risk and internal 

control framework 

PO6.3 IT policies management 

PO6.4 Policy, standard and procedures 

rollout 

PO6.5 Communication of IT objectives and 

direction 

• Stelle Transparenz von und Verständnis für IT- 


Levels sicher 

• Stelle sicher, dass automatischen Transaktionen 

und Informationsaustausch vertraut werden kann 

• Stelle den Schutz von kritischen und vertraulichen 

Informationen vor unberechtigtem Zugriff sicher 

• Stelle sicher, dass der Einfluss einer IT-Service- 

Störung oder -Änderung auf das Geschäft minimiert 

ist 

• Stelle die angemessene Verwendung und Performance 

der Anwendungen und technischen Lösungen 

sicher 

• Stelle sicher, dass IT-Services und Infrastruktur 

Ausfällen auf Grund von Fehlern, bewussten Angriffen 

oder Katastrophen standhalten können und 

ihre Wiederherstellung gewährleistet ist 

PO7 Manage IT human resources • Beschaffe und erhalte IT-Skills, die der IT- 

PO7.1 Personnel recruitment and retention 

Strategie entsprechen 


PO7.2 Personnel competencies 

PO7.3 Staffing of roles 

PO7.4 Personnel training 

PO7.5 Dependence upon individuals 

PO7.6 Personnel clearance procedures 

PO7.7 Employee job performance evaluation 

PO7.8 Job change and termination 

PO8 Manage Quality • Stelle die Enduser-Zufriedenheit mit den Service- 

PO8.1 Quality management system 

angeboten und Service Levels sicher 

• Reduziere Mängel und Nacharbeit bei Lösungen 

PO8.2 IT standards and quality practices und dem Servicebetrieb 

PO8.3 Development and acquisition 

standards 

• Setze Projekte pünktlich und im Budgetrahmen 

und unter Einhaltung der Qualitätsstandards um 



Prozess 

Control 

Objective 

Name Ziele 

PO8.4 Customer focus 

PO8.5 Continuous improvement 

PO8.6 Quality measurement, monitoring 

and review 

PO9 Assess and manage IT risks • Schütze die Erreichung der IT-Ziele 

PO9.1 IT risk management framework 

• Schaffe Klarheit über die Geschäftsauswirkungen 

der Risiken von IT-Zielen und -Ressourcen 

PO9.2 Establishment of risk context • Übernimm die Verantwortung für und schütze alle 

PO9.3 Event identification 

IT-Anlagen 

PO9.4 Risk assessment 

PO9.5 Risk response 

PO9.6 Maintenance and monitoring of a 

risk action plan 

PO10 Manage projects • Reagiere auf Geschäftsanforderungen in Überein- 

PO10.1 Programme management frameworkstimmung 


• Setze Projekte pünktlich und im Budgetrahmen, 

entsprechend der Qualitätsstandards um 

PO10.2 Project management framework • Reagiere auf Anforderungen der Governance 

PO10.3 Project management approach 


PO10.4 Stakeholder commitment 

PO10.5 Project scope statement 

PO10.6 Project phase initiation 

PO10.7 Integrated project plan 

PO10.8 Project resources 

PO10.9 Project risk management 

PO10.1 

0 

Project quality plan 

PO10.1 

1 

Project change control 

PO10.1 Project planning of assurance 

2 methods 

PO10.1 Project performance measurement, 

3 reporting and monitoring 

PO10.1 

4 

Project closure 

Tabelle 10: Ziele und Control Objectives der COBIT-Prozesse aus der Domäne „Plan and Organise“ (PO) 



Prozess 

Control 

Objective 

Name Ziele 

AI1 Identify automated solutions • Definiere, wie funktionale geschäftliche und 

Al1.1 Definition and maintenance of 

business functional and technical 

requirements 

Al1.2 Risk analysis report 

Al1.3 Feasibility study and formulation of 

alternative courses of action 

Al1.4 Requirements and feasibility 

decision and approval 

AI2 Acquire and maintain application 

software 

Al2.1 High-level design 

Al2.2 Detailed design 

Al2.3 Application control and auditability 

Al2.4 Application security and availability 

Al2.5 Configuration and implementation 

of acquired application software 

Al2.6 Major upgrades to existing systems 

Al2.7 Development of application software 

Al2.8 Software quality assurance 

Al2.9 Applications requirements management 

Al2.10 Application software maintenance 

AI3 Acquire and maintain technology 

infrastructure 

Al3.1 Technological infrastructure 

acquisition plan 

Al3.2 Infrastructure resource protection 

and availability 

Al3.3 Infrastructure maintenance 

Al3.4 Feasibility test environment 

Steuerungsanforderungen in wirksame und wirtschaftliche 

automatisierte Lösungen überführt 

werden. 



• Definiere, wie funktionale geschäftliche und 

Kontrollanforderungen in wirksame und wirtschaftliche 

automatisierte Lösungen überführt werden 


Anwendungssysteme 


IT-Infrastruktur 

• Optimiere IT-Infrastruktur, Ressourcen und 

Fähigkeiten 


AI4 Enable operation and use • Stelle die angemessene Verwendung und Per- 

Al4.1 Planning for operational solutions 

Al4.2 Knowledge transfer to business 

management 

Al4.3 Knowledge transfer to end users 

Al4.4 Knowledge transfer to operations 

and support staff 

formance der Anwendungen und technischen Lösungen 

sicher 

• Stelle die Enduser-Zufriedenheit mit den Serviceangeboten 

und Service Levels sicher 

• Integriere die Anwendungen und Technologielösungen 

nahtlos in Geschäftsprozesse 


und dem Servicebetrieb 

AI5 Procure IT resources • Beschaffe und warte integrierte und standardisier- 

Al5.1 

Al5.2 

Procurement control 

Supplier contract management 

• 

te Anwendungssysteme 

Beschaffe und warte integrierte und standardisierte 

IT-Infrastruktur 

Al5.3 Supplier selection 

• Beschaffe und erhalte IT-Skills, die der IT- 

Al5.4 Resources acquisition 


AI6 Manage Changes • Reagiere auf Geschäftsanforderungen in Über- 

Al6.1 Change standards and procedures 

Al6.2 Impact assessment, prioritisation 

and authorisation 

einstimmung mit der Unternehmensstrategie 






Prozess 

Control 

Objective 

Name Ziele 

Al6.3 Emergency changes Störung oder -Änderung auf das Geschäft mini- 

Al6.4 Change status tracking and reporting 

Al6.5 Change closure and documentation 

AI7 Install and accredit solutions 

and changes 

Prozess 

Al7.1 Training 

Al7.2 Test plan 

Al7.3 Implementation plan 

Al7.4 Test environment 

Al7.5 System and data conversion 

Al7.6 Testing of changes 

Al7.7 Final acceptance test 

Al7.8 Promotion to production 

Al7.9 Post-implementation review 

Control 

Objective 

miert ist 

• Definiere, wie funktionale geschäftliche und 

Steuerungsanforderungen in wirksame und wirtschaftliche 

automatisierte Lösungen überführt 

werden. 

• Erhalte die Integrität der Informationen und die 

diese Informationen verarbeitende Infrastruktur 







• Integriere die Anwendungen und Technologielösungen 

nahtlos in Geschäftsprozesse 



sicher 





Tabelle 11: Ziele und Control Objectives der COBIT-Prozesse aus der 

Domäne „Acquire and Implement“ (AI) 

DS1 Define and manage service 

levels 

DS1.1 Service level management framework 

DS1.2 Definition of services 

DS1.3 Service level agreements 

DS1.4 Operating level agreements 

DS1.5 Monitoring and reporting of service 

level achievements 

DS1.6 Review of service level agreements 

and contracts 

Name Ziele 





• Stelle Transparenz und Verständnis von IT- 


Levels sicher 

DS2 Manage third-party services • Stelle die gegenseitig zufriedenstellenden Liefe- 

DS2.1 Identification of all supplier relationships 

DS2.2 Supplier relationship management 

DS2.3 Supplier risk management 

DS2.4 Supplier performance monitoring 

DS3 Manage performance and capacity 

DS3.1 Performance and capacity planning 

DS3.2 Current performance and capacity 

DS3.3 Future performance and capacity 

DS3.4 IT resources availability 

rantenbeziehungen sicher 





Levels sicher 



• Stelle die Verfügbarkeit der IT-Services gemäß 

den Anforderungen sicher 

• Optimiere IT-Infrastruktur, Ressourcen und 

Fähigkeiten 



Prozess 

Control 

Objective 

DS3.5 Monitoring and reporting 

Name Ziele 

DS4 Ensure continuous service • Stelle die Verfügbarkeit der IT-Services gemäß 

DS4.1 IT continuity framework 

DS4.2 IT continuity plans 

DS4.3 Critical IT resources 

DS4.4 Maintenance of the IT continuity 

plan 

DS4.5 Testing of the IT continuity plan 

DS4.6 IT continuity plan training 

DS4.7 Distribution of the IT continuity plan 

DS4.8 IT services recovery and resumption 

DS4.9 Offsite backup storage 

DS4.10 Post-resumption review 




ist 


Ausfälle auf Grund von Fehlern, bewussten Angriffen 



DS5 Ensure systems security • Stelle den Schutz von kritischen und vertraulichen 

DS5.1 Management of IT security 

DS5.2 IT security plan 

DS5.3 Identity management 

DS5.4 User account management 

DS5.5 Security testing, surveillance and 

monitoring 

DS5.6 Security incident definition 

DS5.7 Protection of security technology 

DS5.8 Cryptographic key management 

DS5.9 Malicious software prevention, 

detection and correction 

DS5.10 Network security 

DS5.11 Exchange of sensitive data 




• Erhalte die Integrität der Informationen und die 

diese verarbeitende Infrastruktur 

• Übernimm die Verantwortung für und schütze alle 

IT-Anlagen 





DS6 Identify and allocate costs • Stelle Transparenz der und Verständnis von IT- 

DS6.1 

DS6.2 

Definition of services 

IT accounting 

• 


Levels sicher 

Verbessere die Kosteneffizienz der IT und ihren 

DS6.3 Cost modeling and charging 

Beitrag zum Unternehmenserfolg 

DS6.4 Cost model maintenance 

• Stelle sicher, dass die IT kosteneffiziente Servicequalität, 

eine kontinuierliche Verbesserung und 

Bereitschaft für zukünftige Veränderungen zeigt 

DS7 Educate and train users • Stelle die Enduser-Zufriedenheit mit den Service- 

DS7.1 

DS7.2 

Identification of education and 

training needs 

Delivery of training and education 

• 

angeboten und Service Levels sicher 

Stelle die angemessene Verwendung und Performance 


sicher 

DS7.3 Evaluation of training received • Optimiere IT-Infrastruktur, Ressourcen und 

Fähigkeiten 

DS8 Manage service desk and inci- • Stelle die Enduser-Zufriedenheit mit Serviceangedentsboten 


DS8.1 

DS8.2 

Service desk 

Registration of customer queries 



sicher 

DS8.3 Incident escalation 


DS8.4 Incident closure 


DS8.5 Reporting and trend analysis 



Prozess 

Control 

Objective 

Name Ziele 

DS9 Manage the configuration • Optimiere IT-Infrastruktur, Ressourcen und 

DS9.1 Configuration repository and 

baseline 

DS9.2 Identification and maintenance of 

configuration items 

DS9.3 Configuration integrity review 

Fähigkeiten 


IT-Anlagen 

DS10 Manage problems • Stelle die Enduser-Zufriedenheit mit Serviceange- 

DS10.1 Identification and classification of 

problems 

DS10.2 Problem tracking and resolution 

DS10.3 Problem closure 

DS10.4 Integration of configuration, incident 

and problem management 

boten und Service Levels sicher 



• Schütze die Erreichung der IT-Ziele 

DS11 Manage data • Optimiere die Verwendung von Informationen 

DS11.1 Business requirements for data 

management 

DS11.2 Storage and retention arrangements 

DS11.3 Media library management system 

DS11.4 Disposal 

DS11.5 Backup and restoration 

DS11.6 Security requirements for data 

management 

DS12 Manage the physical environment 

DS12.1 Site selection and layout 

DS12.2 Physical security measures 

DS12.3 Physical access 

DS12.4 Protection against environmental 

factors 

DS12.5 Physical facilities management 



• Stelle die IT-Compliance mit Gesetzen und 

Vorschriften sicher 









ist 


IT-Anlagen 

DS13 Manage operations • Stelle sicher, dass IT-Services und Infrastruktur 

DS13.1 Operations procedures and instructions 

DS13.2 Job scheduling 

DS13.3 IT infrastructure monitoring 

DS13.4 Sensitive documents and output 

devices 

DS13.5 Preventive maintenance for hardware 








Tabelle 12: Ziele und Control Objectives der COBIT-Prozesse aus der Domäne „Deliver and Support“ (DS) 



Prozess 

Control 

Objective 

ME1 Monitor and evaluate IT performance 

ME1.1 Monitoring approach 

ME1.2 Definition and collection of monitoring 

data 

ME1.3 Monitoring method 

ME1.4 Performance assessment 

ME1.5 Board and executive reporting 

ME1.6 Remedial actions 

ME2 Monitor and evaluate IT internal 

control 

ME2.1 Monitoring of internal control 

framework 

ME2.2 Supervisory review 

ME2.3 Control exceptions 

ME2.4 Control self-assessment 

ME2.5 Assurance of internal control 

ME2.6 Internal control at third parties 

ME2.7 Remedial actions 

ME3 Ensure compliance with external 

requirements 

ME3.1 Identification of external legal, 

regulatory and contractual compliance 

requirements 

ME3.2 Optimization of response to external 

requirements 

ME3.3 Evaluation of compliance with 

external requirements 

ME3.4 Positive assurance of compliance 

ME3.5 Integrated reporting 

Name Ziele 

• Reagiere auf Anforderungen der Governance 

entsprechend den Geschäftsführungsvorgaben 





und Bereitschaft für zukünftige Veränderungen 

zeigt 

• Stelle Transparenz und Verständnis von IT - 


Levels sicher 





• Schütze die Erreichung der IT-Ziele 

• Stelle die IT-Compliance mit Gesetzen und Vorschriften 

sicher 


IT-Anlagen 


sicher 

ME4 Provide IT governance • Reagiere auf Anforderungen der Governance 

ME4.1 Establishment of an IT governance 

framework 

ME4.2 Strategic alignment 

ME4.3 Value delivery 

ME4.4 Resource management 

ME4.5 Risk management 

ME4.6 Performance measurement 

ME4.7 Independent assurance 

entsprechend den Geschäftsführungsvorgaben 



Levels sicher 


sicher 



und Bereitschaft für zukünftige Veränderung zeigt 

Tabelle 13: Ziele und Control Objectives der COBIT-Prozesse aus der 

Domäne „Monitor and Evaluate“ (ME) 



Anhang F COBIT-Prozesse und abgeleitete Bezugsobjekte 

Die nachfolgende Tabelle gibt einen Überblick über die in den Aktivitäten der COBIT- 

Prozesse genannten und beschriebenen Bezugsobjekte. Dabei kann es sich um bspw. Modelle, 

Standards, Vorgehensweisen oder Rollen und Gremien handeln. Nähere Erläuterungen 

finden sich im Glossar in Anhang K. 

Prozess Aktivität Bezugsobjekt 

PO1 Verlinke Kerngeschäftsziele mit den IT Zielen 

Identifiziere kritische Abhängigkeiten und gegenwärtige 

Performance 

Erstelle einen strategischen IT-Plan. • Strategischer IT-Plan 

Erstelle einen taktischen IT-Plan. • Taktischer IT-Plan 

Analysiere Programm-Portfolios und manage Projekt- und • Programm-Portfolio 

Service Portfolios. 

• Projekt-Portfolio 

• Service-Portfolio 

PO2 Erstelle und unterhalte ein Modell für Unternehmensinformationen 

• Informationsmodell 

Erstelle und unterhalte ein unternehmensweites Data 

Dictionary 

• Data Dictionary 

Entwickle und unterhalte ein Datenklassifikationsschema 

Stelle Dateneignern Verfahren und Tools für die Klassifizierung 

von Informationssystemen zur Verfügung 

• Datenklassifikationsschema 

Verwende das Informationsmodell, das Data Dictionary • Informationsmodell 

und das Klassifizierungsschema, um optimierte Business • Data Dictionary 

Systeme zu planen 


PO3 Erstelle und unterhalte den technologischen Infrastrukturplan 

• Infrastrukturplan 

Erstelle und unterhalte Technologie-Standards • Technologie-Standard 

Veröffentliche Technologie-Standards 

Überwache die technologische Entwicklung 

Definiere die (zukünftige) (strategische) Verwendung 

neuer Technologien 

• Technologie-Standard 

PO4 Erstelle IT Organisationsstrukturen, inklusive Ausschüs- • IT-Organisationsstruktur 

sen und Verbindungen zu Stakeholdern und Anbietern (IT Organisational Structure) 

Designe das Framework für IT-Prozesse 

Identifiziere Systemeigner 

Identifiziere Dateneigner 

Erstelle und implementiere IT-Rollen und Verantwortlichkeiten, 

inklusive Beaufsichtigung und Funktionstrennung 


PO5 Unterhalte das Programm-Portfolio • Programm-Portfolio 

Unterhalte das Projekt-Portfolio • Projekt-Portfolio 

Unterhalte das Service-Portfolio 

Entwickle und unterhalte einen IT-Budgetierungsprozess 

Identifiziere, kommuniziere und monitore IT-Investitionen, 

Kosten und Wertbeiträge für das Unternehmen 


PO6 Etablieren und Führen einer IT-Kontrollumgebung und • Unternehmensweites IT- 

Frameworks 

Control-Framework 

Entwickeln und Unterhalten von IT-Richtlinien • IT-Richtlinie 




Kommunizieren des IT Control Framework sowie Ziele 

und Ausrichtung der IT 

PO7 Identifiziere IT-Fähigkeiten, Stellenbeschreibungen, 

Gehaltsstufen und Personalperformance-Benchmarks 

Befolge für IT relevante HR-Richtlinien und Verfahren 

(Rekrutierung, Anstellung, Hintergrund-Checks, Gehalt, 

Schulung, Beurteilung, Beförderung) 

• Unternehmensweites IT- 

Control-Framework 

• Personal-Richtlinie 

PO8 Definiere ein Qualitätsmanagementsystem • Qualitätsmanagementsystem 

Erstelle und unterhalte ein Qualitätsmanagementsystem • Qualitätsmanagementsystem 

Erstelle und kommuniziere Qualitätsstandards in der 

Organisation 

• Qualitätsstandard 

Erstelle und manage den Qualitätsplan für kontinuierliche 

Verbesserung 

Messe, überwache und überprüfe Compliance mit den 

Qualitätszielen 

• Qualitätsplan 

PO9 Bestimme die Ausrichtung des Risikomanagements (z. B. 

beurteile Risiken) 

Verstehe relevante strategische Geschäftsziele 

Verstehe relevante Ziele der Unternehmensprozesse 

Identifiziere interne IT-Ziele und stelle die Verbindung 

zum Risiko her 

Identifiziere Ereignisse, die mit Zielen zusammenhängen 

[manche sind business-orientiert (Geschäftsbereich ist A); 

manche sind IT-orientiert (IT ist A, Geschäftsbereich ist 

C)] 

Beurteile Risiken, die mit Ereignissen zusammenhängen 

Evaluiere die Risikoreaktion 

Priorisiere und plane Control-Aktivitäten 

Bewillige und stelle das Budget für Risikomaßnahmenpläne 

sicher 

• Risikomaßnahmeplan 

Unterhalte und überwache einen Risikomaßnahmenplan • Risikomaßnahmeplan 

PO10 Definiere ein Programm-/Portfolio-Management- 

Framework für IT-Investition 

Erstelle und unterhalte ein IT-Projekt-Management- 

Framework 

Erstelle und unterhalte ein IT-Projektüberwachungs-, - 

messungs- und -management-System 

Erstelle Projektaufträge, Termin-, Qualitäts-, Budget-, 

Kommunikations- und Risikomanagementpläne 

Stelle die Beteiligung und das Engagement der Projekt- 

Stakeholder sicher 

Stelle die wirksame Steuerung der Projekte und Projektänderungen 

sicher 

• Programm-Management- 

Framework 

• Portfolio-Management- 

Framework 

• IT-Projekt-Management- 

Framework 

• IT-Projekt- 

Überwachungssystem 


Messungssystem 


Managementsystem 

• Projektauftrag 

• Terminplan 


• Budgetplan 

• Kommunikationsplan 

• Risikomanagementplan 




Definiere und implementiere Methoden für die Projektkontrolle 

und Reviews 

AI1 Definiere funktionale und technische Geschäftsanforderungen 

Etabliere Prozesse für Integrität/Aktualität der Anforderungen 

Identifiziere, dokumentiere und analysiere das 

Geschäftsprozessrisiko 

Führe eine Machbarkeitsstudie und Auswirkungsanalyse 

der Umsetzung der vorgeschlagenen Geschäftsanforderungen 

Bewerte den IT-betrieblichen Nutzen der vorgeschlagenen 

Lösungen 

Bewerte den Unternehmensnutzen der vorgeschlagenen 

Lösungen 

Entwickle einen Prozess zur Freigabe der Anforderungen 

Genehmige und nimm vorgeschlagene Lösungen ab 

AI2 Überleitung von Unternehmensanforderungen in Grobdesign-Spezifikationen 

Vorbereitung detaillierter Design- und technischer Software-Spezifikation 

von Anwendungskontrollen innerhalb 

des Designs 

Anpassung und Implementierung beschaffter automatisierter 

Funktionalität 

Entwicklung formalisierter Methoden und Prozesse zum 

Management des Anwendungsentwicklungsprozesses 

Entwicklung eines Software-Qualitätssicherungsplans für 

das Projekt 

Verfolgung und Management von Anwendungsanforderungen 

Entwicklung eines Wartungsplans für Software- 

Anwendungen 

AI3 Definiere Beschaffungsverfahren/-prozesse 

Verhandle die Beschaffung und beschaffe die benötigte 

Infrastruktur von (akkreditierten) Lieferanten 

Definiere eine Strategie und plane die Wartung für 

Infrastruktur 

Konfiguriere Infrastrukturkomponenten 

AI4 Entwickle eine Strategie, um Lösung in den Betrieb zu 

übernehmen 

• Grobdesign-Spezifikation 

• Detaildesign-Spezifikation 

• Technische Software- 

Spezifikation 

• Software-Qualitätssicherungsplan 

• Wartungsplan 


Entwickle eine Wissenstransfer-Methodik • Wissenstransfer-Methodik 

Entwickle Verfahrenshandbücher für Endbenutzer • Verfahrenshandbuch 

Entwickle technische Supportdokumentation für Betriebsund 

Supportpersonal 

• Supportdokumentation 

Entwickle und halte Schulungen • Schulung 

Evaluiere die Resultate von Schulungen und verbessere 

die Dokumentation, wie erforderlich 


AI5 Entwickle IT-Beschaffungsrichtlinien und -verfahren, die 

mit Beschaffungsrichtlinien auf der Unternehmensebene 

übereinstimmen 

• IT-Beschaffungsrichtlinie 

Erstelle/unterhalte eine Liste akkreditierter Lieferanten 

Evaluiere und wähle Lieferanten durch einen Request for 

Proposal (RFP) Prozess 

• Lieferantenliste 




Entwickle Verträge, die die Interessen des Unternehmens 

schützen 

Beschaffe gemäß der entwickelten Verfahren 

AI6 Entwickle und implementiere einen Prozess für konsistente 

Aufzeichnung, Bewertung und Priorisierung der Change-Requests 

Bewerte die Auswirkungen und priorisiere Changes, die 

auf geschäftlichen Bedürfnissen basieren 

Stelle sicher, dass jeder Notfall und jede kritische Änderung 

den Genehmigungsprozess durchläuft 

• Change Request 

Autorisiere Changes 

Manage und leite die für Änderungen relevante Information 

weiter 


AI7 Erstelle und begutachte Implementierungspläne 

Definiere und begutachte eine Teststrategie (Eingangsund 

Ausgangskriterien) und eine Planungsmethode für 

die Testdurchführung 

• Implementierungsplan 

Erstelle und unterhalte ein Repository von Unternehmens- 

und technisch orientierten Anforderungen und 

Testfällen für akkreditierte Systeme 

Führe Übernahme- und Integrationstests in der Testumgebung 

durch 

Wende eine Testumgebung an und führe Abnahmetests 

durch 

Empfehle die Produktivstellung basierend auf vereinbarten 

Abnahmekriterien 

DS1 Erzeuge ein Framework für die Festlegung von IT- 

Services 

• Anforderungs-Repository 

• Testfall-Repository 

• Übernahmetest 

• Integrationstest 

• Abnahmetest 

• IT-Service-Framework 

Erstelle einen IT Service-Katalog • IT-Service-Katalog 

Definiere Service Level Agreements (SLAs) für kritische 

IT Services 

• SLA 

Definiere Operational Level Agreements (OLAs) entsprechend 

den SLAs 

Überwache und berichte über die end-to-end Service 

Level Performance 

• OLA 

Begutachte SLAs und Underpinning Contracts (externe 

Verträge) 

• SLA 

• Underpinning Contract 

Begutachte und aktualisiere den IT-Service-Katalog • IT-Service-Katalog 

Erstelle einen Verbesserungsplan für Services • Verbesserungsplan 

DS2 Identifiziere und kategorisiere Beziehungen zu Leistungen 

der Dritten 

Definiere und dokumentiere die Prozesse des 

Lieferantenmanagements 

Führe Richtlinien und Verfahren für die Beurteilung und 

Auswahl von Lieferanten ein 

• Katalog der Lieferanten 

Identifiziere, bewerte und reduziere lieferantenbezogene 

Risiken 

• Lieferanten-Risiken 

Überwache die Service Delivery der Lieferanten 

Evaluiere langfristige Ziele hinsichtlich der Lieferanten- 

Beziehungen für alle Stakeholder 

• Berichte über 

Prozessperformance 

DS3 Richte einen Planungsprozess für das Review der Per- • Performance- und 

formance und Kapazität von IT-Ressourcen ein 

Kapazitätsplan 




Begutachte aktuelle Performance und Kapazitäten der IT- 

Ressourcen 

Führe Prognosen zur Performance und Kapazität von IT- 

Ressourcen durch 

Führe Gap-Analysen zur Identifikation inkompatibler IT- 

Ressourcen durch 

Führe eine Notfallplanung für die mögliche Nichtverfügbarkeit 

der IT-Ressourcen durch 

Überwache und berichte laufend über die Verfügbarkeit, 

Performance und Kapazität der IT-Ressourcen 

• Notfallplan 

DS4 Entwickle ein Framework für die IT-Kontinuität 

Führe eine Business-Impact-Analyse und eine Risikobeurteilung 

durch 

• IT Continuity Framework 

Entwickle und unterhalte IT-Kontinuitätspläne 

Identifiziere und kategorisiere IT-Ressourcen nach deren 

Wiederherstellungszielen 

• IT-Kontinuitätsplan 

Definiere und wende Änderungskontrollverfahren an, um 

sicherzustellen, dass der IT-Kontinuitätsplan auf dem 

neuesten Stand ist 


Teste regelmäßig den IT-Kontinuitätsplan • IT-Kontinuitätsplan 

Entwickle einen Folgeplan basierend auf den Testergebnissen 

Plane und führe Trainings für den IT-Wiederanlauf durch 

Plane die Wiederherstellung und den Wiederanlauf von 

IT-Services 

Plane und implementiere Backup-Archivierung und - 

Sicherung 

Führe Verfahren für die Durchführung der Reviews nach 

dem Wiederanlauf ein 


DS5 Definiere und unterhalte einen IT-Sicherheitsplan 

Definiere, erstelle und führe einen Identity- (Benutzerkonten-)managementprozess 

aus 

• IT-Sicherheitsplan 

Überwache mögliche und wirkliche Security Incidents 

Begutachte und bestätige Benutzerzugriffsberechtigungen 

und –privilegien periodisch 

Erstelle und unterhalte Verfahren für die Wartung und 

den Schutz von kryptographischen Schlüsseln 

Implementiere und unterhalte technische Maßnahmen 

und Verfahren zum Schutz des Informationsflusses in 

Netzen 

Führe regelmäßig Verletzbarkeitsanalysen durch 

• Security Incident 

DS6 Mappe die IT-Infrastruktur auf die bereitgestellten 

Services/unterstützten Geschäftsprozesse 

Identifiziere alle IT-Kosten (Personen, Technologie, etc.) 

und bilde sie auf die IT-Services auf Basis der Stückkosten 

ab 

Etabliere und unterhalte einen IT-Rechnungswesen- und 

-Kostenkontrollprozess 

Etabliere und unterhalte Kosten-Policies und -Verfahren • Kosten-Policy 

DS7 Identifiziere und charakterisiere den Schulungsbedarf der 

BenutzerInnen 

Erstelle ein Schulungsprogramm • Schulungsprogramm 




Führe Awareness-, Ausbildungs- und Schulungsaktivitäten 

durch 

Führe eine Schulungsevaluation durch 

Identifiziere und evaluiere die besten Schulungsmethoden 

und -werkzeuge 

• Schulungsevaluation 

DS8 Erstelle Klassifikations- (Schweregrad und Auswirkung) 

und Eskalationsverfahren (funktional und hierarchisch) 

Erkenne und erfasse Incidents / Serviceanfragen / Informationsanfragen 

Klassifiziere, ermittle und diagnostiziere Anfragen 

• Incident 

Behebe, löse und schließe Incidents 

Informiere Benutzer (z. B. Statusaktualisierungen) 

• Incident 

Erstelle Managementauswertungen • Managementauswertung 

DS9 Entwickle Verfahren zur Planung des Konfigurationsmanagements 

Sammle erste Konfigurationsinformationen und erstelle 

Referenzkonfigurationen 

Verifiziere und prüfe Konfigurationsinformationen (einschließlich 

Nachweis von unerlaubter Software) 

• Referenzkonfiguration 

Aktualisiere das Konfigurations-Repository • Konfigurations-Repository 

DS10 Identifiziere und klassifiziere Probleme 

Führe Analysen zur Ermittlung der zu Grunde liegenden 

Ursachen durch 

Löse Probleme 

Verfolge den Status von Problemen 

Erarbeite Verbesserungsvorschläge und erstelle entsprechende 

Change Requests 


Führe Aufzeichnungen über Probleme • Problemaufzeichnung 

DS11 Übertrage Anforderungen bezüglich Datenspeicherung 

und -aufbewahrung in Verfahren 

Definiere, unterhalte und implementiere Verfahren zum 

Management von Medienbibliotheken 

Definiere, unterhalte und implementiere Verfahren zur 

sicheren Entsorgung von Datenträgern und Geräten 

Sichere Daten gemäß dem Schema 

Definiere, unterhalte und implementiere Verfahren zur 

Wiederherstellung von Daten 

• Medienbibliothek 

DS12 Definiere das erforderliche Niveau des physischen 

Schutzes 

Wähle und kommissioniere den Standort (Rechenzentrum, 

Büro, etc.) 

• Schutzniveau 

Implementiere physische Schutzmaßnahmen 

Manage die physische Umgebung (inklusive Wartung, 

Überwachung und Berichterstattung) 

Definiere und implementiere Verfahren für Autorisierung 

und Unterhalt des physischen Zutritts 

• Schutzmaßnahme 

DS13 Erstelle/modifiziere Verfahren des Betriebs (inkl. Handbücher, 

Checklisten, Schichtpläne, Übergabedokumentation, 

Eskalationsverfahren, etc.) 

Plane Workload und Batch Jobs 

Überwache die Infrastruktur und die Verarbeitung und 

löse Probleme 

• Workload 




Manage und schütze physischen Output (Papier, Medien, 

etc.) 

Implementiere Fixes und Changes am Zeitplan und an 

der Infrastruktur 

Implementiere/erstelle einen Prozess zur Absicherung 

der Authentifizierungsanlagen gegen Beeinflussung, 

Verlust und Diebstahl 

Plane und führe präventive Wartung durch 

• Zeitplan 

ME1 Entwickle den Monitoring Ansatz 

Identifiziere und sammle messbare Ziele, die Unternehmensziele 

unterstützen 

Erstelle Scorecards 

Beurteile Performance 

• Scorecard 

Reporte Performance 

Identifiziere und monitore Maßnahmen zur Verbesserung 

der Performance 

• Performance-Report 

ME2 Monitore und steuere IT Internal Control-Aktivitäten 

Monitore den Selbstbeurteilungsprozess 

Monitore die Leistungen unabhängiger Reviews, Audits 

und Prüfungen 

Monitore den Prozess zur Erlangung einer Bestätigung 

der von Dritten ausgeführten Controls 

Monitore den Prozess zur Identifikation und Beurteilung 

der Control-Ausnahmen 

Monitore den Prozess zur Identifikation und Beseitigung 

von Control-Ausnahmen 

Berichte den wesentlichen Stakeholdern • Report zur Wirksamkeit 

von IT-Controls 

ME3 Definiere einen Prozess zur Identifikation von Anforderungen 

aus Gesetzen, Verträgen, Richtlinien und sonstigen 

Regulativen und führe diesen aus 

Evaluiere Compliance der IT-Aktivitäten mit IT-Richtlinien, 

Standards und Verfahren 

Berichte die eindeutige Zusicherung, dass die IT- 

Aktivitäten mit IT-Richtlinien, Standards und Verfahren 

übereinstimmen 

Liefere Input zum Angleichen der IT-Richtlinien, Standards 

und Verfahren in Reaktion auf Compliance- 

Erfordernisse 

Integriere die IT-Berichterstattung über regulative Anforderungen 

mit ähnlichem Output von anderen Bereichen 

ME4 Ermögliche der Geschäftsführung die Beaufsichtigung 

und Erleichterung von Aktivitäten der IT 

Begutachte, befürworte, koordiniere und kommuniziere 

IT-Performance, IT-Strategie, Ressourcen und Risikomanagement 

im Einklang mit der Unternehmensstrategie 

Hole periodisch unabhängige Beurteilung von Performance 

und Compliance mit Richtlinien, Standards und 

Verfahren ein 

Löse Feststellungen von unabhängigen Beurteilungen 

und stelle die Umsetzung des Managements vereinbarter 

Maßnahmen sicher 

• Bericht zur Compliance 

der IT-Aktivitäten mit externen 

rechtlichen und regulatorischen 

Anforderungen 




Erstelle einen IT Governance Report • Bericht zum Status der IT- 

Governance 

Tabelle 14: COBIT-Prozesse und abgeleitete Bezugsobjekte 



Anhang G Abgeleitete Bezugsobjekte aus Control Objectives und 

Aktivitäten der COBIT-Prozesse 

Die nachfolgende Tabelle bietet eine aggregierte Übersicht über die in den Aktivitäten und 

Control Objectives von COBIT genannten Bezugsobjekte. Die Tabelle fasst demnach die 

Inhalte aus Anhang F zusammen und ergänzt sie um die Bezugsobjekte der Control 

Objectives. 

Prozess Name Bezugsobjekte 

PO1 Define a strategic IT plan • Strategischer IT-Plan 

• Taktischer IT-Plan 

• Portfolio IT-gestützter Investitionsprogramme 



• Programm-Portfolio 

PO2 Define the information architecture • Informationsarchitekturmodell 

• Data Dictionary 

• Datensyntaxregeln 


PO3 Define the technological architecture • Technischer Infrastrukturplan 

• Technologisches Forum 


PO4 Define the IT processes, organization 

and relationships 

• IT-Organisationsstruktur 

• Framework der IT-Prozesse 

• Rollenbeschreibungen 

• Kontaktplan des IT-Schlüsselpersonals 


PO5 Manage the IT investment • Framework für das Management von Finanzen 



• Programm-Portfolio 

PO6 Communicate management aims 

and direction 

• Unternehmensweites Framework für IT-Risiken 

und Internal Controls 

• Richtlinien zur Unterstützung der IT-Strategie 

PO7 Manage IT human resources • Anforderungen für IT-Kernkompetenzen 

• Einweisung 

• Schulung 

• Hintergrund-Checks 

• Personal-Richtlinie 

PO8 Manage Quality • Qualitätsmanagement-System 

• Qualitätsstandards 


• Entwicklungs-und Beschaffungsstandards 

PO9 Assess and manage IT risks • Unternehmensweites Risikomanagement-Modell 

• Framework für IT-Governance, Risikomanagement 

und Controls 

• Risikobeurteilungs-Framework 

• Risikomaßnahmeplan 




PO10 Manage projects • Programmmanagement-Framework 

• Portfolio-Management-Framework 

• IT-Projekt-Management-Framework 

• IT-Projekt-Überwachungssystem 

• IT-Projekt-Messungssystem 

• IT-Projekt-Managementsystem 


• Projektmanagement-Framework 

• Business-Case 

• Projekt-Qualitätsplan 

• Projekt-Governance-Framework 

• Integrierter Projektplan 

• Projektauftrag 

• Terminplan 


• Budgetplan 

• Kommunikationsplan 

• Risikomanagementplan 

AI1 Identify automated solutions • 

• 

Risikoanalyse-Bericht 

Machbarkeitsstudie 

• Qualitätsreview 

AI2 Acquire and maintain application 

software 

AI3 Acquire and maintain technology 

infrastructure 

• Grobe Designspezifikation 

• Detaillierte Designspezifikation 

• Technische Software-Anforderungen 

• Technische Software-Spezifikation 

• Sicherheits- und Verfügbarkeitsanforderungen 

• Datenklassifikation 

• Informationssicherheitsarchitektur 

• Entwicklungs- und Dokumentationsstandards 

• Change-Request 

• Softwarequalitätssicherungsplan 

• Wartungs- und Releaseplan 

• Beschaffungsplan für technologische Infrastruktur 



AI4 Enable operation and use • 

• 

Operativer Lösungsplan 

Trainingsplan 

• Wissenstransfer-Methodik 

• Verfahrenshandbuch 


• Schulung 

AI5 Procure IT resources • 

• 

Einkaufsstandards 

IT-Beschaffungsrichtlinie 

AI6 Manage Changes • 

• 

Change 

Change Request 

• Change-Standards 

• Notfall-Change 

• Nachverfolgungs- und Reportingsystem 

AI7 Install and accredit solutions and 

changes 

• Schulung 

• Testplan 


• Change 

• Anforderungs-Repository 

• Testfall-Repository 

DS1 Define and manage service levels • Service Level-Management-Framework 

• SLA 

• OLA 

• Service-Katalog 


• Underpinning Contract 

• Verbesserungsplan 




DS2 Manage third-party services • Formelle Dokumentation von Lieferantenbeziehungen 

und -leistungen 

• Lieferantenkatalog 

DS3 Manage performance and capacity • Kapazitätsplan 

• Performanceplan 


• Notfallplan 

DS4 Ensure continuous service • IT-Kontinuitäts-Framework 


• Change 

• Schulung 


DS5 Ensure systems security • IT-Security Plan 

• Sicherheitsrichtlinien 

• Security Incident 

DS6 Identify and allocate costs • Kostenmodell 

• Unternehmensweites System zur Messung von Finanzzahlen 

• Kosten-Policy 

DS7 Educate and train users • Schulungs-/Trainings-Curriculum 

• Schulungsprogramm 

DS8 Manage service desk and incidents • Service Desk 

• Incident 

• SLA 

• Change 

DS9 Manage the configuration • Configuration Item 

• Configuration Item Repository (Konfigurations- 

Repository) 

• Referenzkonfiguration 

DS10 Manage problems • Incident 

• Problemmanagementsystem 

• Configuration Item 

• Change 


• Known Error 

• RFC 

• SLA 

• Problemaufzeichnung 

DS11 Manage data • IT-Kontinuitätsplan 

• Medienbibliothek 

DS12 Manage the physical environment • 

• 

Technologiestrategie 

Incident 

• Schutzniveau 

DS13 Manage operations • 

• 

Betriebsprotokoll 

Zeitplan 

• Workload 

ME1 Monitor and evaluate IT performance 

ME2 Monitor and evaluate IT internal 

control 

ME3 Ensure compliance with external 

requirements 

• Monitoring-Framework 

• Unternehmensweites System zum Performance- 

Monitoring 


• Scorecard 

• Control Framework 

• Internal Controls 

• Change 

• SLA 

• Programm zur Selbstbeurteilung der Steuerung 





ME4 Provide IT governance • IT-Governance-Framework 



• Change 

• Business Case 

• IT-Risikomanagement-Plan 

Tabelle 15: Abgeleitete Bezugsobjekte aus den Control Objectives und Aktivitäten der COBIT-Prozesse 



Anhang H Verdichtete Ziele der COBIT-Prozesse 

Dieser Abschnitt bildet die Grundlage für die Untersuchung der Ziele, die mit den COBIT- 

Prozessen unterstützt werden sollen. Dazu werden die in den COBIT-Prozessen genannten 

Ziele erfasst und den Zielen der RA gegenübergestellt. Zusätzlich werden die Prozesse 

aufgelistet, für die das betrachtete Ziel zutrifft, d.h. in deren Beschreibungen das betrachtete 

Ziel genannt wird. 

Nr. Ziel Ziel der RA COBIT-Prozesse 

1 

2 

3 

Reagiere auf Geschäftsanforderungen in 

Übereinstimmung mit der Unternehmensstrategie) 

Reagiere auf Anforderungen der Governance 


Stelle die Enduser-Zufriedenheit mit den 

Serviceangeboten und Service Levels 

sicher 

Fachliche Integration, PO1, PO2, PO4, PO10, AI1, 

AI6, AI7, DS1, DS3, ME1 

- PO1, PO4, PO10, ME1, ME4 

Zuverlässigkeit PO8, AI4, DS1, DS2, DS7, 

DS8, DS10, DS13 

4 Optimiere die Verwendung von Information Interoperabilität, Sicherheit PO2, DS11 

5 Stelle IT-Agilität her Agilität PO2, PO4, PO7, AI3 

Definiere, wie funktionale geschäftliche Fachliche Integration AI1, AI2, AI6 

6 

und Steuerungsanforderungen in wirksame 

und wirtschaftliche automatisierte 

Lösungen überführt werden. 

7 

Beschaffe und warte integrierte und 

standardisierte Anwendungssysteme 

Standard-Komponenten und 

-Produkte nutzen 

PO3, AI2, AI5 

8 

Beschaffe und unterhalte integrierte und 

standardisierte IT-Infrastruktur 

Standard-Komponenten und 

-Produkte nutzen 

AI3, AI5 

9 

Beschaffe und erhalte IT-Skills, die der IT- 


- PO7, AI5 

10 

Sicherstellung gegenseitig zufriedenstellender 

Lieferantenbeziehungen 

- DS2 

Integriere die Anwendungen und Techno- Effektivität, fachliche Integ- PO2, AI4, AI7 

11 logielösungen nahtlos in die Geschäftsprozesseration, 

Stelle Transparenz und Verständnis von IT Effizienz, Reduzierung der PO5, PO6, DS1, DS2, DS6, 

12 -Kosten, Nutzen, Strategie, Richtlinien und 

Service Levels sicher 

Komplexität, 

ME1, ME4 

Stelle die angemessene Verwendung und Zuverlässigkeit, PO6, AI4, AI7, DS7, DS8 

13 Performanz von Anwendungen und 

technischen Lösungen sicher 

14 

Übernimm die Verantwortung für und 

schütze alle IT-Anlagen 

Sicherheit PO9, DS5, DS9, DS12, ME2 

15 

Optimiere IT-Infrastruktur, Ressourcen, 

Fähigkeiten 

Effizienz PO3, AI3, DS3, DS7, DS9 

16 

Reduziere Mängel und Nacharbeit bei 

Lösungen und dem Servicebetrieb 

Schneller IT-Service PO8, AI4, AI6, AI7, DS10 

17 Schütze die Erreichung der IT-Ziele Effektivität PO9, DS10, ME2 

Schaffe Klarheit über Geschäftsauswir- - PO9 

18 kungen der Risiken von IT-Zielen und - 

Ressourcen 



Nr. Ziel Ziel der RA COBIT-Prozesse 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

Stelle den Schutz von kritischen und 

vertraulichen Informationen vor unberechtigtem 

Zugriff sicher 

Stelle sicher, dass automatischen Transaktionen 

und Informationsaustausch 

vertraut werden kann 

Stelle sicher, dass IT-Services und Infrastruktur 

Ausfällen auf Grund von Fehlern, 

bewussten Angriffen oder Katastrophen 

standhalten können und ihre Wiederherstellung 

gewährleistet ist (Robustheit & 

Wiederherstellung) 

Stelle sicher, dass der Einfluss einer IT- 

Service-Störung oder -Änderung auf das 

Geschäft minimiert ist 

Stelle die Verfügbarkeit der IT-Services 

gemäß den Anforderungen sicher 

Verbessere die Kosteneffizienz der IT und 

ihren Beitrag zum Unternehmenserfolg 

Setze Projekte pünktlich und im Budgetrahmen 

und unter Einhaltung der Qualitätsstandards 

um 

Erhalte die Integrität der Informationen und 

die diese Informationen verarbeitende 

Infrastruktur 

Stelle die IT-Compliance mit Gesetzen und 

Vorschriften sicher 

Stelle sicher, dass die IT eine kosteneffiziente 

Servicequalität, eine kontinuierliche 

Verbesserung und Bereitschaft für zukünftige 

Veränderung zeigt 

Sicherheit PO6, DS5, DS11, DS12 

Sicherheit PO6, AI7, DS5 

Gewährleistung des Schutzbedarfs, 


Systeme, Schneller IT- 

Service 

Stabilität der IT-Systeme, 


PO6, AI7, DS4, DS5, DS12, 

DS13, ME2 

PO6, AI6, DS4, DS12 

Zuverlässigkeit, Handlungsfähigkeit 

DS3, DS4, DS8, DS13 

Effizienz PO5, DS6 

- PO8, PO10 

Sicherheit, Gewährleistung 

des Schutzbedarfs 

AI6, DS5 

Rechtskonformität, DS11, ME2, ME3, ME4 

Effizienz PO5, DS6, ME1, ME4 

Tabelle 16: Verdichtete Ziele der COBIT-Prozesse 



Anhang I Glossar zentraler Begriffe der RA 

Die nachfolgende Auflistung enthält ein bereinigtes Glossar mit zentralen Begriffen der RA 

und zugehörigen Definitionen, die entweder direkt aus der Dokumentation der RA entnommen 

wurden oder mit dem Bedarfsträger ermittelt wurden. 

Begriff Definitionen aus den Dokumenten Anmerkung 

Aktivität/Funktion Eine Aktivität bzw. Funktion innerhalb eines Prozesses ist 

eine Aktion oder Tätigkeit, die auf ein Ereignis folgt. In der 

Darstellung als Ereignisgesteuerte Prozesskette (EPK) 

werden Funktionen durch Rechtecke mit abgerundeten 

Kanten symbolisiert. 

Aktivitäten sind die kleinsten Aktionen, Tätigkeiten oder 

Handlungsanweisungen innerhalb eines Prozesses. Eine 

Aktivität kann mehrfach innerhalb eines Prozesses, aber 

auch in mehreren verschiedenen Prozessen enthalten sein. 

Anforderung Eine Anforderung nach IEEE ist: 

1) Eine Bedingung oder Fähigkeit, die von einem – 

Benutzer (Person oder System) zur Lösung eines 

Problems oder Erreichung eines Ziels benötigt wird. 

2) Eine Bedingung oder Fähigkeit, die ein System oder 

ein Teilsystem erfüllen oder besitzen muss, um einen 

Vertrag, eine Norm, eine Spezifikation oder andere 

formell vorgegebene Dokumente zu erfüllen. 

Basisdienst 

3) Eine dokumentierte Repräsentation einer Bedingung 

oder Eigenschaft gemäß 1) oder 2). 

Ein Basisdienst ist ein Dienst, der eine gemeinsame, 

übergreifende Grundlage für andere, darauf aufbauende 

Dienste (Fachdienst- und Querschnitts-dienst (QD)e) bildet. 

Der Basisdienst ist keiner einzelnen fachlichen Aufgabe 

direkt zugeordnet. 

Dienst Ein Dienst ist eine logische Einheit, die einen definierten 

Umfang an funktionalen Anforderungen erfüllt. Innerhalb der 

Rahmenarchitektur IT-Steuerung Bund stellt der Dienst eine 

Beschreibungseinheit zur Strukturierung der IT- 

Dienstedomäne 

Unterstützung für geschäftliche Anforderungen dar. 

Mehrere Diensteklassen werden im Dienstemodell (DM) zur 

besseren Auffindbarkeit und klareren Abgrenzung 

Dienstekatalog 

thematisch in Dienstedomänen zusammengefasst. Zwischen 

Dienstedomänen und Diensteklassen besteht folgende 

Beziehung: Dienstklassen ist Teil von Dienstedomäne. 

Ein Beispiel für eine Dienstedomäne wäre die Domäne „IT- 

Sicherheit“. 

Aus funktionaler Sicht wird die Darstellung der Dienste des 

Dienstemodells (DM)s im sog. Dienstekatalog weiter 

detailliert. Dort finden sich Dienste, die bereits in IT- 

Lösungen umgesetzt wurden, sich in Umsetzung befinden 

oder für die konkrete (Termin-)Planungen zu IT- 

Realisierungen existieren. Ihre Beschreibungen entsprechen 

denen von fachlichen Spezifikationen (Pflichtenheft) und 

können direkt zur Erstellung der technischen Spezifikationen 

verwendet werden. Diese wiederum sind Teil der 

Dokumentation des Technischen Modells (TM). Die Menge 

der im Dienstekatalog enthaltenen Dienste ist eine 

Untermenge derer des Dienstemodell (DM)s. 

Diese Begriffe sind deutlich 

voneinander abzugrenzen. 

Funktionsmodellierung vs. 

Geschäftsprozessmodellierun 

g. 

Statische vs. dynamische 

Abstraktion. 




Diensteklasse Mehrere Dienste werden im Dienstemodell zur besseren 

Auffindbarkeit und Verwaltung zahlreicher Dienste zu 

Diensteklassen zusammengefasst. Diese Diensteklassen 

werden in einem zweiten Schritt zu Dienstedomänen 

gruppiert. 

Innerhalb der Domäne „IT-Sicherheit“ bilden 

Verschlüsslungsdienste eine relevante Diensteklasse. 

Dienstemodell 

(DM) 

Diensterealisierung, 

IT-Realisierung 

von Diensten, 

Service 

Das Dienstemodell stellt in der Rahmenarchitektur IT- 

Steuerung Bund eine strukturierte Darstellung von 

Fachdienst-, Querschnittsdienst (QD)- und Basisdiensten auf 

einer funktionalen, logischen Ebene dar. 

Insbesondere enthält das Dienstemodell auch solche 

Dienste, die aus architektonischer Sicht wichtig sind, aber 

derzeit noch nicht realisiert werden sollen oder können. 

Solche Dienste sind ggf. auch noch unvollständig 

dokumentiert und damit (noch) nicht für die Zielgruppe der 

fachlichen IT-Nachfrager geeignet. 

Das Dienstemodell ist „Vermittler“ zwischen den im 

Geschäftlichen Modell (GM) dargestellten Aufgaben und den 

technischen Lösungen. Hier wird das IT-Angebot auf einer 

logischen, konzeptionellen Ebene strukturiert. Dabei werden 

analog zum Geschäftlichen Modell (GM) Fachdienst- und 

Querschnittsdienste (QD) unterschieden. Als weitere 

Kategorie werden Basisdienste dargestellt. Diese bilden eine 

gemeinsame, übergreifende Grundlage für andere, darauf 

aufbauende Dienste (Fachdienst- und Querschnitts-dienst 

(QD)e). Ein Basisdienst ist keiner fachlichen Aufgabe direkt 

zugeordnet. 

Eine Diensterealisierung setzt einen oder mehrere Dienste 

des Dienstemodells (DM) mittels IT um. Diensterealisierungen 

werden im Technischen Modell (TM) in Form von 

IT-Lösungen bzw. IT-Komponenten beschrieben. Dabei ist 

zu beachten, dass IT-Lösungen und IT-Komponenten auch 

mehrere Diensterealisierungen anbieten können. 

Fachdienst Ein Fachdienst ist ein Dienst, der direkt der Erfüllung einer 

speziellen Fachaufgabe dient. 

Funktionalität Eine Funktionalität beschreibt eine definierte Fähigkeit eines 

Dienstes, eine bestimmte (Teil-)Aufgabe zu lösen. 

So besteht beispielsweise der Content Management Dienst 

u. a. aus den Funktionalitäten „Content anlegen“, „Content 

ändern“ und „Content löschen“. 

Geschäftliches 

Modell (GM) 

Funktionalitäten sind die kleinsten durch IT zu 

unterstützenden fachlichen Funktionen oder 

Handlungsanweisungen innerhalb eines Dienstes. Ein Dienst 

besteht aus thematisch sinnvoll zusammengefassten 

Funktionalitäten. 

Das Geschäftliche Modell stellt in der Rahmenarchitektur IT- 

Steuerung Bund eine strukturierte Darstellung der 

geschäftlichen Aufgaben nach Geschäftsfeldern sowie der 

geschäftlichen Prozesse und deren Teilprozesse, die zur 

Erfüllung von Aufgaben benötigt werden und die mit IT zu 

unterstützen sind, dar. 

Das Geschäftliche Modell liefert eine Strukturierung der 

Fach- und Querschnittsaufgaben der Bundesverwaltung. 

Diese Darstellung kann mit der Beschreibung der Nachfrage 

in Zusammenhang gebracht werden. Hieraus können 

Konsequenzen für das IT-Angebot abgeleitet werden. Es ist 

eine enge Kooperation mit dem Ausschuss für 

Organisationsfragen erforderlich. 

Im Dienstekatalog sind alle 

Dienste – realisierte wie 

geplante – festgehalten. Das 

Dienstemodell müsste 

demnach weitere, darüber 

hinausgehende Dienste 

enthalten. Welche sollen das 

sein? 

Der Begriff der 

„Funktionalität“ ist nicht 

eindeutig definiert; bietet ein 

Dienst Funktionalitäten an 

oder besteht er aus 

Funktionalitäten (wer 

„generiert“ dann die F.?)? 

Wieso die „kleinsten“ 

(Definition ist zirkulär – 

„Funktionalitäten sind 

Funktionen“). 




Geschäftsprozess Ein Geschäftsprozess ist eine Beschreibung der logischen 

Abfolge von Funktionen bzw. Aktivitäten. 

Dabei können: 

• verschiedene Personen 

• an verschiedenen Orten 

• unter Verwendung verschiedener Materialen 

• und / oder Informationen 

und / oder Systemen beteiligt sein. 

Informationsmodell 

(IM) 

Das Informationsmodell stellt in der Rahmenarchitektur IT- 

Steuerung Bund eine Beschreibung der semantischen 

Standardisierung für den übergreifenden Austausch von 

Daten dar. 

Das Informationsmodell dient der Festlegung von 

IT-Angebot 

vereinheitlichten Strukturen für den Informationsaustausch 

zwischen Kommunikationspartnern. Es bildet daher die 

wesentliche Grundlage für Interoperabilität von IT-Lösungen. 

Das IT-Angebot umfasst sämtliche von internen wie externen 

IT-Dienstleistern erbrachte IT-Leistungen. 

IT-Architektur Die IT-Architektur beschreibt den Rahmen und die grobe 

Struktur des technischen Modells und des 

Informationsmodells. Sie präzisiert damit die 

Geschäftsarchitektur in Richtung IT und ist Bestandteil der 

Unternehmensarchitektur. Die IT-Architektur wird von den IT 

Dienstleistungszentren des Bundes zunächst separat 

aufgebaut, sodass es eine IT-Architektur des Bundes 

mittelfristig nicht gibt. 

IT-Dienstleistungszentrum 

(DLZ IT) 

IT-Dienstleistungszentren stellen ein IT-Angebot für die IT- 

Nachfrage bereit. Ziel ist die Bereitstellung von IT-Leistungen 

mit hoher Wirtschaftlichkeit und Servicequalität für einzelne 

Ressorts wie auch ressortübergreifend. 

IT-Leistung IT-Leistung umfasst alle von internen wie externen IT- 

Dienstleistern erbrachte informationstechnische 

Unterstützung der Aufgaben der öffentlichen Verwaltung (IT- 

Angebot). Sie enthält einerseits alle ressortspezifischen IT- 

Leistungen wie Planung/Konzeption, Entwicklung/Wartung 

und Betrieb von IT-Systemen sowie den damit verbundenen 

Support als auch alle ressortübergreifend nachgefragten IT- 

Leistungen (Basis-IT und Querschnitts-IT). 

IT-Lösung 

Eine IT-Leistung besteht aus einer Kombination von 

Personen, Prozessen und IT-Lösungen. Eine IT-Leistung 

wird zwischen einem Anbieter und einem Nachfrager durch 

eine verbindliche Vereinbarung über die Leistungsqualität 

definiert. 

Eine IT-Lösung stellt die informationstechnische Realisierung 

eines definierten Leistungsumfangs an IT-Unterstützung 

durch ein (technisches) System dar. In der 

Rahmenarchitektur stellt eine IT-Lösung einen oder mehrere 

Dienste technisch bereit. 

Diese Definition basiert auf dem Begriff „System“ aus DIN 

EN ISO 1941100 00009, (6). 

Zentraler Begriff; nicht explizit 

in Glossar aufgeführt; nicht 

näher erläutert; gleichzeitig 

durchaus unterschiedliche 

Begriffsauslegungen 

denkbar; wird insgesamt zu 

undifferenziert benutzt. 

wichtige Abstraktion; keine 

nähere Erläuterung; evtl. 

anhand von Beispielen 

illustrieren 

Einordnung in 

Rahmenarchitektur fehlt 

ebenso wie Abgrenzung vom 

Begriff 

Unternehmensarchitektur. 

Wie grenzen sich IT-Leistung 

und IT-Angebot voneinander 

ab? 

Wie grenzen sich Dienst und 

IT-Leistung voneinander ab? 

Insgesamt scheint der Begriff 

der IT-Leistung sich bisher 

unklar in die 

Gesamtkonzeption der RA 

einzuordnen, da die 

Abgrenzung des Begriffs zu 

allen anderen begriffen 

unklar bleibt. 




IT-Komponente Eine IT-Komponente stellt einen definierten, meist 

wiederverwendbaren Teil einer IT-Lösung dar, die mit 

anderen IT-Komponenten interagiert. IT-Komponenten 

IT-Maßnahme 

können sowohl Software als auch Hardware sein. 

Eine IT-Maßnahme ist entweder ein IT-Vorhaben oder ein IT- 

Verfahren. Ein IT-Verfahren ist die Weiterentwicklung einer 

existierenden IT-Lösung. Ein IT-Vorhaben ist die Entwicklung 

einer neuen IT-Lösung. 

Wie ordnet sich der mehrfach 

erwähnte Begriff „IT-System“ 

hierzu ein? 

IT-Nachfrage 

IT-Maßnahmen werden im IT-Rahmenkonzept des Bundes 

gesammelt, konsolidiert und verwaltet. 

IT-Nachfrage bezeichnet den von den Ressorts benannten 

und/oder beauftragten Bedarf nach IT-Lösungen bzw. dem 

IT-Angebot. Die IT-Nachfrage wird innerhalb der Ressorts 

von den IT-Beauftragten der Ressorts in eigener 

Verantwortung 

koordiniert. 

und ressortübergreifend vom IT-Rat 

IT-Produkt Synonym zu IT-Lösung 

IT-System Zentraler Begriff ohne 

explizite Abgrenzung vom 

Begriff „Standard“ 

IT-Vorhaben Ein IT-Vorhaben ist die Neuentwicklung einer IT-Lösung. Ein 

IT-Vorhaben ist eine spezielle IT-Maßnahme. 

Querschnittsdienst 

(QD) 

Rahmenarchitektur 

IT- 

Steuerung Bund 

Ein Querschnitts-Dienst ist ein Dienst, der eine 

querschnittliche, in unterschiedlichen Verwaltungseinheiten 

stets in ähnlicher oder gleicher Form anfallende Aufgabe 

unterstützt (z. B. Personalwesen). 

Die Rahmenarchitektur IT-Steuerung Bund ist eine 

übergreifende Modell-basierte Darstellung des Ist-Zustandes 

und des Soll-Bebauungsplans für die IT der 

Bundesverwaltung. Ihr liegt ein definiertes Metamodell 

zugrunde. 

Die vom Rat der IT-Beauftragten des Bundes beschlossene 

Rahmenarchitektur IT-Steuerung Bund definiert 

ressortübergreifend ein gemeinsames Architekturverständnis 

für die Bundesverwaltung. Dieses beinhaltet insbesondere 

Planungsinstrumente für die Fortentwicklung der zentral 

gesteuerten IT-Systeme des Bundes. Eine der strategischen 

Maßnahmen des Konzepts IT-Steuerung Bund ist die 

Trennung von Nachfrage und Angebot. Dies wird durch die 

Einführung logischer Dienste in einem Dienstemodell (DM) 

unterstützt, das als Zwischenschicht zwischen geschäftlicher 

und technischer Ebene fungiert. Eine Schlüsselaufgabe beim 

Design oder Redesign von IT stellt dabei das Erkennen und 

Definieren von allgemein nutzbaren Diensten dar. Dadurch 

sollen sowohl Redundanzen als auch Lücken im IT-Angebot 

vermieden werden. Für die Entwicklung und 

Implementierung von IT-Lösungen ist die Identifikation von 

nutzbaren Diensten aus dem übergreifenden IT-Angebot von 

besonderer Bedeutung. Dazu dienen das Dienstemodell 

(DM) und der Dienstekatalog als Basis. 

Die Rahmenarchitektur IT-Steuerung Bund stellt ein 

ganzheitliches Modell dar, das nicht nur die Beschreibung 

der IT umfasst, sondern auch alle Bereiche berücksichtigt, 

die direkten Wechselwirkungen mit der IT besitzen. Sie 

verwendet dazu fünf Modellbereiche für eine übergreifende 

IT-Planung und -Steuerung. 

Unklare Definition (Folge von 

unklarem Begriff „IT- 

Leistung“). 




Soll- 

Bebauungsplan 

Technisches 

Modell (TM ) 

Unternehmensarchitektur 

Ein Soll-Bebauungsplan in der IT zeigt i.A. die Nutzung 

verschiedener IT-Lösungen für verschiedene Zeiträume 

durch die einzelnen Einheiten einer Organisation. In der 

Rahmenarchitektur ist speziell die gemeinsame Nutzung von 

Diensten in Form von IT-Lösungen innerhalb der 

Bundesverwaltung beschrieben. Der Soll-Bebauungsplan 

stellt dar: 

• durch welche Eigenschaften ein langfristig angestrebter 

Soll-Zustand der IT der Bundesverwaltung 

• 

gekennzeichnet ist, 

welche Querschnitts-dienst (QD)- (und später auch 

Fachdienst-)dienste zur Unterstützung welcher 

Aufgaben als (ressortübergreifende) IT-Lösungen 

• 

realisiert werden sollen, 

wie die zu realisierenden Dienste strukturiert und unter 

Nutzung von Basisdiensten aufgebaut sein sollten. 

Der Soll-Bebauungsplan stellt das zentrale Instrument für die 

Darstellung künftiger Zustände der IT der Bundesverwaltung 

und für die Planung der Transformation vom Ist- in einen 

langfristig avisierten Soll-Zustand dar. Darüber hinaus 

enthält der Soll-Bebauungsplan kurz- bis mittelfristig 

vorgesehene Zwischenzustände, die Meilensteine für die 

schrittweise Annäherung an den Soll-Zustand darstellen. 

Das Technische Modell definiert in der Rahmenarchitektur 

IT-Steuerung Bund technische Mittel zur Bereitstellung von 

Diensten, wie Software-Komponenten, IT-Lösungen und 

Standards. 

Im Technischen Modell werden konkrete IT-Lösungen, IT- 

Komponenten sowie die anzuwendenden Standards 

dargestellt. Weiterhin wird die dabei genutzte Basis- 

Infrastruktur der Bundesverwaltung beschrieben. 

Die Unternehmensarchitektur beschreibt den Rahmen und 

die grobe Struktur aller Modellebenen der RA, also das 

geschäftliche Modell (detailliert in der Geschäftsarchitektur), 

das Dienstemodell, das technische Modell und das 

Informationsmodell (die letzen beiden Modelle sind in der IT- 

Architektur dokumentiert). 

Ziel 

Zielemodell (ZM) Das Zielemodell stellt in der Rahmenarchitektur IT- 

Steuerung Bund Ziele, strukturiert nach Zielfeldern, sowie 

geeignete Kenngrößen für die Ziel-Erreichung dar. 

Das Zielemodell (ZM) dient der strukturierten Darstellung von 

Zielen, sowohl aus geschäftlicher wie auch aus IT-Sicht. 

Weiterhin enthält es Messgrößen und Kennzahlen zur 

Definition und Kontrolle von Zielwerten. 

Tabelle 17: Glossar zentraler Begriffe der RA 

Es wird von „Referenzmodell 

(„Frameworks“) gesprochen, 

ohne dass klar ist, was 

hiermit gemeint ist. 

Vermutlich soll der 

Referenzcharakter 

hervorgehoben werden. 

Zentraler Begriff; vermutlich 

handelt es sich um 


Maßnahmen wie 

Stelleneinrichtungen und die 

Vorgabe von Richtlinien etc.; 

ist zu klären. 

Zentraler Begriff; explizite 

Definition fehlt; keine 

Erwähnung in Glossar; Ziel 

im Kontext der RA 

mehrdeutig verwendet: Ziele 

der ITSB, Ziele der RA, Ziele 

prospektiver Anwender, 



Anhang J Glossar zentraler Begriffe der ITIL 

Die nachfolgende Auflistung enthält ein bereinigtes Glossar mit zentralen Begriffen der ITIL 

und zugehörigen Definitionen, die entweder direkt aus der Dokumentation (bspw. vorhandenen 

Glossaren) der ITIL entnommen oder aus ihr rekonstruiert wurden. Dies wird durch 

einzelne Anmerkungen mit Hinweisen ergänzt. 

Begriff Definition Anmerkung 

Aktivität Eine Gruppe von Aktionen, anhand derer ein bestimmtes 

Ergebnis erzielt werden soll. Aktivitäten werden in der Regel 

als Teil von Prozessen oder Plänen definiert und als Verfahren 

dokumentiert. 

Anforderung Die formale Formulierung dessen, was benötigt wird. Zum 

Beispiel eine Service Level Anforderung, eine Projektanforderung 

oder die Anforderung der erforderlichen Lieferergebnisse 

für einen Prozess. 

Anwendung Software, die die von einem IT Service benötigten Funktionen 

bereitstellt. Jede Anwendung kann Teil eines oder mehrerer 

IT Services sein. Eine Anwendung wird auf einem oder 

mehreren Servern oder Clients ausgeführt. 

Asset Bezeichnung für jedwede Ressource oder Fähigkeit. Die 

Assets eines Service Providers umfassen alle Elemente, die 

zur Erbringung eines Service beitragen können. Assets 

können folgende Typen einschließen: Management, Organisation, 

Prozess, Wissen, Mitarbeiter, Information, Anwendungen, 

Infrastruktur und finanzielles Kapital. 

Business-Prozess Ein Prozess, für den das Business verantwortlich ist und der 

vom Business ausgeführt wird. Ein Business-Prozess ist an 

der Bereitstellung eines Produkts oder eines Service für 

einen Business-Kunden beteiligt. Für einen Händler kann 

beispielsweise ein Einkaufsprozess definiert sein, über den 

die Bereitstellung von Services für seine Business-Kunden 

unterstützt wird. Viele Business-Prozesse basieren auf IT 

Services. 

Core Service Ein IT Service, der die grundlegenden, von einem oder 

mehreren Kunden gewünschten Ergebnisse liefert. 

Daten 

Die Abgrenzung zwischen 

Core Service und IT Service 

bleibt unklar. Es wird davon 

ausgegangen, dass es sich 

bei Core Service, unterstützendem 

Service und IT 

Service ähnlich verhält wie 

mit Dienst, Fach-Dienst und 

Basis-Diensten bei der RA. 




Funktion Ein Team oder eine Gruppe von Personen und die Hilfsmittel, 

die eingesetzt werden, um einen oder mehrere Prozesse 

oder Aktivitäten durchzuführen. Ein Beispiel dafür ist das 

Service Desk. Der Begriff „Funktion“ hat darüber hinaus zwei 

weitere Bedeutungen: 

• Zweck, der mit einem Configuration Item, einer Person, 

einem Team, einem Prozess oder einem IT Service verfolgt 

wird. Eine Funktion kann beispielsweise das Speichern 

und Weiterleiten ausgehender E-Mails sein, und 

eine Funktion eines Business-Prozesses kann die Verteilung 

von Waren an Kunden beinhalten. 

• Korrekte Ausführung in Bezug auf den beabsichtigen 

Zweck („Der Computer funktioniert“). 

IT-Infrastruktur Die Gesamtheit der Hardware, Software, Netzwerke, Anlagen 

etc., die für die Entwicklung, Tests, die Bereitstellung, das 

Monitoring, die Steuerung oder den Support von IT Services 

erforderlich sind. Der Begriff „IT-Infrastruktur“ umfasst die 

gesamte Informationstechnologie, nicht jedoch die zugehörigen 

Mitarbeiter, Prozesse und Dokumentationen. 

Komponente Ein allgemeiner Begriff für einen Teil eines komplexeren 

Elements. Beispielsweise ein Computersystem kann eine 

Komponente eines IT Service sein, eine Anwendung eine 

Komponente eines Release Unit. Bei Komponenten, die 

verwaltet werden müssen, handelt es sich um Configuration 

Items. 

Operational Level 

Agreement (OLA) 

Eine Vereinbarung zwischen einem IT Service Provider und 

einem anderen Teil derselben Organisation. Ein OLA unterstützt 

die Bereitstellung von IT Services durch den IT Service 

Provider für den Kunden. Das OLA definiert die zu liefernden 

Waren oder Services und die Verantwortlichkeiten der beiden 

Parteien. Ein OLA könnte beispielsweise bestehen zwischen: 

• dem IT Service Provider und einer Einkaufsabteilung, um 

Hardware innerhalb vereinbarter Zeitspannen zu erhalten 

• dem Service Desk und einer Support-Gruppe, um eine 

Incident-Lösung innerhalb der vereinbarten Zeit zu erreichen. 

Produkt 

Ressource Ein allgemeiner Begriff, der die IT-Infrastruktur, Personen, 

Geld oder andere Elemente umfasst, die zur Erbringung 

eines IT Service beitragen können. Ressourcen werden als 

Assets einer Organisation betrachtet. 

Service Eine Möglichkeit einen Mehrwert für Kunden zu erbringen, 

indem das Erreichen der von den Kunden angestrebten 

Ergebnisse erleichtert oder gefördert wird. Dabei müssen die 

Kunden selbst keine Verantwortung für bestimmte Kosten 

und Risiken tragen. 

Service Level Messbare und nachweisbare Ergebnisse, die im Hinblick auf 

ein oder mehrere Service Level Ziele erreicht werden. Der 

Begriff „Service Level“ wird im Sprachgebrauch auch als 

Synonym für Service Level Ziel verwendet. 

Service Level 

Agreement (SLA) 

Eine Vereinbarung zwischen einem IT Service Provider und 

einem Kunden. Das SLA beschreibt den jeweiligen IT Service, 

dokumentiert Service Level Ziele und legt die Verantwortlichkeiten 

des IT Service Providers und des Kunden fest. 

Ein einzelnes SLA kann mehrere IT Services oder mehrere 

Kunden abdecken. 




Service Level 

Package (SLP) 

Der festgelegte Grad an Utility und Warranty für ein bestimmtes 

Service Package. Jedes SLP ist darauf ausgerichtet, den 

Anforderungen eines bestimmten Business-Aktivitätsmusters 

gerecht zu werden. 

Service Package Die detaillierte Beschreibung eines IT Service, der Kunden 

zur Verfügung gestellt werden kann. Ein Service Package 

umfasst ein Service Level Package sowie einen oder mehrere 

Core Services und unterstützende Services. 

Servicekatalog Eine Datenbank oder ein strukturiertes Dokument mit Informationen 

zu allen Live IT Services, einschließlich der Services, 

die für das Deployment verfügbar sind. Der 

Servicelinie (LOS) 

Servicekatalog ist der einzige Bestandteil des Serviceportfolios, 

der an die Kunden ausgehändigt wird. Er unterstützt den 

Vertrieb und die Bereitstellung von IT Services. Der Servicekatalog 

enthält Angaben zu Lieferergebnissen, Preisen, 

Bestellungen und Anfragen sowie Kontaktinformationen. 

Ein Core Service oder unterstützender Service, der über 

mehrere Service Level Packages verfügt. Eine Servicelinie 

wird von einem Produktmanager verwaltet und jedes Service 

Level Package ist für die Unterstützung eines bestimmten 

Marktsegments vorgesehen. 

Servicelösung 

Servicepipeline Eine Datenbank oder ein strukturiertes Dokument, in dem alle 

IT Services aufgelistet sind, die zur Diskussion stehen oder 

sich in der Entwicklung befinden und noch nicht für den 

Kunden verfügbar sind. Die Servicepipeline bietet einen 

Überblick über mögliche zukünftige IT Services und ist Teil 

des Serviceportfolios, das in der Regel nicht an die Kunden 

weitergegeben wird. 

Serviceportfolio Die Gesamtheit aller Services, die von einem Service Provider 

verwaltet werden. Das Serviceportfolio wird für das 

Management des gesamten Lebenszyklus aller Services 

genutzt. Es umfasst drei Kategorien: Servicepipeline (beantragt 

oder in Entwicklung), Servicekatalog (Live oder bereit 

zum Deployment) und außer Kraft gesetzte Services. 

Underpinning 

Contract (UC) 

Ein Vertrag zwischen einem IT Service Provider und einer 

Drittpartei. Die Drittpartei stellt Waren oder Services zur 

Verfügung, die die Bereitstellung eines IT Service für einen 

Kunden unterstützen. Der Underpinning Contract definiert 

Ziele und Verantwortlichkeiten, um die in einem SLA vereinbarten 

Service Level Ziele zu erreichen. 

Ziel Der definierte Zweck oder die Zielsetzung eines Prozesses, 

einer Aktivität oder einer ganzen Organisation. Ziele werden 

in der Regel als messbare Elemente ausgedrückt. Der Begriff 

„Ziel“ bezeichnet informell auch eine Anforderung. 

Tabelle 18: Glossar zentraler Begriffe der ITIL 

Abgrenzung zur Servicelinie 

bleibt unklar; beide enthalten 

eine Beschreibung eines 

Services sowie von Service 

Level Packages. 

Die Einordnung zum Service 

Package bleibt unklar. Es ist 

nicht ersichtlich, weshalb 

eine Servicelinie auf Service 

Level Packages – und nicht 

auf Service Packages – 

verweist. 



Anhang K Glossar zentraler Begriffe der COBIT 

Die nachfolgende Auflistung enthält ein bereinigtes Glossar mit zentralen Begriffen der 

COBIT und zugehörigen Definitionen, die entweder direkt aus der Dokumentation (bspw. aus 

vorhandenen Glossaren) der COBIT entnommen oder aus ihr rekonstruiert wurden. Darüber 

hinaus wird festgehalten, ob der Begriff als Bezugsobjekt dient und/oder ein zentrales Konzept 

darstellt. 

Begriff Definition Bezugsobjekt 

The process that limits and controls access to resources of a computer X 

Access control 

system; a logical or physical control designed to protect against unauthorized 

entry or use. 

Accountable 

In a RACI chart, refers to the person or group who has the authority to 

approve or accept the execution of an activity. 

Activity The main actions taken to operate the COBIT process. X 

A program that processes business data through activities such as data X 

Application program 

entry, update or query. It contrasts with systems programs, such as an 

operating system or network control program, and with utility programs, 

such as copy or sort. 

Audit charter 

A document approved by the board, which defines the purpose, authority 

and responsibility of the internal audit activity. 

The act of verifying the identity of a system entity (e.g., user, system, X 

Authentication 

network node) and the entity’s eligibility to access computerized information. 

Designed to protect against fraudulent logon activity, authentication 

can also refer to the verification of the correctness of a piece of data. 

Automated application 

control 

A set of controls embedded within automated solutions (applications). 

A coherent set of performance measures organized into four categories. X 

Balanced scorecard 

It includes traditional financial measures, but adds customer, internal 

business process, and learning and growth perspectives. It was developed 

by Robert S. Kaplan and David P. Norton in 1992. 

A systematic approach to comparing an organization’s performance 

Benchmarking 

against peers and competitors in an effort to learn the best ways of 

conducting business (e.g., benchmarking of quality, logistical efficiency 

and various other metrics) 

Best practice 

A proven activity or process that has been successfully used by multiple 

organizations. 

Capability Having the needed attributes to perform or accomplish. 

Capability Maturity 

Model (CMM) 

Configuration item (CI) 

Configuration management 

The CMM for Software, from the Software Engineering Institute (SEI). A 

model used by many organizations to identify good practices useful in 

helping them assess and increase the maturity of their software development 

processes. 

Component of an infrastructure—or an item, such as a request for 

change, associated with an infrastructure—which is (or is to be) under 

the control of configuration management. CIs may vary widely in complexity, 

size and type, from an entire system (including all hardware, 

software and documentation) to a single module or a minor hardware 

component. 

The control of changes to a set of configuration items over a system life 

cycle. 

Zentrales 

Konzept 


X



Configuration repository 

Consulted 

Continuity 

Continuity plan 

Control framework 

Control objective 

Control practice 

Cost model 

Critical success factor 

(CSF) 

Dashboard 

Data classification 

scheme 

Data dictionary 

Data owners 

Detective control 

Domain 

Enterprise 

A central repository that contains all relevant information on configuration 

items. All changes to configuration items should be logged to the configuration 

repository. 

In a RACI chart, refers to those people whose opinions are sought on an 

activity (two-way communication). 

Preventing, mitigating and recovering from disruption. The terms ‘business 

resumption planning’, ‘disaster recovery planning’ and ‘contingency 

planning’ also may be used in this context; they all concentrate on the 

recovery aspects of continuity. 

Designed to reduce the impact of a major disruption on key business 

functions and processes. The plan should be based on risk understanding 

of potential business impacts and address requirements for resilience, 

alternative processing and recovery capability of all critical IT 

services. It should also cover usage guidelines, roles and responsibilities, 

procedures, communication processes, and the testing approach. 

A set of fundamental controls that facilitates the discharge of business 

process owner responsibilities to prevent financial or information loss in 

an organization. 

A statement of the desired result or purpose to be achieved by implementing 

control procedures in a particular process. 

Key control mechanism that supports the achievement of control objectives 

through responsible use of resources, appropriate management of 

risk and alignment of IT with business. 

Ensures that charging for services is identifiable, measurable and predictable 

by users to encourage proper use of resources. The cost model 

is based on the service definitions that support the calculation of chargeback 

rates per service, 

The most important issues or actions for management to achieve control 

over and within its IT processes. 

A tool for setting expectations for an organization at each level of responsibility 

and continuous monitoring of the performance against set 

targets. 

An enterprise wide scheme for classifying data by factors such as criticality, 

sensitivity and ownership. 

A database that contains the name, type, range of values, source and 

authorization for access for each data element in a database. It also 

indicates which application programs use that data so that when a data 

structure is contemplated, a list of the affected programs can be generated. 

The data dictionary may be a stand-alone information system used 

for management or documentation purposes, or it may control the operation 

of a database. 

Individuals, normally managers or directors, who have responsibility for 

the integrity, accurate reporting and use of computerized data. 

A control that is used to identify events (undesirable or desired), errors 

and other occurrences that an enterprise has determined to have a 

material effect on a process or end product. 

In COBIT, the grouping of control objectives into logical stages in the IT 

life cycle of investments involving IT (Plan and Organize, Acquire and 

Implement, Deliver and Support, and Monitor and Evaluate). 

A group of individuals working together for a common purpose, typically 

within the context of an organizational form such as a corporation, public 

agency, charity or trust. 

Zentrales 

Konzept 


X 

X 

X 

X 

X 

X 

X 

X



Enterprise architecture 

Enterprise architecture 

for IT 

Enterprise governance 

Description of the fundamental underlying design of the components of 

the business system, or of one element of the business system (e.g., 

technology), the relationships amongst them and the manner in which 

they support the organization’s objectives 

Description of the fundamental underlying design of the IT components of 

the business, the relationships amongst them and the manner in which 

they support the organization’s objectives 

A set of responsibilities and practices exercised by the board and executive 

management with the goal of providing strategic direction, ensuring 

that objectives are achieved, ascertaining that risks are managed appropriately 

and verifying that the enterprise’s resources are used responsibly 

Feasibility study Examines the possibility of implementing requirements. X 

General computer 

controls 

Guideline 

Information architecture 

Informed 

Integrated project plan 

Internal control 

ISO/IEC 27002:2005 

ISO 27001 

ISO 9001:2000 

IT 

IT architecture 

Controls, other than application controls, which relate to the environment 

within which computer based application systems are developed, maintained 

and operated, and which are therefore applicable to all applications. 

The objectives of general controls are to ensure the proper 

development and implementation of applications, the integrity of program 

and data files and of computer operations. Like application controls, 

general controls may be either manual or programmed. Examples of 

general controls include the development and implementation of an IS 

strategy and an IS security policy, the organization of IS staff to separate 

conflicting duties, and planning for disaster prevention and recovery. 

A description of a particular way of accomplishing something that is less 

prescriptive than a procedure. 

One component of IT architecture (together with applications and technology). 

In a RACI chart, refers to those people who are kept up to date on the 

progress of an activity (one-way communication). 

A formal, approved integrated project plan (covering business and 

information systems resources) to guide project execution and control 

throughout the life of the project. 

The policies, plans and procedures, and organizational structures designed 

to provide reasonable assurance that business objectives will be 

achieved and undesired events will be prevented or detected and corrected. 

An international standard that defines information confidentiality, integrity 

and availability controls. 

Information Security Management—Specification with Guidance for Use; 

the replacement for BS7799-2. It is intended to provide the foundation for 

third-party audit and is harmonized with other management standards, 

such as ISO/IEC 9001 and 14001. 

Code of practice for quality management from the International Organization 

for Standardization (ISO). ISO 9001:2000, which specifies requirements 

for a quality management system for any organization that needs 

to demonstrate its ability to consistently provide product or service that 

meets particular quality targets. 

Information technology; the hardware, software, communications and 

other facilities used to input, store, process, transmit and output data in 

whatever form. 

Description of the fundamental underlying design of the IT components of 

the business, the relationships amongst them and the manner in which 

they support the organization’s objectives. 

Zentrales 

Konzept 


X 

X 

X 

X



IT continuity framework 


IT governance framework 

IT incident 

IT investment dashboard 

IT process framework 

IT strategic plan 

IT tactical plan 

The objective of the IT continuity framework should be to assist in determining 

the required resilience of the infrastructure and to drive the 

development of disaster recovery and IT contingency plans. The framework 

should address the organizational structure for continuity management, 

covering the roles, tasks and responsibilities of internal and 

external service providers, their management and their customers, and 

the planning processes that create the rules and structures to document, 

test and execute the disaster recovery and IT contingency plans. 

The UK Office of Government Commerce (OGC) IT Infrastructure Library; 

a set of guides on the management and provision of operational IT 

services. 

Defines organizational structures, processes, leadership, roles and 

responsibilities to ensure that enterprise IT investments are aligned and 

delivered in accordance with enterprise strategies and objectives. 

Any event that is not part of the ordinary operation of a service and that 

causes, or may cause, an interruption to, or a reduction in, the quality of 

that service (aligned to ITIL). 

A tool for setting expectations for an organization at each level and 

continuous monitoring of the performance against set targets for expenditures 

on and returns from IT-enabled investment projects in terms of 

business values. 

This framework should include an IT process structure and relationships, 

ownership, maturity, performance measurement, improvement, compliance, 

quality targets and plans to achieve them. It should provide 

integration amongst the processes that are specific to IT, enterprise 

portfolio management, business processes and business change 

processes. The IT process framework should be integrated into a quality 

management system (QMS) and the internal control framework. 

A long-term plan, i.e., three- to five-year horizon, in which business and 

IT management co-operatively describe how IT resources will contribute 

to the enterprise’s strategic objectives (goals). 

A medium-term plan, i.e., six- to 18-month horizon, that translates the IT 

strategic plan direction into required initiatives, resource requirements, 

and ways in which resources and benefits will be monitored and managed. 

IT user A person who uses IT to support or achieve a business objective. 

Key management Those management practices required to successfully execute business 

practices 

processes. 

Key goal indicator; measures that tell management, after the fact, wheth- 

KGI 

er an IT process has achieved its business requirements, usually expressed 

in terms of information criteria. 

Key performance indicator; measures that determine how well the 

process is performing in enabling the goal to be reached. They are lead 

indicators of whether a goal will likely be reached, and are good indica- 

KPI 

tors of capabilities, practices and skills. They measure the activity goals, 

which are the actions the process owner must take to achieve effective 

process performance. 

In business, indicates the degree of reliability or dependency the busi- 

Maturity 

ness can place on a process achieving the desired goals or objectives. 

A standard used to evaluate and communicate performance against 

Measure 

expected results. Measures are normally quantitative in nature capturing 

numbers, dollars, percentages, etc., but can also address qualitative 

Zentrales 

Konzept 


X 

X 

X 

X 

X 

X 

X 

X 

X X


Bezugsobjekt 

Begriff Definition 

information such as customer satisfaction. Reporting and monitoring 

measures help an organization gauge progress toward effective implementation 

of strategy. 

Specific descriptions of how a quantitative and periodic assessment of 

Metrics 

performance is to be measured. A complete metric defines the unit used, 

frequency, ideal target value, the procedure to carry out the measurement 

and the procedure for the interpretation of the assessment. 

OLA 

Operational level agreement; an internal agreement covering the delivery 

of services that support the IT organization in its delivery of services. 

X 

Organization 

The manner in which an enterprise is structured; can also mean the 

entity. 

Measures that represent the consequences of actions previously taken 

and are often referred to as lag indicators. They frequently focus on 

X 

Outcome measures 

results at the end of a time period and characterize historical performance. 

They are also referred to as key goal indicators (KGIs) and are 

used to indicate whether goals have been met. These can be measured 

only after the fact and, therefore, are called ‘lag indicators’. 

Performance In IT, the actual implementation or achievement of a process. 

Measures that are considered the ‘drivers’ of lag indicators. They can be 

measured before the outcome is clear and, therefore, are called ‘lead 

indicators’. There is an assumed relationship between the two that 

Performance drivers suggests that improved performance in a leading indicator will drive 

better performance in the lagging indicator. They are also referred to as 

key performance indicators (KPIs) and are used to indicate whether 

goals are likely to be met. 

Performance management 

Policy 

Portfolio 

Preventive control 

In IT, the ability to manage any type of measurement, including employee, 

team, process, operational or financial measurements. The term 

connotes closed-loop control and regular monitoring of the measurement. 

Generally, a document that records a high-level principle or course of 

action that has been decided upon. A policy’s intended purpose is to 

influence and guide both present and future decision making to be in line 

with the philosophy, objectives and strategic plans established by the 

enterprise’s management teams. In addition to policy content, policies 

need to describe the consequences of failing to comply with the policy, 

the means for handling exceptions, and the manner in which compliance 

with the policy will be checked and measured. 

A grouping of programmes, projects, services or assets selected, managed 

and monitored to optimize business return. 

An internal control that is used to prevent undesirable events, errors and 

other occurrences that an organization has determined could have a 

negative material effect on a process or end product. 

Zentrales 

Konzept 

Problem In IT, the unknown underlying cause of one or more incidents. X 

Provides audit trail facilities that allow tracking, analyzing and determin- X 

Problem management ing the root cause of reported problems, considering all associated 

system 

configuration items, outstanding problems and incidents, known and 

suspected errors and tracking of problem trends. 

Procedure 

A document containing steps that specify how to achieve an activity. 

Procedures are defined as part of processes. 

Generally, a collection of procedures influenced by the organization’s 

policies and procedures that takes inputs from a number of sources, 

X X 

Process 

including other processes, manipulates the inputs, and produces outputs, 

including other processes. Processes have clear business reasons for 

existing, accountable owners, clear roles and responsibilities around the 


X 

X 

X


Programme 

Project 


Project management 

framework 

Project quality plan 

QMS 

RACI chart 

Resilience 

Responsible 

Risk 

Risk management 

framework 

Root cause analysis 

SDLC 

Segregation/ separation 

of duties 

Service catalogue 

execution of the process, and the means to measure performance. 

A structured grouping of interdependent projects that includes the full 

scope of business, process, people, technology and organizational 

activities that are required (both necessary and sufficient) to achieve a 

clearly specified business outcome. 

A structured set of activities concerned with delivering to the enterprise a 

defined capability (that is necessary but not sufficient to achieve a 

required business outcome) based on an agreed-upon schedule and 

budget. 

Defines the scope and boundaries of managing projects, as well as the 

method to be adopted and applied to each project undertaken. The 

framework and supporting method should be integrated with the programme 

management processes. 

Describes a project quality system and how it will be implemented. The 

plan should be formally reviewed and agreed to by all parties concerned 

and then incorporated into the integrated project plan. 

Quality management system; a system that outlines the policies and 

procedures necessary to improve and control the various processes that 

will ultimately lead to improved organization performance. 

Illustrates who is responsible, accountable, consulted and informed 

within an organizational framework. 

In business, the ability of a system or network to recover automatically 

from any disruption, usually with minimal recognizable effect. 

In a RACI chart, refers to the person who must ensure that activities are 

completed successfully. 

In business, the potential that a given threat will exploit vulnerabilities of 

an asset or group of assets to cause loss and/or damage to the assets; 

usually measured by a combination of impact and probability of occurrence. 

Documents a common and agreed-upon level of IT risks, mitigation 

strategies and residual risks. Any potential impact on the goals of the 

organization caused by an unplanned event is identified, analyzed and 

assessed. 

Process of diagnosis to establish origins of events, which can be used for 

learning from consequences, typically of errors and problems. 

System development life cycle; the phases deployed in the development 

or acquisition of a software system. Typical phases include the feasibility 

study, requirements study, requirements definition, detailed design, 

programming, testing, installation and post-implementation review, but 

not the service delivery or benefits realization activities. 

A basic internal control that prevents or detects errors and irregularities 

by assigning to separate individuals responsibility for initiating and 

recording transactions and custody of assets to separate individuals. 

Commonly used in large IT organizations so that no single person is in a 

position to introduce fraudulent or malicious code without detection. 

Organizes and stores service requirements, service definitions, SLAs, 

OLAs and funding sources. 

Service desk A point of contact within the IT organization for users of IT services. 

Service provider External entity that provides services to the organization. 

Service level agreement; an agreement, preferably documented, be- 

SLA 

tween a service provider and the customer(s)/user(s) that defines minimum 

performance targets for a service and how they will be measured. 

Zentrales 

Konzept 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X


Standard 

TCO 


Technological forum 

Technology infrastructure 

plan 

Tracking and reporting 

system 

A mandatory requirement. Examples include ISO/IEC 20000 (an international 

standard), an internal security standard for UNIX configuration or a 

government standard for how financial records should be maintained. 

The term ‘standard’ is also used to refer to a code of practice or specifications 

published by a standards organization, such as ISO or BSI. 

Total cost of ownership; in IT includes: 

• Original cost of the computer and software 

• Hardware and software upgrades 

• Maintenance 

• Technical support 

• Training 

• Certain activities performed by users 

Provides technology guidelines, advice on infrastructure products and 

guidance on the selection of technology, and measures compliance with 

these standards and guidelines. This forum should direct technology 

standards and practices based on their business relevance, risks and 

compliance with external requirements. 

A plan for the technology, human resources and facilities that enables 

the current and future processing and use of applications. 

Documents rejected changes, communicates the status of approved and 

in-process changes, and completed changes. 

Tabelle 19: Glossar zentraler Begriffe von COBIT 

Zentrales 

Konzept 


X 

X 

X X 

X


Anhang L Organisatorische Aufbauelemente der RA 

Die nachfolgende Auflistung enthält die identifizierten organisatorischen Aufbauelemente der 

RA zusammen mit einer Beschreibung ihren Aufgaben und Verantwortungen. Dies basiert 

auf der Dokumentation der RA, die der Untersuchung zugrunde liegt. Es wird dabei zwischen 

Rollen und Gremien unterschieden. 


Geschäftsarchitekt (Ressort) 

IT-Beauftragter der Bundesregierung 

(BfIT, Bundes-CIO) 

Der Geschäftsarchitekt gestaltet die Strukturierung und Darstellung 

der Aufgaben. Er verwendet dazu ein geeignetes, ressortspezifisches 

Architekturmodell, das „kompatibel“ zur Rahmenarchitektur sein sollte. 

Er gibt Impulse für Verbesserungen der Struktur und Organisation 

einerseits und des Bedarfs an IT-Unterstützung andererseits. Er kennt 

die Geschäftsprozesse und Nachfragen nach IT-Unterstützung für 

seinen Aufgabenbereich insbesondere aus Sicht der Fachabteilungen. 

([Methode] S. 9) 

Die für Verwaltungsmodernisierung und IT zuständige Staatssekretärin 

des Bundesministeriums des Innern übernimmt die Rolle der BfIT. 

Sie sitzt dem Rat der IT-Beauftragten sowie der IT-Steuerungsgruppe 

vor. Die BfIT hat u. a. folgende Aufgaben im Kontext des Bundes 

([Konzept], S. 7f.): 

• Ausarbeitung der E-Government-/ IT- und IT-Sicherheitsstrategie 

• Entwicklung von Architektur, Standards und Methoden für die IT 

• Unterstützung des IT-Rats bei der Abstimmung der Angebote der 

IT-Dienstleister 

• Steuerung des IT-Sicherheitsmanagements auf der Grundlage 

der Festlegungen der Bundesregierung 

• Steuerung der Bereitstellung zentraler IT-Infrastrukturen 

• Ausarbeitung von vertraglichen Rahmenwerken und Leitfäden für 

die Beschaffung von IT 

• Ferner vertritt die BfIT die Interessen des Bundes im IT- 

Planungsrat 

IT-Planungsrat Der IT-Planungsrat dient der Bund-Länder übergreifenden IT- 

Steuerung, d.h. der Koordinierung der Zusammenarbeit von Bund und 

Ländern in Fragen der Informationstechnik. Der Bund wird im IT- 

Planungsrat durch den BfIT vertreten. Der IT-Planungsrat steht außerhalb 

der Betrachtung. 


Rolle 

Rolle 

Gremium



IT-Steuerungsgruppe Aufgabe der IT-Steuerungsgruppe des Bundes ist die Verzahnung von 

politischer und haushaltsmäßiger IT-Steuerung. Mitglieder der Steuerungsgruppe 

sind ([Konzept], S. 6f.): 

• IT-Beauftragter der Bundesregierung (BfIT), 

• der Haushaltsstaatssekretär des Bundesministeriums der Finanzen, 

• der für Informations- und Kommunikationstechnik verantwortliche 

Staatssekretär des Bundesministerium für Wirtschaft und Technologie 


• ein Vertreter des Bundeskanzleramtes. 

Zu den Aufgaben und Rechten der IT-Steuerungsgruppe gehören u. a. 

• Initiativrecht für Aufträge an den Rat der IT-Beauftragten (z. B. 

hinsichtlich Standardfragen, Innovationsvorhaben) 

• Einspruchsrecht bei IT-Rahmenkonzepten und anderen Maßnahmen 

der Ressorts, die den Beschlüssen der IT Steuerungsgruppe 

des Bundes oder des Rates der IT-Beauftragten 

widersprechen 

• Sofern keine Einigung im Rat der IT Beauftragten möglich ist, gibt 

die IT-Steuerungsgruppe nach Konsultation der betroffenen Ressorts 

eine Empfehlung für einen Beschluss des Rates der IT- 

Beauftragten der Ressorts ab 

• Bestätigung des IT-Rahmenkonzepts des Bundes 

• Koordinierung von IT-Großprojekten der öffentlichen Verwaltung 

Kundenmanager Die Kundenmanager stellen Ansprechpartner seitens der DLZ-IT des 

Bundes für die Kunden und den Nachfragebeirat da. Sie koordinieren 

in diesem Rahmen ([Nachfragebündelung], S. 16): 

• die Durchführung von Machbarkeitsprüfungen im DLZ-IT des 

Bundes, 

• die Erstellung von (vorläufigen) Angeboten für Produktentwicklungen 

und Produktänderungen 

• sowie die Erstellung von Produktsteckbriefen im Zuge der Anpassung 

des Produktkatalogs 

Lösungsarchitekt Der Lösungsarchitekt entwirft IT-Lösungen. Der Lösungsarchitekt 

sollte Mitarbeiter eines DLZ-IT des Bundes sein, aber auch über einen 

Überblick über die IT-Lösungen der anderen DLZ-IT des Bundes 

verfügen. Er definiert für die IT-Unterstützung von Geschäftsprozessen 

IT-Lösungen sowohl aus geschäftlicher / fachlicher als auch aus 

technischer Sicht. ([Methode] S. 9) 

• Hierzu gehören der Entwurf der gesamten Lösungs- und Komponentenarchitektur, 

• die Abstimmung mit den Bedarfsträgern auf der Grundlage des 

Dienstemodells und 

• die Entwicklung von Strategien zur Implementierung und Integration 

der IT-Lösung. 

Nachfragerbeirat (NFB) Der Nachfragerbeirat besteht aus den Nachfragekoordinatoren der 

Ressorts. Er ist für die 

• Konsolidierung/Bündelung, Priorisierung und die Darstellung des 

ressortübergreifenden 

Bedarfskatalog), 

IT-Bedarfs / der IT-Nachfrage (IT- 

• die Erstellung der Umsetzungsvorgaben (im Wesentlichen Fachanforderungen) 

sowie 

• deren Umsetzungsplanung verantwortlich. 

• Zudem koordiniert der NFB sowohl mit den Ressortvertretern als 

auch den Vertretern der DLZ-IT des Bundes die Klärung der 

Machbarkeit, des Ressourcenbedarfs, der Umsetzungsplanung 

von ressortübergreifenden IT-Maßnahmen und 

• die Abstimmung von ressortübergreifenden Produktentwicklungen, 

Produktänderungen und Produktabkündigungen. ([Nachfragebündelung], 

S.15) 

Gremium 


Rolle 

Rolle 

Gremium




Ressort 

Rat der IT-Beauftragten 

(IT-Rat) 

IT-Beauftragter für Ressort 

(Ressort-CIO) 

Team Architekturmanagement 

Die Nachfragekoordinatoren sind für die Koordinierung und Bündelung 

der ressortinternen IT-Nachfrage, die potentiell ressortübergreifend ist, 

zuständig. Zudem vertreten sie die Interessen des jeweiligen Ressorts 

im Nachfragebeirat. ([Nachfragebündelung], S. 16) 

Der Rat der IT-Beauftragten beschließt die wesentlichen Vorgaben zur 

ressortübergreifenden Steuerung der IT des Bundes. Er setzt sich aus 

den IT-Beauftragten der Ressorts zusammen. Vorsitzende des IT- 

Rates ist die Beauftragte der Bundesregierung für Informationstechnik. 

Zu den Aufgaben des IT-Rats gehört u. a. ([Konzept], S. 5f.): 

• Beschluss einer abgestimmten E-Government- / IT –Strategie und 

einer IT-Sicherheitsstrategie 

• Ausrichtung der IT-Strategie auf die Strategie der Bundesregierung 

zur Verwaltungsmodernisierung und die vom Ausschuss für 

Organisationsfragen (AfO) beschlossenen Modernisierungsprojekte 

• (Bündelung der ressortübergreifenden IT-Nachfrage unter Berücksichtigung 

der Anforderungen der Organisation) 31 

• Entwicklung von Lösungsmodellen für die Gewinnung und den 

Einsatz von IT-Fachpersonal 

• Festlegung der Architektur, Standards und Methoden für die IT 

der Bundesverwaltung 

• Beschluss des IT-Rahmenkonzepts des Bundes und eines Vorschlages 

für die Etatisierung ressortübergreifender Projekte als 

Grundlage für die Haushaltsverhandlungen. 

• Übergreifendes Portfoliomanagement der DLZ IT des Bundes 

• Neufassung und Weiterentwicklung der IT-Richtlinien 

• (Weiter-) Entwicklung einheitlicher Projektmanagement- 

Standards, -Methoden und -Werkzeuge, Bereitstellung eines zentralen 

Dienstleistungsangebotes hinsichtlich Projektmanagement- 

Unterstützung, Sicherstellung von Qualifizierungsmaßnahmen 

(Fortbildung), Externen Projektcontrolling 

Jedes Ressort bestellt einen zentralen IT-Beauftragten für das gesamte 

Ressort. Er gewährleistet die Übereinstimmung des IT-Einsatzes 

mit den politischen, strategischen und operativen Zielen des Ressorts 

und den IT-Festlegungen der Bundesregierung und vertritt die IT 

seines Ressorts nach außen. Dabei ist er der jeweiligen Leitung des 

Ressorts in dieser Funktion grundsätzlich unmittelbar unterstellt. Zu 

den Aufgaben des IT-Beauftragen gehört u. a. ([Konzept], S. 4f.): 

• Kontrolle der Umsetzung der Standards, strategischen Zielvorgaben 

und der Festlegungen des IT-Rats und der IT- 

• 

Steuerungsgruppe des Bundes. 

Gewährleistung der IT Sicherheit des Ressorts 

• Erfolgskontrolle bei wesentlichen IT-relevanten Vorhaben des 

Ressorts 

• (Bündelung der IT-Nachfrage des Ressorts. 31 

• Fachaufsicht über die ressortinternen Anbieter von IT- 

• 

Dienstleistungen 

Konsolidierung der Erbringung der IT-Dienstleistungen innerhalb 

des Ressorts 

• Mitwirkung bei allen IT-Budgets des gesamten Ressorts 

Die konkrete organisatorische Gestaltung und Einbettung ist noch 

nicht abschließend geklärt. Daher kann das Team als „Stellvertreter“ 

bzw. „Platzhalter“ für ein näher zu bestimmendes organisatorisches 

Aufbauelement verstanden werden, das mit Aufgaben des Architekturmanagements 

beauftragt ist ([KoopA], S. 12). Zurzeit erfolgt dies 

auf Ebene von Projektgruppen. 


Rolle 

Gremium 

Rolle 

Gremium 

31 

Per IT-Rats-Beschluss wurde diese Aufgabe zwischenzeitlich an den neu aufgebauten Nachfragerbeirat 

delegiert.



Team IT-Rahmenkonzept Die konkrete organisatorische Gestaltung und Einbettung ist noch 

nicht abschließend geklärt. Daher kann sie als „Stellvertreter“ bzw. 

„Platzhalter“ für ein näher zu bestimmendes organisatorisches Aufbauelement 

verstanden werden, das mit dem IT-Rahmenkonzept des 

Bundes (bspw. der Fortschreibung) beauftragt ist ([KoopA], S. 12). 

Zurzeit erfolgt dies auf Ebene von Projektgruppen. 

Tabelle 20: Organisatorische Aufbauelemente der RA 

Gremium 



Anhang M Organisatorische Aufbauelemente der ITIL 

Die nachfolgende Auflistung enthält die identifizierten organisatorischen Aufbauelemente der 

ITIL zusammen mit einer Kurzbeschreibung. Es wird dabei zwischen Rollen und Gremien 

unterschieden und jeweils das Quelldokument angegeben. 

Aufbauelement Kurzbeschreibung Typ Dokument 

Account Manager Eine Rolle mit vielen Parallelen zum Business 

Application Management 

Relationship Manager, bei der jedoch verstärkt kommerzielle 

Aspekte einbezogen werden. Wird häufig bei 

Abläufen in Verbindung mit externen Kunden eingesetzt. 

Verantwortlich für das Management von Anwendungen 

über ihren gesamten Lebenszyklus hinweg. Unterstützt 

und verwaltet betriebene Anwendungen und wirkt am 

Design, Test und an der Verbesserung von Anwendungen, 

die Teil von IT Services sind, mit. 

Applications Ana- Zuständig für die Zuordnung von Anforderungen zu 

lyst/Architect 

Anwendungsspezifikation. 

Applications Manager/Teamleiter 

Zuständig für die Leitung, Steuerung und Entscheidungsfindung 

für ein Anwendungsteam oder eine 

Abteilung. Stellt technisches Wissen bereit, leitet bestimmte 

Aktivitäten zum Anwendungssupport und fördert 

Kommunikation mit Anwendern und Kunden. 

Rolle Service 

Design 

Funktion Service 

Operation 

Rolle Service 

Operation 

Rolle Service 

Operation 

Availability Manager Stellt sicher, dass alle vorhandenen Services die mit Rolle Service 

dem Business vereinbarten Verfügbarkeitslevel liefern. 

Design 

Business Relationship Eine Rolle, die für die Pflege von Beziehungen zu einem Rolle Service 

Manager 

oder mehreren Kunden verantwortlich ist. Diese Rolle 

wird häufig mit der Rolle des Service Level Managers 

kombiniert. 

Design 

Business-/ Organisations- Kümmert sich um Business-Modelle, Business-Prozesse Rolle Service 

architekt 

und das organisatorische Design – die strukturellen und 

funktionalen Komponenten der Organisation und ihre 

Beziehung und wie die Fachbereiche und Business- 

Aktivitäten der Organisation auf sie verteilt werden. Auch 

verantwortlich für die Governance der Organisation, der 

erforderlichen Rollen und Zuständigkeiten. 

Design 

Business-Vertreter Primäre Service-Empfänger der einzelnen Geschäftsbe- Rolle Service 

reiche, die Business-Anforderungen definieren, Services 

überwachen, Service Requests einreichen und über 

Budgets verfügen. 

Strategy 

Capacity Manager Stellt sicher, dass eine adäquate IT-Kapazität zur Rolle Service 

Erreichung der erforderlichen Service Level vorhanden 

ist, ermittelt Kapazitätsanforderungen und informiert das 

obere IT-Management über die Kapazitätsabstimmung. 

Design 

Change Advisory Board Eine Gruppe von Personen, die den Change Manager Gremium Service 

(CAB) 

bei der Bewertung, Festlegung von Prioritäten und 

zeitlichen Planung in Bezug auf Changes beraten. 

Dieses Gremium setzt sich in der Regel aus Vertretern 

aller Bereiche des IT Service Providers, dem Business 

und den Drittparteien wie z. B. Suppliern zusammen. 

Transition 

Change Manager Erfasst, protokolliert, autorisiert und priorisiert in Zu- Rolle Service 

sammenarbeit mit dem jeweiligen Initiator RFCs, organisiert 

und unterstützt Change Advisory Board Meetings 

und verwaltet, steuert und analysiert ausstehende 

Changes. 

Transition 

Change- 

Vergibt Autorisierungen für Changes. Kann eine Rolle, Funktion Service 

Genehmigungskompetenz Person oder Gruppe von Personen sein. Die hierarchische 

Struktur der Autorisierungsebenen kann weitgehend 

von der Kultur der Organisation bestimmt werden. 

Transition 




Chief Sourcing Officer Fördert und entwickelt mit dem CIO die Sourcing 

Strategy, leitet die Sourcing Abteilung und übernimmt 

eine integrierende Funktion zwischen internen und 

externen Ressourcen und Mitarbeitern. 

CMS-/Tool-Administrator Evaluiert und empfiehlt Asset und Configuration Management 

Tools, überwacht Performance und Kapazität 

bestehender Systeme und sichert deren Integrität und 

operative Performance. 

Configuration Manager Verantwortlich für die Implementierung, Steuerung und 

Überwachung der Richtlinien, Standards, Pläne, Verfahren 

und Prozesse des Configuration Management und 

die Verwaltung und Evaluierung von Configuration Tools 

und Systemen. 

Configuration- 

Administrator/- 

Verantwortlicher 

Verwaltet und sichert alle Masterkopien von Software, 

Assets und Dokumentations-CIs, die im Rahmen des 

Asset und Configuration Management registriert werden. 

Configuration-Analyst Macht Vorschläge bezüglich des Umfangs der Asset und 

Configuration Management Prozesse sowie der Funktionen, 

zu steuernden Elemente und aufzuzeichnenden 

Informationen, entwickelt und unterstützt Asset und 

Configuration Management Standards, Pläne, Verfahren 

und initiiert entsprechende Schulungen. 

Configuration- 

Kontrollgremium 

Gewährleistet, dass die übergreifenden Ziele und 

Richtlinien des Configuration Management während des 

gesamten Service Management Lebenszyklus und unter 

besonderer Berücksichtigung jedes einzelnen Aspekts 

des gesamten Service verfolgt und eingesetzt werden. 

CSI-Manager Verantwortlich für den Erfolg des Verbesserungsprogramm 

und aller Verbesserungsaktivitäten. 

Deployment Sorgt für die physische Endlieferung der Serviceimplementierung, 

koordiniert Release-Dokumentation und – 

Kommunikation, plant das Deployment und unterstützt 

den Release-Prozess. 

Early Life Support Unterstützt den IT Service sowie Business-Funktionen in 

der Release und Deployment-, Überführungs- sowie 

Anfangsphase. 

Emergency Change 

Advisory Board (ECAB) 

Eine Teilgruppe des Change Advisory Board, die Entscheidungen 

zu Notfall-Changes trifft, die umfassende 

Auswirkungen nach sich ziehen. Über die Zusammensetzung 

des ECAB kann bei der Einberufung eines 

Meetings entschieden werden und diese richtet sich 

nach der Art des Notfall-Change. 

Facilities Management Die Funktion, die für die physische Umgebung verantwortlich 

ist, in der sich die IT-Infrastruktur befindet. Das 

Facilities Management umfasst alle Aspekte in Verbindung 

mit der Verwaltung der physischen Umgebung, wie 

beispielsweise das Stromversorgungs- und Kühlungssystem, 

das Access Management für Zutrittsrechte und 

die Umgebungs-Überwachung. 

Financial Management Die Funktionen und die Prozesse mit der Verantwortung 

für den Umgang mit den Anforderungen eines IT Service 

Providers an die Budgetierung, die Kostenrechnung und 

die Leistungsverrechnung. 

Help Desk Eine Anlaufstelle für Anwender, um Incidents zu erfassen. 

Ein Help Desk ist in der Regel eher technisch 

orientiert als ein Service Desk und stellt keinen Single 

Point of Contact für die gesamte Interaktion bereit. Der 

Begriff „Help Desk“ wird häufig auch als Synonym für 

Service Desk verwendet. 

Incident Manager Treibt die Effizienz und Effektivität des Incident Management 

Prozesses voran, managt die Arbeit der Mitarbeiter 

des Incident-Support und überwacht und verwaltet 

Incident Management Systeme und Verfahren. 

Rolle Service 

Strategy 

Rolle Service 

Transition 

Rolle Service 

Transition 

Rolle Service 

Transition 

Rolle Service 

Transition 

Gremium Service 

Transition 

Rolle Continual 

Service 

Improvement 

Rolle Service 

Transition 

Rolle Service 

Transition 


Transition 


Operations 

Funktion Übergreifend 


Operations 

Rolle Service 

Operations 




IT Directorate (IT-Leitung) Oberes Management bei einem Service Provider, das 

für die Entwicklung und Bereitstellung von IT Services 

verantwortlich ist Der Begriff wird meist in Behörden der 

britischen Regierung benutzt. 

IT Operations Analyst Leitender Mitarbeiter des IT-Betriebs, welcher in Umgebungen 

mit hohem Durchsatz und unterschiedlichen 

Anforderungen die effektivste und effizienteste Vorgehensweise 

für eine Reihe von Betriebsabläufen bestimmt. 

IT Operations Control Steuert den Betrieb der IT Services und IT Infrastruktur 

und stellt sicher, dass die routinemäßigen operativen 

Aufgaben und das Monitoring ausgeführt werden. 

IT Operations Management 

Verantwortlich für die täglichen operativen Aktivitäten, 

die für das Management der IT-Infrastruktur erforderlich 

sind. 

IT Operations Manager Übernimmt die Gesamtverantwortung für alle Aktivitäten 

des Operations Management wie Operations Control 

(Konsolenmanagement, Job Scheduling, Backup und 

Restore und Druck- und Ausgabemanagement) und 

Facilities Management. 

IT Operator Führt die täglichen operativen Aktivitäten durch, die vom 

Technical oder Application Management sowie in einigen 

Fällen von IT Operations Analysts festgelegt werden. 

IT Service Continuity 

Manager 

Stellt sicher, dass die Zielsetzungen des IT Service 

Continuity Management erreicht werden. Implementiert 

und verwaltet den ITSCM-Prozess in Übereinstimmung 

mit den allgemeinen Anforderungen des Business 

Continuity Management-Prozesses der Organisation. 

IT Steering Group (ISG) Eine formale Gruppe, die sicherstellen soll, dass die 

Strategien und Pläne von Business und IT Service 

Provider eng aufeinander abgestimmt sind. Zu einer IT 

Steering Group gehören Vertreter des oberen Managements 

aus dem Business und dem IT Service Provider. 

IT-Designer/-Architekt Zuständig für die Gesamtkoordination und das Design 

von Technologiearchitekturen, die alle aktuellen und 

erwarteten zukünftigen IT-Anforderungen der Organisation 

erfüllen. 

IT-Infrastrukturarchitekt Kümmert sich um das physische Technologiemodell, die 

Infrastrukturkomponenten und ihre Beziehungen, einschließlich 

Auswahl von Technologien, Schnittstellen 

und Protokollen sowie die Auswahl von Produkten zur 

Implementierung der Infrastruktur. 

IT-Planer Zuständig für Erstellung, Koordination, Messung und 

Review des Implementierungsstandes aller IT-Pläne, IT- 

Strategien, IT-Standards und Richtlinien, die für die 

Unterstützung einer Business-Strategie der Organisation 

erforderlich sind. 

Knowledge Management 

Process Owner 

Leiter des Service Management 

Management von Build- 

und Testumgebungen 

Performance and Risk 

Evaluation Manager 

Übernimmt die Knowledge Management Rolle, indem er 

Einhaltung der Richtlinien und Prozesse der Organisation 

sicherstellt und Informationen und Wissenselemente 

der Organisation identifiziert, strukturiert, pflegt und 

verwaltet. 

Leitender Angestellter, der das Business kennt und alle 

Aspekte der Servicebereitstellung im Auftrag von Geschäftsbereichen 

definiert, plant, einkauft und verwaltet. 

Sichert, dass alle relevanten Personen zur richtigen Zeit 

über geeignete Umgebungen, Testdaten, Software- 

Versionen und sonstige Ressourcen verfügen. 

Entwickelt auf Grundlage von Service Design und 

Release Package einen Evaluations-Plan für das Testen 

von Services, ermittelt Risiken und Schwierigkeiten der 

Service Transition und berichtet an das Change Management. 

Rolle Übergreifend 

Rolle Service 

Operations 


Operations 


Operations 

Rolle Service 

Operations 

Rolle Service 

Operations 

Rolle Service 

Design 


Design 

Rolle Service 

Design 

Rolle Service 

Design 

Rolle Service 

Design 

Rolle Service 

Transition 

Rolle Service 

Strategy 

Rolle Service 

Transition 

Rolle Service 

Transition 




Planning and Support Bietet Unterstützung für die Service Transition Teams 

und Mitarbeiter, verwaltet und integriert die Ausarbeitung 

der Transition-Pläne und überwacht den Fortschritt. 

Problem Manager Koordiniert alle Problem Management Aktivitäten. Stellt 

eine schnelle Lösung der Probleme im Rahmen der 

SLA-Ziele, den Schutz der KEDB, die Verpflichtungen 

von Drittparteien und die Einbeziehung aller Known 

Errors sicher. 

Process Owner (Prozessverantwortlicher) 

Verantwortlich für die allgemeine Qualität eines Prozess 

und die Überwachung des Management von und die 

organisatorische Konformität mit den Prozessflüssen, 

Verfahren, Datenmodellen, Richtlinien und Technologien 

in Verbindung mit dem IT-Business-Prozess. 

Rolle Service 

Transition 

Rolle Service 

Operations 


Produktmanager Definiert, plant, kauft und verwaltet Sourcing-Elemente Rolle Service 

und -Performance im Auftrag der Sourcing-Organisation. 

Strategy 

Prozess Manager Eine Rolle, die für das operative Management eines Rolle 

Prozesses verantwortlich ist. Zu den Verantwortlichkeiten 

des Prozess-Managers gehören die Planung und die 

Koordination aller Aktivitäten, die zur Ausführung, dem 

Monitoring und der Berichtserstellung in Bezug auf einen 

Prozess erforderlich sind. 

Übergreifend 

Release and Deployment Verantwortlich für die Planung, das Design, das Build, Rolle Service 

Manager 

die Configuration und Tests sämtlicher Software und 

Hardware, mit der das Release Package zur Bereitstellung 

des vorhergesehenen Service erstellt wird. 

Transition 

Release Packaging and Verantwortlich für den Workflow, mit dem Anwendungen Rolle Service 

Build Manager 

und Infrastruktur mit den Anforderungen aus dem 

Service Design bereitgestellt werden. Legt die endgültige 

Release Configuration fest, testet das Lieferergebnis, 

ermittelt Known Errors und liefert Input für den endgültigen 

Prozess. 

Transition 

Reporting Analyst Prüft und analysiert Daten von Komponenten, Systemen Rolle Continual 

und Untersystemen, um ein präzises End-to-End- 

Service 

Ergebnis des Service zu erhalten, identifiziert und 

bewertet Trends und setzt diese Informationen in der 

Präsentation der Daten ein. 

Improvement 

Request Fulfillment Übernimmt die erste Bearbeitung von Service Requests Rolle Service 

(der Serviceanträge). 

Operations 

Schicht Eine Gruppe oder ein Team von Personen, denen eine Gremium Service 

bestimmte Rolle über einen festgelegten Zeitraum 

zugewiesen ist. 

Operations 

Schichtleiter Zuständig für die Leitung, Steuerung, Entscheidungsfin- Rolle Service 

dung während einer Schicht und Sicherstellung der 

Durchführung aller operativen Aktivitäten innerhalb der 

vereinbarten Zeitrahmen und Unternehmensrichtlinien 

und -verfahren. 

Operations 

Security Manager Entwickelt, verwaltet, kommuniziert und sichert die Rolle Service 

Einhaltung der Information Security Policy und unterstützender 

Richtlinien. 

Design 

Service Asset Manager Zuständig für die Implementierung, Steuerung und Rolle Service 

Überwachung der Richtlinien, Standards, Pläne, Verfahren 

und Prozesse des Service Asset Management und 

die Verwaltung und Evaluierung von Asset Management 

Tools und Systemen. 

Transition 

Service Design Manager Zuständig für die Gesamtkoordination, die Erstellung Rolle Service 

und die Verwendung qualitativ hochwertiger Lösungs- 

Designs für Services und Prozesse. 

Design 

Service Desk Bietet eine Anlaufstelle für Anwender zur Kommunikati- Rolle Service 

on und für IT-Gruppen und -Prozesse zur Koordination 

bei Serviceunterbrechungen, Service Requests oder 

einigen Kategorien von Requests für Change. 

Operations 

Service Desk Analyst Stellt First-Level- Support bereit, indem Anrufe entge- Rolle Service 

gengenommen und die daraus resultierenden Incidents 

oder Service Requests bearbeitet werden. 

Operations 




Service Desk Manager Managt allgemeine Aktivitäten des Service Desks, 

fungiert als zusätzlicher Eskalationspunkt für die Supervisor, 

ist zuständig für die Bearbeitung von Incidents und 

Service Requests und berichtet an das obere Management. 

Service Desk Supervisor Sichert während der Betriebszeiten die Verfügbarkeit 

geeigneter Mitarbeiter, erstellt und verwaltet Schichtzeitpläne 

der Mitarbeiter und berichtet an das obere Management. 

Service Knowledge 

Management Owner 

Zuständig für die Entwicklung, Bereitstellung und Einhaltung 

der Knowledge Management Strategien, Prozesse 

und Verfahren. 

Service Level Manager Stellt sicher, dass aktuelle und zukünftige Service- 

Anforderungen der Kunden identifiziert, verstanden und 

dokumentiert werden, verhandelt und vereinbart Service 

Levels und stellt Informationen zu sich ändernden 

Business-Anforderungen bereit. 

Service Manager Verwaltet und steuert die Entwicklung, die Implementierung 

und die Evaluierung sowie das fortlaufende Management 

neuer und vorhandener Produkte und Services. 

Service Owner Verantwortlich für einen bestimmten Service innerhalb 

einer Organisation, unabhängig davon, wo die zugrunde 

liegenden Technologiekomponenten, Prozesse oder 

professionellen Fähigkeiten angesiedelt sind. 

Service Transition Manager 

Zuständig für Gesamtplanung und Management der 

Service Transition einschließlich Continual Service 

Improvement. Verantwortlich für das tägliche Management 

und die Steuerung der Service Transition Teams 

und deren Aktivitäten. 

Servicearchitekt Kümmert sich um die Service-, Daten- und Anwendungsarchitekturen 

– die logischen Architekturen, die 

das Business und die Beziehungen zwischen ihnen 

unterstützen. 

Servicekatalogmanager Zuständig für die Erstellung und Verwaltung des Servicekatalogs. 

Servicetest-Manager Unterstützt Tests und Funktionen des Testteams, 

welche an einer Service Transition beteiligt sind. Entwickelt, 

plant und steuert Teststrategien und Testressourcen. 

Super-User Ein Anwender, der anderen Anwendern hilft und sie bei 

der Kommunikation mit dem Service Desk oder anderen 

Bereichen des IT Service Providers unterstützt. Super- 

User bieten in der Regel Unterstützung bei kleineren 

Incidents oder bei Schulungen an. 

Supplier Manager Unterstützt die Entwicklung und das Review von SLAs, 

Verträgen und Vereinbarungen für externe Supplier und 

sichert das Kosten-Nutzen-Verhältnis aller IT-Supplier 

und Verträge sowie die Konsistenz aller IT-Supplier- 

Prozesse. 

Support-Gruppe Eine Gruppe von Personen mit technischen Fachkenntnissen. 

Support-Gruppen stellen den Technical Support 

bereit, der von IT Service Management Prozessen 

benötigt wird. 

Technical Analyst/Technical 

Architect 

Führt allgemeine Aktivitäten des Technical Management 

aus, ausgenommen der täglichen operativen Aktionen, 

die von Operator-Mitarbeitern entweder im Technical 

oder im IT Operations Management durchgeführt werden. 

Technical Management Die Funktion, die für die Bereitstellung von technischem 

Fachwissen zur Unterstützung von IT Services und für 

das Management der IT-Infrastruktur verantwortlich ist. 

Definiert die Rollen von Support-Gruppen sowie die 

erforderlichen Tools, Prozesse und Verfahren. 

Rolle Service 

Operations 

Rolle Service 

Operations 


Service 

Improvement 

Rolle Service 

Design 


Service 

Improvement 



Service 

Improvement 

Rolle Service 

Design 

Rolle Service 

Design 

Rolle Service 

Transition 

Rolle Service 

Operations 

Rolle Service 

Design 


Operations 

Rolle Service 

Operations 


Operations 




Technical Manager/Teamleiter 

Zuständig für allgemeine Leitung, Steuerung und Entscheidungsfindung 

für das technische Team oder die 

Abteilung. 

Technical Operator Führt alltägliche operative Aufgaben im Technical 

Management durch und stellt in der Regel ein dediziertes 

Team für den IT-Betrieb dar. 

Test-Support Ermöglicht und unterstützt die Durchführung unabhängiger 

Tests aller im Rahmen des Service Transition 

Programms oder Projekts bereitgestellten Komponenten. 

Vertragsmanager Entwirft, verhandelt, überwacht und verwaltet juristische 

und geschäftliche Verträge im Auftrag der Sourcing- 

Organisation. 

Tabelle 21: Organisatorische Aufbauelemente der ITIL 

Rolle Service 

Operations 

Rolle Service 

Operations 

Rolle Service 

Transition 

Rolle Service 

Strategy 



Anhang N Organisatorische Aufbauelemente der COBIT 

Die folgenden organisatorischen Aufbauelemente wurden aus der offiziellen Dokumentation 

zur COBIT in der Version 4.1 rekonstruiert. Dabei wurden sowohl die zu jedem Prozess bzw. 

jeder Aktivität per RACI-Chart zugeordneten Strukturen berücksichtigt als auch die in den 

Control Objectives erwähnten Aufbauelemente mit aufgenommen. Der Ursprung eines Aufbauelements 

wird entsprechend in der Spalte „Quelle“ angegeben. Dabei werden „allgemeine“ 

Aufbauelemente, die in (fast) jedem RACI-Chart von COBIT zu finden sind, mit dem 

Kürzel „RACI“ als Quelle gekennzeichnet (vgl. [COBIT], S. 28). Ansonsten werden die jeweilig 

IDs der Prozesse und Control-Objectives verwendet, in denen ein entsprechender Verweis 

zu finden ist. Bei Elementen, die in COBIT selbst nicht näher spezifiziert werden wird 

ggf. auf Sekundärliteratur ausgewichen (z. B. Gaulke 2010, S. 30f.). Da sich COBIT bei 

einzelnen Aufbauelementen eng an die Begrifflichkeit von ITIL anlehnt, wird an entsprechender 

Stelle darauf verwiesen. 

Aufbauelement Kurzbeschreibung Typ Quelle 

IT Architecture Board A committee that provides architecture guidelines and Gremium 

advice on their application, and to verify compliance. 

This entity should direct IT architecture design, ensuring 

that it enables the business strategy and considers 

regulatory compliance and continuity requirements. 

PO 3.5 

Board In COBIT nicht näher spezifiziert. Gremium ME1, ME2, 

ME7 

Business Executive In COBIT nicht näher spezifiziert. 

Leitender Angestellter im Fachbereich. 

Rolle RACI 

Business Process Owner In COBIT nicht näher spezifiziert. 

Rolle RACI 

(BPO) 

Verantwortlicher für die Identifikation von Anforderungen, 

Abnahme des Designs und Management der 

Prozessleistung. 

Chief Architect In COBIT nicht näher spezifiziert. 

Verantwortlicher für die IT-Architektur. 

Rolle RACI 

Chief Executive Officer 

(CEO) 

The highest-ranking individual in an organization. Rolle RACI 

Chief Financial Officer The individual primarily responsible for managing the Rolle RACI 

(CFO) 

financial risks of an organization. 

Chief Information Officer The individual responsible for the IT group within an Rolle RACI 

(CIO) 

organization. In some cases, the CIO role has been 

expanded to become the chief knowledge officer (CKO), 

who deals in knowledge, not just information. 

Compliance, Audit, Risk Groups with control responsibilities but not operational IT Gremium RACI 

and Security 

responsibilities. 

Configuration Manager Nicht näher spezifiziert, vgl. ITIL Rolle DS9 

Chief Technology Officer Focuses on technical issues in an organization. The title Rolle - 

(CTO) 

CTO is often viewed as synonymous with CIO. 

Data Owners Individuals, normally managers or directors, who have Rolle 

responsibility for the integrity, accurate reporting and use 

of computerized data. 

PO2 

Deployment Team Nicht näher spezifiziert, vgl. ITIL Gremium AI4 

Head Development In COBIT nicht näher spezifiziert. 

Verantwortlicher für die IT-Entwicklung. 

Rolle RACI 

Head IT Administration In COBIT nicht näher spezifiziert. 

Verantwortlicher für die IT-Administration. 

Rolle RACI 



Aufbauelement Kurzbeschreibung Typ Quelle 

Head Operations In COBIT nicht näher spezifiziert. 

Verantwortlicher für den IT-Betrieb. 

IT Steering Committee Committee composed of executive, business and IT 

management to: Determine prioritization of IT-enabled 

investment programs in line with the enterprise’s business 

strategy and priorities, track status of projects and 

resolve resource conflict, and Monitor service levels and 

service improvements. 

Rolle RACI 

Gremium PO 4.3 

IT Strategy Committee Committee at the level of the board of directors to Gremium 

ensure that the board is involved in major IT matters/decisions. 

The committee is primarily accountable 

for managing the portfolios of IT-enabled investments, IT 

services and other IT resources. The committee is the 

owner of the portfolio. 

PO 4.2 

Problem Manager In COBIT nicht näher spezifiziert, vgl. ITIL Rolle DS10 

Project Management 

Officer (PMO) 

Service Desk/ Incident 

Manager 

Project management officer; the individual function 

responsible for the implementation of a specified initiative 

for supporting the project management role and 

advancing the discipline of project management. 

Rolle RACI 

In COBIT nicht näher spezifiziert, vgl. ITIL Rolle DS8 

Service Manager In COBIT nicht näher spezifiziert, vgl. ITIL. 

Jedoch in COBIT eher Definition, Verhandlung und 

Abschluss von Vereinbarungen sowie deren Monitoring 

als die Erbringung des Services. Demnach eher auf 

Abnehmer- als auf Anbieterseite (vgl. ISACA & itSMF 

2008, S. 55) 

Rolle DS1 

Service Provider External entity that provides services to the organization. Rolle DS1, DS2, 

DS4 

Training Department In COBIT nicht näher spezifiziert. Gremium AI4, DS7 

Tabelle 22: Organisatorische Aufbauelemente der COBIT 



Anhang O Notation der Semantischen Netze 

Notationssymbol Bedeutung 

Ein Begriff wird als Knoten dargestellt. 

Eine Kante zwischen zwei Begriffen verweist auf eine 

Zusammenhang bzw. eine Beziehung zwischen den 

beiden Begriffen (den beiden Knoten). Die Kante trägt 

einen Bezeichner, der diesen Zusammenhang konkretisiert. 

Zur weiteren Konkretisierung eines Zusammenhangs 

zwischen zwei Begriffen kann durch eine gestrichelte 

Linie ein anderer Begriff referenziert werden. Dieser 

Begriff dient der Verfeinerung bzw. näheren Beschreibung 

der Beziehung.

suchung zu COBIT und ITIL - Koordinierungs

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?