Enterprise-Architecture-

Management
IM_EAM, SS 2018, EAMgmt#SS18
Teil 9
TOGAF ADM

07.06.2018 IM_EAM, SS 2018, Teil 9 1

 Vorbereitung
07.06.2018 IM_EAM, SS 2018, Teil 9 2

Registrieren Sie sich für die Demo des EAM Tools iteraplan
https://www.iteraplan.de/online-demo/
 WIEDERHOLUNG TEIL 8

07.06.2018 IM_EAM, SS 2018, Teil 9 3

 Teil 2
TOGAF - The Open Group Architecture Management
Framework
07.06.2018 IM_EAM, SS 2018, Teil 9 4

• TOGAF basiert auf dem Technical Architecture Framework for Information

Management (TAFIM) des Department of Defense
(Verteidigungsministerium) der Vereinigten Staaten von Amerika.
• Es wird aktuell von der Open Group weiterentwickelt, einem Konsortium,
dem ca. 400 Unternehmen angehören, die ein gemeinsames Interesse an
der Schaffung herstellerunabhängiger Standards im IT-Bereich haben. Ein
Großteil der an der TOGAF-Spezifikation beteiligten Unternehmen sind IT-
Dienstleister, Technologie- und Beratungsunternehmen.
• TOGAF wird seit April 2018 in der
Version 9.2 geführt.
• Einzelpersonen können sich nach TOGAF
zertifizieren lassen (Foundation und
Certified). Unternehmen als Ganzen sind
nicht zertifizierbar.

Quelle: The Open Group, TOGAF Version 9.2, Figure 1-1: Structure of the TOGAF Standard, 2018
 TOGAF 9.2 Struktur
07.06.2018 IM_EAM, SS 2018, Teil 9 5

Part I - Kurze Einführung in die Kernkonzepte der Unternehmensarchitektur

Introduction und TOGAF sowie Definitionen zu den wichtigsten Begriffen

Part II - Der Kern von TOGAF beschreibt die TOGAF

Architecture Architecture Development Method (ADM) –
Development einen phasenbasierten Ansatz zur
Method Entwicklung einer Unternehmensarchitektur

Part III - ADM Diese Sammlung enthält eine Reihe von

Guidelines and Anleitungen unnd Methoden, die bei der
Techniques Anwendung von TOGAF und der TOGAF ADM
helfen

Quelle: http://pubs.opengroup.org/architecture/togaf92-doc/arch/
 TOGAF 9.2 Struktur
07.06.2018 IM_EAM, SS 2018, Teil 9 6

Part IV - Das TOGAF Content Framework beinhaltet u.

Architecture a. ein strukturiertes Metamodell für
Content Architektur-Artefakte, wiederverwendbare
Framework Architektur-Bausteine und typische
Ergebnisse der Architekturarbeit.
Part V - Dieser Teil behandelt die notwendige
Enterprise Taxonomie und Tools, die zur Kategorisierung
Continuum and und Speicherung der Ergebnisse der
Tools Architekturarbeit im Unternehmen benötigt
werden.
Part VI - Die für die Implementierung und den Betrieb
Architecture der Architektur-Funktion eines
Capability Unternehmens benötigte Organisation,
Framework Prozesse, Skills, Rollen und
Verantwortlichkeiten.

Quelle: http://pubs.opengroup.org/architecture/togaf92-doc/arch/
 Part I - Introduction
07.06.2018 IM_EAM, SS 2018, Teil 9 7

Part I - 1.Introduction
Introduction 2.Core Concepts
3.Definitions

Quelle: http://pubs.opengroup.org/architecture/togaf92-doc/arch/
 Struktur des TOGAF Standards
07.06.2018 IM_EAM, SS 2018, Teil 9 8

Quelle: The Open Group, TOGAF Version 9.2, Figure 1-1: Structure of the TOGAF Standard, 2018
 Teil 4

Architekturdomänen nach TOGAF

07.06.2018 IM_EAM, SS 2018, Teil 9 9

Bei der Nutzung von TOGAF wird die Unternehmensarchitektur üblicherweise

in den drei Domänen Geschäftsarchitektur, Informationssystemarchitektur
(bestehend aus Anwendungsarchitektur und Datenarchitektur) und
Technologiearchitektur modelliert.

Quelle: https://de.wikipedia.org/wiki/TOGAF#Struktur_zur_Beschreibung_der_Unternehmensarchitektur
 Part II - Architecture Development Method
07.06.2018 IM_EAM, SS 2018, Teil 9 10

Part II - 4.Introduction to Part II

Architecture 5.Preliminary Phase
Development 6.Phase A: Architecture Vision
Method
7.Phase B: Business Architecture
8.Phase C: Information Systems Architectures
9.Phase C: Information Systems Architectures - Data
Architecture
10.Phase C: Information Systems Architectures - Applications
Architecture
11.Phase D: Technology Architecture
12.Phase E: Opportunities and Solutions
13.Phase F: Migration Planning
14.Phase G: Implementation Governance
15.Phase H: Architecture Change Management
16.ADM Architecture Requirements Management
Quelle: http://pubs.opengroup.org/architecture/togaf92-doc/arch/
 Part III - ADM Guidelines and Techniques
07.06.2018 IM_EAM, SS 2018, Teil 9 11

Part III - ADM 17.Introduction to Part III

Guidelines and 18.Applying Iteration to the ADM
Techniques 19.Applying the ADM across the Architecture Landscape
20.Architecture Principles
21.Stakeholder Management
22.Architecture Patterns
23.Gap Analysis
24.Migration Planning Techniques
25.Interoperability Requirements
26.Business Transformation Readiness Assessment
27.Risk Management
28.Capability-Based Planning

Quelle: http://pubs.opengroup.org/architecture/togaf92-doc/arch/
 ADM Guidelines and Techniques
07.06.2018 IM_EAM, SS 2018, Teil 9 12

• Die ADM Guidelines and Techniques enthalten eine Reihe von Richtlinien
und Techniken, um die Anwendung des ADM zu unterstützen.
• Zu den Richtlinien gehört die Anpassung des ADM an eine Reihe von
Anwendungsszenarien, einschließlich verschiedener Prozessstile - die
Verwendung von Iterationen und die Anwendung des ADM über alle
Architekturlandschaft.
• Es gibt auch eine allgemeine Beschreibung der Verwendung des TOGAF-
Frameworks mit verschiedenen Architekturstilen anhand von SOA als
Beispiel.
• Die Techniken unterstützen spezifische Aufgaben innerhalb des ADM (wie
etwa Capability-based Planning, das Definieren von Prinzipien, die Gap-
Analyse, das Risikomanagement usw.).

Quelle: TOGAF 9.2

 ADM in der Architekturlandschaft
07.06.2018 IM_EAM, SS 2018, Teil 9 13

In einem typischen Unternehmen werden zu jedem Zeitpunkt viele

Architekturen in der Architekturlandschaft beschrieben. Einige Architekturen
werden sehr spezifische Bedürfnisse adressieren; andere werden allgemeiner
sein. Einige werden Details behandeln; einige werden ein großes Bild liefern.

Quelle: TOGAF 9.2

 Teil 3

Architekturprinzipien
07.06.2018 IM_EAM, SS 2018, Teil 9 14

• Prinzipien sind Grundsätze, die man seinem Handeln zugrunde Definition

legt. Prinzipien sind allgemeingültig, abstrakt, allgemeinster Art. Sie bilden
eine theoretische Grundlage. Prinzipien werden aus der Erfahrung und
Erkenntnis hergeleitet und durch sie bestätigt.

• Sie sollten sehr stabil und dauerhaft gültig sein sowie nur einer sehr
seltenen Änderung unterliegen

• Architekturprinzipien steuern den Architekturprozess im Bezug auf

Entwicklung, Pflege und Nutzung der Unternehmensarchitektur

Quelle: H. Balzert, Lehrbuch der Softwaretechniken, 2011

 TOGAF Gap Analyse
07.06.2018 IM_EAM, SS 2018, Teil 9 15

