Architecture Capability Framework

Transkript

1 Architecture Capability Framework TOGAF Informatik Seminar (Modul BTI7311), Frühlingssemester 2015 "Das Architecture Capability Framework zeigt auf welche Fähigkeiten eine Organisation entwickeln sollte, um im Sinne von TOGAF ihre Architektur entwickeln zu können." Studiengang: BSc in Informatik Autor: Dimitri Hämmerli Betreuer: Dr. Prof. Urs Sauter Datum: Berner Fachhochschule Haute école spécialisée bernoise Bern University of Applied Sciences

2 Management Summary Die moderne Technologie ist aus dem heutigen Leben, sei es aus dem Privatleben oder aus einem Unternehmen, nicht mehr wegzudenken. Mittlerweile hat sich ein grosser Teil der Bevölkerung an den Einzug von Informatikmitteln gewöhnt. Dabei geht oft vergessen, dass die Informatik noch eine sehr junge Disziplin ist und in den letzten Jahren einen riesigen Wandel vollzogen hat. Mit den neuen technologischen Möglichkeiten stiegen auch die Erwartungen und Anforderungen an die Informatik. Unternehmen hatten in der Vergangenheit oft Mühe mit der Geschwindigkeit des technologischen Wandels mitzuhalten. Dies führte dazu, dass in grossen Unternehmen auch heute noch Legacy-Applikationen in Betrieb sind. Zusätzlich wurde durch das historische Wachstum der Informatikinfrastruktur die Komplexität laufend grösser. Als Folge daraus ist heute kaum noch jemand mehr in der Lage, diese Komplexität beurteilen zu können. Dadurch entstehen mehrere Probleme: Abhängigkeiten von Applikationen sind nicht mehr bekannt. Unterschiedliche Fachbereiche verwenden unterschiedliche Software mit derselben Funktionalität (verursacht hohe Kosten). Das Wissen über die alten Applikationen geht verloren. Um Struktur in die verworrenen IT- Landschaften zu bringen, wurden Enterprise Architecture-Ansätze entworfen. Ein solcher Ansatz ist das Architektur- Framework TOGAF von The Open Group. In der vorliegenden Semesterarbeit wird eine Komponente von TOGAF, das Architecture Capability Framework, genauer betrachtet. Dieser Teil von TOGAF beantwortet insbesondere die Fragestellung wie ein Unternehmen aufgebaut sein muss, um architekturfähig zu sein. Interessant dabei ist, dass TOGAF für den Aufbau der Architekturfähigkeit auf eigene Methoden zurückgreift. So wird zum Beispiel die Architecture Development Method ADM verwendet, um die Architekturfunktion zu etablieren. Architecture Capability Framework,

3 Inhaltsverzeichnis 1 Einleitung 4 2 TOGAF Definition von Architektur im Kontext von TOGAF Aufbau der TOGAF - Dokumentation Architecture Development Method (ADM) Architecture Content Framework Enterprise Continuum 8 3 Architecture Capability Framework Etablieren einer Architekturfunktion Phase A. Architekturvision (Architecture Vision) Phase B: Geschäftsarchitektur (Business Architecture) Phase C bis H Architektur-Governance Architektur-Board Architektur-Compliance Framework für Architektur-Fertigkeiten 14 4 Schlussfolgerungen/Fazit 15 5 Abbildungsverzeichnis 16 6 Glossar 16 7 Literaturverzeichnis 16 8 Selbständigkeitserklärung 17 Architecture Capability Framework,

