Eam SS2018 8

Enterprise-Architecture-
Management
IM_EAM, SS 2018, EAMgmt#SS18
Teil 8
Architekturentwicklung mit TOGAF
24.05.2018 IM_EAM, SS 2018, Teil 8 1

Vorbereitung
24.05.2018 IM_EAM, SS 2018, Teil 8 2
Registrieren Sie sich für die Demo des EAM Tools iteraplan
https://www.iteraplan.de/online-demo/
WIEDERHOLUNG TEIL 7-2
24.05.2018 IM_EAM, SS 2018, Teil 8 3

Strategische Bebauungsplanung nach BOC
24.05.2018 IM_EAM, SS 2018, Teil 8 4
Quelle: BOC Group, 2010

Portfolio von Business Capabilities
24.05.2018 IM_EAM, SS 2018, Teil 8 5
Ein Portfolio von Business Capabilities kann ähnlich mit Eigenschaften belegt
werden, wie ein Applikationsportfolio
Ähnliche Attribute findet man auch in Application Management Tools

• ist die Geschäftsfähigkeit „strategisch“ wichtig?
• ist die Geschäftsfähigkeit adäquat implementiert?
• wer sind die Kunden, die die Geschäftsfähigkeit nutzen?
• Welche Volumina von was werden zu welchen Kosten dort bearbeitet
• wie wird „Erfolg“ einer Geschäftsfähigkeit gemessen?
• wer ist der „Owner“ einer Geschäftsfähigkeit?
Bewertung und Messung analog APM oder Balanced Scorecard
Quelle: Keller, EAM - Capabilities (2014-05-22)

Using a business capability map to identify
EA demands
24.05.2018 IM_EAM, SS 2018, Teil 8 6
• Capability-based planning
Quelle: Matthes EAM Foundations, sebis, 2016

TOGAF Capability-Based Planning
24.05.2018 IM_EAM, SS 2018, Teil 8 7
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
TOGAF: Capability Dimensionen
24.05.2018 IM_EAM, SS 2018, Teil 8 8
• Die Funktionen werden unter Berücksichtigung verschiedener Dimensionen

entwickelt und generiert, die die funktionalen Portfolios der Unternehmen
überspannen.
• Jede Organisation hat andere, aber ähnliche Dimensionen. Ein Beispielset
(basierend auf dem kanadischen Department of National Defense) könnte
Personal, Forschung und Entwicklung, Infrastruktur / Einrichtungen, Konzepte /
Prozesse, Informationsmanagement und Material umfassen. werden.
Quelle: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap28.html
TOGAF: Capability Increment Radar
24.05.2018 IM_EAM, SS 2018, Teil 8 9
• Es ist nützlich, die Capability in Capability Increments zu zerlegen, die

diskrete, sichtbare und quantifizierbare Ergebnisse liefern, sowie den
Fokus auf Übergangsarchitekturen und die Ergebnisse von zahlreichen
voneinander abhängigen Projekten zu legen.
• Diese Ergebnisse sind die kritischen Erfolgsfaktoren (CSFs)
Hypothesenbasierter Ansatz nach Niemann
24.05.2018 IM_EAM, SS 2018, Teil 8 10
Um die Optimierungspotentiale zu analysieren und zu bewerten, empfiehlt es

sich zunächst, Hypothesen zu entwickeln und die für deren Untersuchung
erforderlichen Datenstrukturen und Sichten abzuleiten.
Scope
Hypothesen Zielarchitektur- Gaps
definieren und
verifizieren / szenarien analysieren,
Hypothesen zu Ist-Architektur
falsifizieren entwickeln, Roadmap
Optimierungs- analysieren
und Potentiale analysieren definieren und
potentialen
bewerten und bewerten steuern
bilden
Quelle: Klaus Niemann, Analyse von Unternehmensarchitekturen, act! consulting GmbH, 2015
Analyseverfahren
24.05.2018 IM_EAM, SS 2018, Teil 8 11
Die Untersuchung einer Applikations- und Infrastrukturarchitektur im Hinblick

auf Schwachstellen und Optimierungspotentiale lässt sich in 9
Analysebereiche gliedern, denen Untersuchungshypothesen zugeordnet
werden.
Typische Hypothesen zum Untersuchungsbereich
„Heterogenität“
24.05.2018 IM_EAM, SS 2018, Teil 8 12
Zusammenfassung
24.05.2018 IM_EAM, SS 2018, Teil 8 13
• Die Hypothesenbildung erleichtert den Prozess insbesondere bei der

Analyse großer IT-Landschaften und kann den Umfang der erforderlichen
Datenerhebung deutlich reduzieren.
• Die Zuordnung von Analyseverfahren zu den priorisierten Hypothesen und
die anschließende Ableitung der erforderlichen Informationsstruktur
geben frühzeitig Aufschluss über zu erwartende Erhebungs- und
Pflegeaufwände.
Technologiemanagement
24.05.2018 IM_EAM, SS 2018, Teil 8 14
Technologiemanagement
24.05.2018 IM_EAM, SS 2018, Teil 8 15
• Im Technologiemanagement werden die technischen Standards, der

Blueprint, des Unternehmens festgelegt und kontinuierlich
weiterentwickelt.
• Neue technologische Entwicklungen werden im IT-
Innovationsmanagement im Hinblick auf ihre Einsetzbarkeit und
Auswirkungen im Unternehmen beobachtet, evaluiert, bewertet und
gegebenenfalls in den Blueprint aufgenommen.
• Der Lebenszyklus der technischen Bausteine wird gemanagt. Technische
Bausteine und deren Releases, die nicht mehr zukunftsfähig sind oder sich
im Einsatz nicht bewährt haben, werden abgelöst.
• So werden die Zukunftsfähigkeit und Tragfähigkeit von technischen
Standards sichergestellt.
Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p362
Aufgaben im Technologiemanagement
24.05.2018 IM_EAM, SS 2018, Teil 8 16
1. die Festlegung der für das Unternehmen relevanten

Kategorien von Standards, d. h. der technischen Domänen,
die „Fächer“ und „Schubladen“ des Blueprints,
2. die initiale Festlegung und kontinuierliche Weiterentwicklung
und Pflege der technischen Standards mit u. a. Lifecycle-
Management und
3. die Steuerung der Verbauung der technischen Standards.
1. Festlegung der technischen Domänen des
Blueprints
24.05.2018 IM_EAM, SS 2018, Teil 8 17
• Für jeden Standardisierungsbedarf z. B. für Datenbanken wird