In TOGAF wird die Gap-Matrix als wirkungsvolle Methode beschrieben, um die Target
Architecture auf Vollständigkeit bezüglich der Anforderungen zu untersuchen.
Geschäftsarchitektur Datenarchitektur
People gaps (e.g., cross-training requirements) • Daten sind nicht genau genug
Process gaps (e.g., process inefficiencies) • Daten nicht verfügbar, wo sie benötigt
Tools gaps (e.g., duplicate or missing tool werden
functionality) • Benötigte Daten sind nicht verfügbar
Information gaps • Daten nicht zum benötigten Zeitpunkt
Measurement gaps verfügbar
Financial gaps • Daten werden nicht erzeugt
Facilities gaps (buildings, office space, etc.) • Daten werden nicht konsumiert
• Lücken bei Beziehungen zwischen Daten
Technologie-Architektur Applikations-Architektur
• Lücken bei der Beseitigung oder • Lücken bei der Beseitigung oder
Anschaffung von Technologien Anschaffung von Applikationen
• Lücken bei der Betrachtung von • Lücken bei der Betrachtung von
Auswirkungen auf bestehende Technologien Auswirkungen auf bestehende
Quelle: TOGAF 9.2 Applikationen
 Teil 7

TOGAF Capability-Based Planning

07.06.2018 IM_EAM, SS 2018, Teil 9 16

TOGAF sieht Capabilities eher als horizontale Aspekte (Cross Cutting Concerns).
TOGAF enthält zwar auch eine Definition von Capabilities, die in etwa den
Definitionen von Microsoft und Forrester entspricht. In Kapitel 28 von TOGAF 9.2
werden Capabilities auf lediglich 6 Seiten als Planungsinstrument diskutiert und es
wird dort eher der horizontale Aspekt betont.

Quelle: Keller, EAM - Capabilities (2014-05-22),

TOGAF 9.2
 Part IV - Architecture Content Framework
07.06.2018 IM_EAM, SS 2018, Teil 9 17

Part IV - 29.Introduction to Part IV

Architecture 30.Content Metamodel
Content 31.Architectural Artifacts
Framework
32.Architectural Deliverables
33.Building Blocks

Quelle: http://pubs.opengroup.org/architecture/togaf92-doc/arch/
 Part IV - Architecture Content Framework
07.06.2018 IM_EAM, SS 2018, Teil 9 18

Das Architecture Content Framework bietet ein detailliertes Modell von

Produkten für die Architekturarbeit, einschließlich zu liefernder Elemente,
Artefakten innerhalb der zu liefernden Elemente und den Architecture
Building Blocks (ABBs), die Artefakte darstellen.

Quelle: TOGAF 9.2

 Teil 4

TOGAF - Architecture Content Framework (ACF)

07.06.2018 IM_EAM, SS 2018, Teil 9 19

• Das Architecture content framework definiert und klassifiziert die Ergebnisse

der Architekturarbeit
• Das Architecture content framework strukturiert (modelliert) die ADM
outcomes in drei Kategorien
– deliverables: dokumentierte Lieferergebnisse, die mit stakeholders vereinbart sind
und an diese geliefert werden
– artifacts: die in anderen Szenarien wiederverwendbaren Teile dieser
Dokumentation
– architecture building blocks: die wiederverwendbaren Architekturkomponenten
(Architekturbausteine und Lösungsbausteine)

• Das ACF sichert höhere Konsistenz der TOGAF-Outputs (Ergebnistypen)

• Enthält Prüflisten für die Reihenfolge und die Erstellung der verschiedenen
Architektur-Outputs
• Es erhöht die Integrationsgrad der eigenen Arbeitsergebnisse
• Es wird ein offener und genormter Weg vorgegeben der die Architektur
beschreibt
• Es enthält das detaillierte Metamodell
 Teil 4

ACF - Aufbau Arbeitsergebnisse und Artefakte

07.06.2018 IM_EAM, SS 2018, Teil 9 20

Quelle: TOGAF 9.2

 Teil 4

TOGAF Content Metamodel

07.06.2018 IM_EAM, SS 2018, Teil 9 21

Das Content Meta-

model definiert und
kategorisiert die
verschiedenen
Bausteine der
Architektur und
beschreibt deren
Beziehung
zueinander.

Quelle: TOGAF 9.2

 Teil 4

Das TOGAF Metamodell

07.06.2018 IM_EAM, SS 2018, Teil 9 22

Die Unterteilung des Content Metamodells in Kernbestandteile und

Erweiterungen ermöglicht die Schrittweise Ergänzung des Gesamtmodells.
Der Kern (Core) definiert das minimale Set an Architekturinhalten.
Erweiterungen (Extensions) enthalten optionale zusätzliche Konzepte, um
spezifische Aufgaben zu unterstützen.

Quelle: TOGAF 9.2

 Teil 4

TOGAF – Core Content Metamodel

07.06.2018 IM_EAM, SS 2018, Teil 9 23

Quelle: TOGAF 9.2

 Part V - Enterprise Continuum and Tools
07.06.2018 IM_EAM, SS 2018, Teil 9 24

Part V - 34.Introduction to Part V

Enterprise 35.Enterprise Continuum
Continuum and 36.Architecture Partitioning
Tools
37.Architecture Repository
38.Tools for Architecture Development

Quelle: http://pubs.opengroup.org/architecture/togaf92-doc/arch/
 Teil 4

Enterprise Continuum
07.06.2018 IM_EAM, SS 2018, Teil 9 25

• Das Enterprise Continuum bildet das Inhaltsverzeichnis für relevante

Informationen aus verschiedenen Quellen auf Basis der Sprache des
Content Metamedells.
• Es besteht aus zwei komplementären Elementen
– Architecture Continuum
– Solutions Continuum
• TOGAF betrachtet die EA als Kontinuum (ein lückenlosen,
zusammenhängendes Gebilde) von verschiedener Architekturen, die sich
von generischen Architekturen zu immer spezifischeren Architekturen
verbinden
• Der Entwicklungsprozess einer eigenen EA wird als andauernde Bewegung
vom generischen zu spezifischen betrachtet
• ADM ist der Prozess der diese Spezifizierung beschreibt
 Elemente des Enterprise Continuum
07.06.2018 IM_EAM, SS 2018, Teil 9 26

Quelle: TOGAF 9.2

 Teil 4

Elemente des Enterprise Continuum

07.06.2018 IM_EAM, SS 2018, Teil 9 27

Quelle: TOGAF 9.2

 Tools for Architecture Development
07.06.2018 IM_EAM, SS 2018, Teil 9 28

Erfolgreiche Enterprise Architecture-Teams sind häufig diejenigen, die ihre

Architektur-Tools mit ihrem Reifegrad in der Architektur, ihren Team- /
Organisationsfähigkeiten und Zielen oder Fokus harmonisieren.
Wenn verschiedene Organisationen innerhalb eines Unternehmens
unterschiedliche Architektur-Reifegrade haben und unterschiedliche Ziele
oder Schwerpunkte haben (z. B. Enterprise versus Business versus Technology
Architecture), wird es für ein Tool sehr schwierig, alle Anforderungen der
Organisation zu erfüllen.

Quelle: TOGAF 9.2

 Part VI - Architecture Capability Framework
07.06.2018 IM_EAM, SS 2018, Teil 9 29

Part VI - 39.Introduction to Part VI

Architecture 40.Establishing an Architecture Capability
Capability 41.Architecture Board
Framework
42.Architecture Compliance
43.Architecture Contracts
44.Architecture Governance
45.Architecture Maturity Models
46.Architecture Skills Framework

Quelle: http://pubs.opengroup.org/architecture/togaf92-doc/arch/
 Part VI - Architecture Capability Framework
07.06.2018 IM_EAM, SS 2018, Teil 9 30

Quelle: TOGAF 9.2

 Part VI - Architecture Capability Framework
07.06.2018 IM_EAM, SS 2018, Teil 9 31

Das Architecture Capability Framework ist eine Sammlung von Ressourcen,

Richtlinien, Vorlagen, Hintergrundinformationen usw., die dem Architekten
helfen sollen, Enterprise Architecture Management innerhalb einer
Organisation zu etablieren.

Quelle: TOGAF 9.2


