In den ersten drei Teilen dieser Serie zu Enterprise Architecture Management Frameworks habe ich zentrale Begriffe definiert, ein bisschen Historisches erzählt und Meta-EAFs diskuitiert. Endlich ist es also soweit, wir widmen uns hier dem ersten richtigen EAF.

TOGAF ist für jeden online frei zugänglich. Es gibt auch ein PDF, das ca. 700 Seiten lang ist. Ich habe mich sowohl durch Version 9 als auch das Update Version 9.1 durchgearbeitet. Die Lektüre ist spannend, wenn auch nicht so wie ein Krimi … Mit diesem Beitrag versuche ich mich also daran, Ihnen einen Überblick über TOGAF zu geben.

TOGAF: The Open Group Architecture Framework

Die Open Group, eine Vereinigung von aktuell weltweit über vierhundert Firmen, organisiert ihre inhaltliche Arbeit in unterschiedlichen Foren. Das Architecture Forum verantwortet The Open Group Architecture Framework – TOGAF, das seit Ende 2011 in der aktuellen Version 9.1 vorliegt ([TOG11b]). Die erste Version basierte 1995 auf dem Technical Architecture Framework for Information Management (TAFIM) des US amerikanischen Verteidigungsministeriums und ist ebenfalls Vorfahre des bekannten Department of Defense Architecture Framework (DoDAF, [Sch04b]).

TOGAF ist der de facto Standard

In den letzten Jahren hat sich TOGAF neben dem ersten Framework für Enterprise Architecture Management, dem Zachman-Framework, zum in der Literatur am meistgenannten EAF entwickelt ([LJJ+06, LM11]). In Bezug auf die Verbreitung in der Praxis hat TOGAF das Zachman-Framework bereits überholt ([Roh08, Abr13]) und wird als de facto Standard bezeichnet ([BBDF+12]). Die Architekturunterteilung (s.u.) von TOGAF in Geschäftsprozesse, Applikationen, Daten und Infrastruktur wird bereits seit einigen Jahren, z.B. von [LRR03], als allgemein akzeptiert bezeichnet, wobei auch Unterteilungsalternativen bestehen.

TOGAF beschreibt ein EAF als eine Menge von Strukturen, die für die Entwicklung verschiedener Architekturen genutzt werden können. Ein EAF sollte eine Entwurfsmethode enthalten, mit der ein Zielzustand des Unternehmens definiert werden kann. Dabei sollen Building Blocks verwendet werden und diese explizit miteinander in Verbindung gesetzt werden. Darüber hinaus sollten ein Glossar sowie Techniken und Werkzeuge enthalten sein. Auch sollen Standards und Produkte empfohlen werden, die für die Umsetzung der Building Blocks verwendet werden können.

TOGAF ist in neun Teile strukturiert, wovon der erste Teil neben einem Überblick über Inhalte vor allem Definitionen der zentralen Begriffe enthält. Weitere Definitionen finden sich im Anhang von TOGAF.

Archtitecture Development Method

Der zweite Teil enthält die Archtitecture Development Method (ADM), die im Bild dargestellt ist.

Die ADM definiert ein phasenbasiertes Vorgehen, um eine EA schrittweise zu entwickeln. Dazu werden zunächst Bedürfnisse des Geschäfts adressiert und danach die IT-Planung begonnen. Das Geschäft als Treiber und Ausgangspunkt der Betrachtungen zu nehmen, hat sich als erfolgreiches Muster erwiesen ([SHL09]). Unterstützendes Material, wie Richtlinien und von der ADM genutzte Techniken,
sind im dritten Teil zusammengefasst.

Content Framework

Teil vier umfasst das Content Framework. Dessen wesentliche Bestandteile sind das Metamodell, das Entitäten und Relationen zur Modellierung einer EA bereitstellt, sowie die Beschreibungen der Ergebnisdokumente und Artefakte, die von der ADM erzeugt werden.

Enterprise Continuum

Mit dem Enterprise Continuum und zugehörigen Werkzeugen wird im fünften Teil ein Repository vorgestellt, das alle relevanten Informationen strukturiert speichert. Dazu gehören unter anderem Modelle, Architekturmuster und Architekturbeschreibungen, übliche Standards und genutzte Building Blocks.

Referenzmodelle

Zwei Referenzmodelle beanspruchen den sechsten Teil von TOGAF. Zum einen das Foundation Architecture: Technical Reference Model (TRM) und zum anderen das Integrated Information Infrastructure Reference Model (III-RM).

Architecture Capability Framework

Um EAM als Aktivität (siehe Teil drei der Enterprise Architecture Management Definition) im Unternehmen umsetzen zu können, sind bestimmte Anforderungen an die Organisationsform, Prozesse, Fähigkeiten, Rollen und Verantwortlichkeiten zu erfüllen. Diese werden letztlich im siebten Teil, im Architecture Capability Framework, diskutiert.

Die Phasen der ADM

Das Kernelement von TOGAF bildet die ADM, deren Phasen im Folgenden überblicksartig vorgestellt werden. Den Einstieg in einen ADM-Zyklus bildet die Vorbereitungsphase, in der eine Bestandsaufnahme der aktuellen Fähigkeiten des Unternehmens erfolgt und die Rahmenbedingungen für die folgenden Phasen gesetzt werden, beispielsweise in Form von Schlüsseltreibern, Architekturprinzipien
und zu nutzenden Werkzeugen.