im Blueprint, auch technisches Referenzmodell (TRM)
genannt, eine Schublade, eine technische Domäne,
vorgesehen. „Der Griff in die richtige Schublade“ erleichtert
das Auffinden der zum Problemkontext passenden
technischen Bausteine.
• Grafisch wird das technische Referenzmodell durch
sogenannte „Cluster-Grafiken“ visualisiert.
Beispiel Blueprint-Grafik
24.05.2018 IM_EAM, SS 2018, Teil 8 18
Detaillierte Definition der Technologiedomäne
24.05.2018 IM_EAM, SS 2018, Teil 8 19
Die Technologiedomäne ist das zentrale, technisch orientierte

Gliederungselement der Technologie- und Infrastrukturarchitektur
• Technologiedomänen sind hierarchische Gruppierungen von
Technologien, die dem gleichen (bzw. einem hinreichend ähnlichen) Zweck
dienen
• Zu einer Technologiedomäne (auf unterster Ebene) gehört eine definierte
Menge konkreter Technologien
• Technologiedomänen entstehen durch die vollständige Gliederung
benötigter Technologien in disjunkte technische Leistungsbereiche mit
gemeinsamen Merkmalen (Zweck, Mechanismen usw.)
• Technologiedomänen definieren eine logische Struktur, der physisch (zur
Realisierung von Applikationen und Ausführung auf konkreten
Infrastrukturelementen) eingesetzte Technologien bzw.
Infrastrukturelemente zugeordnet werden können
Ausprägungen der Technologie-Domänen
24.05.2018 IM_EAM, SS 2018, Teil 8 20
• Die Technologiedomänen können als „Technology Portfolio“ betrachtet

werden
• Sie werden in einem EAM Tool gepflegt
• Beispiel für Technologiedomänen (Ebene 1)
Presentation Central Base Application

Components Components Components
Runtime Environment
Data Storage
Components
Operating Systems Network & Communication
Hardware
Schnittkriterien für Technologiedomänen
24.05.2018 IM_EAM, SS 2018, Teil 8 21
Schnittkriterium Relevanz Erläuterung

Technologischer Ja Der Einsatzzweck einer Technologie ist das wesentliche Schnittkriterium. Handelt
Einsatzzweck es sich bei einer Technologie z.B. um einen Basisdienst (z.B. im Sinne eines
Betriebssystems) oder um einen technischen Mechanismus zur persistenten
Speicherung strukturierter Daten (z.B. Datenbankmanagementsystem) usw.
Technologisches Ja Dieses Kriterium ist eher ein sekundäres Kriterium zur weiteren Unterteilung
Wirkprinzip / (z.B. Persistenz-Mechanismus von Datenbanken wie relational, objekt-relational,
Funktionsweise hierarchisch, XML-Datenbank o.ä.)
Applikationen / Ja Dieses Kriterium ist nur in Fällen relevant, in denen Applikationen bzw. deren
Applikaitonsmodule Module rein technologisch oder funktional im Sinne eines IT-Bausteins
(Funktionsbaustein) definiert sind. Es ist weniger ein Schnittkriterium, sondern
eher ein Aspekt, mit dem weitere Technologien bzw. Domänen identifiziert
werden können.
Informationsobjekte Ja Dieses Kriterium ist nur dann relevant, wenn es rein technologisch oder
funktional im Sinne eines IT-Bausteins (Funktionsbaustein) definiert ist.
Geschäftsprozesse Nein Dieses Kriterium widerspricht der klaren technologischen Orientierung.
Wertschöpfungstiefe Nein Dieses Kriterium widerspricht der klaren technologischen Orientierung.
Organisationseinheiten Nein Dieses Kriterium widerspricht der klaren technologischen Orientierung.
Produkte und Nein Dieses Kriterium widerspricht der klaren technologischen Orientierung.
Geschäftsfelder
Kundensegmente Nein Dieses Kriterium widerspricht der klaren technologischen Orientierung.
Geographie (Standorte, Nein Dieses Kriterium widerspricht der klaren technologischen Orientierung.
Werke)
Technologie-Domänen und IT-Bausteine
24.05.2018 IM_EAM, SS 2018, Teil 8 22
IT-Bausteine lassen sich durch das Technologie-Domänenkonstrukt abbilden

class Bausteine
«Hierarchie» Technologie nutzt Infrastrukturkomponente

Technologie-Domäne umfasst
1 1..* * *
abgebildet auf abgebildet auf abgebildet auf

ist Ausprägung von ist Instanz von
IT-Baustein IT-Bausteinausprägung IT-Bausteininstanz
1 1..* 1 *
Oracle ORA-DB 1234
Datenbankmanagementsystem DB2 ORA-DB 5678

(DBMS)
MS SQL Serv er
MSSQL-DB 9876
JBoss
App-Serv er 4711
Application
Serv er Apache Tomcat
App-Serv er 0815
IBM WebSphere
2. Initiale Festlegung und kontinuierliche Weiter-
entwicklung und Pflege der technischen Standards
24.05.2018 IM_EAM, SS 2018, Teil 8 23
Für die initiale Befüllung des Blueprints sind folgenden

Aktivitäten notwendig:
1. Ermitteln Sie die aktuell genutzten technischen Bausteine
durch die Analyse der IS-Bebauung und der
Betriebsinfrastruktur.
2. Sammeln Sie Ihre Standardisierungsanforderungen
3. Bewerten Sie die Standardisierungsanforderungen
4. Entscheidung über die Standardisierungskandidaten z. B.
durch das Blueprint-Board
5. Umsetzung der Standardisierungsmaßnahmen entsprechend
der Entscheidung
Technische Standardisierung
24.05.2018 IM_EAM, SS 2018, Teil 8 24
In Abhängigkeit von der strategischen Positionierung der IT im Gesamtunternehmen gibt es unterschiedliche

Motive für die technische Standardisierung
Kostenreduktion im IT-Basisbetrieb
• Nachhaltige Kostenreduktion durch Nutzung von Skaleneffekten, einer zentralen Verhandlungsmacht im
Einkauf und der Knowhow-Bündelung erzielen
Beherrschung und/oder Reduktion der IT-Komplexität