Reifegradmodell ACMM von TOGAF
07.06.2018
Das DoC ACMM (Department of Commerce Architecture Capability Maturity
Model) hat 6 Maturity Level und 9 Architektur Element.
9 Architekturelement
Architekturprozess
Architekturentwicklung
Zusammenarbeit mit der Fachseite
Engagement des
Seniormanagement
Beteiligung der operationalen
Einheiten
Kommunikation
IT-Sicherheit
Architektur-Governance
IT-Investitions- und
Beschaffungsstrategie
Quelle: TOGAF, 9.1
Teil 6
IM_EAM, SS 2018, Teil 9 32
Reifegrade Beispielhafte Eigeenschaften
0 None Keine EAM-Aktivitäten vorhanden
1 Initial Die EAM-Aktivitäten finden ad hoc statt
2 Under Der EAM-Prozess ist dokumentiert und mit
development Rollen und Verantwortlichkeiten
beschrieben
3 Defined Das EAM ist im Detail definiert und
kommuniziert. Die Governance-Aktivitäten
sind explizit und dokumentiert
4 Managed Der EAM-Prozess ist ein Teil der
Unternehmenskultur.
5 Measured Der EAM-Prozess wird kontinuierlich
optimiert und verbessert.
 Was wird durch TOGAF abgedeckt
07.06.2018 IM_EAM, SS 2018, Teil 9 33

Layer / Term Abdeckung Bemerkung

durch
TOGAF
Enterprise TOGAF concentrates on IT architecture
Architecture
Enterprise IT TOGAF covers some Enterprise IT
Architecture Architecture Topics
Large Scale One of the cores of TOGAF (the ADM (architecture
Solution development method) has been explicitly designed
Architecture for large scale solution architecture
Solution Small scale solution architecture needs more
architecture artifacts than the ones defined in TOGAF (UML-
style artifacts)
 TOGAF - unterm Strich
07.06.2018 IM_EAM, SS 2018, Teil 9 34

Pro Contrat
• Hohe Marktdurchdringung • Inkonsistenz zwischen einzelnen
• Schulungen verfügbar Teilen
• Zertifizierungen verfügbar • Anpassung notwendig
• Konforme Werkzeuge verfügbar • TOGAF lernen ≠ TOGAF
• International anerkannt beherrschen
• Offene Entwicklung • Konkrete Vorgaben zur
Einführung von TOGAF fehlen
• Lean EAM als Gegenbewegung

Quelle: 160629 Matthes Useful EAM-Standards and Best-Practice Frameworks

 Vergleich TOGAF mit anderen Frameworks
07.06.2018 IM_EAM, SS 2018, Teil 9 35

Während Frameworks wie Zachman die Ergebnisse der Architekturarbeit klassifizieren,

beschreibt TOGAF ergänzend eine Methode für die Architekturentwicklung
Eine Beschreibung der Methode, mit der Definition und Klassifizierung der Ergebnisse,
die Ergebnisse erzeugt werden welche die Architekturarbeit erzeugt

Architecture Development Method (ADM) TOGAF Content Framework

Andere Frameworks (z.B. Zachman)

 Übung 8-5-1
07.06.2018 IM_EAM, SS 2018, Teil 9 36

Fragen aus dem TOGAF 9 Part 1 Practice Test:

According to TOGAF, all of the following are suggested elements of an

architecture framework, except ___

Choose one of the following answers

a) A common vocabulary
b) A list of recommended standards
c) A method for designing an information system in terms of building blocks
d) A set of structures which can be used to develop a broad range of
architectures
e) A system development lifecycle method for software engineering
Quelle: http://theopenarch.com/81-tests/72-togaf-9-exam-tests.html
 Übung 8-5-2
07.06.2018 IM_EAM, SS 2018, Teil 9 37

Fragen aus dem TOGAF 9 Part 1 Practice Test:

Complete the sentence: According to TOGAF, Capability-based Planning is ___

Choose one of the following answers

a) a tactical planning technique that enhances system performance

b) focused on business outcomes
c) focused on staffing and human resource management issues
d) focused on technical capabilities
e) not relevant to IT architecture

Quelle: http://theopenarch.com/81-tests/72-togaf-9-exam-tests.html
 Übung 8-5-3
07.06.2018 IM_EAM, SS 2018, Teil 9 38

Fragen aus dem TOGAF 9 Part 1 Practice Test:

Views and viewpoints are used by an architect to capture or model the design
of a system architecture. Which one of the following statements is true?

Choose one of the following answers

a) A view is the perspective of an individual stakeholder

b) A viewpoint is the perspective of an individual stakeholder
c) Different stakeholder always share the same views
d) Different stakeholder always share the same viewpoints

Quelle: http://theopenarch.com/81-tests/72-togaf-9-exam-tests.html
 Übung 8-5-4
07.06.2018 IM_EAM, SS 2018, Teil 9 39

Fragen aus dem TOGAF 9 Part 1 Practice Test:

Which of the following best describes the purpose of the TRM?

Choose one of the following answers

a) To provide a generic framework for IT governance

b) To provide a visual model, and core terminology for generic platform
services
c) To provide a list of standards
d) To provide a method for architecture development
e) To provide a system engineering viewpoint on a possible solution

Quelle: http://theopenarch.com/81-tests/72-togaf-9-exam-tests.html
 TEIL 9 – TOGAF ADM

07.06.2018 IM_EAM, SS 2018, Teil 9 40

 Inhalt
07.06.2018 IM_EAM, SS 2018, Teil 9 41

• ADM Überblick und Bereiche

• ADM Phasen
• Wichtige Artefakte
• Entwicklung Business Capabilities
 Part II - Architecture Development Method
07.06.2018 IM_EAM, SS 2018, Teil 9 42

Part II - 4.Introduction to Part II

Architecture 5.Preliminary Phase
Development 6.Phase A: Architecture Vision
Method
7.Phase B: Business Architecture
8.Phase C: Information Systems Architectures
9.Phase C: Information Systems Architectures - Data
Architecture
10.Phase C: Information Systems Architectures - Applications
Architecture
11.Phase D: Technology Architecture
12.Phase E: Opportunities and Solutions
13.Phase F: Migration Planning
14.Phase G: Implementation Governance
15.Phase H: Architecture Change Management
16.ADM Architecture Requirements Management
Quelle: http://pubs.opengroup.org/architecture/togaf92-doc/arch/
 Part II - Architecture Development Method
07.06.2018 IM_EAM, SS 2018, Teil 9 43

Das ADM beschreibt, wie eine organisationsspezifische Unternehmens-

architektur abgeleitet werden kann um die Geschäftsanforderungen zu
erfüllen.
Das ADM ist der Hauptbestandteil von TOGAF und bietet eine
Orientierungshilfe für Architekten auf verschiedenen Ebenen:
• Es bietet einen Zyklus von Architekturentwicklungsphasen
(Geschäftsarchitektur, Informationssystemarchitekturen,
Technologiearchitektur) als eine Prozessvorlage für die
Architekturentwicklung
• Es beschreibt die Architekturphasen in Bezug auf Ziele, Ansatz, Inputs,
Schritte und Outputs
• Es bietet phasenübergreifende Aspekte, die das Anforderungs-
management abdecken

Quelle: TOGAF 9.2

 TOGAF - Architecture Development Method (ADM)
07.06.2018 IM_EAM, SS 2018, Teil 9 44

Die ADM beinhaltet neun

Phasen, die vorgeben
sollen, wie ein architektur-
relevantes IT-Projekt
inhaltlich zu strukturieren
ist.
Durch Views werden
Sichten auf die Architektur
aus der Perspektive von
Stakeholdern (Viewpoints)
in den Phasen beschrieben.

Quelle: TOGAF 9.2

 TOGAF - Architecture Development Method (ADM)
07.06.2018 IM_EAM, SS 2018, Teil 9 45

Phase Prelim (Vorbereitung)

und A des ADM sind der
Architekturkontext

Zweiter Bereich, Phase B bis D

des ADM sind die
architektonischen
Anforderungen

Dritter Bereich, Phase E bis F

des ADM sind die technische
Umsetzung

Vierter Bereich, Phase G bis H

ist die Überwachung der
bestehenden Architektur und
Planung des nächsten Zyklus

Quelle: https://thunk.technology/blog/togaf-adm-big-bang-theory
 Architekturdomänen nach TOGAF
07.06.2018 IM_EAM, SS 2018, Teil 9 46

Bei der Nutzung von TOGAF wird die Unternehmensarchitektur üblicherweise

in den drei Domänen Geschäftsarchitektur, Informationssystemarchitektur
(bestehend aus Anwendungsarchitektur und Datenarchitektur) und
Technologiearchitektur modelliert.