Phase A sorgt zunächst für den Aufbau einer Infrastruktur für die Architekturarbeit (z.B. Personal, Arbeitsplätze, etc.). Es wird der Umfang (scope) der Architekturarbeit festgelegt und eine high-level Vision der Ziele formuliert, die mit ihr zu erreichen sind. Dafür werden die relevanten Stakeholder identifiziert, deren Concerns aufgenommen und Kennzahlen definiert, mit denen die Zielerreichung gemessen werden soll. Ein iteratives Vorgehen in den ersten beiden Phasen ist möglich.

Phase B erfasst den Ist-Zustand der Geschäftsarchitektur, die unter anderem die Aufbauorganisation mit ihren Standorten und die Geschäftsprozesse (GP) umfasst. Nachdem der Soll-Zustand der Geschäftsarchitektur definiert wurde, werden die Unterschiede (Gaps) zwischen Ist und Soll identifiziert. Die notwendigen Schritte zur Beseitigung der Gaps werden in Form einer Roadmap skizziert, die in den folgenden Phasen verfeinert wird.

Phase C wird in die Schritte Data Architecture und Application Architecture geteilt. Sowohl für die Daten als auch für die Anwendungen werden der jeweilige Ist-Zustand erfasst, ein Soll-Zustand definiert und Gaps identifiziert. Die Roadmap wird mit den Informationen aus dieser Phase ergänzt. Die beiden Teilphasen können iterativ durchlaufen werden.

Phase D geht wie die vorherigen beiden Phasen vor. Hier liegt der Fokus auf den technischen Systemen, die die Softwaresysteme, Daten und letztlich die Prozesse unterstützen. Speziell für die wiederkehrende und für Planungszwecke zentrale Aufgabe der Gap-Analyse eignen sich spezielle Informationsmodelle und Systeme, wie sie in [GP10, PSS09, Sec09] beschrieben werden.

Phase E erstellt die erste vollständige Version der Roadmap und leitet aus dieser Arbeitspakete ab, die in vorläufige Projekte, Programme oder Portfolios zusammengefasst werden. Der in den vorherigen Phasen definierte Zielzustand kann über in dieser Phase definierte Zwischenschritte, so genannte Transitionsarchitekturen, erreicht werden.

Phase F erarbeitet aufbauend auf den Ergebnissen der vorherigen Phasen einen detaillierten Umsetzungsplan, der von vollständig definierten Projekten erfüllt werden soll. Zwischen den Phasen E und F sind Iterationszyklen vorgesehen, wie auch für die Phasen B bis einschließlich F.

Phase G übernimmt die Kontrollfunktion über die Umsetzungsarbeiten und steuert sie kontinuierlich auf die Zielarchitektur hin. Dazu werden Reviews der laufenden Projekte durchgeführt und Projektergebnisse evaluiert.

Phase H beobachtet Veränderungen und stellt Mittel bereit, um auf Veränderungen zu reagieren. Beispielsweise werden Technologieveränderungen oder Änderungen im Geschäft mit möglichen Auswirkungen auf die jeweiligen Ist-Zustände der Architekturen beobachtet. Auch werden Projekte in den Geschäftsbereichen begleitet, damit die Potenziale der Architekturveränderungen der vorherigen Phasen gehoben werden können. Diese Phase kann iterativ mit Phase G ausgeführt werden und einen neuen Durchlauf des gesamten ADM-Zyklus verursachen, wenn festgestellt wird, dass die festgestellten Veränderungen zu große Konsequenzen haben, als das sie parallel zum Tagesgeschäft durchgeführt werden können.

Das Requirements Management schließlich ist mit allen Phasen verbunden, um Anforderungen zu jeder Zeit erfassen zu können. Anforderungen werden kontinuierlich verwaltet, bewertet, priorisiert und an den entsprechenden Stellen in einen ADM-Zyklus zurückgeführt. Dadurch können Iterationen ausgelöst und der gesamte ADM-Zyklus neu angestoßen werden.

Zusammenfassung

Dieser Beitrag hat also in relativer Kürze (das TOGAF-Dokument hat ca. 700 Seiten) das wahrscheinlich wichtigste Framework für Enterprise Architecture Management vorgestellt, das es derzeit gibt.

TOGAF kennt eine ganze Menge von Artefakten, die während der Phasen der ADM erzeugt werden. Beispiele finden sich dafür in einem Dokumen der Open Group, das auch frei zugänglich ist: TOGAF v9 Sample Catalog, Matrices and Diagrams. All den Beispielen gemein ist, dass ich sie persönlich nicht so recht ansprechend finde.

Wenn Sie TOGAF oder ein anderes Framework im Unternehmen nutzen möchten, achten Sie bitte auf eine sinnvolle Unterstützung, um die Daten der Artefakte sinnvoll ablegen und auch wieder nutzen zu können. Der letzte Beitrag dieser Serie wird zusätzlich noch ein paar allgemeine Hinweise enthalten.