• IT-Komplexität durch Steigerung der technischen Qualität beherrschen (wiederholte Verwendung von
bewährten technischen Bausteinen)
Optimierung des Tagesgeschäfts

• Standardisierung von Methoden und Verfahren z. B. für die Administration und den Betrieb von
Anwendungen oder aber auch im fachlichen Kontext
IT strategisch ausrichten
• Tragfähige und zukunftssichere technische Standards vorgeben
Beitrag zur Weiterentwicklung des Geschäfts

• Festlegung von Standards, die Flexibilität fördern und Änderungen schneller durchführen lassen
Quelle: HANSCHKE, Inge, 2016. Enterprise Architecture Management - einfach und effektiv, p17f
Anforderungen an IT Standards
24.05.2018 IM_EAM, SS 2018, Teil 8 25
• Erfüllung strategischer Anforderungen

– Trägt zu Gelingen oder Scheitern einer IT-Strategie bei
– Funktional: betrifft elementare Geschäftsprozesse oder -objekte (ERP-System)
– Nicht-funktional:
• Performanz oder Ausfallsicherheit
• Mandantenfähigkeit, Konfigurierbarkeit
• Integrierbarkeit, Schnittstellen
• Kosten
– TCO trägt substantiell zu IT-Gesamtkosten bei z.B. bei großen Middleware-
Plattformen, ERP-Systemen
• Rechtliche Risiken
– z.B. Open Source – Beispiel Hibernate
• Wirtschaftliche Risiken
– Insolvenz vs. Vendor Lock-In
Quelle: Bente, EAM Transformation, 2015, p53
Vor- und Nachteile durch Standardisierung
24.05.2018 IM_EAM, SS 2018, Teil 8 26
Vorteile
• Rabatte durch Bündelung der Einkaufsvolumina
• geringerer Entwicklungsaufwand und Einsparung von Entwicklungskosten
• Verwendung bewährter Techniken
• vereinfachte Kommunikation zwischen Komponenten
Nachteile
• weniger Differenzierungsmöglichkeiten
• spezielle Anforderungen nicht genügend berücksichtigt
• weniger Gestaltungsspielraum
• Weiterentwicklungen erschwert
Initiale Festlegung der technischen Standards
24.05.2018 IM_EAM, SS 2018, Teil 8 27
• Nehmen Sie in den initialen Blueprint nur strategische

Vorgaben und bewährte Lösungen aus Ihrem Unternehmen
auf (Mischung aus Top-down- und Bottom-up-Vorgehen). So
können Sie die Weiterentwicklung strategisch ausrichten und
schaffen gleichzeitig Akzeptanz für die Vorgaben.
• Analysieren Sie alle technischen Domänen und legen Sie Ihre
Standards für Technologien wie z. B. JEE oder IT-Produkte wie
z. B. ORACLE 12.1 fest. Beschränken Sie sich dabei auf das
Sinnvolle und Notwendige, dessen Umsetzung auch möglich
und gleichzeitig angemessen ist. Einige Schubladen dürfen
durchaus auch leer bleiben, wenn aktuell noch kein Standard
sinnvoll festzulegen ist.
Kontinuierliche Weiterentwicklung der technischen
Standards
24.05.2018 IM_EAM, SS 2018, Teil 8 28
Die Weiterentwicklung der technischen Standards erfolgt ausgerichtet

an der Unternehmens und IT-Strategie sowie den
Geschäftsanforderungen. Der Blueprint ist kontinuierlich an die
veränderte Situation anzupassen. Dabei helfen Ihnen folgende
Fragestellungen:
• Welche bestehenden technischen Standards sind noch
angemessen, tragfähig und zukunftsfähig?
• Für welche technischen Trends und Neuerungen sollten neue
technische Standards für das Unternehmen erstellt werden?
Welche bestehenden technischen Standards sollte man dafür
ablösen?
• Für welchen im Rahmen der Analyse der IS-Bebauung oder im
Rahmen der operativen Projektabwicklung identifizierten
Handlungsbedarf und für welche Optimierungspotenziale sollten
neue technische Standards erstellt oder bestehende verändert
werden?
Standardisierungsmaßnahmen
24.05.2018 IM_EAM, SS 2018, Teil 8 29
Durch die Umsetzung der verabschiedeten Standardisierungsmaßnahmen wird

der Blueprint weiterentwickelt. Beispiele für Standardisierungsmaßnahmen:
• Erstellung von Referenzarchitekturen oder Architekturmustern
• Evaluierung von IT-Kaufprodukten
Bei der Evaluierung von IT-Kaufprodukten werden die am Markt verfügbaren
IT-Kaufprodukte ermittelt, entsprechend den unternehmensspezifischen
Anforderungen bewertet, eine Vorauswahl getroffen und eine Empfehlung für
eines der IT-Kaufprodukte aus der Vorauswahl abgegeben.
• Erstellung von technischen Komponenten
Entsprechend den unternehmensspezifischen Anforderungen werden
technische Komponenten entwickelt oder angepasst bzw. konfiguriert.
• Bereitstellung von Migrationshilfestellungen
Wenn technische Standards, die in Informationssystemen oder Schnittstellen
verbaut wurden, auslaufen, müssen Hilfestellungen für die Migration z. B. auf
Nachfolgerbausteine gegeben werden. Dies kann z. B. ein Migrationskonzept,
ergänzt um Migrationsskripte, sein. Migrationshilfestellungen sind
insbesondere auch bei neuen Releases technischer Bausteine erforderlich.
Wichtige Grundsätze für die Akzeptanz von
technischen Standards
24.05.2018 IM_EAM, SS 2018, Teil 8 30
• Achten Sie auf die Angemessenheit, Tragfähigkeit, Zukunftsfähigkeit und