Quelle: https://de.wikipedia.org/wiki/TOGAF#Struktur_zur_Beschreibung_der_Unternehmensarchitektur
 ArchiMate® 3.0 und TOGAF ADM
07.06.2018 IM_EAM, SS 2018, Teil 9 47

Quelle: http://www3.opengroup.org/subjectareas/enterprise/archimate/3.0-whats-new
 ADM Phasen
07.06.2018 IM_EAM, SS 2018, Teil 9 48
 Preliminary Phase
07.06.2018 IM_EAM, SS 2018, Teil 9 49

Diese Phase beschreibt die

Vorbereitungs -und Initialaktivitäten
die notwendig sind, um anhand der
Geschäftsdirektive eine erste und
neue EA in der organisations-
spezifischen Form umzusetzen.

Quelle: TOGAF 9.2

 Preliminary Phase - Ziele
07.06.2018 IM_EAM, SS 2018, Teil 9 50

1. Angestrebte Architektur-Capability bestimmen

– Organisatorischen Kontext bewerten
– Elemente der Organisation identifizieren, die von der Architektur-Capability
betroffen sind
– Identifikation etablierter Frameworks und Methoden, die mit der Architektur-
Capability verknüpft sind

2. Etablierung der Architektur-Capability

– Organisation der Architektur-Capability bestimmen
– Detaillierte Prozesse und Ressourcen für die Architekturgovernance
bestimmen
– Unterstützende Tools auswählen und implementieren
– Architekturprinzipien festlegen
 Preliminary Phase - Ansatz
07.06.2018 IM_EAM, SS 2018, Teil 9 51

In dieser Phase geht es darum, "wo, was, warum, wer und wie wir Architektur
machen" im Unternehmen zu definieren. Die wichtigsten Aspekte sind:
• Definition des Unternehmens
• Identifizierung der zentralen Treiben und Ihrer Elemente im orga. Kontext
• Definition der Anforderungen für architektonische Tätigkeiten
• Definition der Architekturprinzipien
• Definition des Frameworks das eingesetzt werden soll
• Definition der Abhängigkeiten zwischen den Frameworks
• Evaluierung der EA-Reife
 Preliminary Phase – Input / Output
07.06.2018 IM_EAM, SS 2018, Teil 9 52

Inputs der Phase:

• Businessplan, Geschäftsstrategie, IT-Strategie, Geschäftsprinzipien,
Geschäftsziele, Geschäftstreiber, Geschäftspartner und Vertragsabschlüsse

Outputs der Phase:

• Umfang der Beeinträchtigung in der Organisation
• Rollen und Verantwortlichkeiten
• Unternehmensspezifisches EA-Framework (Architekturprinzipien)
• Finanzielle Anforderungen
• Bedingungen an die architektonischen Tätigkeiten
 Input – Bearbeitungsschritte - Output
07.06.2018
• TOGAF
• Andere Architektur-
Frameworks
• Geschäftsstrategie,
Geschäftsprinzipien,
Geschäftsziele und
Werttreiber
• Andere Management
Frameworks
• Governance Frameworks
• Budget
• Partnerschafts- und
Vertragsvereinbarungen
• IT-Strategie
• Organisationsmodell für
die EA
• Existierende Architektur-
Frameworks (im
Unternehmen)
• Architekturprinzipien
• Architektur-Repository
Quelle TOGAF 9.2
IM_EAM, SS 2018, Teil 9
Reichweite der
Architekturarbeit
festlegen
Bestätigung des
Architektur-Governance
Frameworks
Einrichten der Enterprise
Architecture Organisation
Identifikation und
Verabschiedung der
Architekturprinzipien
Auswahl und Anpassung
des Enterprise
Architecture Frameworks
Einführung eine EAM-
Tools
53
• Organisationsmodell für die
Unternehmensarchitektur
– Reichweite
– Reifegradeinschätzung und geplante
Weiterentwicklung
– Rollen und Verantwortlichkeiten
– Rahmenbedingungen
– Budgetbedarfe
– Governancestrategie
• Unternehmensspezifisches EA-
Framework
– Architekturentwicklungsmethode
– Architekturinhalt (Arbeitsergebnisse
und Artefakte)
– Architekturprinzipien
– Konfigurierte und einsatzbereite
Tools
• Initiales Architektur-Repository, gefüllt
mit Framework-Inhalt
• Bestätigung der Geschäftsstrategie,
Geschäftsprinzipien, Geschäftsziele und
Werttreiber
• Request for Architecture Work
(optional)
• Governance-Framework
 Phase A: Architecture Vision
07.06.2018 IM_EAM, SS 2018, Teil 9 54

In der Phase A der ADM geht es um

die Festlegung welchen Umfang die
Architekturvision haben soll. Auch
werden die Stakeholder identifiziert
und alle architekturrelevanten
Genehmigungen eingeholt.

Quelle: TOGAF 9.2

 Phase A: Architecture Vision - Ziele
07.06.2018 IM_EAM, SS 2018, Teil 9 55

Ziele der Phase:

• Entwicklung einer Vision der Fähigkeiten und des Wertbeitrags zum
Unternehmenserfolg (jeweils als Resultat der einzuführenden Enterprise
Architektur)
• Offizielle Bestätigung des Statements of Architecture Work, welches das
Programm zur Entwicklung und Ausführung der in der Vision
beschriebenen Architektur beschreibt
 Phase A: Architecture Vision - Ansatz
07.06.2018 IM_EAM, SS 2018, Teil 9 56

Generelle Vorgehensweise
• Anfrage nach Architekturarbeit (Umfang und Rahmenbedingungen der
Arbeit)
• Geschäftsprinzipien, -ziele und strategische Treiber konsolidieren

Erstellung der Architekturvision

• Stellt Mehrwert für die anderen Stakeholder und Entscheidungsträger dar
• Sichert Zustimmung über den Zweck des Aufwands
• Kernelemente der Architekturvision Unternehmensvision, -strategie und
-ziele müssen verfügbar sein
• Auftrag für die Architekturarbeit fasst Ziele zusammen und zeichnet sie
formal ab
 Phase A: Architecture Vision - Bearbeitungsschritte
07.06.2018 IM_EAM, SS 2018, Teil 9 57

• Einrichtung des Architekturprojekts

• Stakeholder und ihre Interessen bzw. Anforderungen identifizieren
• Bestätigung oder Ausarbeitung der Geschäftsziele, Werttreiber und
Rahmenbedingungen
• Bewertung der Fähigkeiten
• Prüfung der Bereitschaft zur Geschäftstransformation
• Reichweite der Architekturarbeit festlegen
• Bestätigung oder Ausarbeitung der Architekturprinzipien
• Entwicklung der Architekturvision
• Definieren Sie die Zielarchitekturwertvorschläge und KPIs
• Risiko-Analyse der Geschäftstransformation und Maßnahmen
• Bestätigung des Auftrags für die Architekturarbeit
 Phase A: Architecture Vision – Input / Output
07.06.2018 IM_EAM, SS 2018, Teil 9 58

Input
• Architektur Referenzmaterial
• Anfrage für Architekturarbeiten (Request for Architecture Work)
• Geschäftsprinzipien, Geschäftsziele und Werttreiber
• Organisationsmodell für EA
• Unternehmensspezifisches EA-Framework
• Architektur-Repository
Output
• Abgestimmter Auftrag für die Architekturarbeit (Statement of Architecture Work)
– insbesondere Beschreibung und Umfang des Architekturprojekts, Überblick über Architektur Vision,
Architektur Projektplan und Zeitplan
• Verfeinerte Aussagen zu Geschäftsprinzipien, Geschäftszielen und Werttreibern
• Architekturprinzipien
• Fähigkeitsbeurteilung
• Unternehmensspezifisches EA-Framework
• Architektur Vision
– einschließlich Problembeschreibung, Ziel der Architekturarbeit, Übersichtsansichten, Geschäftsszenario
(optional), verfeinerte Anforderungen
• Entwurf eines Architecture Definition Document einschließlich:
– Ist-Architektur (Version 0.1) der Geschäfts-, Daten-, Anwendungs- und Technologiearchitektur
– Ziel-Architektur (Version 0.1) der Geschäfts-, Daten-, Anwendungs- und Technologiearchitektur
• Kommunikationsplan
• Aktualisiertes Architektur Repository
 ADM Konvention für Nummerierung von Versionen
07.06.2018 IM_EAM, SS 2018, Teil 9 59