4 1 Einleitung Die folgende Arbeit beschäftigt sich hauptsächlich mit einem Teil von TOGAF: dem Architecture Capability Framework. Dieser relativ kleine Teil ist jedoch immens wichtig, weil ohne Architekturfähigkeit die Grundlage fehlt, damit eine Organisation oder ein Unternehmen Architekturen erstellen kann. Gliederung Um eine Architekturfunktion zu erstellen, verwendet TOGAF Methoden, beziehungsweise Komponenten des eigenen Frameworks. Aus diesem Grund werden diese Komponenten im ersten Teil dieser Arbeit kurz erläutert, ohne jedoch ins Detail zu gehen. Mit dem Wissen aus dem ersten Teil sollte die Grundlage geschaffen sein, um die Funktionsweise als auch die Rolle des Architecture Capabilty Frameworks zu verstehen. Dies ist der zweite Teil dieser Arbeit. Abgrenzung Um die Komplexität der vorliegenden Semesterarbeit zu begrenzen, wird auf die Konstruktion eines eigenen prototypischen Architekturfunktion-Ansatzes verzichtet. Ebenfalls wird auf Aspekte von verwandten Disziplinen wie Projektmanagement oder Qualitätsmanagement verzichtet. Architecture Capability Framework,

5 2 TOGAF TOGAF - The Open Group Architecture Framework ist ein frei verfügbares Architektur-Framework von The Open Group. Dieses Framework dient unter anderem als Werkzeug beim Erstellen, Nutzen oder Pflegen von Architekturen. Das Kernstück ist dabei ein iteratives Prozessmodell, welches durch andere Elemente, wie zum Beispiel wiederverwendbaren Architekturelementen, unterstützt wird. TOGAF basiert auf TAFIM, dem technischen Architektur-Framework für Informationsmanagement des US-Verteidigungsministeriums und wurde erstmals 1995 freigegeben. Seither hat das Architekturforum von The Open Group kontinuierlich Folgeversionen entwickelt und ist auch heute noch für die Konzipierung und Weiterentwicklung verantwortlich. Die aktuelle Version von TOGAF wird jeweils auf der Website von The Open Group bereitgestellt. Zum jetzigen Zeitpunkt ist dies die Version 9.1. ( TOGAF lässt sich sehr gut mit anderen Rahmenwerken kombinieren. Dadurch können Unternehmensarchitekturen aus unterschiedlichsten Branchen auf der Grundlage von TOGAF erstellt werden Definition von Architektur im Kontext von TOGAF Die Definition von Architektur ist in TOGAF kontextabhängig: 1. "Eine formale Beschreibung eines Systems oder ein detaillierter Plan des Systems auf Komponenteneben als Leitlinie für die Implementierung." 2 2. "Die Struktur der Komponenten, deren Beziehungen untereinander sowie die Prinzipien und Richtlinien, die das Design und die Weiterentwicklung der Komponenten im Laufe der Zeit bestimmen". 3 Nachdem nun bekannt ist, wie TOGAF dem Begriff Architektur interpretiert, wird in den nächsten Kapitel der Aufbau der TOGAF - Dokumentation näher betrachtet. 1 Vgl. Andrew Josey et al. (2010): TOGAF TM Version 9 - Ein Pocket Guide, S 21ff. 2 Andrew Josey et al. (2010): TOGAF TM Version 9 - Ein Pocket Guide, S Andrew Josey et al. (2010): TOGAF TM Version 9 - Ein Pocket Guide, S 24. Architecture Capability Framework,

6 2.2 Aufbau der TOGAF - Dokumentation Die folgende Grafik zeigt die Struktur und den Inhalt einer Architekturfunktion (Architecture Capability) innerhalb eines Unternehmens. In den folgenden Unterkapiteln werden die wichtigsten Komponenten (in der Grafik farbig dargestellt) kurz thematisiert, damit klar ist, welche Rollen diese Komponenten innerhalb von TOGAF einnehmen. Abbildung 1: Struktur von TOGAF 4 4 The Open Group (2011): Structure of the TOGAF Document. URL: doc/m/chap01.html ( ). Architecture Capability Framework,

7 2.2.1 Architecture Development Method (ADM) In der vorangegangenen Grafik (siehe Abbildung 1: Struktur von TOGAF) ist ersichtlich, dass die ADM (orange) das zentrale Element von TOGAF ist. Es beschreibt die Methodik mit der die Architektur nach TOGAF entwickelt werden kann. Zusätzlich bietet TOGAF eine Zusammenstellung von Richtlinien und Techniken (rot), die diesen iterativen Prozess der Architekturentwicklung unterstützen. 5 Die folgende Grafik (siehe Abbildung 2: Architekturentwicklungszyklus) veranschaulicht die Phasen, die die verschiedenen Architekturdomänen zyklisch durchlaufen. Diese grundlegende Struktur ermöglicht es Architekten auch mit grossen Mengen von komplexen Anforderungen umzugehen. 6 Die ADM wird unter anderem auch beim Erstellen der Architekturfunktion (Enterprise Architecture Capability) von zentraler Bedeutung sein. Abbildung 2: Architekturentwicklungszyklus Architecture Content Framework Damit die Ergebnisse, die während der Ausführung der ADM erarbeitet werden, konsistent und strukturiert zusammengestellt werden können, ist ein Rahmenwerk für Architekturinhalte erforderlich. TOGAF hat zu diesem Zweck das sogenannte Architecture Content Framework entwickelt. In diesem Framework werden wichtige Architektur-Arbeitsergebnisse, wie zum Beispiel Prozessflüsse, Projektpläne, usw. zusammengestellt. Dabei wird zwischen freigegebenen Arbeitsergebnissen, Artefakten innerhalb der Arbeitsergebnisse und Architekturbausteinen unterschieden. 8 5 Vgl. Andrew Josey et al. (2010): TOGAF TM Version 9 - Ein Pocket Guide, S Vgl. Andrew Josey et al. (2010): TOGAF TM Version 9 - Ein Pocket Guide, S The Open Group (2011): 5.2 Architecture Development Cycle. URL: doc/m/chap05.html ( ) 8 Vgl. Andrew Josey et al. (2010): TOGAF TM Version 9 - Ein Pocket Guide, S 125. Architecture Capability Framework,

8 Abbildung 3: Enterprise Continuum 11 Eine weitere Komponente von TOGAF ist das Architecture Capability Framework, blau dargestellt (siehe Abbildung 1: Struktur von TOGAF). Diese Komponente wird nun in den folgenden Kapiteln vertieft angeschaut Enterprise Continuum Das Enterprise Continuum, grün dargestellt (siehe Abbildung 1: Struktur von TOGAF), ist ein virtuelles Repository, beziehungsweise ein Modell zur Strukturierung eines solchen Repository. Darin enthalten sind die Architektur-Assets s und die zugehörigen Lösungen (Modelle, Muster, Architekturbeschreibungen, etc.). Das Enterprise Continuum verfolgt dabei zwei zentrale Ziele: einerseits soll die Wiederverwendbarkeit von Architekturen oder Architekturbestandteilen gefördert werden, andererseits sollen die darin enthaltenen Assets als Kommunikationshilfe dienen. 9 Dabei gibt es eine Unterscheidung zwischen Architekturen, dem sogenannten Architecture- Continuum und den Lösungen (Solution-Continuum). Wie in der nachfolgenden Abbildung (siehe Abbildung 3: Enterprise Continuum) ersichtlich ist, sind diese Komponenten miteinander verbunden. Zusätzlich sind im Enterprise Continuum Referenzmodelle enthalten, wie zum Beispiel die TOGAF- Basisarchitektur. Anhand dieser Grundlage können die Anwender ihre spezifischen Architekturen oder Architekturkomponenten aufbauen Vgl. Andrew Josey et al. (2010): TOGAF TM Version 9 - Ein Pocket Guide, S Vgl. Andrew Josey et al. (2010): TOGAF TM Version 9 - Ein Pocket Guide, S The Open Group (2011): Structure Part V. Introduction. URL: doc/m/chap39.html ( ) Architecture Capability Framework,

9 3 Architecture Capability Framework TOGAF definiert das Architecture Capability Framework (ACF) folgendermassen: "Das Architecture Capability Framework bietet einen Satz an Referenzmaterial al zum Etablieren einer dazugehörigen Architekturfunktion". 12 Anders ausgedrückt: Das ACF bietet eine Antwort auf die Frage wie ein Unternehmen aufgebaut, beziehungsweise strukturiert sein muss, um erfolgreich Architektur betreiben zu können. Wie in der folgenden Darstellung (siehe Abbildung 4: Ausgeprägte Architecture Capability) ersichtlich wird, sind neben der reinen Organisationsstruktur auch die Prozesse, Rollen, Verantwortlichkeiten und Fähigkeiten von zentraler Bedeutung. 13 Die folgende Abbildung gibt einen Überblick, wie eine ausgeprägte Architekturfunktion aussehen kann. Steuerndes Element ist dabei der violett markierte Bereich Governance Bodies. Zusätzlich ist erkennbar, dass die unterschiedlichen Rollen, beziehungsweise die Rollenbesetzung von dem Wissen und den Fähigkeiten, der Mitarbeiten in einer Organisation abhängt (grün-blau). Abbildung 4: Ausgeprägte Architecture Capability 14 Das ACF wird in verschiedene Themenbereiche unterteilt, die in den folgenden Kapiteln vertieft angeschaut werden. Um die Umsetzung des ACF zu erleichtern, bietet TOGAF zu jedem dieser Themenbereiche eine Vielzahl an Richtlinien an. Im Rahmen dieser Seminararbeit werden nur einzelne ausgewählte Richtlinien angeschaut. Bei Interesse an den weiteren Richtlinien kann die Webseite von The Open Group besucht werden ( 12 Andrew Josey et al. (2010): TOGAF TM Version 9 - Ein Pocket Guide, S Vgl. The Open Group (2011): Structure of Part VII. Introduction. URL: doc/m/chap45.html ( ) 14 The Open Group (2011): Structure of Part VII. Introduction. URL: doc/m/chap45.html ( ) Architecture Capability Framework,

10 3.1 Etablieren einer Architekturfunktion Wie bereits in Kapitel Architecture Development Method (ADM) kurz erwähnt, wird das Erstellen einer Enterprise Architecture Capability durch die Architecture Development Method (ADM) unterstützt. Ähnlich wie bei jeder anderen Business Capability bleibt auch beim Aufbau einer Architecture Capability der Ansatz bestehen, dass dies nicht als einmaliges Architekturprojekt angeschaut werden darf, sondern als kontinuierlicher Prozess. Das bedeutet, dass in diesem Prozess immer wieder auf sich verändernde Elemente, wie zum Beispiel Umgebung, Ressourcen, etc. neu reagiert werden muss. Damit in einer Organisation Architekturfähigkeiten (Architecture Capabilities) implementiert werden können, ist nach TOGAF die Entwicklung von vier Architekturdomänen (Domain Architectures) erforderlich: 15 Die Geschäftsarchitektur (Business Architecture) beschäftigt sich mit Themen wie Governance, Prozessen, Organisationsstrukturen, etc. Die Datenarchitektur (Data Architecture) definiert die Struktur des Enterprise Continuums und des Architecture Repositorys der Organisation. Die Anwendungsarchitektur (Application Architecture) spezifiziert von der Architekturorganisation benötigte Funktionalitäten und Anwendungsdienste. Die Technologiearchitektur (Technology Architecture) bestimmt Infrastrukturanforderungen, die benötigt werden, um Applikationen oder das Enterprise Continuum zu unterstützen. 16 Um nun konkret die Fähigkeit zur Realisierung einer Architektur zu entwickeln, wird wie bereits Eingangs dieses Kapitels erwähnt, auf die Phasen der ADM zurückgegriffen. In den folgenden Unterkapiteln werden diese Phasen nun schrittweise durchlaufen und einzelne Schlüsselelemente jeder Phase hervorgehoben, ohne jedoch Anspruch auf Vollständigkeit zu erheben. Dabei gilt es zu beachten, dass insbesondere die Phasen A- Architekturvision (siehe Abbildung 5: Phase A: Architecture Vision) und B-Geschäftsarchitektur (siehe Abbildung 6: Phase B: Business Architecture) für die Entwicklung der Architekturfunktion massgebend sind. Die restlichen Phasen werden zwar auch durchlaufen, spielen aber für den Aufbau der Architekturfunktion eine untergeordnete Rolle. 15 Vgl. The Open Group (2011): 46. Establishing an Architecture Capability Overview. URL: ( ) 16 Vgl. Andrew Josey et al. (2010): TOGAF TM Version 9 - Ein Pocket Guide, S 152. Architecture Capability Framework,

11 3.1.1 Phase A. Architekturvision (Architecture Vision) Im Kontext der Entwicklung von Architekturfähigkeit ist das Ziel dieser Phase, sich mit der Vision, den Stakeholdern und den Prinzipien der Architekturfähigkeit auseinanderzusetzen. Projekt gründen: Definieren, welche Stakeholder einbezogen werden. Dabei sollen sowohl Stakeholder angesprochen werden, welche bei der Entwicklung der Architekturfähigkeit mitwirken, als auch die Kunden, die von den Lieferobjekten profitieren. Identifizieren der Business Anforderungen und der Architekturvision: : Erstellen der ersten High-Level- Grundanforderungen aus Sicht des Business als auch aus Technologiesicht. Umfang definieren: Erstellen eines ersten High- Level-Projektplans. Abbildung 5: Phase A: Architecture Vision 17 Einschränkungen definieren: Organisationsweite Einschränkungen festhalten, die auf die Architekturfunktion Einfluss haben Phase B: Geschäftsarchitektur (Business Architecture) In dieser Phase soll die Business Architektur erstellt, oder falls bereits vorhanden, verfeinert werden. Dabei sind folgende Schlüsselbereiche im Fokus: Architekturontologie erstellen: Begriffe und deren Definition erstellen, damit innerhalb der Organisation ein einheitliches Verständnis dieser Begriffe herrscht. Architekturprozess definieren: Als Kernstück des Architekturprozesses muss definiert werden, wie die ADM aussehen soll, damit die organisatorischen Anforderungen optimal abgedeckt werden können. Unterschiedliche Architektursichtpunkte auflisten: Damit erkennbar wird, welche Bedürfnisse berücksichtig werden müssen. Dabei wird auf die Stakeholderliste aus Phase A zurückgegriffen. Definieren des Architekturframeworks: Entscheiden, welche unterschiedlichen Architekturergebnisse durch die Architekturfunktion erstellt werden und wie deren Beziehungen aussehen. 19 Abbildung 6: Phase B: Business Architecture The Open Group (2011): 7. Phase A: Architecture Vision. URL: doc/m/chap07.html ( ) 18 Vgl. The Open Group (2011): 46. Establishing an Architecture Capability Phase A: Architecture Vision. URL: ( ) 19 Vgl. The Open Group (2011): 46. Establishing an Architecture Capability Phase B: Business Architecture. URL: ( ) 20 The Open Group (2011): 8. Phase B: Business Architecture. URL doc/m/chap08.html ( ) Architecture Capability Framework,

12 3.1.3 Phase C bis H Auch die restlichen Phasen der ADM werden beim Etablieren der Architekturfunktion durchlaufen. Sie sind jedoch in diesem Kontext nicht ganz so zentral wie die beiden ersten Phasen und werden deshalb in diesem Kapitel zusammengefasst. Phase C: Informationssystemarchitekturen (Application Architecture) In dieser Phase werden die Funktionalitäten definiert, die notwendig sind um die Architekturergebnisse zu erstellen, veröffentlichen und zu steuern. Unter anderem sollte der Fokus dabei auf die Werkzeuge gelegt werden, die zum Erstellen der Ergebnisse benötigt werden. Phase D: Technologiearchitektur (Technology Architecture) In der Phase Technologiearchitektur soll die Infrastruktur des Informationssystems definiert werden, welches benötigt wird, um die Architekturfunktion zu unterstützen. Phase E: Chance und Lösungen (Opportunities & Solutions) Der Aufbau einer Architekturfunktion erfordert einen organisatorischen Wandel. Also muss definiert werden wie die Organisationsstruktur neu aussehen soll und wie dies erreicht werden kann. Phase F: Migrationsplanung (Migration Planung) Die Anpassung des Architekturprozesses wird sehr grosse Auswirkungen auf die Architekturfunktion einer Organisation haben. Deshalb muss geklärt sein, wie die Anpassungen erfolgen und welche Veränderungen dadurch für die Stakeholder entstehen. Phase G: Steuerung der Implementierung (Implementation Governance) Die sich verändernde Architekturfunktion bringt auch Veränderungen in der Organisation mit sich. Dies können grosse Herausforderungen sein und sollen durch geeignete Techniken im Bereich Organisation-Change bewältigt werden. Phase H: Management der Architekturveränderung (Architecture Change Management) Alle Änderungen der Architekturfunktion sollen in dieser Phase adressiert und verwaltet werden. Ein entsprechender Change kann beispielsweise auch zu einem Architekturergebnis führen Vgl. The Open Group (2011): 46. Establishing an Architecture Capability Phase C: Application Architecture ff. URL: ( ) Architecture Capability Framework,

13 3.2 Architektur-Governance Wie bereits im vorangegangenen Kapitel erwähnt wurde, ist, die Architekturorganisation ein wichtiges Element. Aus diesem Grund beschreibt das Architecture Capability Framework ein Regelwerk und Richtlinien zur Architektur-Steuerung. Die Architektur-Governance ist die Architekturorganisation, welche anhand des Frameworks die Steuerung, Kontrolle und Verwaltung von Architekturen in der Organisation übernimmt. Dazu gehören unter anderem folgende Aufgaben: Implementierung eines Steuerungssystems, damit sämtliche Architekturaktivitäten überwacht werden können. Damit soll eine effektive Einführung und Weiterentwicklung der Architekturen sichergestellt werden. Sicherstellen der Compliance mit internen oder externen Standards oder regulatorischen Vorgaben. Prozessentwicklung, damit die vorangegangenen Punkte sauber realisiert werden können. Entscheidungsstrukturen erstellen und dokumentieren, die einen Einfluss auf die Unternehmensarchitektur haben. Ein Kommunikationsverfahren entwickeln, mit welchem die Rechenschaftspflicht gegenüber einer klar definierten Stakeholder-Gesellschaft sichergestellt werden kann. Dies können sowohl externe als auch interne Stakeholder sein. Damit die Architekturorganisation diese Aufgaben korrekt ausführt und definierte Prinzipien einhält, benötigt es ein Entscheidungsgremium, das Architektur-Board (siehe Kapitel 3.3) Architektur-Board TOGAF bietet einen Vielzahl Richtlinien für den Aufbau und Betrieb eines Architektur-Boards. Unter anderem auch ein Framework zur Entscheidungsfindung. Das für betriebliche Aspekte zuständige Architekturboard muss in Konfliktsituationen Entscheidungen treffen und anschliessend die Verantwortung dafür übernehmen. Damit solche Entscheidungen eine möglichst hohe Akzeptanz erhalten, ist es von zentraler Bedeutung, dass alle wichtigen Architektur- Stakeholder im Board vertreten sind. Unter anderem für folgende Aspekte trägt das Architekturboard die Verantwortung und Rechenschaftspflicht: Konsistenz zwischen untergeordneten Architekturen Identifizieren wiederverwendbaren Komponenten Durchsetzung der Architektur- Compliance Zusätzlich ist das Architekturboard für operative Aspekte wie beispielsweise die Steuerung und die Überwachung von Architekturverträgen verantwortlich Vgl. Andrew Josey et al. (2010): TOGAF TM Version 9 - Ein Pocket Guide, S Vgl. Andrew Josey et al. (2010): TOGAF TM Version 9 - Ein Pocket Guide, S Architecture Capability Framework,

14 3.4 Architektur-Compliance Um die Compliance der Projekte mit der Architektur sicherzustellen, umfasst das Architecture Capability Framework ein Set von Prozessen, Richtlinien und eine Checkliste. Darin enthalten ist eine Bewertung der Auswirkungen aus Sicht der Projekte und der Prozess für das Architecture Compliance Review (siehe Abbildung 7: Prozess für Architecture Compliance Review). Abbildung 7: Prozess für Architecture Compliance Review Framework für Architektur-Fertigkeiten Damit Unternehmensarchitekten richtig arbeiten können, braucht es eine genaue Klassifizierung ihrer Fertigkeiten, Rollen und Erfahrungen. Es stellt ein häufiges Problem dar, dass der Begriff "Unternehmensarchitekt" nicht klar definiert ist. Dieses fehlende gemeinsame Verständnis führt oft zu Missverständnisse und Unklarheiten in der Kommunikation. TOGAF versucht dieser Problematik mit dem Framework für Architekturfertigkeiten rfertigkeiten zu begegnen, indem Definitionen von Architekturfertigkeiten und Qualifikationsebenen für die unterschiedlichen Architektur-Rollen angegeben werden The Open Group (2011): 48.4 Architecture Compliance Review Process. URL: ( ) 25 Vgl. Andrew Josey et al. (2010): TOGAF TM Version 9 - Ein Pocket Guide, S 158. Architecture Capability Framework,

15 4 Schlussfolgerungen/Fazit Wie zu Beginn dieser Arbeit erwähnt, ist es schwierig in einer komplexen Systemlandschaft erfolgreich Architektur zu betreiben. Insbesondere weil Architektur bereichs- oder abteilungsübergreifend erfolgen muss, funktioniert dies häufig nur über das Topdown Prinzip. TOGAF bietet sicher das Werkzeug um auch schwierige Systemlandschaften in einem komplexen Umfeld abzubilden und obwohl TOGAF sehr umfangreich ist, erachte ich die die Dokumentation als gut strukturiert und verständlich. Zudem bietet TOGAF Standards und Richtlinien an, die einen erfolgreichen Architekturaufbau ermöglichen. Die Architekturfunktion aufzubauen, sehe ich als sehr grosse Herausforderung. Meiner Meinung nach ist es nur mit viel Erfahrung möglich, zu bestimmen, welche Komponenten in der jeweiligen Situation notwendig sind und welche nicht mitberücksichtigt werden müssen. Eine zusätzliche Schwierigkeit sehe ich in der Adaption von TOGAF auf unterschiedliche Unternehmensgrössen. Auch dieser Punkt ist meiner Meinung nach nur mit viel Erfahrung erfolgreich zu bewältigen. Leider fehlen in der Literatur die Erfahrungsberichte, wie der Aufbau einer Architekturfunktion erfolgreich funktioniert. Ich vermute zwar, dass diese Informationen auf irgend eine Art und Weise wieder in TOGAF einfliessen, trotzdem wäre es meiner Meinung nach wünschenswert, wenn solche praktische Erfahrungswerte offen gelegt würden. Ich bin überzeugt, dass von diesem Wissen viele Unternehmen und Organisationen profitieren könnten. Architecture Capability Framework,

16 5 Abbildungsverzeichnis Abbildung 1: Struktur von TOGAF 6 Abbildung 2: Architekturentwicklungszyklus 7 Abbildung 3: Enterprise Continuum 8 Abbildung 4: Ausgeprägte Architecture Capability 9 Abbildung 5: Phase A: Architecture Vision 11 Abbildung 6: Phase B: Business Architecture 11 Abbildung 7: Prozess für Architecture Compliance Review 14 Titelbild: Complex Systems have simple roots ( URL: ( ) 6 Glossar Legacy - Applikation Eine etablierte, historisch gewachsene Anwendung im Bereich Unternehmenssoftware 7 7 Literaturverzeichnis TOGAFTM Version 9 - Ein Pocket Guide Andrew Josey et al., TOGAFTM Version 9 - Ein Pocket Guide, Van Haren Publishing, 1.Ausgabe, Juni 2010: 7 The Open Group TOGAF (Zuletzt besucht am ) 9 Architecture Capability Framework,

17 8 Selbständigkeitserklärung Ich bestätige, dass ich die vorliegende Arbeit selbstständig und ohne Benutzung anderer als der im Literaturverzeichnis angegebenen Quellen und Hilfsmittel angefertigt habe. Sämtliche Textstellen, die nicht von mir stammen, sind als Zitate gekennzeichnet und mit dem genauen Hinweis auf ihre Herkunft versehen. Ort, Datum: Bern, Unterschrift: Architecture Capability Framework,