einfache Nutzbarkeit aller neuen oder veränderten technischen
Bausteine.
• Häufig werden technische Bausteine aus Best-Practices in Projekten unter
Mitwirkung der Softwarearchitekten aus der „Linie“ konsolidiert. Dies
erhöht zudem die Akzeptanz der technischen Standards.
• Kommunikation von neuen und veränderten technischen Standards
• Hilfsmittel für die Nutzung
Nur durch Hilfsmittel für die Nutzung wie z. B. ein Nutzungskonzept oder
Checklisten kann die bestimmungsgemäße Verbauung der technischen
Bausteine sichergestellt werden.
• Kontinuierliches Aufräumen
Sorgen Sie dafür, dass der Blueprint immer auf einem aktuellen Stand ist.
Im Rahmen der Pflege sind die bestehenden Standards kontinuierlich zu
überprüfen und nicht mehr relevante Standards als „abzulösen“ zu
markieren. Nur so bleiben die technischen Standards wartbar und nur so
realisieren Sie die angestrebte Kosteneinsparung.
3. Steuerung der Verbauung der technischen
Standards
24.05.2018 IM_EAM, SS 2018, Teil 8 31
• Die besten technischen Standards helfen nicht, wenn sie nicht

verwendet werden. Nur durch die aktive Steuerung der
Verbauung können die mit dem Technologiemanagement
verbundenen Ziele erreicht werden. Es muss sichergestellt
werden, dass die festgelegten technischen Standards im
Rahmen der Projekte und Wartungsmaßnahmen sowie im
Betrieb eingehalten und abzulösende Standards auch wirklich
abgelöst werden.
• Durch die kontinuierliche Überwachung der Tragfähigkeit und

Zukunftsfähigkeit, der Kosten und des Nutzens sowie der
Häufigkeit des Einsatzes kann die Weiterentwicklung des
Blueprint wirkungsvoll gesteuert werden.
Technologie-Standards: Typische Adaptionszeitpunkte
24.05.2018 IM_EAM, SS 2018, Teil 8 32
Kern-Technologien: Nicht zu früh an Bord nehmen, nicht zu lange behalten!
Quelle: Bente, EAM Transformation, 2015, p53,

https://de.wikipedia.org/wiki/Datei:Abb3_Technologietypen.png, Michel (1987) S. 67, Von Robert Orzanna - Eigenes Werk, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=46466161
Übung 7-8
24.05.2018 IM_EAM, SS 2018, Teil 8 33
• Eine leistungsfähige Suchmaschine, ein Tool zum Verarbeiten und

Normalisieren von Protokollen und eins zum Visualisieren der Auswertungen –
Elasticsearch, Logstash und Kibana bilden den ELK-Stack, der auf Systemen mit
großem Log-Aufkommen den Karren aus dem Dreck zieht.
• Schon ein einzelner kleiner LAMP-Server produziert etliche Logdateien. Ein

großer Serververbund generiert jedoch so viele Protokolle, dass
Administratoren mit Bordmitteln schnell an ihre Grenzen geraten, wenn sie die
verteilten Logs optimal auswerten möchten. Die völlig unterschiedlichen
Formate der diversen Applikationen verursachen zusätzliche Probleme.
• Allen diesen Schwierigkeiten stellt sich der ELK-Stack in den Weg, eine
Kooperation aus Elasticsearch, Logstash und Kibana. Elasticsearch ist ein
extrem leistungsfähiger Suchserver. Seine Daten erhält er von Logstash, einer
Anwendung, die Daten aus den Serverprotokollen zieht, normalisiert und in
einem Elasticsearch-Index ablegt. Kibana schließlich erzeugt aus diesen Daten
ansprechende Darstellungen – das Visualisierungstool bietet neben einer
Echtzeitanalyse äußerst flexible Ansichten auf die Informationen.
Quelle: http://www.linux-magazin.de/ausgaben/2016/02/elk-stack/
Übung 7-8
24.05.2018 IM_EAM, SS 2018, Teil 8 34
Die Aussagen auf der vorherigen Seite enthalten Produkte und Architekturen,
die eine gewisse Marktdurchdringung erreicht haben.
Als Chief Enterprise Architect wollen Sie deshalb Synergien für Ihr
Unternehmen erreichen. Welche Schritte im Technologiemanagement
würden Sie Ihrem CIO empfehlen.
Dokumentieren Sie die beiden Referenzarchitekturen in iteraplan und

erstellen Sie eine Cluster-Grafik.
Übung 7-8
24.05.2018 IM_EAM, SS 2018, Teil 8 35
TEIL 8 – ARCHITEKTURENTWICKLUNG
MIT TOGAF
24.05.2018 IM_EAM, SS 2018, Teil 8 36

Teil 2
TOGAF - The Open Group Architecture Management
Framework
24.05.2018 IM_EAM, SS 2018, Teil 8 37
• 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
Teil 2
Die Komponenten von TOGAF 9.1

24.05.2018 IM_EAM, SS 2018, Teil 8 38
Quelle: BOC Group | boc@boc-group.com

TOGAF 9.2 Struktur
24.05.2018 IM_EAM, SS 2018, Teil 8 39
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
24.05.2018 IM_EAM, SS 2018, Teil 8 40
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.
TOGAF 9.2 Struktur
24.05.2018 IM_EAM, SS 2018, Teil 8 41
Part I - 1.Introduction
2.Core Concepts
Introduction 3.Definitions
Part II - 4.Introduction to Part II 10.Phase C: Information Systems
5.Preliminary Phase Architectures - Applications Architecture
Architecture 6.Phase A: Architecture Vision 11.Phase D: Technology Architecture
Development 7.Phase B: Business Architecture 12.Phase E: Opportunities and Solutions
Method 8.Phase C: Information Systems 13.Phase F: Migration Planning
Architectures 14.Phase G: Implementation Governance
9.Phase C: Information Systems 15.Phase H: Architecture Change
Architectures - Data Architecture Management
16.ADM Architecture Requirements
Management
Part III - ADM 17.Introduction to Part III 23.Gap Analysis
18.Applying Iteration to the ADM 24.Migration Planning Techniques
Guidelines and 19.Applying the ADM across the 25.Interoperability Requirements
Techniques Architecture Landscape 26.Business Transformation Readiness
20.Architecture Principles Assessment
21.Stakeholder Management 27.Risk Management
22.Architecture Patterns 28.Capability-Based Planning
TOGAF 9.2 Struktur
24.05.2018 IM_EAM, SS 2018, Teil 8 42
Part IV - 29.Introduction to Part IV