Phase Deliverable Content Version Beschreibung

A: Architecture Vision Architecture Business 0.1 Version 0.1 weist darauf hin, dass eine grobe
Vision Architecture Gliederung der Architektur vorhanden ist.
Data 0.1 Version 0.1 weist darauf hin, dass eine grobe
Architecture Gliederung der Architektur vorhanden ist.
Application 0.1 Version 0.1 weist darauf hin, dass eine grobe
Architecture Gliederung der Architektur vorhanden ist.
Technology 0.1 Version 0.1 weist darauf hin, dass eine grobe
Architecture Gliederung der Architektur vorhanden ist.
B: Business Architecture Business 1.0 Version 1.0 weist auf eine formal überprüfte
Architecture Definition Architecture detaillierte Architektur hin.
Document
C: Information Architecture Data 1.0 Version 1.0 weist auf eine formal überprüfte
Systems Definition Architecture detaillierte Architektur hin.
Architecture Document Application 1.0 Version 1.0 weist auf eine formal überprüfte
Architecture detaillierte Architektur hin.
D: Technology Architecture Technology 1.0 Version 1.0 weist auf eine formal überprüfte
Architecture Definition Architecture detaillierte Architektur hin.
Document

Quelle: http://pubs.opengroup.org/architecture/togaf92-doc/arch/chap04.html#tagtcjh_1
 Übung 9-1
07.06.2018 IM_EAM, SS 2018, Teil 9 60

• Was ist das Architecture Definition Document?

• Welche Inhalte sollte es laut TOGAF haben?
 Phase B: Business Architecture
07.06.2018 IM_EAM, SS 2018, Teil 9 61

In Phase B werden Ist- und Ziel-

Geschäftsarchitektur beschrieben
und Maßnahmen zum Schließen der
Abweichungen festgelegt.

Quelle: TOGAF 9.2

 Phase B: Business Architecture - Ziele
07.06.2018 IM_EAM, SS 2018, Teil 9 62

• Entwicklung eines Zielbildes der Geschäftsarchitektur, die beschreibt, wie

das Unternehmen operieren sollte, um die strategischen Treiber zu
bedienen und die unternehmerischen Ziele zu erreichen
• Identifizierung erster Roadmap-Komponenten für die Programmplanung,
basierend auf Abweichungen zwischen Baseline- und
Zielgeschäftsarchitektur
 Phase B: Business Architecture – Ansatz / Output
07.06.2018 IM_EAM, SS 2018, Teil 9 63

• IST-Analyse der Geschäftsarchitektur durchführen. Das ist wesentliche

Voraussetzung für die weitere Architekturarbeit (Daten-, Anwendungs-
und Technologiearchitektur)
• Wirkungsbereich der Arbeiten in dieser Phase festlegen. Er ist davon
abhängig, inwiefern die Kernelemente der Geschäftsarchitektur schon im
Rahmen anderer Prozesse geplant und gesteuert werden.
• Geschäftsarchitektur dazu verwenden, den Key Stakeholdern den
unternehmerischen Wert der Architekturarbeit zu demonstrieren.

Wesentliche Ergebnisse
• Entwurf des Architecture Definition Document
– Ist-Geschäftsarchitektur (Version 1.0)
– Ziel-Geschäftsarchitektur (Version 1.0)
mit Organisationsstruktur, Geschäftsziele, Geschäftsfunktionen, Business
Services, Geschäftsprozesse, Rollen, Geschäftsdaten
 Phase C: Information Systems Architectures
07.06.2018 IM_EAM, SS 2018, Teil 9 64

In Phase C werden Zielarchitekturen

für die Daten- und Anwendungs-
domäne entworfen.

Quelle: TOGAF 9.2

 Phase C: Information Systems Architectures - Ziele
07.06.2018 IM_EAM, SS 2018, Teil 9 65

• Entwicklung eines Zielbildes der Informationssystemarchitektur, mit dem

Focus der Unterstützung der Businessarchitektur und Architektur Vision
• Identifizierung erster Roadmap-Komponenten für die Programmplanung,
basierend auf Abweichungen zwischen Baseline- und Target-
Informationssystemarchitektur
 Phase C: Data Architectures
07.06.2018 IM_EAM, SS 2018, Teil 9 66

Der erste Teil von Phase C umfasst alle notwendigen Schritte, um die
Datenarchitektur als einen Teil der Informationssystemarchitektur zu
realisieren.

Ziele der Phase:

• Entwicklung eines Zielbildes der Datenarchitektur, mit Focus auf der
Unterstützung der Businessarchitektur und Architektur Vision
• Identifizierung erster Roadmap-Komponenten für die Programmplanung,
basierend auf Abweichungen zwischen Baseline- und Target-
Datenarchitektur
• Kein Datenbankdesign
 Phase C: Application Architectures
07.06.2018 IM_EAM, SS 2018, Teil 9 67

Der zweite Teil von Phase C umfasst alle notwendigen Schritte, um die
Anwendungsarchitektur als zweiten Teil der Informationssystemarchitektur zu
realisieren.

Ziele der Phase:

• Entwicklung eines Zielbildes der Anwendungsarchitektur, mit Focus auf
der Unterstützung der Businessarchitektur und Architektur Vision
• Identifizierung erster Roadmap-Komponenten für die Programmplanung,
basierend auf Abweichungen zwischen Baseline- und Target-
Anwendungsarchitektur
 Phase C: Information Systems Architectures - Output
07.06.2018 IM_EAM, SS 2018, Teil 9 68

Wesentliche Ergebnisse
• Entwurf des Architecture Definition Document
– Ist-Datenarchitektur (Version 1.0)
– Ziel-Datenarchitektur (Version 1.0)
mit Geschäftsdatenmodell, Logisches Datenmodell, Modell des
Datenmanagement-Prozesses und Daten-Interoperabilitätsanforderungen
(Schema, Sicherheit)
– Ist- Anwendungsarchitektur (Version 1.0)
– Ziel- Anwendungsarchitektur (Version 1.0)
mit Funktionsmodell, Interaktionsmodell und Organisation/Rollen Modell
 Phase D: Technology Architecture
07.06.2018 IM_EAM, SS 2018, Teil 9 69

Die in Phase D entwickelte

Technologiearchitektur soll die
definierte Geschäfts-, Daten- und
Anwendungsarchitektur optimal
unterstützen.

Quelle: TOGAF 9.2

 Phase D: Technology Architecture – Ziele / Output
07.06.2018 IM_EAM, SS 2018, Teil 9 70

• Entwicklung eines Zielbildes der Technologiearchitektur, mit Focus auf

der Unterstützung der Businessarchitektur und Architektur Vision
• Identifizierung erster Roadmap-Komponenten für die Programmplanung,
basierend auf Abweichungen zwischen Baseline- und Target-
Technologiearchitektur

Wesentliche Ergebnisse
• Entwurf des Architecture Definition Document
– Ist-Technologiearchitektur (Version 1.0)
– Ziel-Technologiearchitektur (Version 1.0)
mit Technologie-Komponenten, Technologie-Plattformen, Umgebungen und
Standorte, Verarbeitungsmengen und „Load-Balancing“, physische
Kommunikationsnetze, Hardware- und Netzwerkspezifikationen
 Phase E: Opportunities & Solutions
07.06.2018 IM_EAM, SS 2018, Teil 9 71

In Phase E werden alternative

Lösungen geprüft und unter
Berücksichtigung anderer Initiativen
mit der Planung der Umsetzung
begonnen.

Quelle: TOGAF 9.2

 Phase E: Opportunities & Solutions - Ziele / Output
07.06.2018 IM_EAM, SS 2018, Teil 9 72

Das ist die erste Phase im ADM bei der es um Implementierung geht. Hier
sind die notwendigen Implementierungsprojekte zu identifizieren. Fokus liegt
bei Implementierungsprojekten die kurzfristig Erfolg und Gewinne einbringen
und Schwachstellen die schon länger bestehen schließen. Z.B. Schwachstellen
beim Austausch oder beim Bereitstellen von Daten

Wesentliche Ergebnisse
• Konsolidierte Roadmap mit Transitionsarchitekturen
• Implementierungs- und Migrationsplan (Version 0.1)
 Phase F: Migration Planning
07.06.2018 IM_EAM, SS 2018, Teil 9 73

In Phase F werden die in Phase E

