SlideShare ist ein Scribd-Unternehmen logo
Unternehmensarchitektur vereint Gesch¨aftsprozesse und IT-Architektur. Um das Management in der
Planung, Umsetzung und Weiterf¨uhrung von Unternehmensarchitekturen zu unterst¨utzen, gibt es
verschiedene Enterprise Architecture Frameworks. Die Open Group bietet mit TOGAF ein solches
Framework – es findet weltweit Verwendung. Mit der vorliegenden Semesterarbeit soll der vierte Teil
von TOGAF Version 9 erl¨autert werden: Das Architecture Content Framework (Rahmenwerk f¨ur
Architekturinhalte). Es strukturiert die Ergebnisse aus der Architekturarbeit, dient zur ¨Ubersicht und
eignet sich als Schnittstelle zu anderen Frameworks.
Studiengang: Informatik, Modul BTI7311 Informatik Seminar
Autor: Roland Bruggmann, roland.bruggmann@students.bfh.ch
Co-Autor Tobias Millauer, tobias.millauer@students.bfh.ch
Dozent: Prof. Dr. Urs Sauter, urs.sauter@bfh.ch
Datum: 12. April 2015
Berner Fachhochschule | Haute ´ecole sp´ecialis´ee bernoise | Bern University of Applied Sciences
TOGAF Architecture Content Framework
IT-Management und Unternehmensarchitektur
mit TOGAF 9 Teil IV
Semesterarbeit
Inhaltsverzeichnis
1 Einleitung 1
2 Grundlagen 2
2.1 Enterprise Architecture Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1.1 Ebenen der Unternehmensarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2 Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.3 Zust¨andigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Enterprise Architecture Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Framework der Open Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2 Capability-Based Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.3 TOGAF in der Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Architecture Content Framework 6
3.1 Content Metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Architecture Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Schlussfolgerungen und Ausblick 12
Abk¨urzungen 13
Glossar 15
Literaturverzeichnis 16
Bildnachweis 17
Abbildungsverzeichnis 18
Tabellenverzeichnis 18
Stichwortverzeichnis 19
TOGAF Architecture Content Framework, 12. April 2015 i
1 Einleitung
Das Rahmenwerk f¨ur Unternehmensarchitektur der Open Group – The Open Group Architecture Framework (TO-
GAF) – wird als wichtiger offener Standard f¨ur die Architekturentwicklung anerkannt. Die Komplexit¨at von TOGAF
stellt die Anwender vor grosse Herausforderungen. Im Informatik-Seminar sollen deshalb verschiedene Gesichtspunk-
te von TOGAF beleuchtet werden.
Der vierte Teil von TOGAF, das Architecture Content Framework gibt eine ¨Ubersicht ¨uber m¨ogliche Arbeitsergeb-
nisse der Architekturarbeit und ein Metamodell, um diese einzuordnen. Mit der vorliegenden Semesterarbeit soll
dieses Framework eingehend erl¨autert werden. Dabei sollen auch Kosten und Nutzen der Architekturarbeit und
Grenzen des Frameworks zur Sprache kommen.
Der vorliegende Bericht ist in vier Kapitel geteilt: Auf diese Einleitung folgt der eine Erl¨auterung der Grundlagen
zu den Themen Enterprise Architecture Management, Enterprise Architecture Framework und zu TOGAF im all-
gemeinen (Kapitel 2). Im Hauptteil wird das Architecture Content Framework von TOGAF im speziellen behandelt
(Kapitel 3) und in den Schlussfolgerungen werden die wichtigsten Ergebnisse rekapituliert (Kapitel 4).
TOGAF Architecture Content Framework, 12. April 2015 1
2 Grundlagen
Eine Recherche zum Schlagwort ’Enterprise Architecture (EA)’ (dt. Unternehmensarchitektur) resultierte in folgen-
den Publikationen:
ˆ S. Aier, C. Riege und R. Winter (2008): Unternehmensarchitektur – Literatur¨uberblick und Stand der Praxis.
ˆ D. Matthes (2011a): Enterprise Architecture Frameworks Kompendium – ¨Uber 50 Rahmenwerke f¨ur das
IT-Management.
ˆ D. Matthes (2011b): Matthes Framework Map - frameworks according to their nationality and intention.
Aier, Riege und Winter [ARW08] am Institut f¨ur Wirtschaftsinformatik der Universit¨at St.Gallen gibt einen aus-
f¨uhrlichen Literatur¨uberblick. Matthes [Mat11a] listet und erl¨autert die wichtigsten 50 Frameworks. Diese zeigt er
auch auf einer informativen ¨Ubersichtskarte ([Mat11b]).
Zudem fanden sich die folgenden relevanten Publikationen in den Suchresultaten zum Schlagwort ’TOGAF’:
ˆ D. Weinberger (2010): . . . und am Anfang steht die Gesch¨aftsanforderung, oder?
ˆ A. Josey u.a. (2010): TOGAF Version 9 – Ein Pocket Guide.
ˆ The Open Group (2010): TOGAF Version 9.1. Document Number: G116.
ˆ W. Keller (2012): IT-Unternehmensarchitektur – Von der Gesch¨aftsstrategie zur optimalen IT-Unterst¨utzung.
Der informative Fachartikel von Weinberger [Wei10] wird zum Erarbeiten der Grundlagen verwendet. Nebst dem
online publizierten Dokument Nummer G116
”
TOGAF Version 9.1”auf dem Website der Open Group ([Ope-G116])
dient schliesslich der Pocket Guide zu TOGAF ([Jos+10]) als Hauptquelle f¨ur diesen Bericht. F¨ur eine austarierte
Beurteilung dient Kellers Publikation ([Kel12]).
Mit dem Newsletter Elca Update No. 8 ([ELCA14a]) und einem Flyer von ELCA ([ELCA14b]) kommt eine Consul-
ting Firma zur Sprache, anhand des Standards P030 des Informatiksteuerungsorganes des Bundes ISB ([ISB-P030])
wird ein Business Case aus dem Bereich der Verwaltung in der Schweiz erw¨ahnt.
F¨ur die Erl¨auterung einzelner Begriffe wird die Enzyklop¨adie der Wirtschaftsinformatik konsultiert, ein Online-
Lexikon der Universit¨at Oldenburg, herausgegeben von Kurbel u.a. ([Kur+14]). Es sei an dieser Stelle deklariert, dass
die Begriffe aus TOGAF als Fachbegriffe betrachtet werden, d.h. allenfalls nur soweit wie in [Jos+10] eingedeutscht
werden.
2.1 Enterprise Architecture Management
Wie dem Newsletter [ELCA14a] zu entnehmen ist, kann Enterprise Architecture Management (EAM) generell
als eine Schl¨usselkompetenz des Betriebsmanagement bezeichnet werden: Es vereint Gesch¨aftsprozesse und IT-
Architektur. Gem¨ass Aier, Riege und Winter [ARW08, S. 292 f.] hat das Management der Unternehmensarchitektur
in den letzten Jahren stark an Bedeutung gewonnen. Die Herausforderung bestehe darin,
”
die Gestaltung von
Gesch¨aftsfeldern und Produkten, deren Abbildung in Gesch¨aftsprozessen und Organisationsstrukturen bis hin zur
Implementierung durch Anwendungssysteme und dem Betrieb der dazu notwendigen Infrastruktur durch eine [. . . ]
Gesamtsicht des Unternehmens zu unterst¨utzen.“ Dies best¨atigt auch Xavier Ruvilly, Enterprise Architekt bei ELCA.
Er beurteilt das Management der Unternehmensarchitektur als
”
eine zentrale Disziplin, um verschiedene IT-Bereiche
wie [Business Intelligence (BI)], [Customer Relationship Management (CRM)], [Enterprise Content Management
(ECM)], Portale usw. zu einem umfassenden Ganzen zu kombinieren und um Trends wie Big Data, die Cloud,
Digitalisierung und Mobile Computing f¨ur die Gesch¨aftst¨atigkeit zu nutzen“ (vgl. [ELCA14b, S. 2]).
TOGAF Architecture Content Framework, 12. April 2015 2
2.1.1 Ebenen der Unternehmensarchitektur
Weinberger [Wei10, S. 2] bezeichnet Unternehmensarchitektur als Beschreibung der Struktur von Komponenten
und ihren Beziehungen ¨uber das gesamte Unternehmen. Die Dom¨anen der Unternehmensarchitektur gliedert er
grob in Business Architecture und IT Architecture, letztere wiederum in Information Systems Architecture und
Technology Architecture (siehe Abbildung 2.1). Die Br¨ucken und Beziehungen zwischen diesen Dom¨anen gelte es
aufzubauen und zu managen.
Die Architektur ist im Grunde die Be-
schreibung und die Struktur von Kompo-
nenten und ihren Beziehungen über die
gesamte Organisation, sprich das gesamte
Unternehmen. Somit geht es also um den
Aufbau und um das Managen von
„Brücken“ und ihren „Beziehungen“ im
gesamten Unternehmen. EAM beschränkt
sich also nicht nur auf IT, sondern umfasst
mehrere Systeme und funktionale Gruppen
im Unternehmen. Abbildung 2 verdeut-
licht das sehr gut.
Warum EAM? – Erfolgsfaktor
Unternehmenskultur
Eine Frage, die oft gestellt wird und schon
viele in Argumentationsnöte gebracht hat.
Haben die Unternehmen zudem noch
schlechte Erfahrungen mit EAM – vielleicht
gar in Verbindung mit serviceorientierter
Architektur (SOA) – gemacht, führt das
zwangsläufig zu einer Grundsatzfrage im
Unternehmen. Prinzipiell kann man sagen,
dass EAM das im Unternehmen umsetzt, was
die Geschäftsstrategie entwickelt bzw. die
Geschäftsanforderungen aus dem „Daily
Business“ einfordern. Die Kunst besteht
jedoch darin, die richtige Balance zwischen
diesen Geschäftsinnovationen und der IT-
Effizienz zu finden, siehe auch Abbildung 3.
Um dem Ganzen einen praktischen
Bezug zu geben, ein kurzes Beispiel. Eine
Firma A unterhält geschäftliche Bezieh-
ungen zu einer Firma B. A verkauft in die-
sem Fall eine Lösung an B, woraufhin B
eine Preisreduzierung nachfragt. Gleich-
zeitig ist B Lieferant und verkauft Produkte
an A. Hier hat B jedoch Probleme im
Service und die Aktivitäten der Geschäfts-
beziehung 1 sind hier nicht bekannt. Zu
guter Letzt ist B auch noch ein Partner von
A. Er fungiert hier als Vertriebs- und als
Technologiepartner. Der Vertrieb läuft
jedoch schleppend und die Produkte lassen
sich nur schwierig integrieren. In
Abbildung 4 sind diese Beziehungen noch
einmal grafisch dargestellt.
Wie man an diesem Beispiel deutlich
sehen kann, sind in diesen drei
Geschäftsfällen zwei Akteure in unter-
schiedlichen Rollen involviert. Dies
Konstrukt ist mit Sicherheit nicht imm
der Fall und auch nicht immer so komple
aber gerade im B2B-Geschäft sind die
oder ähnliche Beziehungen zwisch
Unternehmen sehr häufig anzutreffe
Auch bedeutet es nicht automatisch, da
die Beteiligten eines Geschäftsfalls von d
Aktivitäten eines anderen Geschäftsfa
Kenntnis haben bzw. haben wollen. D
mag jetzt weit hergeholt klingen, ist ab
durchaus häufiger der Fall, als man denk
Aber warum eigentlich? Ganz einfach, a
drei Parteien haben für sich unterschied
che Ziele. So hat der Vertrieb i
Geschäftsfall A das Ziel, Umsatz mit de
Kunden (Akteur B) zu generieren, d
Einkauf soll mit seinem Lieferanten (gleic
er Akteur B, aber andere Rolle) Einkauf
kosten einsparen und der Partner-Manag
liegt irgendwo dazwischen. Ein gemeins
mes Ziel, wie eingangs in der Begriff
definition beschrieben, sieht anders aus.
Was hat das Ganze jetzt mit EAM
tun? Bisher wurden EAM-Projekte mei
durch Anforderungen von einzeln
Geschäftsbereichen initiiert, die den Fok
auf bestimmte Geschäftsprozesse und d
diese unterstützenden IT-Anwendung
legten. Hinzu kam, dass der Erfolg ma
geblich von den Erfahrungen und Fähi
keiten des EAM-Teams abhängig war. Hi
bietet TOGAF 9 mit dem Architectu
Skills Framework z.B. eine gute Method
das Wissen der Architekten zu bewert
und entsprechend weiterzuentwickeln.
Das Beispiel oben und die folgenden, si
daraus ableitenden, Fragestellungen zeig
2Online-Themenspecial EAM 2010
Online-Themenspecial EAM 2010 fachartikel
Abb. 2: Domänen der Architektur
Abb. 3: Darum EAM
Abbildung 2.1: Dom¨anen der Architektur
Aier, Riege und Winter [ARW08, S. 292 f.] gliedert die Unternehmensarchitektur in f¨unf Ebenen und beruft sich
dabei auf den Standard 1471-2000 des Institute of Electrical and Electronic Engineers (IEEE) (siehe Tabelle 2.1).
Tabelle 2.1: Ebenen der Unternehmensarchitektur
Strategie: Produkte, Dienstleistungen, Unternehmensziele, Kunden, Zulieferer.
Organisation: Vertriebskan¨ale, Gesch¨aftsprozesse, Organisationseinheiten, Rollen, Standorte.
Integration: Applikationen, Dienste, Schnittstellen.
Software: Softwarekomponenten, Datenstrukturen.
IT-Infrastruktur: Hardware, Netzwerk, Software-Plattformen.
2.1.2 Nutzen
Auf die Frage:
”
Warum EAM?”geht Weinberger [Wei10, S. 2] ein. EAM setze im Unternehmen um, was Gesch¨aftss-
trategie und Gesch¨aftsanforderung im t¨aglichen Gebrauch einfordern w¨urden.
Ein Hauptnutzen des EAM kann die Transparenz der Zusammenh¨ange in der Unternehmung sein. Diese kommt
gerade bei Unternehmensver¨anderungen zum Tragen. Soll z.B. ein System oder eine Technologie abgel¨ost werden,
kann gezeigt werden, welche Daten, Prozesse oder organisatorischen Einheiten der Unternehmung vom Wechsel
betroffen sind. Entsprechend k¨onnen Massnahmen den Bed¨urfnissen angepasst geplant und umgesetzt werden.
Dasselbe gilt f¨ur die ¨Anderung eines Gesch¨aftsziels, so Weinberger [Wei10, S. 3]:
”
Wenn das Produktmanagment in
Abstimmung mit der Gesch¨aftsstrategie Produkte weiterentwickelt [. . . ], um neue Kunden und M¨arkte zu bedienen
[. . . ], muss die Frage gekl¨art werden, wer in der neuen Zielarchitektur f¨ur welche Aufgabe zust¨andig ist, wie die IT
das unterst¨utzt und wie [. . . ] externe Partner integriert werden.”
2.1.3 Zust¨andigkeiten
Michael Schr¨oder, Head of Business Consulting Z¨urich verortet das Management der Unternehmensarchitektur als
”
eine der zentralen Disziplinen des [Chief Information Officer (CIO)], neben dem Strategie- und Portfoliomana-
gement“ ([ELCA14b, S. 3]). Anstelle der Bezeichnung CIO verwendet Keller [Kel12, S. xi] hingegen explizit den
TOGAF Architecture Content Framework, 12. April 2015 3
Begriff des IT-Vorstandes, womit
”
auch der Gesch¨aftsf¨uhrer eines ausgegr¨undeten IT-Dienstleisters, der nicht den
Titel Vorstand tr¨agt”, gemeint sein kann.
2.2 Enterprise Architecture Framework
Zur Unterst¨utzung des IT-Management bei der Planung, Migration oder Weiterf¨uhrung von Unternehmensarchitek-
turen empfiehlt es sich, ein Enterprise Architecture Framework (EAF) (dt. Unternehmensarchitekturrahmenwerk)
einzusetzen. Solche gibt es nicht wenige – Matthes [Mat11a] beschreibt deren 50 an der Zahl. Er gruppiert die am
Markt verf¨ugbaren EAF in sieben Typen (vgl. [Mat11b]):
ˆ Government and Agency Framework: massgeschneidert f¨ur die Bed¨urfnisse von Beh¨orden
ˆ Interoperability Framework: zur Umsetzung von Interoperabilit¨at
ˆ Management Framework: f¨ur die Unterst¨utzung des Managements
ˆ Manufacturing-Specific Framework: f¨ur Produktionsl¨osungen
ˆ Military Framework: zur Unterst¨utzung von milit¨arischen Bed¨urfnissen
ˆ Add-On Framework: als Erg¨anzung anderer Frameworks, Projekten usw.
ˆ Technical orientated Framework: Rahmenwerk ohne betriebswirtschaftliche Management-Methoden
Gem¨ass einer Einsch¨atzung von Keller [Kel12, S. 296] sind von den bekannten EAM-Frameworks vorallem TOGAF
mit einem sich im Wachsen befindenden Marktanteil von 32%, gefolgt von Zachman mit einem stagnierenden
Marktanteil von 25% von Relevanz (Stand 2008), nebst den Frameworks aus dem ¨offentlichen Sektor in den USA
wie z.B. das Department of Defense Architecture Framework (DoDAF).
2.2.1 Framework der Open Group
Wie [Ope-G116] zu entnehmen ist, z¨ahlen zum Konsortium der Open Group namhafte Unternehmen wie HP, IBM,
Oracle oder Phillips. Die Mitglieder sind gem¨ass Matthes [Mat11b] zu 50% in Nordamerika, zu 25% in Europa
und zu 25% im asiatisch-pazifischen Raum ans¨assig. Das Framework findet somit weltweit Verwendung, zur Zeit
in der Version 9.1. Matthes [Mat11b] ordnet TOGAF der Gruppe der Management Frameworks zu. Wie Aier,
Riege und Winter [ARW08, S. 295] aufzeigt, deckt TOGAF vier Ebenen der Unternehmensarchitektur gem¨ass IEEE
(vgl. Tabelle 2.1) ab, beginnend bei der Organisation, vorallem aber die drei Ebenen Integration, Software und
IT-Infrastruktur. Keller [Kel12, S. 294] sieht TOGAF ausschliesslich als Framework zur Prozessdefinition im IT-
Management und verweist auf ein Klassifizierungsraster von Rozemeijer und Van Bon [RV07, S. 24], das TOGAF
als rein taktisches Framework ohne strategischen oder operativen Elementen beurteilt (siehe Abbildung 2.2).
Abbildung 2.2: Klassifizierungsraster f¨ur EAM-Frameworks
TOGAF Architecture Content Framework, 12. April 2015 4
Das Rahmenwerk besteht gem¨ass [Jos+10, S. 22] aus sieben Teilen:
1. Einf¨uhrung: Schl¨usselkonzepte, Terminologie, Release notes
2. Architecture Development Method (ADM): Schritt f¨ur Schritt eine EA entwickeln
3. ADM Guidelines & Techniques
4. Architecture Content Framework: Content Metamodel mit Deliverables aus Artifacts und Building Blocks
5. Enterprise Continuum & Tools: Verwaltung von unternehmensweiten Resultaten
6. TOGAF Reference Models: TOGAF Foundation Architecture, Integrated Information Infrastructure Refe-
rence Model (III-RM).
7. Architecture Capability: Anforderungen an eine Architekturfunktion
2.2.2 Capability-Based Planning
Weinberger [Wei10, S. 3] stellt fest, dass EAM-Projekte oft auf die Architektur der Systeme und Technologien
fokussieren. Im besten Fall werden noch ein paar Gesch¨aftsprozesse davor und danach erw¨ahnt. Einen anderen
Ansatz bietet das Capability-Based Planning: Die Gesch¨aftsstrategie wird unterst¨utzt durch ein Gesch¨aftsziel – dieses
wird sodann als Business Capability (dt. Gesch¨aftsf¨ahigkeit), kurz Capability bezeichnet. Um die Gesch¨aftsf¨ahigkeit
resp. die Capability zu erreichen, sind meist sowohl mehrere organisatorische Einheiten als auch Prozesse und
verschiedene Systeme oder Technologien involviert (siehe Abbildung 2.3). TOGAF basiert auf diesem Konzept.
Eventuell müssen bestimmte Personen oder
Personengruppen speziell ausgebildet wer-
den, um den neuen Anforderungen gerecht
zu werden.
Auf einer anderen Ebene muss identifi-
ziert werden, wie „fähig“ die IT und die
Infrastruktur sind, diese Prozesse und letzt-
endlich die Bereitstellung des neuen
Produktes zu unterstützen. Aktivitäts-
diagramme, Applikationskataloge oder
Matrizen können z.B. die entsprechenden
Artefakte darstellen. Wird in diesem Fall
ein neues Datacenter mit neuen Applika-
tionen benötigt, spielen die Konsolidierung
der gesamten Daten und die Bereitstellung
der neuen Services eine große Rolle. Diese
Beschreibung verdeutlicht sehr gut, dass die
Geschäftsfähigkeiten auf der operati-
ven Ebene abzuschätzen und entspre-
chende alternative Fähigkeiten auszu-
wählen.
■ Ein Bausteinansatz erlaubt individuelle
Fähigkeiten innerhalb ihrer eigenen
Geschäftsdomäne zu definieren, zu ent-
wickeln und zu testen.
Die einzelnen Fähigkeiten in diesem Bei-
spiel der Produktneuentwicklung können
innerhalb einzelner, kleiner Architektur-
domänen der Geschäfts-, Informations-
und Technologiearchitektur (Phasen B, C
und D im TOGAF ADM) evaluiert und
entwickelt werden. Die Geschäftsprozesse
und die handelnden Personen sind dann in
der Geschäftsarchitektur zu betrachten,
Die fähigkeitsbasie
also um die Etablieru
eine bestimmte An
Aufgaben zu erfüllen
erheblicher Nutzen,
die Migrationsplan
angeht. Man hat
Geschäftsnutzen un
Geschäftsresultat (B
Auge und fokussiert
Unternehmensarchit
Architecture) auf die
Fazit
Capability-Based Pla
stellt mit Sicherheit
um auf der Basis
schäftsresultaten ein
bauen und zu mana
diese Methode nich
anwendet, sollte
Geschäftsnutzen un
Resultat für die Ges
daraus schlussfolge
tivitäten zugrunde leg
sind in diesem Fall w
anforderungen an da
und stellen eigentlich
der Architektur – Ge
Phase B nach TOGA
Als Pionier und w
Bereich Enterprise A
ment und TOGAF, b
Enterprise langjähri
und Beratungsangeb
TOGAFTM
9 for
zierungskurs, Ent
Assessment Services
prise Architecture
shops zu verschiede
Online-Themenspecial EAM 2010 f
Abb. 5: Capability Increments and Dimensions – TOGAF 9
Abbildung 2.3: Beispiel-Inkrement einer Capability mit involvierten Dimensionen
2.2.3 TOGAF in der Verwaltung
In der Schweiz findet TOGAF Verwendung in der Bundesverwaltung. Wie das Informatiksteuerungsorgan des Bundes
(ISB) festh¨alt, ist TOGAF
”
sehr offen und l¨asst die Integration [von] anderen Methoden wie z.B. U.S. DoDAF oder
[Federal Enterprise Architecture Framework (FEAF)] oder Entwicklungen wie z.B. der Service Oriented Architecture
(SOA) ohne weiteres zu” (vgl. [ISB-P030, S. 4]). Letzteres best¨atigt auch Matthes [Mat11b]: So bietet z.B. die
Firma SAP AG ein EAF an, konzipiert als technisches Framework und Add-On zu TOGAF, um das Einbinden von
SOA zu realisieren.
TOGAF Architecture Content Framework, 12. April 2015 5
3 Architecture Content Framework
Der vierte Teil von TOGAF beschreibt das Architecture Content Framework (dt. Rahmenwerk f¨ur Architekturinhal-
te). Das Rahmenwerk soll zur ¨Ubersicht dienen: Es enth¨alt ein strukturiertes Content Metamodel, um Erzeugnisse
aus der Architekturarbeit zu sammeln und einzuordnen. Gem¨ass [Jos+10, S. 125] kann TOGAF erst durch das
Architecture Content Framework als eigenst¨andiges Framework f¨ur Architekturen bezeichnet werden. Anstelle des
Architecture Content Framework k¨onnte auch ein Framework wie ArchiMate oder Zachman Verwendung finden.
Kommt aber das Architecture Content Framework von TOGAF zum Einsatz, kann dieses auch als Refernz zu den
Metamodellen anderer Frameworks dienen.
Das Architecture Content Framework von TOGAF unterscheidet drei Typen von Erzeugnissen, die mit der ADM
erarbeitet werden: Deliverables, Artifacts und Building Blocks (dt. Arbeitsergebnisse, Artefakte und Bausteine; siehe
dazu Abbildung 3.1). Nach Josey [Jos+10, S. 126] k¨onnen diese folgendermassen umschrieben werden:
Deliverable: Formales, vertraglich spezifiziertes Erzeugnis, das von den Stakeholdern ¨uberpr¨uft, genehmigt und
abgenommen wird, h¨aufig als Resultat von Projekten.
Artifact: Detailliert definiertes Erzeugnis, das eine Architektur aus einer bestimmten Perspektive heraus beschreibt.
Ein Deliverable kann mehrere Artefakte enthalten (siehe dazu das Beispiel in Abbildung 3.2): Kataloge (Auf-
listungen von Elementen), Matrizen (Darstellungen von Beziehungen zwischen den Elementen) und/oder
Diagramme (Abbildungen von Elementen).
Building Block: Komponente einer Gesch¨afts-, IT- oder Architekturf¨ahigkeit (vgl. Abschnitt 2.2.2), evtl. wieder-
verwendbar.
Abbildung 3.1: Deliverables mit Artifacts und Building Blocks
Abbildung 3.2: Deliverable am Beispiel eines Architecture Definition Document
TOGAF Architecture Content Framework, 12. April 2015 6
3.1 Content Metamodel
Das Architecture Content Framework enth¨alt ein strukturiertes Content Metamodel, um Erzeugnisse aus der Archi-
tekturarbeit zu sammeln und einzuordnen (siehe Abbildung 3.3). Das Framework sieht Core Entities (dt. Kerninhalte)
und Extensions (dt. Erweiterungsinhalte) vor. Mit den Core Entities soll das Umsetzen einer EA mit vern¨unftigem
Aufwand erm¨oglicht werden, lediglich bei Bedarf werden gem¨ass [Jos+10, S. 128] Extensions eingearbeitet, bis
hin zum m¨oglichen Full Content Metamodel. In diesem Bericht beschr¨anken wir uns jedoch auf das Core Content
Metamodel.
Abbildung 3.3: Content Metamodel nach ADM-Phasen
Das Framework enth¨alt schliesslich Listen mit den Beschreibungen s¨amtlicher Entities, ihren Attributen und den
Beziehungen zwischen den Entities unter Angabe der Extension, in welcher die Entities allenfalls zu finden sind.
3.2 Architecture Artifacts
Die Arbeitsergebnisse der ADM, die sogenannten Architecture Artifacts (dt. Architektur-Artefakte) werden gem¨ass
[Ope-G116] erstellt, um ein System, eine L¨osung oder einen Zustand des Unternehmens zu beschreiben. Das Konzept
dazu wurde vom Standard ISO/IEC 42010:2007 resp. IEEE 1471 adapdiert (siehe Abbildung 3.4). Ein Artefakt
kann nach [Jos+10, S. 130] in unterschiedlichem Kontext wiederverwendet werden. [Jos+10, S. 131] erl¨autert die
Konzepte dazu, wie sie in TOGAF f¨ur die Sichten zur Anwendung kommen. Diese sind knapp zusammengefass in der
Tabelle 3.1. Eine m¨ogliche Konstellation dieser Konzepte und ihrer Beziehungen wird in Abbildung 3.5 gezeigt.
Tabelle 3.1: Konzepte in Verbindung mit Sichten auf die Architektur
System Eine Sammlung von Komponenten, die organisiert sind, um eine
Funktion auszuf¨uhren.
Architektur Allgemeine Anordnung von Komponenten, die Beschreibung ihrer Be-
ziehungen untereinander und zur Umgebung sowie die Prinzipien zur
Steuerung der Weiterentwicklung.
Architektural
description
Sammlung von Artefakten zur Dokumentation der Architektur.
Stakeholder Personen, die eine wichtige Rolle im System einnehmen oder Anliegen
(Concerns) bez¨uglich des Systems haben.
Concern Hauptinteressen, die f¨ur die Stakeholder von entscheidender Bedeu-
tung sind.
View Darstellung des Gesamtsystems aus einem Blickwinkel betrachtet,
dder durch gleichartige Concerns resp. Interessen bestimmt wird.
Viewpoint Bestimmt den Blickwinkel, aus dem die Bildung eines Views erfolgt.
TOGAF Architecture Content Framework, 12. April 2015 7
Abbildung 3.4: Grundkonzepte der Architekturbeschreibung
Abbildung 3.5: Die Konzepte und ihre Beziehungen
Views und Viewpoints
Die Entwicklung verschiedener Views und Viewpoints (dt. Sichten und Perspektiven auf die Unternehmensarchi-
tektur) erfolgt w¨ahrend der Architekturarbeit mit der ADM und wird deshalb im Teil III von TOGAF beschrieben.
Entsprechende Werkzeuge und Sprachen f¨ur die Entwicklung der Views sind im Teil V von TOGAF zu finden.
Werkzeuge gibt es gem¨ass [Ope-G116] viele – was fehle sei eine gemeinsame Sprache f¨ur den Datenaustausch.
Auch Keller [Kel12, S. 160] beklagt das Fehlen einer Standardisierung:
”
Solche Darstellungen leiden h¨aufig unter
¨ahnlichen Problemen: Die Semantik der Darstellung ist nicht immer klar.”Wichtig w¨aren die Vereinheitlichung von
Farbe, Position und Gr¨osse der Objekte sowie der Verbindungen. Keller [Kel12, S. 161 f.] erl¨autert sodann die Soft-
warekartographie als Grundlage der Systematisierung und nennt Clusterkarten, Prozessunterst¨utzungskarten und
TOGAF Architecture Content Framework, 12. April 2015 8
Intervallkarten als
”
Softwarekarten mit Kartengrund zur Verortung”. Winter [Win09, S. 22] hat dazu ein Beispiel
mit Sichten und Perspektiven, erstellt mit ADOben (siehe dazu Abbildung 3.6).
TOGAF listet und beschreibt schliesslich alle Artifacts, die in den verschiedenen ADM-Phasen erarbeitet werden
sollen (siehe dazu auch Abbildung 3.7). In [Ope-G116] wird empfohlen, die folgenden Sichten zu erstellen: Business
Architecture View, Enterprise Security View, Software Engineering View, System Engineering View, Communications
Engineering View, Data Flow View, Enterprise Manageability View und Acquirer View.
© Aug-09, IWI-HSG
Seite 22
Beispiel für einen „ausgewogenen“ UA-Ansatz
Kundensysteme
Lieferanten-Systeme
Kernsysteme
Interne Systeme
Ÿ
Web-Portal
Ÿ
CRM-System
Ÿ
Kundenverwaltungs-
System
Ÿ
Produkt-Datenbank
Ÿ
Angebots- und
Buchungssystem
Ÿ
Lieferanten-
Datenbank
Ÿ
Internes
Mitarbeiter-
Informationssystem
Ÿ
HR-System
Ÿ
Finanzsystem
(Individualentwicklung)
Ÿ
DWH
Ÿ
Abrechnungssystem
Ÿ
Lieferanten-
Schnittstellen-
System
Ÿ
Produkt-Liste (Excel)
Ÿ
Finanzsystem (SAP)
Ÿ
Schnittstelle zu
Markt-
forschungsinstitut
Applikationen (Bestandsführung)
Ausserhalb deseigenen Unternehmens
Ausserhalb des eigenen Unternehmens Applikationen der smartTravel AG
Web-Frontend
Back-Office
Ÿ
Web -Po rta l
Ÿ
CR M-Syst em
D
Ku nd en spe zi fisc he
Em pfeh lu ng en
Ÿ
Kun denver waltu ngs-
SystemD
K un de nprä feren ze n
D
Ku den da ten
Ÿ
Pr oduk t-D at enbank
D
A ktue ll e A ng eb ote
Ÿ
An gebot s- und
Bu ch ungssystem
D
An ge bote
D
K un de na nfrag e
D
An ge bo te
D
An frage ,
B esta nd sko rrektu r
Ÿ
Ab rechnu ngssyst em
D
Z ah lu ng sda ten
Ÿ
Lief eran ten-
D at enbank
D
A nbi e te rda ten
Ÿ
Liefer ant en-
Schnit tste llen-
System
D
A nfrag e, Bu chu ng
D
A ng ebo te,
B uch un gsb estä tig un g Ÿ
An gebot s- und
Bu ch ungssystem
( Liefer ant)
D
An frage , B uch un g
D
A ng eb ote,
B u chu ng sbe stäti gu ng
D
Sch ni ttste ll en da ten
Ÿ
Int ern es
Mit arb eiter -
I nf orm ations s ys tem
D
A nb ie terda ten
Ÿ
H R -Syste m
D
Mi ta rbei terd ate n
Ÿ
Finan zs ys te m
( In dividualen twic klun g) D
D aten z ur R enta bi l itä t
v on
G esch äftsb ezi eh un ge n
D
R ech nu ng sda ten
D
A nal yti sch e
Fi na nz date n
Ÿ
D WH
D
A ufbe rei tete
F in an zda ten
D
A nb ie terda ten
(A bg le ic h)
Ÿ
Zahlun gs sys t em
(K redit kart enun ter nehmen
und B anken)
D
Z ah lu ng sd ta en
Ÿ
Schnit tste lle zu
Mar kt-
for schungsinst itut
D
Mark tda ten
Ÿ
Fin anzsys t em ( SAP)
Ÿ
Pr odukt -List e (Excel)
Applikationslandkarte
Prozesslandkarte
smartTravelAG - Gesamtunternehmen
Führungsprozesse
Leistungsprozesse
Unterstützungsprozesse
05 Unternehmens-
strategie
entwickeln
06 Unternehmens-
comntrolling
durchführen
07 IT-Betrieb
08 Finanz- und
Rechnungswesen
01
Kundengewinnung
und -Beziehungs-
management
02 Reiseabwicklung
03 Lieferanten-
gewinnung und
-Beziehungs-
management
04 Angebots-
erstellung
Geschäftsleitung
Funktionen auf
Konzernebene
Controlling und
Budgetierung
Innovati ons-
Management
Personal-Managem ent
Finanzen und
Administration
Marketing und
Werbung
Kundenwerbung
Anbieterwerbung
Marktforschung
Lieferanten-
Management
Airli nes
Hotel s
Mi etwagenfirmen
Kundenmanagement
Individualreisen
Paus chalreis en
Städtereis en
Aktivurlaub
Erlebnisurlaub
Club-U rlaub
IT
Familienurlaub
Anwendungs-
Entwicklung
Anbieter-Integration
IT-Infrastruktur
Reiseversicherer
Angebote vor Ort
Zusatzdi enste
Aufbauorganisationsmodell
Lieferanten-
Information
ii
Lieferanten-
Schnittstellen-
Informationii
Zahlungs-Information
ii
Reiseinformation
ii
Reiseverlaufs-
information
ii
Reise
ii
Buchung
ii
Buchungsbestätigung
ii
beschrieben in
hat
hat
Informationsmodell
Kunden-
bedarfsanalyse -
Individualreisen
i
Kundenbeda rf Lieferanten-
gewinnung -
Individualreisen
i
Lieferanten-
Information
Lieferanten-
betreuung -
Pauschalreisen
Lieferanten-
Anbindung -
Pauschalreisen
Komponenten-
einkauf -
Pauschalreisen
i
Reise-Kompone nte Referenzprozess
Erstellung
Pauschalangebote
i
Leistungspake t
i
Kundena nfrage
Anfrage-Eingang
und
Angebotserstellung
- Pauschalreisen
Reisebuchung -
Pauschalreisen
i
Leistungspak et
i
Reiseinformation
Reisebetreuung -
Pauschalreisen
08Finanz- und
Rechnungswesen
i
Zahlungs-Information
07IT-Betriebi
Lie feranten-
Schnittste llen-
Information
Kunden- und
Marktanalyse -
Pauschalreisen
Kunden-
Beziehungs-
management -
Pauschalreisen
Kundenwerbung -
Pauschalreisen
i
Reiseverlaufs-
informati on
i
Kundenpräferenz
i
Marktanalyse
Informationslandkarte
smartTravel AG Geschäftskunden
Privatkunden
P auschalreisen
Transport
Mietwagen-Anbieter
Reiseversicherer
Hotel s
Routenplaner
Wetterdienste
Anbieter von S prachführern
Anbieter von Ausfügen und
V eranstaltungen
Anbieter von Auslands-
Telefonkarte n
Anbieter von Reisebücher n
bzw. Reiseführern
Foto-Dienstleister
F
Indivi dualrei sen
F
Städterei sen
Privatkunde
Ei nzelpersonen
F
Akti vurl aub
F
Cl ub-Url aub
F
Erlebnisrei sen
F
Fam il i enurl aub
Ai rlines
SharedServi c eProvi der
Mi etwagen-Anbi eter
Shared Servi ce Provi der
Rei seversi c herer
Shared Servi ce Provi der
H otels
Shared Servi ce Provi der
R outenpl aner
Shared Servi ce Provi der
Wetterdienste
Exc lus iveServi ce. ..
Anbi etervon
Srachführern
ExclusiveService...
Anbi etervon Ausfl ügen
und Veranstal tungen
SharedServi c eProvi der
Anbi etervon
Ausl andstel efonkarten
SharedServi c eProvi der
Anbi etervon
Reis eführern bz w.
Reisebüchern
SharedServi c eProvi der
Online-Fotoal ben
ExclusiveService...
Tradi tionel le
Fotoentwic kler
ExclusiveService...
U nternehmenBahn
SharedServi c eProvi der
Busunternehmen
SharedServi c eProvi der
®
Buchungspl attform
der Bahn
BCI
F
Individualreise n Privat kunde
Û
Auf ruf de r
Reiseplattf orm /
Konta ktanbahnung
Û
Konfiguration eine r
Indiv idualreise
Ü
Market ing(Werbung
durchf ühren,
Plattform-, Reise-...
Ü
Erst elklung eine r
Resiek onfiguratio n
Ü
Verwalt ung vo n
Reiseko nfiguratione n
Û
Inform at ione nübe r
die Reiseplattf orm
Ü
Angebot
kont exta bhängige r
Zusat zangebot e... Û
Suche nac h
Zusat zangeboten
(Tele fonk art en,...
Û
Buchung des
individuellen Angebot s
Ü
Buchungde s
individuellen Angebot s
Ü
Zahlungsabwicklung
Ü
Angebot zusätzliche r
Mögli chkei tenv or Ort
(Veranstaltungen,... Û
Suche nac h
Ange bote nvorOrt
(Veranstalt ungen,.. .
Û
Zahlung
Û
Unt erstützung bei
Probleme n
Ü
Hot line
Ü
Bet reuung vor Ort
Û
Verwa ltungde r
Urlauibsfotos
Û
Reiseinfor matione n
Ü
Entwic klung /
Bereitst ellung der
Urlaubsf otos
Ü
Buchungsbest ätigung
Ü
Identif ikation vo n
Alternativangebot en
Û
Inform at ione nübe r
Alternativangebot e
Ü
Zusatzinformationen
(Wetter, etc.)
Û
Last Minute -
Inf orm ationen vor
Reiseant rit t
®
Pay Servic e
Pauschalreisen
001
Städtereise:
v
®®
Ü
002
Club-Urlaub:
v
®
®
Ü
003
Familienurlaub:
v
®
®
Ü
004
Erlebnisreisen:
v
®
®
Ü
005
Aktivurlaub:
v
®®
Ü
006
Jugendreisen:
v
®®
Ü
007
Studentenreisen:
v
®®
Ü
008
Studienreisen:
v
®
®
Ü
009
Single-Reisen:
v
®
®
Ü
002
Sporturlaub:
v
®
®
Ü
009
Themenreisen:
v
®®
Ü
ZielgruppeImage/MarkeLeistungsangeobotZweiseitigeKommunikationMitbewerber
Gruppenstruktur
Alte rsst rukt ur
Kostenstruktu r
Tra nsport -Prä ferenz
Werte
Int eraktionsziele
Mit bewerber
Nebenkosten-Präf erenz
Bet reuungs-Int ensit ät
Präferenzen zur Gestalt ung des Auf enthalts
Image / Mark e
Kommunikations-Präferen z
All ei nr ei se n Si ngl e-R ei se nPaarre is en Fam il ie nr ei se n G rup penrei se n
J ug en d Stude nt en Jun ge B er uf stätig e Be ru fs täti g e Se ni or en
D is co un te r Mit tel kla ss e Obere Mi ttel kla ss e Lu xu s
Fl u g Bus Indi vidual -Anrei s eZu g
Erl ebni s &
Abent eu er
Erholu n g Sp o rtKun st & K ul tur
D esi gn &
Am b ie nt e
Party
I ndi vid ual i tät
G ruppen -
ind ivi du ali tät
Ko ntaktori en ti ert
Reis eb üro s
On li ne-
Pl attform e n
Lok al e
Re is eanb ieter
Re is ek on ze rn e
Lan d & Le ute
Selb st v ers orge r
Ü be rn ac ht un g &
Frühs tüc k
Vo ll pe ns ionHal bp ens ion Al l I nc l us iv e
H ot lin e
Ans pr ec hpar tn er
vor Ort
Rei se le itung vor
Or t
Bi ld un g
I nd ivi dual
Vor -O rt
Paketan ge bo te
Ko mp l ett -
Arran ge m en ts
Kul in ari sc h
Tradi ti on el l Conveni enc e Exkl usi v Fac hkundi g Pr ei s we rt
Mo de rn &
I nnovati v
Kun den -S B
pas s i ver-
s em ip er sö nl i c he...
pa ss iver-
pe rs önl i c her.. .
U nte rnehem ens -
ak ti ve r Kontak t
Geschäftsnetzwerk-
modell
Geschäftspartner-
prozessmodell
Produkte und Services
(Bestandsführung)
Strategische
Positionierung
Stammdaten
Operative Daten
Analytische Daten
Kundenanfrage
Reiseangebot
Kunde Kundenpräferenz
Zahlungs-
information
Lieferanten-
Schnittstellenin...
Anbieter
Analytische
Finanzinformati...
Rechnung
Anbieter-
Rentabilität
Mitarbeiter
Finanz-
information
Buchung Buchungs-
bestätigung
hat
hat
Produkt-
information
bezieht sich auf
gehört zu
bezieht sich auf
gehört zu
gehört zu
Marktdaten
Datenmodell
C01 Cluster 1
001
DWH Te mp Tables
003
Komponente
Auswertungen
003
DWH Core Customer
004
Preismodell
002
Komponente
Buchung
Softwarelandkarte
ZonenPhysische Server Servercluster
Anton
Bert
Cl audia
Die te r
Egon
Freddy
01
Ant on
V
0101
Alf ons
V
0102
Albert
V
0103
Arne
02
B ert
V
0201
Bernd
V
0202
Bet tina
V
0204
Bine
V
0203
Beat
03
Claudia
V
0301
Claus
04
Diet er
V
0401
Diet mar
V
0402
Dagobert
V
0404
Denise
V
0403
Dagmar
05
Egon
V
0501
Ernie
06
Freddy
V
0601
Frieda
V
0602
Friedmann
V
0604
Franzi
V
0603
Fritz
V
0405
Dolce
ŸŸ
C01
Cluster 1
V
0205
Bertram
ŸŸ
C02
Cluster 2
ŸŸ
C03
Cluster 3
ŸŸ
C04
Cluster 4
ŸŸ
C05
Cluster 5
V
Edeltraut
Server-Modell
Unix/Linux
Microsoft Windows
Novell Netware
IBM OS/390
Ÿ
Windows 2000
Ÿ
Windows 2003
Ÿ
OS/390 V2R6
Ÿ
Windows NT 4.0
Ÿ
Solaris 9
Ÿ
HP-UX 11.00
Ÿ
SUSE Linux 8.1
Ÿ
Solaris 8
Ÿ
Solaris 10
Ÿ
Solaris 2.6
Ÿ
AIX 5.2
Ÿ
AIX 5.3
Ÿ
HP-UX 10.20
Ÿ
Debian Linux 3.1
Ÿ
Red Hat Enterprise
Linux
Ÿ
Embedded Linux
Ÿ
Net Ware 5.1
Ÿ
NetWare 4.11
Systemsoftware
(Bestandsführung)
ŸŸ
ŸŸŸ
Ÿ
Produkt-Datenbank
(Produktion)
ŸŸ
ŸŸŸ
Ÿ
Angebots- und
Buchungssystem
(Produktion)
Environment-Modell
StrategieOrganisationAlignment
Softwareund
Daten
IT-Infrastruktur
FRAGE
1
Abbildung 3.6: Beispiele von Sichten und Perspektiven
Abbildung 3.7: Architecture Artifacts des Core Content Metamodel sowie der Extensions
TOGAF Architecture Content Framework, 12. April 2015 9
3.3 Deliverables
Das Content Metamodel verwaltet die Deliverables, welche typischerweise im ADM-Zyklus ben¨otigt resp. als Output
produziert werden und allenfalls an weitern Punkten der ADM wieder zum Einsatz kommen. Auch Deliverables,
welche anderswo produziert wurden und in den Phasen der ADM ben¨otigt werden, werden eingeordnet. [Ope-G116]
listet s¨amtliche Deliverables, welche durch die Architekturarbeit mit der ADM produziert werden (siehe Tabelle 3.2
und Abbildung 3.8). Schliesslich werden diese Deliverables in den Deliverable Descriptions von TOGAF einzeln
genau beschrieben (vgl. [Ope-G116]).
Abbildung 3.8: Die Phasen der ADM
Tabelle 3.2: ADM Deliverables
Deliverable Output from... Input to...
Architecture Building Blocks F, H A, B, C, D, E
Architecture Contract ­ ­
Architecture Definition Document B, C, D, E, F C, D, E, F, G, H
Architecture Principles Preliminary, A, B, C, D Preliminary, , B, C, D, E, F, G, H
Architecture Repository Preliminary Preliminary, A, B, C, D, E, F, G, H,
Requirements Management
Architecture Requirements B, C, D, E, F, Requirements
Management
C, D, Requirements Management
Architecture Roadmap B, C, D, E, F B, C, D, E, F
Architecture Vision A, E B, C, D, E, F, G, H, Requirements Management
Business Principles, Business Goals, and
Business Drivers
Preliminary, A, B A, B
Capability Assessment A, E B, C, D, E, F
Change Request F, G, H ­
Communications Plan A B, C, D, E, F
Compliance Assessment G H
Implementation and Migration Plan E, F F
Implementation Governance Model F G, H
Organizational Model for Enterprise Preliminary Preliminary, A, B, C, D, E, F, G, H,
Requirements Management
Request for Architecture Work Preliminary, F, H A, G
Requirements Impact Assessment Requirements Management Requirements Management
Solution Building Blocks G A, B, C, D, E, F, G
Statement of Architecture Work A, B, C, D, E, F, G, H B, C, D, E, F, G, H, Requirements Management
Tailored Architecture Framework Preliminary, A Preliminary, A, B, C, D, E, F, G, H,
Requirements Management
TOGAF Architecture Content Framework, 12. April 2015 10
3.4 Building Blocks
Ein Building Block (dt. Baustein) stellt gem¨ass [Jos+10, S. 126] eine Komponente einer Gesch¨afts-, IT- oder Ar-
chitekturf¨ahigkeit (vgl. Abschnitt 2.2.2). Eine solche Komponente kann sowohl Architekuren (Architecture Building
Block (ABB)) als auch L¨osungen (Solution Building Block (SBB)) zugeordnet werden, falls es sich zu einem sp¨a-
teren Zeitpunkt z.B. um Projekte aus einer Capability handelt (vgl. [Jos+10, S. 135 ff.]). Systeme werden gem¨ass
[Jos+10, S. 135] aus einer Sammlung von Building Blocks erstellt. Die Bausteine ihrerseits m¨ussen Schnittstellen
aufweisen, damit sie mit anderen Bausteinen interagieren k¨onnen. Die Bausteine entstehen in der Architekturarbeit
der ADM-Phasen (siehe Abbildung 3.9).
Abbildung 3.9: Phasen resp. Schritte der ADM, die Building Blocks generieren
TOGAF Architecture Content Framework, 12. April 2015 11
4 Schlussfolgerungen und Ausblick
TOGAF ber¨ucksichtigt das Management der Organisation, fokussiert aber vorallem auf die drei Ebenen Integration,
Software und IT-Infrastruktur. Nicht geeignet ist das Rahmenwerk f¨ur das Management der Unternehmensstrategie.
Das Rahmenwerk erlaubt ein Capability-Based Planning und involviert die Stakeholder. Dabei wird TOGAF erst
mit dem Architecture Content Framework zu einem eigenst¨andigen EAF. Das Content Metamodel strukturiert die
Ergebnisse der Architekturarbeit und dient zur ¨Ubersicht. Das Architecture Content Framework bietet sich zudem
als Schnittstelle zu anderen, eventuell auch erg¨anzenden Rahmenwerken an.
Spannend w¨are ein Vergleich verschiedener EAF und ihre Entsprechungen untereinander, dargestellt als Matrix,
um M¨oglichkeiten und Grenzen aufzuzeigen. Auch eine ¨Ubersicht zu Schnittstellen k¨onnte f¨ur das IT-Management
von Nutzen sein. Wie [ARW08, S. 293] feststellt, lassen sich jedoch die g¨angigen Frameworks
”
Aufgrund ihrer
Komplexit¨at und den zum Teil unterschiedlichen Zielstellungen bei der Entwicklung [. . . ] nur bedingt miteinander
vergleichen”. Er erw¨ahnt in diesem Zusammenhang das Generalised Reference Architecture and Methodology (GE-
RAM) Framework, das genau dies zum Ziel habe, beurteilt die Resultate des Frameworks jedoch als
”
weitgehend
abstrakt”.
Mit dem Core Content Metamodel von TOGAF kann ein Mindestsatz an Architekturinhalten verwaltet werden.
Auch zu einem sp¨ateren Zeitpunkt kann die Architektur mit gew¨unschten Extensions noch verfeinert werden. So
l¨asst sich eine EA mit vern¨unftigem Aufwand umsetzen.
TOGAF Architecture Content Framework, 12. April 2015 12
TOGAF Architecture Content Framework, 12. April 2015 13
Abk¨urzungen
ABB Architecture Building Block
ADM Architecture Development Method
BI Business Intelligence
CIO Chief Information Officer
CRM Customer Relationship Management
DoDAF Department of Defense Architecture Framework
EA Enterprise Architecture
EAF Enterprise Architecture Framework
EAM Enterprise Architecture Management
ECM Enterprise Content Management
FEAF Federal Enterprise Architecture Framework
GERAM Generalised Reference Architecture and Methodology
IEEE Institute of Electrical and Electronic Engineers
III Integrated Information Infrastructure
III-RM Integrated Information Infrastructure Reference Model
IKT Informations- und Kommunikationstechnik
ISB Informatiksteuerungsorgan des Bundes
IT Informationstechnologie
RM Reference Model
SBB Solution Building Block
SOA Service Oriented Architecture
TOGAF The Open Group Architecture Framework
TOGAF Architecture Content Framework, 12. April 2015 14
Glossar
Architecture Capability Framework Das Architecture Capability Framework als Teil von TOGAF zeigt auf, wel-
che F¨ahigkeiten eine Organisation haben sollte, um im Sinne von TOGAF ihre Architektur entwickeln zu
k¨onnen.
Architecture Content Framework Mit dem Architecture Content Framework (dt. Rahmenwerk f¨ur Architektu-
rinhalte) als Teil von TOGAF werden die Erzeugnisse aus der Architekturarbeit gesammelt und ¨ubersichtlich
verwaltet. Dazu werden die Erzeugnisse klassifiziert und in einem Metamodell eingeordnet.
Architecture Development Method Die Architecture Development Method (ADM, dt. Architekturentwicklungs-
methode) ist das zentrale Element von TOGAF zur Entwicklung von Architekturen.
Enterprise Architecture Framework Ein Enterprise Architecture Framework (EAF, dt. Unternehmensarchitek-
turrahmenwerk) ist ein Mittel f¨ur das IT-Management zur Planung, Realisierung und Weiterf¨uhrung von
Unternehmensarchitekturen in der Informationstechnologie.
Enterprise Architecture Tool Ein Enterprise Architecture Tool (dt. Unternehmensarchitekturwerkzeug) ist ein
Werkzeug zur Unterst¨utzung in der Architekturarbeit, meist in Form einer Software-Applikation. Damit lassen
sich Komponenten der Unternehmensarchitektur wie z.B. Modelle und Prozesse erstellen resp. verwalten und
Projekte weiterentwickeln.
Stakeholder Person, f¨ur die es aufgrund ihrer Interessenlage von Belang ist, wie ein bestimmtes Unternehmen sich
verh¨alt (z.B. Aktion¨ar, Mitarbeiter, Kunde, Lieferant, Abteilungsleiter, Productmanager).
TOGAF Architecture Content Framework, 12. April 2015 15
Literaturverzeichnis
[ARW08] Stephan Aier, Christian Riege und Robert Winter.
”
Unternehmensarchitektur – Literatur¨uberblick und
Stand der Praxis“. In: Wirtschaftsinformatik 50 (2008), Nr. 4. 2008, S. 292–304. DOI: 10.1365/
s11576-008-0062-9. URL: http://dx.doi.org/10.1365/s11576-008-0062-9 (besucht am
26. 02. 2015).
[ELCA14a] ELCA.
”
Business Consulting: Macht IT noch wertvoller f¨ur Ihr Business“. In: Elca Update No. 8. Nov.
2014. URL: https://www.elca.ch/de/elcaupdate8 (besucht am 19. 02. 2015).
[ELCA14b] ELCA.
”
Business Consulting: Unternehmensarchitektur“. In: Flyer ELCA. Nov. 2014. URL: https:
//www.elca.ch/sites/default/files/elc_enterprise_architecture_de_web_0.pdf
(besucht am 19. 02. 2015).
[ISB-P030] ISB. P030 – The Open Group Architecture Framework (TOGAF) als Unternehmensarchitektur Me-
thode f¨ur die Bundesverwaltung. ISB P030. Version 1.01. Informatiksteuerungsorgan des Bundes ISB,
Aug. 2011. URL: http://www.isb.admin.ch/themen/standards/alle/03264/ (besucht am
02. 03. 2015).
[Jos+10] Andrew Josey u. a. TOGAF Version 9 – Ein Pocket Guide. Zaltbommel NL: Van Haren Publishing,
2010. Kap. 5: Architecture Content Framework, S. 125–138. ISBN: 978-9-08753-581-0.
[Kel12] Wolfgang Keller. IT-Unternehmensarchitektur – Von der Gesch¨aftsstrategie zur optimalen IT-Unter-
st¨utzung. 2. Aufl. Heidelberg: dpunkt, 2012. ISBN: 978-3-89864-768-7.
[Kur+14] Karl Kurbel u. a. Enzyklop¨adie der Wirtschaftsinformatik – Online-Lexikon. 8. Aufl. M¨unchen: Olden-
bourg, 2014. URL: http://www.enzyklopaedie-der-wirtschaftsinformatik.de/ (besucht
am 03. 03. 2015).
[Mat11a] Dirk Matthes. Enterprise Architecture Frameworks Kompendium – ¨Uber 50 Rahmenwerke f¨ur das
IT-Management. Berlin Heidelberg: Springer, 2011. ISBN: 978-3-642-12955-1. DOI: 10.1007/978-
3-642-12955-1. URL: http://link.springer.com/book/10.1007%2F978-3-642-12955-1
(besucht am 19. 03. 2015).
[Mat11b] Dirk Matthes.
”
Matthes Framework Map - frameworks according to their nationality and inten-
tion“. In: Enterprise Architecture Frameworks Kompendium – ¨Uber 50 Rahmenwerke f¨ur das IT-
Management. Springer, 2011. ISBN: 3-64212-954-4. URL: http://www.eaf-book.de/Matthes%
20FrameworkMap.pdf (besucht am 26. 02. 2015).
[Ope-G116] The Open Group. TOGAF Version 9.1. Document Number: G116. 2010. Kap. IV: Architecture Con-
tent Framework. ISBN: 978-9-08753-679-4. URL: http://pubs.opengroup.org/architecture/
togaf9-doc/arch/ (besucht am 26. 02. 2015).
[RV07] Eric Rozemeijer und Jan Van Bon. Frameworks for IT Management – a Pocket Guide. Zaltbommel
NL: Van Haren Publishing, 2007. ISBN: 978-90-8753-087-7.
[Wei10] Danny Weinberger.
”
. . . und am Anfang steht die Gesch¨aftsanforderung, oder?“ In: objektSPEKTRUM
EAM/2010 (2010). URL: http://www.sigs-datacom.de/fachzeitschriften/objektspektrum/
archiv / artikelansicht . html ? tx _ mwjournals _ pi1 % 5BshowUid % 5D = 6582 (besucht am
26. 02. 2015).
[Win09] Robert Winter.
”
One size fits all? – Unternehmensarchitekturmanagement im Spannungsfeld von
Standardisierung und (unternehmens-)individueller Nutzenmaximierung“. In: Das 13. Berner Archi-
tekten Forum im R¨uckblick. 2009. URL: http://www.berner-architekten-treffen.ch/archiv/
13/treffen_no13.php (besucht am 04. 04. 2015).
TOGAF Architecture Content Framework, 12. April 2015 16
Bildnachweis
Titelseite: Enterprise Architecture (EA) Development.
Website der Firma Systems Plus, Inc., Rockville Maryland.
Rubrik Services & Solutions: Consulting Services
Bearbeitet mit GIMP. Eine Online-Version der Originaldatei ist verf¨ugbar unter
http://www.sysplus.com/images/img_enterprise.jpg (Zugriff: 19. Februar 2015).
Abbildung 2.1: Abb. 2: Dom¨anen der Architektur. In: [Wei10, S. 2].
Abbildung 2.2: Figure 1a Cross-references for quality management and Business Process Management frameworks.
In: [RV07, S. 24].
Abbildung 2.3: Abb. 5: Capability Increments and Dimensions – TOGAF 9. In: [Wei10, S. 4].
Abbildung 3.1: Figure 33-1: Relationships between Deliverables, Artifacts, and Building Blocks. In: [Ope-G116].
Abbildung 3.2: Figure 33-2: Example - Architecture Definition Document. In: [Ope-G116].
Abbildung 3.3: Figure 34-4: Content Framework by ADM Phases. In: [Ope-G116].
Abbildung 3.4: Figure 35-1: Basic Architectural Concepts. In: [Ope-G116].
Abbildung 3.5: Figure 34-2: Core Entities and their Relationships. In: [Ope-G116].
Abbildung 3.6: Beispiel f¨ur einen
”
ausgewogenen”UA-Ansatz. In: [Win09, S. 22].
Abbildung 3.7: Figure 35-3: Artifacts Associated with the Core Content Metamodel and Extensions.
In: [Ope-G116].
Abbildung 3.8: Figure 5-1: Architecture Development Cycle. In: [Ope-G116].
Abbildung 3.9: Figure 37-1: Key ADM Phases/Steps at which Building Blocks are Evolved/Specified.
In: [Ope-G116].
TOGAF Architecture Content Framework, 12. April 2015 17
Abbildungsverzeichnis
2.1 Dom¨anen der Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Klassifizierungsraster f¨ur EAM-Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Beispiel-Inkrement einer Capability mit involvierten Dimensionen . . . . . . . . . . . . . . . . . . . 5
3.1 Deliverables mit Artifacts und Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Deliverable am Beispiel eines Architecture Definition Document . . . . . . . . . . . . . . . . . . . 6
3.3 Content Metamodel nach ADM-Phasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Grundkonzepte der Architekturbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5 Die Konzepte und ihre Beziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6 Beispiele von Sichten und Perspektiven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.7 Architecture Artifacts des Core Content Metamodel sowie der Extensions . . . . . . . . . . . . . . 9
3.8 Die Phasen der ADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.9 Phasen resp. Schritte der ADM, die Building Blocks generieren . . . . . . . . . . . . . . . . . . . . 11
Tabellenverzeichnis
2.1 Ebenen der Unternehmensarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Konzepte in Verbindung mit Sichten auf die Architektur . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 ADM Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
TOGAF Architecture Content Framework, 12. April 2015 18
Stichwortverzeichnis
Architecture Content Framework, 1, 5–7, 12
Artifact, 5–7, 9
Building Block, 5, 6, 11
Content Metamodel, 5–7, 10, 12
Deliverable, 5, 6, 10
Architecture Development Method, 5–7, 10, 11
Building Block, 5, 6, 11
Architecture Building Block, 11
Solution Building Block, 11
Capability-Based Planning, 5, 12
Architekturf¨ahigkeit, 6, 11
Capability, 5
Gesch¨aftsf¨ahigkeit, 5, 6, 11
IT-F¨ahigkeit, 6, 11
Content Metamodel, 5–7, 10, 12
Core Content Metamodel, 7, 9, 12
Core Entity, 7
Extension, 7, 9, 12
Full Content Metamodel, 7
Enterprise Architecture, 2–5, 7, 12
Enterprise Architecture Framework, 1, 4–6, 12
ArchiMate, 6
DoDAF, 4, 5
FEAF, 5
GERAM, 12
TOGAF, 1, 2, 4–6, 10, 12
Zachman, 4, 6
Enterprise Architecture Management, 1–4
Service Oriented Architecture, 5
Stakeholder, 12
TOGAF Architecture Content Framework, 12. April 2015 19
Selbst¨andigkeitserkl¨arung
Wir best¨atigen, dass wir die vorliegende Arbeit selbstst¨andig und ohne Benutzung anderer als der im Literaturver-
zeichnis angegebenen Quellen und Hilfsmittel angefertigt haben. S¨amtliche Textstellen, die nicht von uns stammen,
sind als Zitate gekennzeichnet und mit dem genauen Hinweis auf ihre Herkunft versehen.
Ort, Datum: Biel/Bienne, 12. April 2015
Vorname, Name: Roland Bruggmann
Unterschrift: ......................................
Vorname, Name: Tobias Millauer
Unterschrift: ......................................
TOGAF Architecture Content Framework, 12. April 2015 20

Weitere ähnliche Inhalte

Was ist angesagt?

Togaf 9 template transition architecture
Togaf 9 template   transition architectureTogaf 9 template   transition architecture
Togaf 9 template transition architecture
Sandeep Sharma IIMK Smart City,IoT,Bigdata,Cloud,BI,DW
 
Unternehmenssteuerung mit dem SAP Sustainability Control Tower – Überblick u...
 Unternehmenssteuerung mit dem SAP Sustainability Control Tower – Überblick u... Unternehmenssteuerung mit dem SAP Sustainability Control Tower – Überblick u...
Unternehmenssteuerung mit dem SAP Sustainability Control Tower – Überblick u...
IBsolution GmbH
 
Enterprise Architecture - TOGAF Overview
Enterprise Architecture - TOGAF OverviewEnterprise Architecture - TOGAF Overview
Enterprise Architecture - TOGAF Overview
Mohamed Sami El-Tahawy
 
Bridging business analysis and business architecture - The Open Group webinar
Bridging business analysis and business architecture - The Open Group webinarBridging business analysis and business architecture - The Open Group webinar
Bridging business analysis and business architecture - The Open Group webinar
Craig Martin
 
Integrated Project and Solution Delivery And Business Engagement Model
Integrated Project and Solution Delivery And Business Engagement ModelIntegrated Project and Solution Delivery And Business Engagement Model
Integrated Project and Solution Delivery And Business Engagement Model
Alan McSweeney
 
Digital Transformation And Solution Architecture
Digital Transformation And Solution ArchitectureDigital Transformation And Solution Architecture
Digital Transformation And Solution Architecture
Alan McSweeney
 
Solution Architecture And User And Customer Experience
Solution Architecture And User And Customer ExperienceSolution Architecture And User And Customer Experience
Solution Architecture And User And Customer Experience
Alan McSweeney
 
Enterprise Architecture Management (EAM) I Best Practices I NuggetHub
Enterprise Architecture Management (EAM) I Best Practices I NuggetHubEnterprise Architecture Management (EAM) I Best Practices I NuggetHub
Enterprise Architecture Management (EAM) I Best Practices I NuggetHub
RichardNowack
 
GE Predix - The IIoT Platform
GE Predix - The IIoT PlatformGE Predix - The IIoT Platform
GE Predix - The IIoT Platform
Juan Pablo Genovese
 
Enterprise Architecture Approach Togaf 9
Enterprise Architecture Approach   Togaf 9Enterprise Architecture Approach   Togaf 9
Enterprise Architecture Approach Togaf 9
Prashant Patade
 
Togaf introduction and core concepts
Togaf introduction and core conceptsTogaf introduction and core concepts
Togaf introduction and core concepts
Paul Sullivan
 
Modeling the Insurance Enterprise
Modeling the Insurance EnterpriseModeling the Insurance Enterprise
Modeling the Insurance Enterprise
Iver Band
 
Industry 4.0
Industry 4.0Industry 4.0
Industry 4.0
Dr. N. Asokan
 
SAP S4HANA : Learn From Our Implementation Journey
SAP S4HANA : Learn From Our Implementation JourneySAP S4HANA : Learn From Our Implementation Journey
SAP S4HANA : Learn From Our Implementation Journey
Anup Lakra
 
EA Report.pdf
EA Report.pdfEA Report.pdf
EA Report.pdf
DrShekharTankhiwale
 
Enterprise Security Architecture
Enterprise Security ArchitectureEnterprise Security Architecture
Enterprise Security Architecture
Priyanka Aash
 
Solution Architecture
Solution ArchitectureSolution Architecture
Solution Architecture
FirmansyahIrma1
 
Cloud architecture with the ArchiMate Language
Cloud architecture with the ArchiMate LanguageCloud architecture with the ArchiMate Language
Cloud architecture with the ArchiMate Language
Iver Band
 
SAP Process Mining in Action: Hear from Two Customers
SAP Process Mining in Action: Hear from Two CustomersSAP Process Mining in Action: Hear from Two Customers
SAP Process Mining in Action: Hear from Two Customers
Celonis
 
Business Architecture Explained
Business Architecture ExplainedBusiness Architecture Explained
Business Architecture Explained
aaronwilliamson
 

Was ist angesagt? (20)

Togaf 9 template transition architecture
Togaf 9 template   transition architectureTogaf 9 template   transition architecture
Togaf 9 template transition architecture
 
Unternehmenssteuerung mit dem SAP Sustainability Control Tower – Überblick u...
 Unternehmenssteuerung mit dem SAP Sustainability Control Tower – Überblick u... Unternehmenssteuerung mit dem SAP Sustainability Control Tower – Überblick u...
Unternehmenssteuerung mit dem SAP Sustainability Control Tower – Überblick u...
 
Enterprise Architecture - TOGAF Overview
Enterprise Architecture - TOGAF OverviewEnterprise Architecture - TOGAF Overview
Enterprise Architecture - TOGAF Overview
 
Bridging business analysis and business architecture - The Open Group webinar
Bridging business analysis and business architecture - The Open Group webinarBridging business analysis and business architecture - The Open Group webinar
Bridging business analysis and business architecture - The Open Group webinar
 
Integrated Project and Solution Delivery And Business Engagement Model
Integrated Project and Solution Delivery And Business Engagement ModelIntegrated Project and Solution Delivery And Business Engagement Model
Integrated Project and Solution Delivery And Business Engagement Model
 
Digital Transformation And Solution Architecture
Digital Transformation And Solution ArchitectureDigital Transformation And Solution Architecture
Digital Transformation And Solution Architecture
 
Solution Architecture And User And Customer Experience
Solution Architecture And User And Customer ExperienceSolution Architecture And User And Customer Experience
Solution Architecture And User And Customer Experience
 
Enterprise Architecture Management (EAM) I Best Practices I NuggetHub
Enterprise Architecture Management (EAM) I Best Practices I NuggetHubEnterprise Architecture Management (EAM) I Best Practices I NuggetHub
Enterprise Architecture Management (EAM) I Best Practices I NuggetHub
 
GE Predix - The IIoT Platform
GE Predix - The IIoT PlatformGE Predix - The IIoT Platform
GE Predix - The IIoT Platform
 
Enterprise Architecture Approach Togaf 9
Enterprise Architecture Approach   Togaf 9Enterprise Architecture Approach   Togaf 9
Enterprise Architecture Approach Togaf 9
 
Togaf introduction and core concepts
Togaf introduction and core conceptsTogaf introduction and core concepts
Togaf introduction and core concepts
 
Modeling the Insurance Enterprise
Modeling the Insurance EnterpriseModeling the Insurance Enterprise
Modeling the Insurance Enterprise
 
Industry 4.0
Industry 4.0Industry 4.0
Industry 4.0
 
SAP S4HANA : Learn From Our Implementation Journey
SAP S4HANA : Learn From Our Implementation JourneySAP S4HANA : Learn From Our Implementation Journey
SAP S4HANA : Learn From Our Implementation Journey
 
EA Report.pdf
EA Report.pdfEA Report.pdf
EA Report.pdf
 
Enterprise Security Architecture
Enterprise Security ArchitectureEnterprise Security Architecture
Enterprise Security Architecture
 
Solution Architecture
Solution ArchitectureSolution Architecture
Solution Architecture
 
Cloud architecture with the ArchiMate Language
Cloud architecture with the ArchiMate LanguageCloud architecture with the ArchiMate Language
Cloud architecture with the ArchiMate Language
 
SAP Process Mining in Action: Hear from Two Customers
SAP Process Mining in Action: Hear from Two CustomersSAP Process Mining in Action: Hear from Two Customers
SAP Process Mining in Action: Hear from Two Customers
 
Business Architecture Explained
Business Architecture ExplainedBusiness Architecture Explained
Business Architecture Explained
 

Ähnlich wie TOGAF Architecture Content Framework

TOGAF Architecture Content Framework
TOGAF Architecture Content FrameworkTOGAF Architecture Content Framework
TOGAF Architecture Content Framework
Roland Bruggmann
 
Architekturbewertung
ArchitekturbewertungArchitekturbewertung
Architekturbewertung
Brockhaus Consulting GmbH
 
Das Intranet Konzept
Das Intranet KonzeptDas Intranet Konzept
Das Intranet Konzept
Volker Grünauer
 
Tisson & Company IT Management - Architektur
Tisson & Company IT Management - ArchitekturTisson & Company IT Management - Architektur
Tisson & Company IT Management - Architektur
Horst Tisson
 
Icom Intranet Workshops V2 Web
Icom Intranet Workshops V2 WebIcom Intranet Workshops V2 Web
Icom Intranet Workshops V2 Web
Jürgen Mirbach
 
Enterprise Architecture Management - Capabilities entwickeln
Enterprise Architecture Management - Capabilities entwickelnEnterprise Architecture Management - Capabilities entwickeln
Enterprise Architecture Management - Capabilities entwickeln
Jan Thielscher
 
Bachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20TscheschnerBachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20Tscheschner
tutorialsruby
 
Bachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20TscheschnerBachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20Tscheschner
tutorialsruby
 
Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...
Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...
Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...
servicEvolution
 
Industrie 4.0 Referenzmodell 2014
Industrie 4.0 Referenzmodell 2014Industrie 4.0 Referenzmodell 2014
Industrie 4.0 Referenzmodell 2014
Martin Gutberlet
 
B&IT-Broschüre: Training Projektmanagement (2 Tage)
B&IT-Broschüre: Training Projektmanagement (2 Tage)B&IT-Broschüre: Training Projektmanagement (2 Tage)
B&IT-Broschüre: Training Projektmanagement (2 Tage)
Wolfgang Hornung
 
constag ag Firmenpräsentation
constag ag Firmenpräsentationconstag ag Firmenpräsentation
constag ag Firmenpräsentation
Erich Stähli
 
Das "LerNetz Lern-Haus": Austrian eLearning Conference 2013 (AeLC) / Dr. Dani...
Das "LerNetz Lern-Haus": Austrian eLearning Conference 2013 (AeLC) / Dr. Dani...Das "LerNetz Lern-Haus": Austrian eLearning Conference 2013 (AeLC) / Dr. Dani...
Das "LerNetz Lern-Haus": Austrian eLearning Conference 2013 (AeLC) / Dr. Dani...
Dr. Daniel Stoller-Schai
 
Microsoft Project meets PMBOK - den internationalen Projektmanagement-Standard
Microsoft Project meets PMBOK - den internationalen Projektmanagement-StandardMicrosoft Project meets PMBOK - den internationalen Projektmanagement-Standard
Microsoft Project meets PMBOK - den internationalen Projektmanagement-Standard
Digicomp Academy AG
 
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Peter Affolter
 
Software trends veranstaltungsprogramm_neu
Software trends veranstaltungsprogramm_neuSoftware trends veranstaltungsprogramm_neu
Software trends veranstaltungsprogramm_neu
CON.ECT Eventmanagement
 
[DE] Enterprise Content Management | Dr. Ulrich Kampffmeyer | Hamburg 2006
[DE] Enterprise Content Management | Dr. Ulrich Kampffmeyer | Hamburg 2006[DE] Enterprise Content Management | Dr. Ulrich Kampffmeyer | Hamburg 2006
[DE] Enterprise Content Management | Dr. Ulrich Kampffmeyer | Hamburg 2006
PROJECT CONSULT Unternehmensberatung Dr. Ulrich Kampffmeyer GmbH
 
PLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
PLM Open Hours - Dokumentation von Projekten mit ImplementierungsanteilPLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
PLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
Intelliact AG
 
DNUG 36 2012_Konferenzbroschuere
DNUG 36 2012_KonferenzbroschuereDNUG 36 2012_Konferenzbroschuere
DNUG 36 2012_Konferenzbroschuere
Friedel Jonker
 
Cloud Computing - Technische Grundlagen, Chancen und Probleme des Trends
Cloud Computing - Technische Grundlagen, Chancen und Probleme des TrendsCloud Computing - Technische Grundlagen, Chancen und Probleme des Trends
Cloud Computing - Technische Grundlagen, Chancen und Probleme des Trends
Michael Xander
 

Ähnlich wie TOGAF Architecture Content Framework (20)

TOGAF Architecture Content Framework
TOGAF Architecture Content FrameworkTOGAF Architecture Content Framework
TOGAF Architecture Content Framework
 
Architekturbewertung
ArchitekturbewertungArchitekturbewertung
Architekturbewertung
 
Das Intranet Konzept
Das Intranet KonzeptDas Intranet Konzept
Das Intranet Konzept
 
Tisson & Company IT Management - Architektur
Tisson & Company IT Management - ArchitekturTisson & Company IT Management - Architektur
Tisson & Company IT Management - Architektur
 
Icom Intranet Workshops V2 Web
Icom Intranet Workshops V2 WebIcom Intranet Workshops V2 Web
Icom Intranet Workshops V2 Web
 
Enterprise Architecture Management - Capabilities entwickeln
Enterprise Architecture Management - Capabilities entwickelnEnterprise Architecture Management - Capabilities entwickeln
Enterprise Architecture Management - Capabilities entwickeln
 
Bachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20TscheschnerBachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20Tscheschner
 
Bachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20TscheschnerBachelor%20thesis%20Willi%20Tscheschner
Bachelor%20thesis%20Willi%20Tscheschner
 
Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...
Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...
Arbeitsbericht Nr. 118: 'IT-Service Management - Ein neues Paradigma für das ...
 
Industrie 4.0 Referenzmodell 2014
Industrie 4.0 Referenzmodell 2014Industrie 4.0 Referenzmodell 2014
Industrie 4.0 Referenzmodell 2014
 
B&IT-Broschüre: Training Projektmanagement (2 Tage)
B&IT-Broschüre: Training Projektmanagement (2 Tage)B&IT-Broschüre: Training Projektmanagement (2 Tage)
B&IT-Broschüre: Training Projektmanagement (2 Tage)
 
constag ag Firmenpräsentation
constag ag Firmenpräsentationconstag ag Firmenpräsentation
constag ag Firmenpräsentation
 
Das "LerNetz Lern-Haus": Austrian eLearning Conference 2013 (AeLC) / Dr. Dani...
Das "LerNetz Lern-Haus": Austrian eLearning Conference 2013 (AeLC) / Dr. Dani...Das "LerNetz Lern-Haus": Austrian eLearning Conference 2013 (AeLC) / Dr. Dani...
Das "LerNetz Lern-Haus": Austrian eLearning Conference 2013 (AeLC) / Dr. Dani...
 
Microsoft Project meets PMBOK - den internationalen Projektmanagement-Standard
Microsoft Project meets PMBOK - den internationalen Projektmanagement-StandardMicrosoft Project meets PMBOK - den internationalen Projektmanagement-Standard
Microsoft Project meets PMBOK - den internationalen Projektmanagement-Standard
 
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
 
Software trends veranstaltungsprogramm_neu
Software trends veranstaltungsprogramm_neuSoftware trends veranstaltungsprogramm_neu
Software trends veranstaltungsprogramm_neu
 
[DE] Enterprise Content Management | Dr. Ulrich Kampffmeyer | Hamburg 2006
[DE] Enterprise Content Management | Dr. Ulrich Kampffmeyer | Hamburg 2006[DE] Enterprise Content Management | Dr. Ulrich Kampffmeyer | Hamburg 2006
[DE] Enterprise Content Management | Dr. Ulrich Kampffmeyer | Hamburg 2006
 
PLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
PLM Open Hours - Dokumentation von Projekten mit ImplementierungsanteilPLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
PLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
 
DNUG 36 2012_Konferenzbroschuere
DNUG 36 2012_KonferenzbroschuereDNUG 36 2012_Konferenzbroschuere
DNUG 36 2012_Konferenzbroschuere
 
Cloud Computing - Technische Grundlagen, Chancen und Probleme des Trends
Cloud Computing - Technische Grundlagen, Chancen und Probleme des TrendsCloud Computing - Technische Grundlagen, Chancen und Probleme des Trends
Cloud Computing - Technische Grundlagen, Chancen und Probleme des Trends
 

Mehr von Roland Bruggmann

Fingerprint Analysis – Preprocessing and Feature Extraction
Fingerprint Analysis – Preprocessing and Feature ExtractionFingerprint Analysis – Preprocessing and Feature Extraction
Fingerprint Analysis – Preprocessing and Feature Extraction
Roland Bruggmann
 
Unreal Engine IoT Project: Heartbeat
Unreal Engine IoT Project: HeartbeatUnreal Engine IoT Project: Heartbeat
Unreal Engine IoT Project: Heartbeat
Roland Bruggmann
 
3D Content for Dream-like VR
3D Content for Dream-like VR3D Content for Dream-like VR
3D Content for Dream-like VR
Roland Bruggmann
 
OSG Volume Rendering - Presentation
OSG Volume Rendering - PresentationOSG Volume Rendering - Presentation
OSG Volume Rendering - Presentation
Roland Bruggmann
 
Swiss National Supercomputing Centre CSCS
Swiss National Supercomputing Centre CSCSSwiss National Supercomputing Centre CSCS
Swiss National Supercomputing Centre CSCS
Roland Bruggmann
 
Sprechen als Handeln
Sprechen als HandelnSprechen als Handeln
Sprechen als Handeln
Roland Bruggmann
 
Numerische Methoden: Approximation und Integration
Numerische Methoden: Approximation und IntegrationNumerische Methoden: Approximation und Integration
Numerische Methoden: Approximation und Integration
Roland Bruggmann
 
Multicore and GPU Programming
Multicore and GPU ProgrammingMulticore and GPU Programming
Multicore and GPU Programming
Roland Bruggmann
 
Unity® Volume Rendering - Abstract
Unity® Volume Rendering - AbstractUnity® Volume Rendering - Abstract
Unity® Volume Rendering - Abstract
Roland Bruggmann
 
Unity® Volume Rendering - Benutzerhandbuch
Unity® Volume Rendering - BenutzerhandbuchUnity® Volume Rendering - Benutzerhandbuch
Unity® Volume Rendering - Benutzerhandbuch
Roland Bruggmann
 
Serious Game "Virtual Surgery" - Game Design Document
Serious Game "Virtual Surgery" - Game Design DocumentSerious Game "Virtual Surgery" - Game Design Document
Serious Game "Virtual Surgery" - Game Design Document
Roland Bruggmann
 
OSG Volume Rendering
OSG Volume RenderingOSG Volume Rendering
OSG Volume Rendering
Roland Bruggmann
 
Digitale Kamera und Modulationstransferfunktion
Digitale Kamera und ModulationstransferfunktionDigitale Kamera und Modulationstransferfunktion
Digitale Kamera und Modulationstransferfunktion
Roland Bruggmann
 
Quadriken im Raum
Quadriken im RaumQuadriken im Raum
Quadriken im Raum
Roland Bruggmann
 
Visualisierung von Algorithmen und Datenstrukturen
Visualisierung von Algorithmen und DatenstrukturenVisualisierung von Algorithmen und Datenstrukturen
Visualisierung von Algorithmen und Datenstrukturen
Roland Bruggmann
 
User-centered Design für Telemedizin-App
User-centered Design für Telemedizin-AppUser-centered Design für Telemedizin-App
User-centered Design für Telemedizin-App
Roland Bruggmann
 
Ondes stationnaires
Ondes stationnairesOndes stationnaires
Ondes stationnaires
Roland Bruggmann
 
Passwords Safe
Passwords SafePasswords Safe
Passwords Safe
Roland Bruggmann
 
Stehende Wellen
Stehende WellenStehende Wellen
Stehende Wellen
Roland Bruggmann
 
Cultural Dimensions
Cultural DimensionsCultural Dimensions
Cultural Dimensions
Roland Bruggmann
 

Mehr von Roland Bruggmann (20)

Fingerprint Analysis – Preprocessing and Feature Extraction
Fingerprint Analysis – Preprocessing and Feature ExtractionFingerprint Analysis – Preprocessing and Feature Extraction
Fingerprint Analysis – Preprocessing and Feature Extraction
 
Unreal Engine IoT Project: Heartbeat
Unreal Engine IoT Project: HeartbeatUnreal Engine IoT Project: Heartbeat
Unreal Engine IoT Project: Heartbeat
 
3D Content for Dream-like VR
3D Content for Dream-like VR3D Content for Dream-like VR
3D Content for Dream-like VR
 
OSG Volume Rendering - Presentation
OSG Volume Rendering - PresentationOSG Volume Rendering - Presentation
OSG Volume Rendering - Presentation
 
Swiss National Supercomputing Centre CSCS
Swiss National Supercomputing Centre CSCSSwiss National Supercomputing Centre CSCS
Swiss National Supercomputing Centre CSCS
 
Sprechen als Handeln
Sprechen als HandelnSprechen als Handeln
Sprechen als Handeln
 
Numerische Methoden: Approximation und Integration
Numerische Methoden: Approximation und IntegrationNumerische Methoden: Approximation und Integration
Numerische Methoden: Approximation und Integration
 
Multicore and GPU Programming
Multicore and GPU ProgrammingMulticore and GPU Programming
Multicore and GPU Programming
 
Unity® Volume Rendering - Abstract
Unity® Volume Rendering - AbstractUnity® Volume Rendering - Abstract
Unity® Volume Rendering - Abstract
 
Unity® Volume Rendering - Benutzerhandbuch
Unity® Volume Rendering - BenutzerhandbuchUnity® Volume Rendering - Benutzerhandbuch
Unity® Volume Rendering - Benutzerhandbuch
 
Serious Game "Virtual Surgery" - Game Design Document
Serious Game "Virtual Surgery" - Game Design DocumentSerious Game "Virtual Surgery" - Game Design Document
Serious Game "Virtual Surgery" - Game Design Document
 
OSG Volume Rendering
OSG Volume RenderingOSG Volume Rendering
OSG Volume Rendering
 
Digitale Kamera und Modulationstransferfunktion
Digitale Kamera und ModulationstransferfunktionDigitale Kamera und Modulationstransferfunktion
Digitale Kamera und Modulationstransferfunktion
 
Quadriken im Raum
Quadriken im RaumQuadriken im Raum
Quadriken im Raum
 
Visualisierung von Algorithmen und Datenstrukturen
Visualisierung von Algorithmen und DatenstrukturenVisualisierung von Algorithmen und Datenstrukturen
Visualisierung von Algorithmen und Datenstrukturen
 
User-centered Design für Telemedizin-App
User-centered Design für Telemedizin-AppUser-centered Design für Telemedizin-App
User-centered Design für Telemedizin-App
 
Ondes stationnaires
Ondes stationnairesOndes stationnaires
Ondes stationnaires
 
Passwords Safe
Passwords SafePasswords Safe
Passwords Safe
 
Stehende Wellen
Stehende WellenStehende Wellen
Stehende Wellen
 
Cultural Dimensions
Cultural DimensionsCultural Dimensions
Cultural Dimensions
 

TOGAF Architecture Content Framework

  • 1. Unternehmensarchitektur vereint Gesch¨aftsprozesse und IT-Architektur. Um das Management in der Planung, Umsetzung und Weiterf¨uhrung von Unternehmensarchitekturen zu unterst¨utzen, gibt es verschiedene Enterprise Architecture Frameworks. Die Open Group bietet mit TOGAF ein solches Framework – es findet weltweit Verwendung. Mit der vorliegenden Semesterarbeit soll der vierte Teil von TOGAF Version 9 erl¨autert werden: Das Architecture Content Framework (Rahmenwerk f¨ur Architekturinhalte). Es strukturiert die Ergebnisse aus der Architekturarbeit, dient zur ¨Ubersicht und eignet sich als Schnittstelle zu anderen Frameworks. Studiengang: Informatik, Modul BTI7311 Informatik Seminar Autor: Roland Bruggmann, roland.bruggmann@students.bfh.ch Co-Autor Tobias Millauer, tobias.millauer@students.bfh.ch Dozent: Prof. Dr. Urs Sauter, urs.sauter@bfh.ch Datum: 12. April 2015 Berner Fachhochschule | Haute ´ecole sp´ecialis´ee bernoise | Bern University of Applied Sciences TOGAF Architecture Content Framework IT-Management und Unternehmensarchitektur mit TOGAF 9 Teil IV Semesterarbeit
  • 2. Inhaltsverzeichnis 1 Einleitung 1 2 Grundlagen 2 2.1 Enterprise Architecture Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1.1 Ebenen der Unternehmensarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.2 Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.3 Zust¨andigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Enterprise Architecture Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1 Framework der Open Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.2 Capability-Based Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.3 TOGAF in der Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3 Architecture Content Framework 6 3.1 Content Metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Architecture Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4 Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4 Schlussfolgerungen und Ausblick 12 Abk¨urzungen 13 Glossar 15 Literaturverzeichnis 16 Bildnachweis 17 Abbildungsverzeichnis 18 Tabellenverzeichnis 18 Stichwortverzeichnis 19 TOGAF Architecture Content Framework, 12. April 2015 i
  • 3. 1 Einleitung Das Rahmenwerk f¨ur Unternehmensarchitektur der Open Group – The Open Group Architecture Framework (TO- GAF) – wird als wichtiger offener Standard f¨ur die Architekturentwicklung anerkannt. Die Komplexit¨at von TOGAF stellt die Anwender vor grosse Herausforderungen. Im Informatik-Seminar sollen deshalb verschiedene Gesichtspunk- te von TOGAF beleuchtet werden. Der vierte Teil von TOGAF, das Architecture Content Framework gibt eine ¨Ubersicht ¨uber m¨ogliche Arbeitsergeb- nisse der Architekturarbeit und ein Metamodell, um diese einzuordnen. Mit der vorliegenden Semesterarbeit soll dieses Framework eingehend erl¨autert werden. Dabei sollen auch Kosten und Nutzen der Architekturarbeit und Grenzen des Frameworks zur Sprache kommen. Der vorliegende Bericht ist in vier Kapitel geteilt: Auf diese Einleitung folgt der eine Erl¨auterung der Grundlagen zu den Themen Enterprise Architecture Management, Enterprise Architecture Framework und zu TOGAF im all- gemeinen (Kapitel 2). Im Hauptteil wird das Architecture Content Framework von TOGAF im speziellen behandelt (Kapitel 3) und in den Schlussfolgerungen werden die wichtigsten Ergebnisse rekapituliert (Kapitel 4). TOGAF Architecture Content Framework, 12. April 2015 1
  • 4. 2 Grundlagen Eine Recherche zum Schlagwort ’Enterprise Architecture (EA)’ (dt. Unternehmensarchitektur) resultierte in folgen- den Publikationen: ˆ S. Aier, C. Riege und R. Winter (2008): Unternehmensarchitektur – Literatur¨uberblick und Stand der Praxis. ˆ D. Matthes (2011a): Enterprise Architecture Frameworks Kompendium – ¨Uber 50 Rahmenwerke f¨ur das IT-Management. ˆ D. Matthes (2011b): Matthes Framework Map - frameworks according to their nationality and intention. Aier, Riege und Winter [ARW08] am Institut f¨ur Wirtschaftsinformatik der Universit¨at St.Gallen gibt einen aus- f¨uhrlichen Literatur¨uberblick. Matthes [Mat11a] listet und erl¨autert die wichtigsten 50 Frameworks. Diese zeigt er auch auf einer informativen ¨Ubersichtskarte ([Mat11b]). Zudem fanden sich die folgenden relevanten Publikationen in den Suchresultaten zum Schlagwort ’TOGAF’: ˆ D. Weinberger (2010): . . . und am Anfang steht die Gesch¨aftsanforderung, oder? ˆ A. Josey u.a. (2010): TOGAF Version 9 – Ein Pocket Guide. ˆ The Open Group (2010): TOGAF Version 9.1. Document Number: G116. ˆ W. Keller (2012): IT-Unternehmensarchitektur – Von der Gesch¨aftsstrategie zur optimalen IT-Unterst¨utzung. Der informative Fachartikel von Weinberger [Wei10] wird zum Erarbeiten der Grundlagen verwendet. Nebst dem online publizierten Dokument Nummer G116 ” TOGAF Version 9.1”auf dem Website der Open Group ([Ope-G116]) dient schliesslich der Pocket Guide zu TOGAF ([Jos+10]) als Hauptquelle f¨ur diesen Bericht. F¨ur eine austarierte Beurteilung dient Kellers Publikation ([Kel12]). Mit dem Newsletter Elca Update No. 8 ([ELCA14a]) und einem Flyer von ELCA ([ELCA14b]) kommt eine Consul- ting Firma zur Sprache, anhand des Standards P030 des Informatiksteuerungsorganes des Bundes ISB ([ISB-P030]) wird ein Business Case aus dem Bereich der Verwaltung in der Schweiz erw¨ahnt. F¨ur die Erl¨auterung einzelner Begriffe wird die Enzyklop¨adie der Wirtschaftsinformatik konsultiert, ein Online- Lexikon der Universit¨at Oldenburg, herausgegeben von Kurbel u.a. ([Kur+14]). Es sei an dieser Stelle deklariert, dass die Begriffe aus TOGAF als Fachbegriffe betrachtet werden, d.h. allenfalls nur soweit wie in [Jos+10] eingedeutscht werden. 2.1 Enterprise Architecture Management Wie dem Newsletter [ELCA14a] zu entnehmen ist, kann Enterprise Architecture Management (EAM) generell als eine Schl¨usselkompetenz des Betriebsmanagement bezeichnet werden: Es vereint Gesch¨aftsprozesse und IT- Architektur. Gem¨ass Aier, Riege und Winter [ARW08, S. 292 f.] hat das Management der Unternehmensarchitektur in den letzten Jahren stark an Bedeutung gewonnen. Die Herausforderung bestehe darin, ” die Gestaltung von Gesch¨aftsfeldern und Produkten, deren Abbildung in Gesch¨aftsprozessen und Organisationsstrukturen bis hin zur Implementierung durch Anwendungssysteme und dem Betrieb der dazu notwendigen Infrastruktur durch eine [. . . ] Gesamtsicht des Unternehmens zu unterst¨utzen.“ Dies best¨atigt auch Xavier Ruvilly, Enterprise Architekt bei ELCA. Er beurteilt das Management der Unternehmensarchitektur als ” eine zentrale Disziplin, um verschiedene IT-Bereiche wie [Business Intelligence (BI)], [Customer Relationship Management (CRM)], [Enterprise Content Management (ECM)], Portale usw. zu einem umfassenden Ganzen zu kombinieren und um Trends wie Big Data, die Cloud, Digitalisierung und Mobile Computing f¨ur die Gesch¨aftst¨atigkeit zu nutzen“ (vgl. [ELCA14b, S. 2]). TOGAF Architecture Content Framework, 12. April 2015 2
  • 5. 2.1.1 Ebenen der Unternehmensarchitektur Weinberger [Wei10, S. 2] bezeichnet Unternehmensarchitektur als Beschreibung der Struktur von Komponenten und ihren Beziehungen ¨uber das gesamte Unternehmen. Die Dom¨anen der Unternehmensarchitektur gliedert er grob in Business Architecture und IT Architecture, letztere wiederum in Information Systems Architecture und Technology Architecture (siehe Abbildung 2.1). Die Br¨ucken und Beziehungen zwischen diesen Dom¨anen gelte es aufzubauen und zu managen. Die Architektur ist im Grunde die Be- schreibung und die Struktur von Kompo- nenten und ihren Beziehungen über die gesamte Organisation, sprich das gesamte Unternehmen. Somit geht es also um den Aufbau und um das Managen von „Brücken“ und ihren „Beziehungen“ im gesamten Unternehmen. EAM beschränkt sich also nicht nur auf IT, sondern umfasst mehrere Systeme und funktionale Gruppen im Unternehmen. Abbildung 2 verdeut- licht das sehr gut. Warum EAM? – Erfolgsfaktor Unternehmenskultur Eine Frage, die oft gestellt wird und schon viele in Argumentationsnöte gebracht hat. Haben die Unternehmen zudem noch schlechte Erfahrungen mit EAM – vielleicht gar in Verbindung mit serviceorientierter Architektur (SOA) – gemacht, führt das zwangsläufig zu einer Grundsatzfrage im Unternehmen. Prinzipiell kann man sagen, dass EAM das im Unternehmen umsetzt, was die Geschäftsstrategie entwickelt bzw. die Geschäftsanforderungen aus dem „Daily Business“ einfordern. Die Kunst besteht jedoch darin, die richtige Balance zwischen diesen Geschäftsinnovationen und der IT- Effizienz zu finden, siehe auch Abbildung 3. Um dem Ganzen einen praktischen Bezug zu geben, ein kurzes Beispiel. Eine Firma A unterhält geschäftliche Bezieh- ungen zu einer Firma B. A verkauft in die- sem Fall eine Lösung an B, woraufhin B eine Preisreduzierung nachfragt. Gleich- zeitig ist B Lieferant und verkauft Produkte an A. Hier hat B jedoch Probleme im Service und die Aktivitäten der Geschäfts- beziehung 1 sind hier nicht bekannt. Zu guter Letzt ist B auch noch ein Partner von A. Er fungiert hier als Vertriebs- und als Technologiepartner. Der Vertrieb läuft jedoch schleppend und die Produkte lassen sich nur schwierig integrieren. In Abbildung 4 sind diese Beziehungen noch einmal grafisch dargestellt. Wie man an diesem Beispiel deutlich sehen kann, sind in diesen drei Geschäftsfällen zwei Akteure in unter- schiedlichen Rollen involviert. Dies Konstrukt ist mit Sicherheit nicht imm der Fall und auch nicht immer so komple aber gerade im B2B-Geschäft sind die oder ähnliche Beziehungen zwisch Unternehmen sehr häufig anzutreffe Auch bedeutet es nicht automatisch, da die Beteiligten eines Geschäftsfalls von d Aktivitäten eines anderen Geschäftsfa Kenntnis haben bzw. haben wollen. D mag jetzt weit hergeholt klingen, ist ab durchaus häufiger der Fall, als man denk Aber warum eigentlich? Ganz einfach, a drei Parteien haben für sich unterschied che Ziele. So hat der Vertrieb i Geschäftsfall A das Ziel, Umsatz mit de Kunden (Akteur B) zu generieren, d Einkauf soll mit seinem Lieferanten (gleic er Akteur B, aber andere Rolle) Einkauf kosten einsparen und der Partner-Manag liegt irgendwo dazwischen. Ein gemeins mes Ziel, wie eingangs in der Begriff definition beschrieben, sieht anders aus. Was hat das Ganze jetzt mit EAM tun? Bisher wurden EAM-Projekte mei durch Anforderungen von einzeln Geschäftsbereichen initiiert, die den Fok auf bestimmte Geschäftsprozesse und d diese unterstützenden IT-Anwendung legten. Hinzu kam, dass der Erfolg ma geblich von den Erfahrungen und Fähi keiten des EAM-Teams abhängig war. Hi bietet TOGAF 9 mit dem Architectu Skills Framework z.B. eine gute Method das Wissen der Architekten zu bewert und entsprechend weiterzuentwickeln. Das Beispiel oben und die folgenden, si daraus ableitenden, Fragestellungen zeig 2Online-Themenspecial EAM 2010 Online-Themenspecial EAM 2010 fachartikel Abb. 2: Domänen der Architektur Abb. 3: Darum EAM Abbildung 2.1: Dom¨anen der Architektur Aier, Riege und Winter [ARW08, S. 292 f.] gliedert die Unternehmensarchitektur in f¨unf Ebenen und beruft sich dabei auf den Standard 1471-2000 des Institute of Electrical and Electronic Engineers (IEEE) (siehe Tabelle 2.1). Tabelle 2.1: Ebenen der Unternehmensarchitektur Strategie: Produkte, Dienstleistungen, Unternehmensziele, Kunden, Zulieferer. Organisation: Vertriebskan¨ale, Gesch¨aftsprozesse, Organisationseinheiten, Rollen, Standorte. Integration: Applikationen, Dienste, Schnittstellen. Software: Softwarekomponenten, Datenstrukturen. IT-Infrastruktur: Hardware, Netzwerk, Software-Plattformen. 2.1.2 Nutzen Auf die Frage: ” Warum EAM?”geht Weinberger [Wei10, S. 2] ein. EAM setze im Unternehmen um, was Gesch¨aftss- trategie und Gesch¨aftsanforderung im t¨aglichen Gebrauch einfordern w¨urden. Ein Hauptnutzen des EAM kann die Transparenz der Zusammenh¨ange in der Unternehmung sein. Diese kommt gerade bei Unternehmensver¨anderungen zum Tragen. Soll z.B. ein System oder eine Technologie abgel¨ost werden, kann gezeigt werden, welche Daten, Prozesse oder organisatorischen Einheiten der Unternehmung vom Wechsel betroffen sind. Entsprechend k¨onnen Massnahmen den Bed¨urfnissen angepasst geplant und umgesetzt werden. Dasselbe gilt f¨ur die ¨Anderung eines Gesch¨aftsziels, so Weinberger [Wei10, S. 3]: ” Wenn das Produktmanagment in Abstimmung mit der Gesch¨aftsstrategie Produkte weiterentwickelt [. . . ], um neue Kunden und M¨arkte zu bedienen [. . . ], muss die Frage gekl¨art werden, wer in der neuen Zielarchitektur f¨ur welche Aufgabe zust¨andig ist, wie die IT das unterst¨utzt und wie [. . . ] externe Partner integriert werden.” 2.1.3 Zust¨andigkeiten Michael Schr¨oder, Head of Business Consulting Z¨urich verortet das Management der Unternehmensarchitektur als ” eine der zentralen Disziplinen des [Chief Information Officer (CIO)], neben dem Strategie- und Portfoliomana- gement“ ([ELCA14b, S. 3]). Anstelle der Bezeichnung CIO verwendet Keller [Kel12, S. xi] hingegen explizit den TOGAF Architecture Content Framework, 12. April 2015 3
  • 6. Begriff des IT-Vorstandes, womit ” auch der Gesch¨aftsf¨uhrer eines ausgegr¨undeten IT-Dienstleisters, der nicht den Titel Vorstand tr¨agt”, gemeint sein kann. 2.2 Enterprise Architecture Framework Zur Unterst¨utzung des IT-Management bei der Planung, Migration oder Weiterf¨uhrung von Unternehmensarchitek- turen empfiehlt es sich, ein Enterprise Architecture Framework (EAF) (dt. Unternehmensarchitekturrahmenwerk) einzusetzen. Solche gibt es nicht wenige – Matthes [Mat11a] beschreibt deren 50 an der Zahl. Er gruppiert die am Markt verf¨ugbaren EAF in sieben Typen (vgl. [Mat11b]): ˆ Government and Agency Framework: massgeschneidert f¨ur die Bed¨urfnisse von Beh¨orden ˆ Interoperability Framework: zur Umsetzung von Interoperabilit¨at ˆ Management Framework: f¨ur die Unterst¨utzung des Managements ˆ Manufacturing-Specific Framework: f¨ur Produktionsl¨osungen ˆ Military Framework: zur Unterst¨utzung von milit¨arischen Bed¨urfnissen ˆ Add-On Framework: als Erg¨anzung anderer Frameworks, Projekten usw. ˆ Technical orientated Framework: Rahmenwerk ohne betriebswirtschaftliche Management-Methoden Gem¨ass einer Einsch¨atzung von Keller [Kel12, S. 296] sind von den bekannten EAM-Frameworks vorallem TOGAF mit einem sich im Wachsen befindenden Marktanteil von 32%, gefolgt von Zachman mit einem stagnierenden Marktanteil von 25% von Relevanz (Stand 2008), nebst den Frameworks aus dem ¨offentlichen Sektor in den USA wie z.B. das Department of Defense Architecture Framework (DoDAF). 2.2.1 Framework der Open Group Wie [Ope-G116] zu entnehmen ist, z¨ahlen zum Konsortium der Open Group namhafte Unternehmen wie HP, IBM, Oracle oder Phillips. Die Mitglieder sind gem¨ass Matthes [Mat11b] zu 50% in Nordamerika, zu 25% in Europa und zu 25% im asiatisch-pazifischen Raum ans¨assig. Das Framework findet somit weltweit Verwendung, zur Zeit in der Version 9.1. Matthes [Mat11b] ordnet TOGAF der Gruppe der Management Frameworks zu. Wie Aier, Riege und Winter [ARW08, S. 295] aufzeigt, deckt TOGAF vier Ebenen der Unternehmensarchitektur gem¨ass IEEE (vgl. Tabelle 2.1) ab, beginnend bei der Organisation, vorallem aber die drei Ebenen Integration, Software und IT-Infrastruktur. Keller [Kel12, S. 294] sieht TOGAF ausschliesslich als Framework zur Prozessdefinition im IT- Management und verweist auf ein Klassifizierungsraster von Rozemeijer und Van Bon [RV07, S. 24], das TOGAF als rein taktisches Framework ohne strategischen oder operativen Elementen beurteilt (siehe Abbildung 2.2). Abbildung 2.2: Klassifizierungsraster f¨ur EAM-Frameworks TOGAF Architecture Content Framework, 12. April 2015 4
  • 7. Das Rahmenwerk besteht gem¨ass [Jos+10, S. 22] aus sieben Teilen: 1. Einf¨uhrung: Schl¨usselkonzepte, Terminologie, Release notes 2. Architecture Development Method (ADM): Schritt f¨ur Schritt eine EA entwickeln 3. ADM Guidelines & Techniques 4. Architecture Content Framework: Content Metamodel mit Deliverables aus Artifacts und Building Blocks 5. Enterprise Continuum & Tools: Verwaltung von unternehmensweiten Resultaten 6. TOGAF Reference Models: TOGAF Foundation Architecture, Integrated Information Infrastructure Refe- rence Model (III-RM). 7. Architecture Capability: Anforderungen an eine Architekturfunktion 2.2.2 Capability-Based Planning Weinberger [Wei10, S. 3] stellt fest, dass EAM-Projekte oft auf die Architektur der Systeme und Technologien fokussieren. Im besten Fall werden noch ein paar Gesch¨aftsprozesse davor und danach erw¨ahnt. Einen anderen Ansatz bietet das Capability-Based Planning: Die Gesch¨aftsstrategie wird unterst¨utzt durch ein Gesch¨aftsziel – dieses wird sodann als Business Capability (dt. Gesch¨aftsf¨ahigkeit), kurz Capability bezeichnet. Um die Gesch¨aftsf¨ahigkeit resp. die Capability zu erreichen, sind meist sowohl mehrere organisatorische Einheiten als auch Prozesse und verschiedene Systeme oder Technologien involviert (siehe Abbildung 2.3). TOGAF basiert auf diesem Konzept. Eventuell müssen bestimmte Personen oder Personengruppen speziell ausgebildet wer- den, um den neuen Anforderungen gerecht zu werden. Auf einer anderen Ebene muss identifi- ziert werden, wie „fähig“ die IT und die Infrastruktur sind, diese Prozesse und letzt- endlich die Bereitstellung des neuen Produktes zu unterstützen. Aktivitäts- diagramme, Applikationskataloge oder Matrizen können z.B. die entsprechenden Artefakte darstellen. Wird in diesem Fall ein neues Datacenter mit neuen Applika- tionen benötigt, spielen die Konsolidierung der gesamten Daten und die Bereitstellung der neuen Services eine große Rolle. Diese Beschreibung verdeutlicht sehr gut, dass die Geschäftsfähigkeiten auf der operati- ven Ebene abzuschätzen und entspre- chende alternative Fähigkeiten auszu- wählen. ■ Ein Bausteinansatz erlaubt individuelle Fähigkeiten innerhalb ihrer eigenen Geschäftsdomäne zu definieren, zu ent- wickeln und zu testen. Die einzelnen Fähigkeiten in diesem Bei- spiel der Produktneuentwicklung können innerhalb einzelner, kleiner Architektur- domänen der Geschäfts-, Informations- und Technologiearchitektur (Phasen B, C und D im TOGAF ADM) evaluiert und entwickelt werden. Die Geschäftsprozesse und die handelnden Personen sind dann in der Geschäftsarchitektur zu betrachten, Die fähigkeitsbasie also um die Etablieru eine bestimmte An Aufgaben zu erfüllen erheblicher Nutzen, die Migrationsplan angeht. Man hat Geschäftsnutzen un Geschäftsresultat (B Auge und fokussiert Unternehmensarchit Architecture) auf die Fazit Capability-Based Pla stellt mit Sicherheit um auf der Basis schäftsresultaten ein bauen und zu mana diese Methode nich anwendet, sollte Geschäftsnutzen un Resultat für die Ges daraus schlussfolge tivitäten zugrunde leg sind in diesem Fall w anforderungen an da und stellen eigentlich der Architektur – Ge Phase B nach TOGA Als Pionier und w Bereich Enterprise A ment und TOGAF, b Enterprise langjähri und Beratungsangeb TOGAFTM 9 for zierungskurs, Ent Assessment Services prise Architecture shops zu verschiede Online-Themenspecial EAM 2010 f Abb. 5: Capability Increments and Dimensions – TOGAF 9 Abbildung 2.3: Beispiel-Inkrement einer Capability mit involvierten Dimensionen 2.2.3 TOGAF in der Verwaltung In der Schweiz findet TOGAF Verwendung in der Bundesverwaltung. Wie das Informatiksteuerungsorgan des Bundes (ISB) festh¨alt, ist TOGAF ” sehr offen und l¨asst die Integration [von] anderen Methoden wie z.B. U.S. DoDAF oder [Federal Enterprise Architecture Framework (FEAF)] oder Entwicklungen wie z.B. der Service Oriented Architecture (SOA) ohne weiteres zu” (vgl. [ISB-P030, S. 4]). Letzteres best¨atigt auch Matthes [Mat11b]: So bietet z.B. die Firma SAP AG ein EAF an, konzipiert als technisches Framework und Add-On zu TOGAF, um das Einbinden von SOA zu realisieren. TOGAF Architecture Content Framework, 12. April 2015 5
  • 8. 3 Architecture Content Framework Der vierte Teil von TOGAF beschreibt das Architecture Content Framework (dt. Rahmenwerk f¨ur Architekturinhal- te). Das Rahmenwerk soll zur ¨Ubersicht dienen: Es enth¨alt ein strukturiertes Content Metamodel, um Erzeugnisse aus der Architekturarbeit zu sammeln und einzuordnen. Gem¨ass [Jos+10, S. 125] kann TOGAF erst durch das Architecture Content Framework als eigenst¨andiges Framework f¨ur Architekturen bezeichnet werden. Anstelle des Architecture Content Framework k¨onnte auch ein Framework wie ArchiMate oder Zachman Verwendung finden. Kommt aber das Architecture Content Framework von TOGAF zum Einsatz, kann dieses auch als Refernz zu den Metamodellen anderer Frameworks dienen. Das Architecture Content Framework von TOGAF unterscheidet drei Typen von Erzeugnissen, die mit der ADM erarbeitet werden: Deliverables, Artifacts und Building Blocks (dt. Arbeitsergebnisse, Artefakte und Bausteine; siehe dazu Abbildung 3.1). Nach Josey [Jos+10, S. 126] k¨onnen diese folgendermassen umschrieben werden: Deliverable: Formales, vertraglich spezifiziertes Erzeugnis, das von den Stakeholdern ¨uberpr¨uft, genehmigt und abgenommen wird, h¨aufig als Resultat von Projekten. Artifact: Detailliert definiertes Erzeugnis, das eine Architektur aus einer bestimmten Perspektive heraus beschreibt. Ein Deliverable kann mehrere Artefakte enthalten (siehe dazu das Beispiel in Abbildung 3.2): Kataloge (Auf- listungen von Elementen), Matrizen (Darstellungen von Beziehungen zwischen den Elementen) und/oder Diagramme (Abbildungen von Elementen). Building Block: Komponente einer Gesch¨afts-, IT- oder Architekturf¨ahigkeit (vgl. Abschnitt 2.2.2), evtl. wieder- verwendbar. Abbildung 3.1: Deliverables mit Artifacts und Building Blocks Abbildung 3.2: Deliverable am Beispiel eines Architecture Definition Document TOGAF Architecture Content Framework, 12. April 2015 6
  • 9. 3.1 Content Metamodel Das Architecture Content Framework enth¨alt ein strukturiertes Content Metamodel, um Erzeugnisse aus der Archi- tekturarbeit zu sammeln und einzuordnen (siehe Abbildung 3.3). Das Framework sieht Core Entities (dt. Kerninhalte) und Extensions (dt. Erweiterungsinhalte) vor. Mit den Core Entities soll das Umsetzen einer EA mit vern¨unftigem Aufwand erm¨oglicht werden, lediglich bei Bedarf werden gem¨ass [Jos+10, S. 128] Extensions eingearbeitet, bis hin zum m¨oglichen Full Content Metamodel. In diesem Bericht beschr¨anken wir uns jedoch auf das Core Content Metamodel. Abbildung 3.3: Content Metamodel nach ADM-Phasen Das Framework enth¨alt schliesslich Listen mit den Beschreibungen s¨amtlicher Entities, ihren Attributen und den Beziehungen zwischen den Entities unter Angabe der Extension, in welcher die Entities allenfalls zu finden sind. 3.2 Architecture Artifacts Die Arbeitsergebnisse der ADM, die sogenannten Architecture Artifacts (dt. Architektur-Artefakte) werden gem¨ass [Ope-G116] erstellt, um ein System, eine L¨osung oder einen Zustand des Unternehmens zu beschreiben. Das Konzept dazu wurde vom Standard ISO/IEC 42010:2007 resp. IEEE 1471 adapdiert (siehe Abbildung 3.4). Ein Artefakt kann nach [Jos+10, S. 130] in unterschiedlichem Kontext wiederverwendet werden. [Jos+10, S. 131] erl¨autert die Konzepte dazu, wie sie in TOGAF f¨ur die Sichten zur Anwendung kommen. Diese sind knapp zusammengefass in der Tabelle 3.1. Eine m¨ogliche Konstellation dieser Konzepte und ihrer Beziehungen wird in Abbildung 3.5 gezeigt. Tabelle 3.1: Konzepte in Verbindung mit Sichten auf die Architektur System Eine Sammlung von Komponenten, die organisiert sind, um eine Funktion auszuf¨uhren. Architektur Allgemeine Anordnung von Komponenten, die Beschreibung ihrer Be- ziehungen untereinander und zur Umgebung sowie die Prinzipien zur Steuerung der Weiterentwicklung. Architektural description Sammlung von Artefakten zur Dokumentation der Architektur. Stakeholder Personen, die eine wichtige Rolle im System einnehmen oder Anliegen (Concerns) bez¨uglich des Systems haben. Concern Hauptinteressen, die f¨ur die Stakeholder von entscheidender Bedeu- tung sind. View Darstellung des Gesamtsystems aus einem Blickwinkel betrachtet, dder durch gleichartige Concerns resp. Interessen bestimmt wird. Viewpoint Bestimmt den Blickwinkel, aus dem die Bildung eines Views erfolgt. TOGAF Architecture Content Framework, 12. April 2015 7
  • 10. Abbildung 3.4: Grundkonzepte der Architekturbeschreibung Abbildung 3.5: Die Konzepte und ihre Beziehungen Views und Viewpoints Die Entwicklung verschiedener Views und Viewpoints (dt. Sichten und Perspektiven auf die Unternehmensarchi- tektur) erfolgt w¨ahrend der Architekturarbeit mit der ADM und wird deshalb im Teil III von TOGAF beschrieben. Entsprechende Werkzeuge und Sprachen f¨ur die Entwicklung der Views sind im Teil V von TOGAF zu finden. Werkzeuge gibt es gem¨ass [Ope-G116] viele – was fehle sei eine gemeinsame Sprache f¨ur den Datenaustausch. Auch Keller [Kel12, S. 160] beklagt das Fehlen einer Standardisierung: ” Solche Darstellungen leiden h¨aufig unter ¨ahnlichen Problemen: Die Semantik der Darstellung ist nicht immer klar.”Wichtig w¨aren die Vereinheitlichung von Farbe, Position und Gr¨osse der Objekte sowie der Verbindungen. Keller [Kel12, S. 161 f.] erl¨autert sodann die Soft- warekartographie als Grundlage der Systematisierung und nennt Clusterkarten, Prozessunterst¨utzungskarten und TOGAF Architecture Content Framework, 12. April 2015 8
  • 11. Intervallkarten als ” Softwarekarten mit Kartengrund zur Verortung”. Winter [Win09, S. 22] hat dazu ein Beispiel mit Sichten und Perspektiven, erstellt mit ADOben (siehe dazu Abbildung 3.6). TOGAF listet und beschreibt schliesslich alle Artifacts, die in den verschiedenen ADM-Phasen erarbeitet werden sollen (siehe dazu auch Abbildung 3.7). In [Ope-G116] wird empfohlen, die folgenden Sichten zu erstellen: Business Architecture View, Enterprise Security View, Software Engineering View, System Engineering View, Communications Engineering View, Data Flow View, Enterprise Manageability View und Acquirer View. © Aug-09, IWI-HSG Seite 22 Beispiel für einen „ausgewogenen“ UA-Ansatz Kundensysteme Lieferanten-Systeme Kernsysteme Interne Systeme Ÿ Web-Portal Ÿ CRM-System Ÿ Kundenverwaltungs- System Ÿ Produkt-Datenbank Ÿ Angebots- und Buchungssystem Ÿ Lieferanten- Datenbank Ÿ Internes Mitarbeiter- Informationssystem Ÿ HR-System Ÿ Finanzsystem (Individualentwicklung) Ÿ DWH Ÿ Abrechnungssystem Ÿ Lieferanten- Schnittstellen- System Ÿ Produkt-Liste (Excel) Ÿ Finanzsystem (SAP) Ÿ Schnittstelle zu Markt- forschungsinstitut Applikationen (Bestandsführung) Ausserhalb deseigenen Unternehmens Ausserhalb des eigenen Unternehmens Applikationen der smartTravel AG Web-Frontend Back-Office Ÿ Web -Po rta l Ÿ CR M-Syst em D Ku nd en spe zi fisc he Em pfeh lu ng en Ÿ Kun denver waltu ngs- SystemD K un de nprä feren ze n D Ku den da ten Ÿ Pr oduk t-D at enbank D A ktue ll e A ng eb ote Ÿ An gebot s- und Bu ch ungssystem D An ge bote D K un de na nfrag e D An ge bo te D An frage , B esta nd sko rrektu r Ÿ Ab rechnu ngssyst em D Z ah lu ng sda ten Ÿ Lief eran ten- D at enbank D A nbi e te rda ten Ÿ Liefer ant en- Schnit tste llen- System D A nfrag e, Bu chu ng D A ng ebo te, B uch un gsb estä tig un g Ÿ An gebot s- und Bu ch ungssystem ( Liefer ant) D An frage , B uch un g D A ng eb ote, B u chu ng sbe stäti gu ng D Sch ni ttste ll en da ten Ÿ Int ern es Mit arb eiter - I nf orm ations s ys tem D A nb ie terda ten Ÿ H R -Syste m D Mi ta rbei terd ate n Ÿ Finan zs ys te m ( In dividualen twic klun g) D D aten z ur R enta bi l itä t v on G esch äftsb ezi eh un ge n D R ech nu ng sda ten D A nal yti sch e Fi na nz date n Ÿ D WH D A ufbe rei tete F in an zda ten D A nb ie terda ten (A bg le ic h) Ÿ Zahlun gs sys t em (K redit kart enun ter nehmen und B anken) D Z ah lu ng sd ta en Ÿ Schnit tste lle zu Mar kt- for schungsinst itut D Mark tda ten Ÿ Fin anzsys t em ( SAP) Ÿ Pr odukt -List e (Excel) Applikationslandkarte Prozesslandkarte smartTravelAG - Gesamtunternehmen Führungsprozesse Leistungsprozesse Unterstützungsprozesse 05 Unternehmens- strategie entwickeln 06 Unternehmens- comntrolling durchführen 07 IT-Betrieb 08 Finanz- und Rechnungswesen 01 Kundengewinnung und -Beziehungs- management 02 Reiseabwicklung 03 Lieferanten- gewinnung und -Beziehungs- management 04 Angebots- erstellung Geschäftsleitung Funktionen auf Konzernebene Controlling und Budgetierung Innovati ons- Management Personal-Managem ent Finanzen und Administration Marketing und Werbung Kundenwerbung Anbieterwerbung Marktforschung Lieferanten- Management Airli nes Hotel s Mi etwagenfirmen Kundenmanagement Individualreisen Paus chalreis en Städtereis en Aktivurlaub Erlebnisurlaub Club-U rlaub IT Familienurlaub Anwendungs- Entwicklung Anbieter-Integration IT-Infrastruktur Reiseversicherer Angebote vor Ort Zusatzdi enste Aufbauorganisationsmodell Lieferanten- Information ii Lieferanten- Schnittstellen- Informationii Zahlungs-Information ii Reiseinformation ii Reiseverlaufs- information ii Reise ii Buchung ii Buchungsbestätigung ii beschrieben in hat hat Informationsmodell Kunden- bedarfsanalyse - Individualreisen i Kundenbeda rf Lieferanten- gewinnung - Individualreisen i Lieferanten- Information Lieferanten- betreuung - Pauschalreisen Lieferanten- Anbindung - Pauschalreisen Komponenten- einkauf - Pauschalreisen i Reise-Kompone nte Referenzprozess Erstellung Pauschalangebote i Leistungspake t i Kundena nfrage Anfrage-Eingang und Angebotserstellung - Pauschalreisen Reisebuchung - Pauschalreisen i Leistungspak et i Reiseinformation Reisebetreuung - Pauschalreisen 08Finanz- und Rechnungswesen i Zahlungs-Information 07IT-Betriebi Lie feranten- Schnittste llen- Information Kunden- und Marktanalyse - Pauschalreisen Kunden- Beziehungs- management - Pauschalreisen Kundenwerbung - Pauschalreisen i Reiseverlaufs- informati on i Kundenpräferenz i Marktanalyse Informationslandkarte smartTravel AG Geschäftskunden Privatkunden P auschalreisen Transport Mietwagen-Anbieter Reiseversicherer Hotel s Routenplaner Wetterdienste Anbieter von S prachführern Anbieter von Ausfügen und V eranstaltungen Anbieter von Auslands- Telefonkarte n Anbieter von Reisebücher n bzw. Reiseführern Foto-Dienstleister F Indivi dualrei sen F Städterei sen Privatkunde Ei nzelpersonen F Akti vurl aub F Cl ub-Url aub F Erlebnisrei sen F Fam il i enurl aub Ai rlines SharedServi c eProvi der Mi etwagen-Anbi eter Shared Servi ce Provi der Rei seversi c herer Shared Servi ce Provi der H otels Shared Servi ce Provi der R outenpl aner Shared Servi ce Provi der Wetterdienste Exc lus iveServi ce. .. Anbi etervon Srachführern ExclusiveService... Anbi etervon Ausfl ügen und Veranstal tungen SharedServi c eProvi der Anbi etervon Ausl andstel efonkarten SharedServi c eProvi der Anbi etervon Reis eführern bz w. Reisebüchern SharedServi c eProvi der Online-Fotoal ben ExclusiveService... Tradi tionel le Fotoentwic kler ExclusiveService... U nternehmenBahn SharedServi c eProvi der Busunternehmen SharedServi c eProvi der ® Buchungspl attform der Bahn BCI F Individualreise n Privat kunde Û Auf ruf de r Reiseplattf orm / Konta ktanbahnung Û Konfiguration eine r Indiv idualreise Ü Market ing(Werbung durchf ühren, Plattform-, Reise-... Ü Erst elklung eine r Resiek onfiguratio n Ü Verwalt ung vo n Reiseko nfiguratione n Û Inform at ione nübe r die Reiseplattf orm Ü Angebot kont exta bhängige r Zusat zangebot e... Û Suche nac h Zusat zangeboten (Tele fonk art en,... Û Buchung des individuellen Angebot s Ü Buchungde s individuellen Angebot s Ü Zahlungsabwicklung Ü Angebot zusätzliche r Mögli chkei tenv or Ort (Veranstaltungen,... Û Suche nac h Ange bote nvorOrt (Veranstalt ungen,.. . Û Zahlung Û Unt erstützung bei Probleme n Ü Hot line Ü Bet reuung vor Ort Û Verwa ltungde r Urlauibsfotos Û Reiseinfor matione n Ü Entwic klung / Bereitst ellung der Urlaubsf otos Ü Buchungsbest ätigung Ü Identif ikation vo n Alternativangebot en Û Inform at ione nübe r Alternativangebot e Ü Zusatzinformationen (Wetter, etc.) Û Last Minute - Inf orm ationen vor Reiseant rit t ® Pay Servic e Pauschalreisen 001 Städtereise: v ®® Ü 002 Club-Urlaub: v ® ® Ü 003 Familienurlaub: v ® ® Ü 004 Erlebnisreisen: v ® ® Ü 005 Aktivurlaub: v ®® Ü 006 Jugendreisen: v ®® Ü 007 Studentenreisen: v ®® Ü 008 Studienreisen: v ® ® Ü 009 Single-Reisen: v ® ® Ü 002 Sporturlaub: v ® ® Ü 009 Themenreisen: v ®® Ü ZielgruppeImage/MarkeLeistungsangeobotZweiseitigeKommunikationMitbewerber Gruppenstruktur Alte rsst rukt ur Kostenstruktu r Tra nsport -Prä ferenz Werte Int eraktionsziele Mit bewerber Nebenkosten-Präf erenz Bet reuungs-Int ensit ät Präferenzen zur Gestalt ung des Auf enthalts Image / Mark e Kommunikations-Präferen z All ei nr ei se n Si ngl e-R ei se nPaarre is en Fam il ie nr ei se n G rup penrei se n J ug en d Stude nt en Jun ge B er uf stätig e Be ru fs täti g e Se ni or en D is co un te r Mit tel kla ss e Obere Mi ttel kla ss e Lu xu s Fl u g Bus Indi vidual -Anrei s eZu g Erl ebni s & Abent eu er Erholu n g Sp o rtKun st & K ul tur D esi gn & Am b ie nt e Party I ndi vid ual i tät G ruppen - ind ivi du ali tät Ko ntaktori en ti ert Reis eb üro s On li ne- Pl attform e n Lok al e Re is eanb ieter Re is ek on ze rn e Lan d & Le ute Selb st v ers orge r Ü be rn ac ht un g & Frühs tüc k Vo ll pe ns ionHal bp ens ion Al l I nc l us iv e H ot lin e Ans pr ec hpar tn er vor Ort Rei se le itung vor Or t Bi ld un g I nd ivi dual Vor -O rt Paketan ge bo te Ko mp l ett - Arran ge m en ts Kul in ari sc h Tradi ti on el l Conveni enc e Exkl usi v Fac hkundi g Pr ei s we rt Mo de rn & I nnovati v Kun den -S B pas s i ver- s em ip er sö nl i c he... pa ss iver- pe rs önl i c her.. . U nte rnehem ens - ak ti ve r Kontak t Geschäftsnetzwerk- modell Geschäftspartner- prozessmodell Produkte und Services (Bestandsführung) Strategische Positionierung Stammdaten Operative Daten Analytische Daten Kundenanfrage Reiseangebot Kunde Kundenpräferenz Zahlungs- information Lieferanten- Schnittstellenin... Anbieter Analytische Finanzinformati... Rechnung Anbieter- Rentabilität Mitarbeiter Finanz- information Buchung Buchungs- bestätigung hat hat Produkt- information bezieht sich auf gehört zu bezieht sich auf gehört zu gehört zu Marktdaten Datenmodell C01 Cluster 1 001 DWH Te mp Tables 003 Komponente Auswertungen 003 DWH Core Customer 004 Preismodell 002 Komponente Buchung Softwarelandkarte ZonenPhysische Server Servercluster Anton Bert Cl audia Die te r Egon Freddy 01 Ant on V 0101 Alf ons V 0102 Albert V 0103 Arne 02 B ert V 0201 Bernd V 0202 Bet tina V 0204 Bine V 0203 Beat 03 Claudia V 0301 Claus 04 Diet er V 0401 Diet mar V 0402 Dagobert V 0404 Denise V 0403 Dagmar 05 Egon V 0501 Ernie 06 Freddy V 0601 Frieda V 0602 Friedmann V 0604 Franzi V 0603 Fritz V 0405 Dolce ŸŸ C01 Cluster 1 V 0205 Bertram ŸŸ C02 Cluster 2 ŸŸ C03 Cluster 3 ŸŸ C04 Cluster 4 ŸŸ C05 Cluster 5 V Edeltraut Server-Modell Unix/Linux Microsoft Windows Novell Netware IBM OS/390 Ÿ Windows 2000 Ÿ Windows 2003 Ÿ OS/390 V2R6 Ÿ Windows NT 4.0 Ÿ Solaris 9 Ÿ HP-UX 11.00 Ÿ SUSE Linux 8.1 Ÿ Solaris 8 Ÿ Solaris 10 Ÿ Solaris 2.6 Ÿ AIX 5.2 Ÿ AIX 5.3 Ÿ HP-UX 10.20 Ÿ Debian Linux 3.1 Ÿ Red Hat Enterprise Linux Ÿ Embedded Linux Ÿ Net Ware 5.1 Ÿ NetWare 4.11 Systemsoftware (Bestandsführung) ŸŸ ŸŸŸ Ÿ Produkt-Datenbank (Produktion) ŸŸ ŸŸŸ Ÿ Angebots- und Buchungssystem (Produktion) Environment-Modell StrategieOrganisationAlignment Softwareund Daten IT-Infrastruktur FRAGE 1 Abbildung 3.6: Beispiele von Sichten und Perspektiven Abbildung 3.7: Architecture Artifacts des Core Content Metamodel sowie der Extensions TOGAF Architecture Content Framework, 12. April 2015 9
  • 12. 3.3 Deliverables Das Content Metamodel verwaltet die Deliverables, welche typischerweise im ADM-Zyklus ben¨otigt resp. als Output produziert werden und allenfalls an weitern Punkten der ADM wieder zum Einsatz kommen. Auch Deliverables, welche anderswo produziert wurden und in den Phasen der ADM ben¨otigt werden, werden eingeordnet. [Ope-G116] listet s¨amtliche Deliverables, welche durch die Architekturarbeit mit der ADM produziert werden (siehe Tabelle 3.2 und Abbildung 3.8). Schliesslich werden diese Deliverables in den Deliverable Descriptions von TOGAF einzeln genau beschrieben (vgl. [Ope-G116]). Abbildung 3.8: Die Phasen der ADM Tabelle 3.2: ADM Deliverables Deliverable Output from... Input to... Architecture Building Blocks F, H A, B, C, D, E Architecture Contract ­ ­ Architecture Definition Document B, C, D, E, F C, D, E, F, G, H Architecture Principles Preliminary, A, B, C, D Preliminary, , B, C, D, E, F, G, H Architecture Repository Preliminary Preliminary, A, B, C, D, E, F, G, H, Requirements Management Architecture Requirements B, C, D, E, F, Requirements Management C, D, Requirements Management Architecture Roadmap B, C, D, E, F B, C, D, E, F Architecture Vision A, E B, C, D, E, F, G, H, Requirements Management Business Principles, Business Goals, and Business Drivers Preliminary, A, B A, B Capability Assessment A, E B, C, D, E, F Change Request F, G, H ­ Communications Plan A B, C, D, E, F Compliance Assessment G H Implementation and Migration Plan E, F F Implementation Governance Model F G, H Organizational Model for Enterprise Preliminary Preliminary, A, B, C, D, E, F, G, H, Requirements Management Request for Architecture Work Preliminary, F, H A, G Requirements Impact Assessment Requirements Management Requirements Management Solution Building Blocks G A, B, C, D, E, F, G Statement of Architecture Work A, B, C, D, E, F, G, H B, C, D, E, F, G, H, Requirements Management Tailored Architecture Framework Preliminary, A Preliminary, A, B, C, D, E, F, G, H, Requirements Management TOGAF Architecture Content Framework, 12. April 2015 10
  • 13. 3.4 Building Blocks Ein Building Block (dt. Baustein) stellt gem¨ass [Jos+10, S. 126] eine Komponente einer Gesch¨afts-, IT- oder Ar- chitekturf¨ahigkeit (vgl. Abschnitt 2.2.2). Eine solche Komponente kann sowohl Architekuren (Architecture Building Block (ABB)) als auch L¨osungen (Solution Building Block (SBB)) zugeordnet werden, falls es sich zu einem sp¨a- teren Zeitpunkt z.B. um Projekte aus einer Capability handelt (vgl. [Jos+10, S. 135 ff.]). Systeme werden gem¨ass [Jos+10, S. 135] aus einer Sammlung von Building Blocks erstellt. Die Bausteine ihrerseits m¨ussen Schnittstellen aufweisen, damit sie mit anderen Bausteinen interagieren k¨onnen. Die Bausteine entstehen in der Architekturarbeit der ADM-Phasen (siehe Abbildung 3.9). Abbildung 3.9: Phasen resp. Schritte der ADM, die Building Blocks generieren TOGAF Architecture Content Framework, 12. April 2015 11
  • 14. 4 Schlussfolgerungen und Ausblick TOGAF ber¨ucksichtigt das Management der Organisation, fokussiert aber vorallem auf die drei Ebenen Integration, Software und IT-Infrastruktur. Nicht geeignet ist das Rahmenwerk f¨ur das Management der Unternehmensstrategie. Das Rahmenwerk erlaubt ein Capability-Based Planning und involviert die Stakeholder. Dabei wird TOGAF erst mit dem Architecture Content Framework zu einem eigenst¨andigen EAF. Das Content Metamodel strukturiert die Ergebnisse der Architekturarbeit und dient zur ¨Ubersicht. Das Architecture Content Framework bietet sich zudem als Schnittstelle zu anderen, eventuell auch erg¨anzenden Rahmenwerken an. Spannend w¨are ein Vergleich verschiedener EAF und ihre Entsprechungen untereinander, dargestellt als Matrix, um M¨oglichkeiten und Grenzen aufzuzeigen. Auch eine ¨Ubersicht zu Schnittstellen k¨onnte f¨ur das IT-Management von Nutzen sein. Wie [ARW08, S. 293] feststellt, lassen sich jedoch die g¨angigen Frameworks ” Aufgrund ihrer Komplexit¨at und den zum Teil unterschiedlichen Zielstellungen bei der Entwicklung [. . . ] nur bedingt miteinander vergleichen”. Er erw¨ahnt in diesem Zusammenhang das Generalised Reference Architecture and Methodology (GE- RAM) Framework, das genau dies zum Ziel habe, beurteilt die Resultate des Frameworks jedoch als ” weitgehend abstrakt”. Mit dem Core Content Metamodel von TOGAF kann ein Mindestsatz an Architekturinhalten verwaltet werden. Auch zu einem sp¨ateren Zeitpunkt kann die Architektur mit gew¨unschten Extensions noch verfeinert werden. So l¨asst sich eine EA mit vern¨unftigem Aufwand umsetzen. TOGAF Architecture Content Framework, 12. April 2015 12
  • 15. TOGAF Architecture Content Framework, 12. April 2015 13
  • 16. Abk¨urzungen ABB Architecture Building Block ADM Architecture Development Method BI Business Intelligence CIO Chief Information Officer CRM Customer Relationship Management DoDAF Department of Defense Architecture Framework EA Enterprise Architecture EAF Enterprise Architecture Framework EAM Enterprise Architecture Management ECM Enterprise Content Management FEAF Federal Enterprise Architecture Framework GERAM Generalised Reference Architecture and Methodology IEEE Institute of Electrical and Electronic Engineers III Integrated Information Infrastructure III-RM Integrated Information Infrastructure Reference Model IKT Informations- und Kommunikationstechnik ISB Informatiksteuerungsorgan des Bundes IT Informationstechnologie RM Reference Model SBB Solution Building Block SOA Service Oriented Architecture TOGAF The Open Group Architecture Framework TOGAF Architecture Content Framework, 12. April 2015 14
  • 17. Glossar Architecture Capability Framework Das Architecture Capability Framework als Teil von TOGAF zeigt auf, wel- che F¨ahigkeiten eine Organisation haben sollte, um im Sinne von TOGAF ihre Architektur entwickeln zu k¨onnen. Architecture Content Framework Mit dem Architecture Content Framework (dt. Rahmenwerk f¨ur Architektu- rinhalte) als Teil von TOGAF werden die Erzeugnisse aus der Architekturarbeit gesammelt und ¨ubersichtlich verwaltet. Dazu werden die Erzeugnisse klassifiziert und in einem Metamodell eingeordnet. Architecture Development Method Die Architecture Development Method (ADM, dt. Architekturentwicklungs- methode) ist das zentrale Element von TOGAF zur Entwicklung von Architekturen. Enterprise Architecture Framework Ein Enterprise Architecture Framework (EAF, dt. Unternehmensarchitek- turrahmenwerk) ist ein Mittel f¨ur das IT-Management zur Planung, Realisierung und Weiterf¨uhrung von Unternehmensarchitekturen in der Informationstechnologie. Enterprise Architecture Tool Ein Enterprise Architecture Tool (dt. Unternehmensarchitekturwerkzeug) ist ein Werkzeug zur Unterst¨utzung in der Architekturarbeit, meist in Form einer Software-Applikation. Damit lassen sich Komponenten der Unternehmensarchitektur wie z.B. Modelle und Prozesse erstellen resp. verwalten und Projekte weiterentwickeln. Stakeholder Person, f¨ur die es aufgrund ihrer Interessenlage von Belang ist, wie ein bestimmtes Unternehmen sich verh¨alt (z.B. Aktion¨ar, Mitarbeiter, Kunde, Lieferant, Abteilungsleiter, Productmanager). TOGAF Architecture Content Framework, 12. April 2015 15
  • 18. Literaturverzeichnis [ARW08] Stephan Aier, Christian Riege und Robert Winter. ” Unternehmensarchitektur – Literatur¨uberblick und Stand der Praxis“. In: Wirtschaftsinformatik 50 (2008), Nr. 4. 2008, S. 292–304. DOI: 10.1365/ s11576-008-0062-9. URL: http://dx.doi.org/10.1365/s11576-008-0062-9 (besucht am 26. 02. 2015). [ELCA14a] ELCA. ” Business Consulting: Macht IT noch wertvoller f¨ur Ihr Business“. In: Elca Update No. 8. Nov. 2014. URL: https://www.elca.ch/de/elcaupdate8 (besucht am 19. 02. 2015). [ELCA14b] ELCA. ” Business Consulting: Unternehmensarchitektur“. In: Flyer ELCA. Nov. 2014. URL: https: //www.elca.ch/sites/default/files/elc_enterprise_architecture_de_web_0.pdf (besucht am 19. 02. 2015). [ISB-P030] ISB. P030 – The Open Group Architecture Framework (TOGAF) als Unternehmensarchitektur Me- thode f¨ur die Bundesverwaltung. ISB P030. Version 1.01. Informatiksteuerungsorgan des Bundes ISB, Aug. 2011. URL: http://www.isb.admin.ch/themen/standards/alle/03264/ (besucht am 02. 03. 2015). [Jos+10] Andrew Josey u. a. TOGAF Version 9 – Ein Pocket Guide. Zaltbommel NL: Van Haren Publishing, 2010. Kap. 5: Architecture Content Framework, S. 125–138. ISBN: 978-9-08753-581-0. [Kel12] Wolfgang Keller. IT-Unternehmensarchitektur – Von der Gesch¨aftsstrategie zur optimalen IT-Unter- st¨utzung. 2. Aufl. Heidelberg: dpunkt, 2012. ISBN: 978-3-89864-768-7. [Kur+14] Karl Kurbel u. a. Enzyklop¨adie der Wirtschaftsinformatik – Online-Lexikon. 8. Aufl. M¨unchen: Olden- bourg, 2014. URL: http://www.enzyklopaedie-der-wirtschaftsinformatik.de/ (besucht am 03. 03. 2015). [Mat11a] Dirk Matthes. Enterprise Architecture Frameworks Kompendium – ¨Uber 50 Rahmenwerke f¨ur das IT-Management. Berlin Heidelberg: Springer, 2011. ISBN: 978-3-642-12955-1. DOI: 10.1007/978- 3-642-12955-1. URL: http://link.springer.com/book/10.1007%2F978-3-642-12955-1 (besucht am 19. 03. 2015). [Mat11b] Dirk Matthes. ” Matthes Framework Map - frameworks according to their nationality and inten- tion“. In: Enterprise Architecture Frameworks Kompendium – ¨Uber 50 Rahmenwerke f¨ur das IT- Management. Springer, 2011. ISBN: 3-64212-954-4. URL: http://www.eaf-book.de/Matthes% 20FrameworkMap.pdf (besucht am 26. 02. 2015). [Ope-G116] The Open Group. TOGAF Version 9.1. Document Number: G116. 2010. Kap. IV: Architecture Con- tent Framework. ISBN: 978-9-08753-679-4. URL: http://pubs.opengroup.org/architecture/ togaf9-doc/arch/ (besucht am 26. 02. 2015). [RV07] Eric Rozemeijer und Jan Van Bon. Frameworks for IT Management – a Pocket Guide. Zaltbommel NL: Van Haren Publishing, 2007. ISBN: 978-90-8753-087-7. [Wei10] Danny Weinberger. ” . . . und am Anfang steht die Gesch¨aftsanforderung, oder?“ In: objektSPEKTRUM EAM/2010 (2010). URL: http://www.sigs-datacom.de/fachzeitschriften/objektspektrum/ archiv / artikelansicht . html ? tx _ mwjournals _ pi1 % 5BshowUid % 5D = 6582 (besucht am 26. 02. 2015). [Win09] Robert Winter. ” One size fits all? – Unternehmensarchitekturmanagement im Spannungsfeld von Standardisierung und (unternehmens-)individueller Nutzenmaximierung“. In: Das 13. Berner Archi- tekten Forum im R¨uckblick. 2009. URL: http://www.berner-architekten-treffen.ch/archiv/ 13/treffen_no13.php (besucht am 04. 04. 2015). TOGAF Architecture Content Framework, 12. April 2015 16
  • 19. Bildnachweis Titelseite: Enterprise Architecture (EA) Development. Website der Firma Systems Plus, Inc., Rockville Maryland. Rubrik Services & Solutions: Consulting Services Bearbeitet mit GIMP. Eine Online-Version der Originaldatei ist verf¨ugbar unter http://www.sysplus.com/images/img_enterprise.jpg (Zugriff: 19. Februar 2015). Abbildung 2.1: Abb. 2: Dom¨anen der Architektur. In: [Wei10, S. 2]. Abbildung 2.2: Figure 1a Cross-references for quality management and Business Process Management frameworks. In: [RV07, S. 24]. Abbildung 2.3: Abb. 5: Capability Increments and Dimensions – TOGAF 9. In: [Wei10, S. 4]. Abbildung 3.1: Figure 33-1: Relationships between Deliverables, Artifacts, and Building Blocks. In: [Ope-G116]. Abbildung 3.2: Figure 33-2: Example - Architecture Definition Document. In: [Ope-G116]. Abbildung 3.3: Figure 34-4: Content Framework by ADM Phases. In: [Ope-G116]. Abbildung 3.4: Figure 35-1: Basic Architectural Concepts. In: [Ope-G116]. Abbildung 3.5: Figure 34-2: Core Entities and their Relationships. In: [Ope-G116]. Abbildung 3.6: Beispiel f¨ur einen ” ausgewogenen”UA-Ansatz. In: [Win09, S. 22]. Abbildung 3.7: Figure 35-3: Artifacts Associated with the Core Content Metamodel and Extensions. In: [Ope-G116]. Abbildung 3.8: Figure 5-1: Architecture Development Cycle. In: [Ope-G116]. Abbildung 3.9: Figure 37-1: Key ADM Phases/Steps at which Building Blocks are Evolved/Specified. In: [Ope-G116]. TOGAF Architecture Content Framework, 12. April 2015 17
  • 20. Abbildungsverzeichnis 2.1 Dom¨anen der Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Klassifizierungsraster f¨ur EAM-Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Beispiel-Inkrement einer Capability mit involvierten Dimensionen . . . . . . . . . . . . . . . . . . . 5 3.1 Deliverables mit Artifacts und Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Deliverable am Beispiel eines Architecture Definition Document . . . . . . . . . . . . . . . . . . . 6 3.3 Content Metamodel nach ADM-Phasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 Grundkonzepte der Architekturbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5 Die Konzepte und ihre Beziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.6 Beispiele von Sichten und Perspektiven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.7 Architecture Artifacts des Core Content Metamodel sowie der Extensions . . . . . . . . . . . . . . 9 3.8 Die Phasen der ADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.9 Phasen resp. Schritte der ADM, die Building Blocks generieren . . . . . . . . . . . . . . . . . . . . 11 Tabellenverzeichnis 2.1 Ebenen der Unternehmensarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Konzepte in Verbindung mit Sichten auf die Architektur . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 ADM Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 TOGAF Architecture Content Framework, 12. April 2015 18
  • 21. Stichwortverzeichnis Architecture Content Framework, 1, 5–7, 12 Artifact, 5–7, 9 Building Block, 5, 6, 11 Content Metamodel, 5–7, 10, 12 Deliverable, 5, 6, 10 Architecture Development Method, 5–7, 10, 11 Building Block, 5, 6, 11 Architecture Building Block, 11 Solution Building Block, 11 Capability-Based Planning, 5, 12 Architekturf¨ahigkeit, 6, 11 Capability, 5 Gesch¨aftsf¨ahigkeit, 5, 6, 11 IT-F¨ahigkeit, 6, 11 Content Metamodel, 5–7, 10, 12 Core Content Metamodel, 7, 9, 12 Core Entity, 7 Extension, 7, 9, 12 Full Content Metamodel, 7 Enterprise Architecture, 2–5, 7, 12 Enterprise Architecture Framework, 1, 4–6, 12 ArchiMate, 6 DoDAF, 4, 5 FEAF, 5 GERAM, 12 TOGAF, 1, 2, 4–6, 10, 12 Zachman, 4, 6 Enterprise Architecture Management, 1–4 Service Oriented Architecture, 5 Stakeholder, 12 TOGAF Architecture Content Framework, 12. April 2015 19
  • 22. Selbst¨andigkeitserkl¨arung Wir best¨atigen, dass wir die vorliegende Arbeit selbstst¨andig und ohne Benutzung anderer als der im Literaturver- zeichnis angegebenen Quellen und Hilfsmittel angefertigt haben. S¨amtliche Textstellen, die nicht von uns stammen, sind als Zitate gekennzeichnet und mit dem genauen Hinweis auf ihre Herkunft versehen. Ort, Datum: Biel/Bienne, 12. April 2015 Vorname, Name: Roland Bruggmann Unterschrift: ...................................... Vorname, Name: Tobias Millauer Unterschrift: ...................................... TOGAF Architecture Content Framework, 12. April 2015 20