Architecture 30.Content Metamodel
Content 31.Architectural Artifacts
32.Architectural Deliverables
Framework
33.Building Blocks
Part V - 34.Introduction to Part V
Enterprise 35.Enterprise Continuum
Continuum and 36.Architecture Partitioning
37.Architecture Repository
Tools
38.Tools for Architecture Development
Part VI - 39.Introduction to Part VI
Architecture 40.Establishing an Architecture Capability
Capability 41.Architecture Board
42.Architecture Compliance
Framework
43.Architecture Contracts
44.Architecture Governance
45.Architecture Maturity Models
46.Architecture Skills Framework
Übung 8-1
24.05.2018 IM_EAM, SS 2018, Teil 8 43
Mit der Version 9.2 von TOGAF wurde die Framework leicht umstrukturiert.
• Analysieren Sie die TOGAF Dokumentation.
• TOGAF 9.2 online: http://pubs.opengroup.org/architecture/togaf92-doc/arch/
• Ermitteln Sie in welchem Bereich von TOGAF die Referenzarchitekturen

TRM und III-RM nun beschrieben sind.
Part I - Introduction
24.05.2018 IM_EAM, SS 2018, Teil 8 44
Part I - 1.Introduction
Introduction 2.Core Concepts
3.Definitions
Struktur des TOGAF Standards
24.05.2018 IM_EAM, SS 2018, Teil 8 45
Quelle: The Open Group, TOGAF Version 9.2, Figure 1-1: Structure of the TOGAF Standard, 2018
Teil 4
Architekturdomänen nach TOGAF

24.05.2018 IM_EAM, SS 2018, Teil 8 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
Teil 4
TOGAF – Geschäftsarchitektur
24.05.2018 IM_EAM, SS 2018, Teil 8 47
Die Geschäftsarchitektur betrachtet die Strategie, die Aufbauorganisation,

die Geschäftsprozesse und die Geschäftsfähigkeiten (Business Capabilities)
des Unternehmens. Die Geschäftsprozessarchitektur ist das Ergebnis der
Geschäftsprozessmodellierung.
Aufbauorganisation
• Die Aufbauorganisation bildet das – meistens hierarchische – Gerüst einer
Organisation. Die Aufbauorganisation legt die Rahmenbedingungen, d. h.
welche Aufgaben von welchen Menschen und Sachmitteln zu bewältigen
sind. Modelle dazu: Strukturgramm, Businessplan, Geschäftsmodell
Teil 4
TOGAF – Datenarchitektur
24.05.2018 IM_EAM, SS 2018, Teil 8 48
In der Datenarchitektur werden die Daten mit ihren Beziehungen, die für die
Durchführung der Geschäftsprozesse benötigt werden, identifiziert und
beschrieben.
Dies erfolgt in einem Modell und einer Darstellungsform, die stabil,
vollständig, konsistent und für alle Beteiligten verständlich ist. Die
Informationsarchitektur repräsentiert Informationen, Informationsgruppen
und deren Informationsbedürfnisse. Unter Informationsgruppen sind
verschiedene Rollen zusammengefasst, die den gleichen Informationsbedarf
haben (z.B. Controller).
Teil 4
TOGAF – Anwendungsarchitektur
24.05.2018 IM_EAM, SS 2018, Teil 8 49
Innerhalb der Anwendungsarchitektur werden die Anwendungen verwaltet,

die für die Ausführung der Geschäftsprozesse erforderlich sind. Neben der
Bestandsführung aller Anwendungen werden auch die Beziehungen und
Schnittstellen zwischen den Anwendungen im Rahmen der
Anwendungsarchitektur betrachtet. Die Anwendungen werden anhand ihrer
fachlichen Funktionalität und der durch sie verarbeiteten Informationen
kategorisiert. Diese Kategorien sind relativ stabil. Die konkreten
Anwendungen, die innerhalb der Kategorien zum Einsatz kommen, werden
häufiger ersetzt. Dieser Wandel ergibt sich aus der technischen
Weiterentwicklung und veränderten Anforderungen.
Teil 4
TOGAF – Technologiearchitektur
24.05.2018 IM_EAM, SS 2018, Teil 8 50
Die Technologiearchitektur beschreibt die Architekturelemente für Aufbau

und Betrieb der IT-Infrastruktur. Sie definiert die Basis, auf der Anwendungen
beschafft, integriert und betrieben werden können.
• Software (OS, Virusscanner usw.)
• Hardware (Server, PCs, Mobile Geräte usw.)
• Kommunikationsinfrastruktur (Switche, Router)
Part II - Architecture Development Method
24.05.2018 IM_EAM, SS 2018, Teil 8 51
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
Part II - Architecture Development Method
24.05.2018 IM_EAM, SS 2018, Teil 8 52
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

Teil 2
TOGAF - Architecture Development Method (ADM)

24.05.2018 IM_EAM, SS 2018, Teil 8 53
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)
24.05.2018 IM_EAM, SS 2018, Teil 8 54
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
Wuelle: https://thunk.technology/blog/togaf-adm-big-bang-theory
Part III - ADM Guidelines and Techniques
24.05.2018 IM_EAM, SS 2018, Teil 8 55
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
ADM Guidelines and Techniques
24.05.2018 IM_EAM, SS 2018, Teil 8 56
• 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
24.05.2018 IM_EAM, SS 2018, Teil 8 57
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
05.04.2018 IM_EAM, SS 2018, Teil 3 58
• 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

Teil 3
Architekturdomänen nach TOGAF

24.05.2018 IM_EAM, SS 2018, Teil 8 59
• Geschäftsprinzipien
betreffen Geschäftsstrategie, Steuerung, Organisation und
Geschäftsprozesse im Hinblick auf die IT
• Datenprinzipien
beschreiben die wesentlichen Grundsätze zum Umgang mit
Unternehmensdaten
• Applikationsprinzipien
definieren die Leitlinien für Anwendungssysteme
• Technologieprinzipien
legen die grundlegenden Rahmenbedingungen für technologische
Entscheidungen fest
Quelle: TOGAF 9.1
Teil 3
Beispiel: Prinzip IT Verantwortung TOGAF-7