definierten Implementierungs-
projekte priorisiert und in einem
Migrationsplan auf eine Zeitleiste
gebracht.

Quelle: TOGAF 9.2

 Phase F: Migration Planning - Ziele / Output
07.06.2018 IM_EAM, SS 2018, Teil 9 74

Eine Priorisierungsliste der Implementierungsprojekte fest zulegen. Z.B

mittels eines Projektportfoliomanagements, außerdem sind Kosten-Nutzen-
und Risikoanalysen durchzuführen.

Wesentliche Ergebnisse
• Finalisiertes Architecture Definition Document
• Finalisierte Architektur-Roadmap
• Implementierungs- und Migrationsplan (Version 1.0)
• Wiederverwendbare Bausteine
 Phase G: Implementation Governance
07.06.2018 IM_EAM, SS 2018, Teil 9 75

Phase G setzt die Governance für die

Implementierung auf.

Quelle: TOGAF 9.2

 Phase G: Implementation Governance - Ziele / Output
07.06.2018 IM_EAM, SS 2018, Teil 9 76

Sicherstellen der Konformität der Implamentierungsprojekte mit der

erarbeiteten Zielarchitektur
Ausführung angemessener Architektur-Governance gegenüber der Lösung
und implementierungsgetriebenen Change Requests

Wesentliche Ergebnisse
• Architektur-compliant bereitgestellte Lösungen und implementiertes
System
• Compliance Prüfung
 Übung 9-2
07.06.2018 IM_EAM, SS 2018, Teil 9 77

TOGAF definiert für die Compliance-Prüfung Konformitätsgrade.

• Wo sind diese definiert?
• Welche Konformitätsgrade werden definiert?
 Phase H: Architecture Change Management
07.06.2018 IM_EAM, SS 2018, Teil 9 78

In Phase H werden Methoden und

Regeln für das Management von
Veränderungen der Enterprise
Architecture festgelegt und
operationalisiert.

Quelle: TOGAF 9.2

 Phase H: Architecture Change Management - Ziele /
Output
07.06.2018 IM_EAM, SS 2018, Teil 9 79

Pflege und Aufrechterhaltung des Architekturlebenszyklus sicherstellen

Konforme Ausführung des Governance Frameworks sicherstellen
Sicherstellen, dass die Architektur-Capability des Unternehmens aktuellen
Anforderungen gerecht wird

Wesentliche Ergebnisse
• Veränderungen am Architektur-Framework und an den
Architekturprinzipien
• Neue Anfrage nach Architekturarbeit
 Requirements Management
07.06.2018 IM_EAM, SS 2018, Teil 9 80

Stellen sicher, dass die relevanten

Architekturanforderungen für jede
Phase verfügbar sind.

Quelle: TOGAF 9.2

 Wichtige Artefakte
07.06.2018 IM_EAM, SS 2018, Teil 9 81
 TOGAF – Artefakte nach ADM Phasen
07.06.2018 IM_EAM, SS 2018, Teil 9 82

Quelle: TOGAF 9.2

 Übung 9-3-1
07.06.2018 IM_EAM, SS 2018, Teil 9 83

Fragen aus dem TOGAF 9 Part 1 Practice Test:

In which phase does the Business Scenarios first get defined?

Choose one of the following answers

a) Preliminary phase
b) Phase A
c) Phase B
d) Phase C
e) Phase D

Quelle: http://theopenarch.com/81-tests/72-togaf-9-exam-tests.html
 Übung 9-3-2
07.06.2018 IM_EAM, SS 2018, Teil 9 84

Fragen aus dem TOGAF 9 Part 1 Practice Test:

Which of the following statements about Business Architecture is NOT correct?

Choose one of the following answers

a) A knowledge of the Business Architecture is a prerequisite for architecture

work in any other domain
b) Business Architecture is often necessary as a means of demonstrating the
business value of subsequent architecture work
c) Business Architecture looks at the Enterprise in abstraction and does not look
at the relationship between people and process
d) Business Architecture should support the agreed Architecture Vision
e) Business Architecture should demonstrate how stakeholder concerns are
addressed

Quelle: http://theopenarch.com/81-tests/72-togaf-9-exam-tests.html
 Übung 9-3-3
07.06.2018 IM_EAM, SS 2018, Teil 9 85

Fragen aus dem TOGAF 9 Part 1 Practice Test:

In which phase is an agreement reached on the architecture method to be

adopted?

Choose one of the following answers

a) Preliminary Phase
b) Phase A
c) Phase B
d) Phase E
e) Requirement Management Phase

Quelle: http://theopenarch.com/81-tests/72-togaf-9-exam-tests.html
 Entwicklung Business Capabilities
07.06.2018 IM_EAM, SS 2018, Teil 9 86
 Begriffsdefinitionen Business Capability
07.06.2018 IM_EAM, SS 2018, Teil 9 87

• Geschäftsfähigkeit (Capability) = wesentliche Fähigkeit des Unternehmens

• Startpunkt für die Betrachtung der Geschäftsarchitektur
Business Capability

A business capability defines the organization’s capacity to

Was successfully perform a unique business activity.
Capabilities:
Are the building blocks of the business,
represent stable business functions,
are unique and independent from each other,
are abstracted from the organizational model,
capture the business interests.
(Microsoft) (Forrest Research)

Wie

Geschäftsprozess
Wer Womit

Organisation IT Applikation
 Business Capability vs. Prozess
07.06.2018 IM_EAM, SS 2018, Teil 9 88

Quelle: Bente, EAM Bebauungsplanung, 2015, p17

 Busines Capabilities sind Funktionsbausteine, die die
Fähigkeiten eines Unternehmens darstellen
07.06.2018 IM_EAM, SS 2018, Teil 9 89

Business Capability als einheitlicher, stabiler Funktionsbaustein

Eigenschaften von Keine Eigenschaften von

Business Capabilities Business Capabilities

• fachlich gleichartige Funktionen • technische Systeme oder Services

• erbringbar mit spezifischen Fähigkeiten • abhängig von einem akuten Einsatzzweck
• nicht abhängig von anderen Capabilities • abhängig von einem bestimmten Bereich
• durch klare Aufgabenbereiche definiert oder Standort

 Angeordnet in einer strukturierten Art und Weise entsteht die Business Capability Map.
 Die einheitliche Darstellung von Business Capabilities
führt zu vielen Vorteilen.
07.06.2018 IM_EAM, SS 2018, Teil 9 90

Business Capability Maps ermöglichen/unterstützen …

Keine Silobildung in Anforderungs- &

Standorten, Bereichen oder der IT Bedarfsmanagement
 Ganzheitliche Betrachtung von Fähigkeiten über  Wer plant in diesem Bereich noch
Organisationsgrenzen hinweg Veränderungen oder hat
Anforderungen?

Einheitliche Sprache Ein Rundumblick Klare Verantwortlichkeiten

 Verbesserte Kommunikation in Ein einheitlicher Ordnungsrahmen führt zum  Einheitliche Granularität erlaubt es
Fachbereich und IT Aufzeigen von Zusammenhängen, eindeutige Rollen zuzuordnen
Überlappungen und Synergien

Heatmaps und Potenzialmaps Portfoliomanagement

 In welchen Bereichen habe ich Handlungsbedarf (zu  Welche Lösungen (Prozesse, Tools, Daten, …)
viele Tools, zu unterschiedliche Prozesse, gibt es in dem Bereich schon?
unterschiedliche Daten)

Business Capability Maps sind ein Ordnungsrahmen!

 Beispiel Archimate Business Capability Map
07.06.2018 IM_EAM, SS 2018, Teil 9 91

Quelle: http://blog.bizzdesign.com/archimate-3-strategy-concepts-and-capability-based-planning
Business Capability Maps sind Grundlage für
Heatmaps und damit Basis für weitere Maßnahmen
IM_EAM, SS 2018, Teil 9

Capability Map Mapping der Capabilities auf die IT-Systemlandschaft

1 2
Service Nachberei- Service- Mapping der Capabilities auf
Vertrieb tung erbringung
IT-Systeme
Termin- Customer Rechnungs- Capability 3.1 Capability 3.2
verein- stellung
baurng Care IT System x

Support Auftrags- IT System y

Mana- Diagnose erstellung
gement

Erstellung von Heatmaps für verschiedene Sichtweisen

3

Heatmap Heatmap
„Toolabdeckung“ „Prozessabdeckung“

3.1 3.2 3.3 3.1 3.2 3.3

3.4 3.5 3.6 3.4 3.5 3.6
3.7 3.8 3.9 3.7 3.8 3.9
 Eigenschaften, die bei der Erstellung von Business
Capablity Maps zu beachten sind.
07.06.2018 IM_EAM, SS 2018, Teil 9 93

Hohe Klare Unabhängigkeit von

Stabilität Verantwortlichkeiten Organisationseinheiten
- Betrachtung von stabilen - Jede Capability unterliegt und Prozessen
Fähigkeiten anstelle von einer klaren - Unter keinen Umständen darf
volatilen Prozessen Verantwortlichkeit eine Capability Standort oder
- Wachstum mit dem - Ist diese nicht zuordenbar, Bereich spezifisch sein
Unternehmen nur dann muss die Granularität - Jede Capability muss
möglich, wenn der geändert werden unternehmensweit gültig sein
Ordnungsrahmen keine oder und entsprechend granular
nur wenig Änderungen formuliert werden
erfährt

 Keine Einordnung nach  Wenn Verantwortliche  Abbildung erfolgt eher

veränderlichen
Elementen, sondern
anhand von aus
Unternehmenssicht
stabilen Fähigkeiten.
für Daten oder Eigentümer
eines Systems benötigt
werden, gibt die Capability
Map einen Anhaltspunkt
querschnittlich zu
Organigrammen bzw.
Standorten,
Organisationseinheiten
und Prozessen
 Beispiel der Business Capabilities des Fachbereichs IT
auf Ebene eins und zwei auf der CapMap
07.06.2018 IM_EAM, SS 2018, Teil 9 94

Strategisches Management Fahrzeugentwicklung

Strategie- & Enterprise
Unternehmens-
Unternehmens Innovations- Elektronik- Aggregat- Baugruppen- Fahrzeugsänd- Fahrzeug- Qualitäts-
Unternehm- Architecture kommunikation beziehungs- Interieur-design
ungsplanung Mgmt. Management management entwicklung entwicklung Inf.-Mgmt. erungsmgmt. projektmgmt. sicherung

Produktport- Forschung & Nachhaltigkeits Fahrzeugfkt.- Fahrwerk- Karosserie- Exterieur- Prototyp- Versuchs- Modul- Konstruktions- &
Governance planung & - entwicklung & träger- & Fertigungs-
folio-Mgmt. Entwicklung management bewertung entwicklung entwicklung design Testing Prüfung Management vorbereitung

Kunden und Partner Management Fahrzeug- und Komponentenfertigung

Kunden-
management

Kunden-
vertragsmgmt.
Vertriebs-
management

Kunden QoS &

SLA
Kundenauftrags
management

Flotten-
management
Kunden-
kontaktmgmt.

Kundenange-
botsmgmt.
Business Fertigungs-
auftragsmgmt.

Gießerei
Fertigungs-
planung

Kunststoff
Kapazitäts-
management

Motoren-
fertigung
Fertigungs-
steuerung

Fahrwerks-
fertigung

Werbe- &
Kampagnen
Service
Fulfillment
Provisionier-
ung
Kunden-Scoring &
Bewertung
Capability Presswerk

Werker-
Karosseriebau

Sitzfertigung
Montage

Getriebe-
Lackiererei

Produktquali-
führung fertigung tätssicherung
Logistik
Inbound-
Logistik

Behälter-
On-Site-Logistik

Logistikauftrags
Warenlager

Verpackungsma
Fahrzeugs-
bestandmgmt

Transport-
Map Einkauf und Beschaffung
Lieferanten- Kommission-
Sourcing Beschaffung
Management management nagement Management Management ierung

Finanzen und Controlling Unternehmensunterstützung

Finanzielle Liquiditäts- Devisen- Rechnungs- Personal- Personalein- Effektivitäts- & Revisions- & Sicherheits- Informations-
Treasury Controlling Mangement Qualitätsmgmt- Compliance Management
Steuerung management management wesen satzplanung Mgmt. Management

Risko- Gebäude-
… … … … … … … … … …
Management Management

94
 Sicht auf die Funktionsebene drei der IT-
Fachfunktionen.
07.06.2018 IM_EAM, SS 2018, Teil 9 95

Informationstechnologie-Management

IT-Steuerung Fachseiten- & Anforderungsmanagement IT-Sicherheit

IT Risk- und IT Kennzahlen- IT-Finanz- Fachkonzeptions- Fachseiten- Projekt-/system- IT-Security Application Security Network-Security
Compliance- Steuerung (IT- Management Management übergreifendes
Management Performance) Management Demand Mgmt. Management Managment Management

IT-Lizenz- Entwicklung IT- IT-Organisations- Identity & Access Informations-

Projekt-/system- sicherheit-Mgmt.
Management Strategie Entwicklung Management
spezifisches
Requirement
Innovations- IT-Lieferanten- IT-HR-Skill-
Mgmt.
Management Management Management

IT-Programm- und IT-Portfoliomanagement IT-Release-Management IT-Entwicklung

IT-Ressourcen- IT-Programm- Applikations- IT-Infrastuktur-
Management IT-Budgetplanung controlling Release Planung Rollout Planung Entwicklung Übergabe Betrieb
Entwicklung

IT-Projekt-
IT-Projekt-
Portfolio-
management
Management

IT-Qualitätsmanagement IT-Servicemanagement Enterprise Architecture Management

IT- Service Domänenmodell-
Produktqualitäts- IT-Prozessqualitäts- Service Strategy Service Design IT-Bebauung IT-Modulmgmt.
management management Transition Management

Continual Service Architektur-

Service Operation
Improvement management

Web/ Applikatinon Deployment

 Wie kommt man zu Business Capabilities
07.06.2018 IM_EAM, SS 2018, Teil 9 96

Generische Capability Maps und auch an Branchen angepasste Capability

Maps kann man extern beschaffen.

Quelle: Keller, EAM - Capabilities (2014-05-22)

Microsoft
 Orientierungskriterien für den Schnitt der Businness
Capabilities
07.06.2018
Informationsorientiert
► Eine Domäne ist eine kohärente
Ansammlung von Funktionalitäten,
deren Zusammengehörigkeit sich an
der Bearbeitung derselben
Informationsobjekttypen orientiert
Vorteile
 Gute zeitliche Stabilität des
Informationsobjektmodells und somit
des Domänenschnitts
 Erhöhrung von Vertrauen und
Akzeptanz in das Domänenmodell
 Verbesserte Übereinstimmung von
Informations- und Funktionsmodellen
Nachteile
 Mögliche Überschneidungen durch
ähnliche Funktionen für unter-
schiedliche Informationsobjekte
 Erschwerte Identifizierung funkt.
Synergien und Möglichkeiten der
Wiederverwendung
IM_EAM, SS 2018, Teil 9
Funktionsorientiert
► Die Zusammengehörigkeit der
Funktionen innerhalb einer Domäne
orientiert sich an der funktionalen
Ähnlichkeit der zu bearbeitenden
Aufgabe (ggfs. auf verschiedenen
Informationsobjekten)
Vorteile
 Gute Identifizierbarkeit von
Synergien und Redundanzen
 Erhöhung der Wiederverwendbarkeit
Nachteile
 Weniger enger Zusammenhang
zwischen Funktionalitäten und
Informationsobjekten und dadurch
ggfs. erhöhter Aufwand für die
Abstimmung (“Alignment”)
97
Kontextorientiert
► Die Gruppierung von Funktionalitäten
zu einer Domäne erfolgt auf Basis des
gemeinsamen fachlichen Kontextes
Vorteile
 Oftmals Repräsentation bekannter
Ordnungsstrukturen (z.B.
Organisationseinheiten) durch einen
Kontext
 Verbesserte Akzeptanz des Modells
Nachteile
 Übertragung möglicher Nachteile von
Organisationsstrukturen auf das
Modell
 Funktionale Synergien und
Redundanzen schwer zu
identifizieren und zu adressieren
 Ungeeignete Orientierungskriterien
07.06.2018 IM_EAM, SS 2018, Teil 9 98