24.05.2018 IM_EAM, SS 2018, Teil 8 60
Statement / Aussage
• Die IT-Organisation ist für die Betreuung und Implementierung der IT-Prozesse und
der Infrastruktur verantwortlich, so dass die definierten Anforderungen bezüglich
der Funktionalität, Service Levels, Lieferung und Zeitvorgaben erfüllt werden.
Rationale / Begründung
• Es ist eine Richtlinie des Unternehmens, die Erwartungen der Fachseite an
Geschäftsfähigkeiten und Kosten so abzustimmen, dass die Projekte kosteneffektiv
durchgeführt werden. Effektive und effiziente Lösungen sollen vernünftige Kosten
und klaren Nutzen haben.
Implications / Auswirkungen
• Ein Prozess, der die Projekte priorisiert, muss etabliert werden.
• Die IT-Organisation benötigt Prozesse für das Erwartungsmanagement der
Businesseinheiten.
• Die zur Entwicklung qualitativer Lösungen benötigten Modelle für Daten,
Anwendungen und Technologie müssen entwickelt werden.
Quelle: TOGAF 9.1

Teil 3
TOGAF Architekturprinzipien
24.05.2018 IM_EAM, SS 2018, Teil 8 61
Business Principles Statement
1 Primacy of Principles These principles of information management apply to all organizations within
the enterprise.
2 Maximize Benefit to the Enterprise Information management decisions are made to provide maximum benefit to
the enterprise as a whole.
3 Information Management is Everybody's All organizations in the enterprise participate in information management
Business decisions needed to accomplish business objectives.
4 Business Continuity Enterprise operations are maintained in spite of system interruptions.
5 Common Use Applications Development of applications used across the enterprise is preferred over the
development of similar or duplicative applications which are only provided to
a particular organization.
6 Compliance with Law Enterprise information management processes comply with all relevant laws,
policies, and regulations.
7 IT Responsibility The IT organization is responsible for owning and implementing IT processes
and infrastructure that enable solutions to meet user-defined requirements
for functionality, service levels, cost, and delivery timing.
8 Protection of Intellectual Property The enterprise's Intellectual Property (IP) must be protected. This protection
must be reflected in the IT architecture, implementation, and governance
processes.
Quelle: TOGAF 9.1

Teil 3
24.05.2018 IM_EAM, SS 2018, Teil 8 62
Data Principles Statement
9 Data is an Asset Data is an asset that has value to the enterprise and is managed accordingly.
10 Data is Shared Users have access to the data necessary to perform their duties; therefore,
data is shared across enterprise functions and organizations.
11 Data is Accessible Data is accessible for users to perform their functions.
12 Data Trustee Each data element has a trustee accountable for data quality.
13 Common Vocabulary and Data Definitions Data is defined consistently throughout the enterprise, and the definitions are
understandable and available to all users.
14 Data Security Data is protected from unauthorized use and disclosure. In addition to the
traditional aspects of national security classification, this includes, but is not
limited to, protection of pre-decisional, sensitive, source selection-sensitive,
and proprietary information.
Quelle: TOGAF 9.1

Teil 3
24.05.2018 IM_EAM, SS 2018, Teil 8 63
Application Principles Statement
15 Technology Independence Applications are independent of specific technology choices and therefore can
operate on a variety of technology platforms.
16 Ease-of-Use Applications are easy to use. The underlying technology is transparent to
users, so they can concentrate on tasks at hand.
Quelle: TOGAF 9.1

Teil 3
24.05.2018 IM_EAM, SS 2018, Teil 8 64
Technology Principles Statement
17 Requirements-Based Change Only in response to business needs are changes to applications and
technology made.
18 Responsive Change Management Changes to the enterprise information environment are implemented in a
timely manner.
19 Control Technical Diversity Technological diversity is controlled to minimize the non-trivial cost of
maintaining expertise in and connectivity between multiple processing
environments.
20 Interoperability Software and hardware should conform to defined standards that promote
interoperability for data, applications, and technology.
Quelle: TOGAF 9.1

TOGAF Gap Analyse
24.05.2018 IM_EAM, SS 2018, Teil 8 65
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

24.05.2018 IM_EAM, SS 2018, Teil 8 66
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
Teil 7
TOGAF: Capability Dimensionen

24.05.2018 IM_EAM, SS 2018, Teil 8 67
• Die Funktionen werden unter Berücksichtigung verschiedener Dimensionen

entwickelt und generiert, die die funktionalen Portfolios der Unternehmen
überspannen.
• Jede Organisation hat andere, aber ähnliche Dimensionen. Ein Beispielset
(basierend auf dem kanadischen Department of National Defense) könnte
Personal, Forschung und Entwicklung, Infrastruktur / Einrichtungen, Konzepte /
Prozesse, Informationsmanagement und Material umfassen. werden.
Teil 7
TOGAF: Capability Increment Radar

24.05.2018 IM_EAM, SS 2018, Teil 8 68
• Es ist nützlich, die Capability in Capability Increments zu zerlegen, die

diskrete, sichtbare und quantifizierbare Ergebnisse liefern, sowie den
Fokus auf Übergangsarchitekturen und die Ergebnisse von zahlreichen
voneinander abhängigen Projekten zu legen.
• Diese Ergebnisse sind die kritischen Erfolgsfaktoren (CSFs)
Part IV - Architecture Content Framework
24.05.2018 IM_EAM, SS 2018, Teil 8 69
Part IV - 29.Introduction to Part IV

Architecture 30.Content Metamodel
Content 31.Architectural Artifacts
Framework
32.Architectural Deliverables
33.Building Blocks
Part IV - Architecture Content Framework
24.05.2018 IM_EAM, SS 2018, Teil 8 70
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)

24.05.2018 IM_EAM, SS 2018, Teil 8 71
• 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

24.05.2018 IM_EAM, SS 2018, Teil 8 72
Quelle: TOGAF 9.2

Teil 4
TOGAF Content Metamodel

24.05.2018 IM_EAM, SS 2018, Teil 8 73
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

24.05.2018 IM_EAM, SS 2018, Teil 8 74
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

24.05.2018 IM_EAM, SS 2018, Teil 8 75
Quelle: TOGAF 9.2

Teil 4
TOGAF – Artefakte nach ADM Phasen

24.05.2018 IM_EAM, SS 2018, Teil 8 76
Quelle: TOGAF 9.2

Übung 8-2
24.05.2018 IM_EAM, SS 2018, Teil 8 77
Das Content Metamodel von TOGAF wurde in der Version 9.2 erweitert.
Welche Objekte sind im „Content Metamodel“ von TOGAF 9.2
hinzugekommen (gegenüber der Version 9.1)?
Part V - Enterprise Continuum and Tools
24.05.2018 IM_EAM, SS 2018, Teil 8 78
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
Teil 4
Enterprise Continuum
24.05.2018 IM_EAM, SS 2018, Teil 8 79
• 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
24.05.2018 IM_EAM, SS 2018, Teil 8 80
Quelle: TOGAF 9.2

Teil 4
Elemente des Architecture Continuum

24.05.2018 IM_EAM, SS 2018, Teil 8 81
Foundation Architectures (Basisarchitekturen):

• Die allgemeinste Architekturbeschreibung, diese kann von jedem
Unternehmen genutzt werden
Common System Architectures:
• Architekturbeschreibungen die in vielen Unternehmen vorhanden sind
Industry Architectures (Domänenarchitekturen):
• Architekturbeschreibungen die spezifisch für eine Reihe von Unternehmen
ist die aus der gleichen Domäne stammen
Organisational Architectures (Organisationsarchitekturen):
• Die Architekturbeschreibung die passgenau für ein
Unternehmen\Organisation verwendet wird
Teil 4
Elemente des Solutions Continuum

24.05.2018 IM_EAM, SS 2018, Teil 8 82
Foundation Solutions:
• Kaufbare Elemente, die Ressourcen, Nutzen oder Lösungen bieten
Common System Solutions :
• Domänenübergreifende Lösungen, z.B. EAI-Plattformen, B2B Lösungen,
SaaS
Industry Solutions:
• Wiederverwendbare Pakete gemeinsamer Komponenten und
branchenspezifischer Services
Organisational Solutions:
• Einmalige Lösung durch die Organisation zur Abbildung spezifischer
Anforderungen
Teil 4
Elemente des Enterprise Continuum

24.05.2018 IM_EAM, SS 2018, Teil 8 83
Quelle: TOGAF 9.2

Tools for Architecture Development
24.05.2018 IM_EAM, SS 2018, Teil 8 84
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
24.05.2018 IM_EAM, SS 2018, Teil 8 85
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
24.05.2018 IM_EAM, SS 2018, Teil 8 86
Quelle: TOGAF 9.2

24.05.2018 IM_EAM, SS 2018, Teil 8 87
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

TOGAF - Architecture Governance Framework
24.05.2018 IM_EAM, SS 2018, Teil 8 88
Teil 6
Reifegradmodell ACMM von TOGAF

24.05.2018 IM_EAM, SS 2018, Teil 8 89
Das DoC ACMM (Department of Commerce Architecture Capability Maturity

Model) hat 6 Maturity Level und 9 Architektur Element.
9 Architekturelement
Reifegrade Beispielhafte Eigeenschaften
Architekturprozess
0 None Keine EAM-Aktivitäten vorhanden
Architekturentwicklung
1 Initial Die EAM-Aktivitäten finden ad hoc statt
Zusammenarbeit mit der Fachseite
2 Under Der EAM-Prozess ist dokumentiert und mit
Engagement des development Rollen und Verantwortlichkeiten
Seniormanagement beschrieben
Beteiligung der operationalen 3 Defined Das EAM ist im Detail definiert und
Einheiten kommuniziert. Die Governance-Aktivitäten
Kommunikation sind explizit und dokumentiert
IT-Sicherheit 4 Managed Der EAM-Prozess ist ein Teil der
Unternehmenskultur.
Architektur-Governance
5 Measured Der EAM-Prozess wird kontinuierlich
IT-Investitions- und optimiert und verbessert.
Beschaffungsstrategie
Quelle: TOGAF, 9.1
Übung 8-3-1
24.05.2018 IM_EAM, SS 2018, Teil 8 90
Fragen aus dem TOGAF 9 Part 1 Practice Test:
Which are the three main categories of architectural work product does
Architecture Content Framework specify?
Choose one of the following answers
a) Architecture Vision, Architecture Requirements Specification and

Architecture Roadmap
b) Source Architecture, Target Architecture and Gap Analysis
c) Architecture Vision, Architecture Design Document and Transition
Architecture
d) Building Block, Artifact and Deliverable
e) Request for Architecture Work, Statement of Architecture Work and
Architecture Contract
Quelle: http://theopenarch.com/81-tests/72-togaf-9-exam-tests.html
Übung 8-3-2
24.05.2018 IM_EAM, SS 2018, Teil 8 91
Which is NOT one of the seven parts of TOGAF document?
a) ADM Guidelines and Techniques

b) Architecture Content Framework
c) Architecture Governance
d) TOGAF Reference Models
e) Architecture Capability Framework
Übung 8-3-3
24.05.2018 IM_EAM, SS 2018, Teil 8 92
Which of the following is NOT an ADM Guideline or Technique?
a) Architecture Principles
b) Usecase Modeling
c) Architecture Patterns
d) Interoperability Requirements
e) Capability-Based Planning
Übung 8-3-4
24.05.2018 IM_EAM, SS 2018, Teil 8 93
What according to TOGAF is an Enterprise?
a) Entire business group or corporation comprising of all local and

international main and sub offices, divisions, subsidiaries, and
departments
b) Any collection of organizations that has a common set of goals
c) Any large organization
d) An enterprise is an organization that uses computers
e) A large corporation or government agency, but it may also refer to a
company of any size with many systems and users to manage
Übung 8-3-5
24.05.2018 IM_EAM, SS 2018, Teil 8 94
What is Architecture in the Context of TOGAF?
a) The fundamental organization of a system, embodied in its components, their

relationships to each other and the environment, and the principles governing its
design and evolution
b) A rigorous description of the structure of an enterprise, which comprises enterprise
components (business entities), the externally visible properties of those components,
and the relationships (e.g. the behavior) between them
c) An architecture is the most important, pervasive, top-level, strategic inventions,
decisions, and their associated rationales about the overall structure (i.e., essential
elements and their relationships) and associated characteristics and behavior
d) Architecture is the use of abstractions and models to simplify and communicate
complex structures and processes to improve understanding and forecasting
e) A formal description of a system, or a detailed plan of the system at a component level
to guide its implementation or the structure of components, their inter-relationships,
and the principles and guidelines governing their design and evolution over time
Was wird durch TOGAF abgedeckt
24.05.2018 IM_EAM, SS 2018, Teil 8 95
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)
Übung 8-4
24.05.2018 IM_EAM, SS 2018, Teil 8 96
Welche Schwerpunkte setzt TOGAF? Untersuchen Sie die TOGAF