Ungeeignetes Begründung
Kriterium
Geschäftsprozesse  Insbesondere Prozesse auf höheren Ebenen benötigen unterschiedlichste
Funktionalitäten, was der geforderten Kohärenz des Domänenmodells widerspräche
Organisationseinheiten  Das Domänenmodell sollte stabil bleiben. Dem widersprechen die erfahrungsgemäß
nicht selten vorgenommenen organisatorischen Umstrukturierungen.
Applikationen  Annahme ist, dass die funktionalen Grenzen der Anwendungen bzw. der Schnitt der
Applikationen (aus historischen Gegebenheiten) oftmals nicht zu der benötigten
fachlich-funktionalen Aufteilung der Domänen passt.
Produkte  Da die Produkte (hier im wesentlichen Fahrzeugmodelle oder fahrzeugbezogene
Mehrwertdienste) alle hinreichend ähnlich sind, sollten die Gemeinsamkeiten auch
gemeinsam (innerhalb einer Domäne) behandelt werden.
 Die Abstraktion von Unterschieden ermöglicht ggfs. Synergien.
Kundensegmente  Die Ähnlichkeit der für verschiedene Kundensegmente benötigten Funktionen macht
dieses Kriterium wenig sinnvoll
 Domänen sollten kundensegmentübergreifend funktionieren
Geographie  Ein möglichst hoher Grad an standort- u. werksübergreifender Standardisierung /
(Standorte, Werke) Wiederverwendung widerspricht der Nutzung als Kriterium
 Fachfunktionsschnitt Geschäftsfunktionsorientiert vs.
Kontextobjektorientiert
07.06.2018 IM_EAM, SS 2018, Teil 9 99

Risko-Management Risk-Management
Geschäftsfunktionsorientiert Kontextorientiert

Enterprise Risk Management Enterprise Risk Management

Manage Manage Bus.

Manage Fraud &
Establish Context Identify Risk Analyse Risk Information & Continuity &
Investigations
IT/NT Security Desaster Recov.

Accept Risk &

Monitor Risk Manage HR Manage Financial Manage Revenue
Treat Risk Compliance Sign
Management Security Risk Assurance
Off

Communicate & Manage Physical, Manage legal,

Consult Risk Manage Product &
Personal & Event normative &
Management Service Security
Security regulatory risks

The capabilities within the Business function Enterprise Risk The capabilities within the Business function Enterprise Risk
Management can be executed in the followings contexts: Management always comprise the following business functions:

Establish Context, Identify Risk, Analyze Risk, Treat Risk, Accept Risk
IT/NT Security, HR Security, Physical Security, Information Security, & Compliance Sign Off, Monitor Risk Management, Communicate &
Investigations, Personal & Event Security, Business Continuity & Consult Risk Management
Disaster Recovery Management, Product & Service Security, all legal,
normative and regulative contexts, Fraud, Financial Risk, and
Revenue Assurance
 Fachfunktionsschnitt Geschäftsfunktionsorientiert vs.
Geschäftsobjektorientiert
07.06.2018 IM_EAM, SS 2018, Teil 9 100

Business Information Management Business Information Management

Geschäftsfunktionsorientiert Geschäftsobjektorientiert

Business Information Management Business Information Management

Define report
Collect data from Report on Service Report on
Define KPIs information & Report on Sales
operative sources Usage Marketing
layout

Perform respective
Report on Report on Report on
algorithms Create report Analyze data
Financials CRM Production
(slice, dice)

Report on
Report for Report on
Revenue
Management HR
Assurance

Report on Report on
Report on Generic
Corporate Customer
Topics
Knowledge Service

Independent from the specific data that are handled the capabilities The capabilities within the FC Business Information Management are
within the FC Business Information Management always perform structured according to the business entities they handle and report
similar functions to create reports. on.
 Qualitätskriterien für ein stringentes funktionales und
fachlich-logisches Modell
07.06.2018 IM_EAM, SS 2018, Teil 9 101

Gemeinsame Sprache Geschäftsorientierung Konsistente Struktur Unabhängigkeit

 Eine Business Capability  Eine Business Capability
Map besitzt eine Map wird vom Geschäfts-
konsistente Terminologie modell und der
und eine mit Fachseiten Unternehmensstrategie
abgestimmte Sprache abgeleitet
 Geschäftsprozesse und
fachliche Anforderungen
werden unterstützt
 Funktionen/Module sind  Eine Business Capability
hierarchisch geschachtelt, Map ist unabhängig von
disjunkt und innerhalb Organisations-modellen, -
des Models eindeutig verantwortungen
Produktmodellen und
 Die Module sind stabile,
Technologien und
hoch-kohäsive, fachliche
Herstellerlösungen
und logische Geschäfts-
funktionen

Geschäftskohärenz Nachhaltig Komplexitätsreduzierend Lebenszyklus

 Eine Business Capability  Eine Business Capability
Map besteht aus
fachlichen Funktionen die
den gleichen fachlichen
und logischen Geschäfts-
kontext besitzen
 Eine Business Capability  Eine Business Capability
Map bildet die Map reduziert die Map unterliegt einem
Fachlichkeit über die Zeit Komplexität und Änderungsmanagement
konzentriert sich auf das
stabil und nachhaltig ab Wesentliche und
 Detaillierungsgrade  Änderungen werden in
werden durch die Abstimmung mit
verschiedenen Ebenen Fachbereichen
dargestellt
durchgeführt
 Konsistente Struktur
07.06.2018 IM_EAM, SS 2018, Teil 9 102

• Fachfunktionen sind hierarchisch geschachtelt, disjunkt und innerhalb der

Fachfunktionslandkarte eindeutig. Funktionen auf Ebene zwei sind genau
einer Funktion der Ebene 1 eindeutig zu geordnet.
• Die Fachfunktionen sind stabile, hoch-kohäsive, fachliche und logische
Geschäftsfunktionen.

Funktionsebene 1 Fahrzeugentwicklung

Funktionsebene 2 Aggregatentwicklung

Funktionsebene 3 Entwicklung Motorblock

Funktionsebene 3 Entwicklung
Motorsteuergerät
 Gemeinsame Sprache
07.06.2018 IM_EAM, SS 2018, Teil 9 103

• Eine Business Capability Map mit definierten Funktionsbereichen besitzt

eine konsistente Terminologie und eine mit Fachseiten abgestimmte
Sprache und Nomenklatur. Maßgeblich für die Nomenklatur und
Beschreibung einer Fachfunktion bzw. eines Geschäftsobjekts sind die
Fachterminologien der jeweiligen Fachseiten.
• Grundlage für das Anforderungsmanagement

Fachseiten IT
 Unabhängigkeit
07.06.2018 IM_EAM, SS 2018, Teil 9 104

• Business Capabilities werden unabhängig von der konkreten Organisation,

Technology oder Herstellerlösung geschnitten.
 Richtige Business Capabilities
07.06.2018 IM_EAM, SS 2018, Teil 9 105

Welche von zwei oder mehr Capability-Hierarchien ist also richtig für ein
Unternehmen?

Beide!
Vorausgesetzt man verwendet EINE einheitliche für einen
Entscheidungsbereich / für ein Unternehmen
Quelle: Keller, EAM - Capabilities (2014-05-22)
 Vergleichbarkeit von Business Capabilities
07.06.2018 IM_EAM, SS 2018, Teil 9 106

Auch wenn Capabilities unterschiedlich in Hierarchien hängen – Ein Matching

zwischen den Modellen zweier Firmen ist meist möglich

Quelle: Keller, EAM - Capabilities (2014-05-22)

 Übung 9-4
07.06.2018 IM_EAM, SS 2018, Teil 9 107

Business Capabilities können nach unterschiedlichen Orientierungskriterien

modelliert werden. Diese sind
• Kontextorientiert
• Informationsorientiert
• Funktionsorientiert

Entwickeln Sie je eine Capability Map mit Ebene 1 und 2 für die THI nach zwei
Design-Prinzipien.
Erfassen Sie beide in einem EAM Tool und vergleichen Sie diese.
 Fragen zum Teil 9
07.06.2018 IM_EAM, SS 2018, Teil 9 108

• Was sind Business Capabilities?

• Wie unterscheiden sich Business Capabilities von Prozessen?
• Was sind Domänen im Kontext von EAM? Wieso benötigt man Domänen?
• Welche Bereiche umfasst die ADM?
• Welche Architekturen werden in der ADM entwickelt?
• Welche Phasen der ADM beschäftigen sich mit der Entwicklung der
Architekturen?