Dokumentation bezüglich folgender Fragen:
• Unterstützt TOGAF 9 das Thema Findung einer IT-Strategie?
• Was sagt TOGAF zum Management des Anwendungsportfolios?

TOGAF - unterm Strich
24.05.2018 IM_EAM, SS 2018, Teil 8 97
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

Teil 2
TOGAF - Bewertung
24.05.2018 IM_EAM, SS 2018, Teil 8 98
Zusammenfassung TOGAF
• TOGAF 9 hat seine Stärke im Bereich der ADM (Architecture Development Method)
• Projektarchitektur für große Projekte
• Der strategische Teil von IT-Unternehmensarchitektur wird nur am Rande gestreift
– IT-Strategie
– IT-Portfolio-Management
• Für ein Management der IT-Unternehmensarchitektur benötigen man deutlich mehr als TOGAF
Bewertung
• TOGAF
– Ist anbieter-, werkzeug- und branchenneutral
– Hat sich in der Praxis als De-facto-Standard etabliert
– Werkzeuge und Personen können zertifiziert werden
– Ist ein Framework (generisch) und muss auf die Organisation angepasst werden
• Vorteile
– Umfassend
– Methodisch
– Hebt die Geschäftssicht bei IT-Projekten hervor (Top-down-Ansatz)
• Nachteile
– Komplex, dadurch Anpassung an die Organisation herausfordernd
– Stark projektorientiert
Quelle: BOC Group | boc@boc-group.com

Vergleich TOGAF mit anderen Frameworks
24.05.2018 IM_EAM, SS 2018, Teil 8 99
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)

Fragen zum Teil 8
24.05.2018 IM_EAM, SS 2018, Teil 8 100
• Was ist TOGAF?

• Nennen Sie drei Bestandteile von TOGAF.
• Welchen Schwerpunkt hat TOGAF?
• Wie definiert TOGAF das Unternehmen?

Eam SS2018 8

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Eam SS2018 8

Hochgeladen von

Copyright:

Verfügbare Formate

Enterprise-Architecture-

24.05.2018 IM_EAM, SS 2018, Teil 8 1

24.05.2018 IM_EAM, SS 2018, Teil 8 3

Quelle: BOC Group, 2010

Ähnliche Attribute findet man auch in Application Management Tools

Bewertung und Messung analog APM oder Balanced Scorecard

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

Quelle: Matthes EAM Foundations, sebis, 2016

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

• Die Funktionen werden unter Berücksichtigung verschiedener Dimensionen

• Es ist nützlich, die Capability in Capability Increments zu zerlegen, die

Um die Optimierungspotentiale zu analysieren und zu bewerten, empfiehlt es

Die Untersuchung einer Applikations- und Infrastrukturarchitektur im Hinblick

• Die Hypothesenbildung erleichtert den Prozess insbesondere bei der

• Im Technologiemanagement werden die technischen Standards, der

1. die Festlegung der für das Unternehmen relevanten

• Für jeden Standardisierungsbedarf z. B. für Datenbanken wird

Die Technologiedomäne ist das zentrale, technisch orientierte

• Die Technologiedomänen können als „Technology Portfolio“ betrachtet

Presentation Central Base Application

Operating Systems Network & Communication

Schnittkriterium Relevanz Erläuterung

IT-Bausteine lassen sich durch das Technologie-Domänenkonstrukt abbilden

«Hierarchie» Technologie nutzt Infrastrukturkomponente

abgebildet auf abgebildet auf abgebildet auf

Oracle ORA-DB 1234

Datenbankmanagementsystem DB2 ORA-DB 5678

Für die initiale Befüllung des Blueprints sind folgenden

In Abhängigkeit von der strategischen Positionierung der IT im Gesamtunternehmen gibt es unterschiedliche

Beherrschung und/oder Reduktion der IT-Komplexität

Optimierung des Tagesgeschäfts

Beitrag zur Weiterentwicklung des Geschäfts

• Erfüllung strategischer Anforderungen

• Nehmen Sie in den initialen Blueprint nur strategische

Die Weiterentwicklung der technischen Standards erfolgt ausgerichtet

Durch die Umsetzung der verabschiedeten Standardisierungsmaßnahmen wird

• Achten Sie auf die Angemessenheit, Tragfähigkeit, Zukunftsfähigkeit und

• Die besten technischen Standards helfen nicht, wenn sie nicht

• Durch die kontinuierliche Überwachung der Tragfähigkeit und

Kern-Technologien: Nicht zu früh an Bord nehmen, nicht zu lange behalten!

Quelle: Bente, EAM Transformation, 2015, p53,

• Eine leistungsfähige Suchmaschine, ein Tool zum Verarbeiten und

• Schon ein einzelner kleiner LAMP-Server produziert etliche Logdateien. Ein

Dokumentieren Sie die beiden Referenzarchitekturen in iteraplan und

24.05.2018 IM_EAM, SS 2018, Teil 8 36

• TOGAF basiert auf dem Technical Architecture Framework for Information

Die Komponenten von TOGAF 9.1

Quelle: BOC Group | boc@boc-group.com

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

Part II - Der Kern von TOGAF beschreibt die TOGAF

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

Part IV - Das TOGAF Content Framework beinhaltet u.

Part IV - 29.Introduction to Part IV

• Analysieren Sie die TOGAF Dokumentation.

• TOGAF 9.2 online: http://pubs.opengroup.org/architecture/togaf92-doc/arch/

• Ermitteln Sie in welchem Bereich von TOGAF die Referenzarchitekturen

Architekturdomänen nach TOGAF

Bei der Nutzung von TOGAF wird die Unternehmensarchitektur üblicherweise

Die Geschäftsarchitektur betrachtet die Strategie, die Aufbauorganisation,

Innerhalb der Anwendungsarchitektur werden die Anwendungen verwaltet,

Die Technologiearchitektur beschreibt die Architekturelemente für Aufbau

Part II - 4.Introduction to Part II

Das ADM beschreibt, wie eine organisationsspezifische Unternehmens-