Was ist TOGAF®?

/0 Kommentare/in

TOGAF ist die Abkürzung für „The Open Group Architecture Framework“ und eingetragenes Warenzeichen der „Open Group“.

Es ist eines der bekanntesten und beliebtesten Rahmenwerke unter den ca. 70 verschiedenen Frameworks für Enterprise Architecture.

Der Ursprung geht zurück auf das Technical Architecture Framework for Information Management (TAFIM) genannte Referenzmodell des United States Department of Defence (DoD). Das Bild rechts zeigt den konzeptionellen Aufbau mit den drei Architektur-Domänen Data, Application und Technical Infrastruktur.

TAFIM selbst wurde inspiriert durch einen Artikel von John Zachman im IBM Journal aus dem Jahre 1987, welcher sich mit dem Thema der zunehmenden Komplexität der System-Landschaft und möglicher Lösungen beschäftigte. Das DoD entwickelte TAFIM weiter bis es von einem neuen Modell (C4ISR) abgelöst wurde.

TAFIM wurde von der Open Group übernommen und seit 1995 als TOGAF weiterentwickelt. Die Open Group ist ein Technologie- und Hersteller-neutrales Konsortium, welches gegründet wurde um einen einheitlichen UNIX-Standard bereitzustellen. Die Open Group hat heute mehr als 500 Mitglieder-Organisationen und kümmert sich generell um Standardisierungen in der IT-Industrie.

Laut der Open Group benutzten im Jahre 2016 ca. 80% der weltweit größten (blue chip) Unternehmen sowie 60% der größten 500 US-Unternehmen TOGAF. Im Lauf der Zeit wurden über 50.000 Personen gemäß TOGAF zertifiziert.

Eines der Schlüsselelemente von TOGAF ist die sogenannte „Architecture Development Method“ (ADM). Ein Prozessmodell, welches in seiner Urform bereits in TAFIM zu finden ist.

In der „Preliminary Phase“ werden Vorbereitungen getroffen, um den Ring mit seinen Phasen von A bis H zu durchschreiten. Zu den wichtigsten Tätigkeiten in dieser Phase zählt die Definition der Enterprise, Bereitstellung von Architektur-Prinzipien und -Mustern sowie das Etablieren der Steuerungsfunktionen (Governance) um Standardisierung und Wandel auszubalancieren und das richtige Mass an Administration zu schaffen.

Phase A bis H werden typischerweise während der Erstellung einer Architektur durchlaufen. Dies kann auch in Iterationen oder anderer Reihenfolge geschehen. Dabei gibt TOGAF nicht vor, welche Architektur genau beim Durchlaufen des Rings adressiert wird. Von kleinen Einzellösungen, über komplexe System-Landschaften bis hin zur Konzeption der eignen Architektur-Funktion im Unternehmen, lassen sich alle Formen von Architektur realisieren.

Im Vergleich zu TAFIM hat TOGAF eine Architektur-Domänen hinzugewonnen: Die Business-Architektur. Dies zeigt den Stellenwert der grundlegenden Geschäftsmodelle und Strategien in der moderneren Auslegung der Enterprise Architecture.

Hier eine kurze Übersicht der Phasen der ADM:

  • Preliminary: Hier wird bestimmt welche Fähigkeiten bei der Planung, Implementierung und Evolution von Architekturen das Unternehmen anstrebt und besitzt. Danach werden die fehlenden Fähigkeiten etabliert. Diese Phase muss nicht für jedes Projekt durchlaufen werden aber man kann zurückkehren um Veränderungen in den Architektur-Fähigkeiten vorzunehmen.
  • Architecture Vision: Hier wird die grundlegenden Eigenschaften und der Zweck der Architektur herausgestellt. Unter anderem werden die Voraussetzungen zur Umsetzung und Einführung bereits früh überprüft sowie ein Kommunikationsplan erstellt, damit es zu keinem „Show-Stopper“ kommt.
  • Phase B bis D: Hier wird die Business-, Daten-, Anwendungs- und Technology-Architektur erstellt.
  • Phase E und F: Beschäftigen sich mit der Planung der Umsetzung. Dabei wird versucht die Gesamtarchitektur in eine Roadmap zu zerlegen. Zweck ist es schon früh den größten Nutzen der Architektur zu realisieren und ggf. Anpassungen vorzunehmen.
  • Implementation Governance: Diese Phase verläuft parallel zur Implementierung der Architektur. Aufgabe ist es die Konformität mit der Planung zu wahren sowie schnell auf Planungslücken zu reagieren.
  • Architecture Change Management: Diese Phase verläuft parallel zum Betrieb der Architektur. Aufgabe ist es wichtige Metriken wie Business Value, Stabilität, Performance, usw. zu überwachen sowie auf Veränderungen (z.b. Auslaufen von Plattformen) zu reagieren. Änderungen an der Architektur werden entweder im Rahmen von Wartungsarbeiten (Linien-Organisation) oder durch das erneute Durchlaufen des Rings (Projekt-Organisation) vorgenommen.
  • Requirements Management: Angeordnet im Kern der ADM zeigt sie die Bedeutung des Requirements Managements für alle Phasen der ADM. Hier werden für den gesamten Lebenszyklus der Architektur Anforderungen gesammelt und deren Auswirkung beurteilt.

Um die ADM erfolgreich zu Durchlaufen gibt TOGAF umfangreiche Unterstützung. Das Buch der Open Group für TOGAF 9.1 hat in seiner gedruckten Form über 600 Seiten und gliedert sich in folgende Abschnitte:

  • Einführung: Erklärt die Grundkonzepte, gibt Motivation zum Einsatz von TOGAF und führt die Terminologie ein.
  • ADM: Erläutert die Architecture Development Method
  • Richtlinien & Techniken: Erläutert die Hilfsmittel und Richtlinien, welche bei der ADM zum Einsatz kommen.
  • Architecture Content Framework: Beschreibt welche Architektur-Beschreibungen anfallen und nach welchen Meta-Modell sie miteinander verbunden sind
  • Enterprise Continuum: Befasst sich damit welche Informationen wie abgelegt und kategorisiert werden. Ziel ist eine einfache Struktur zu realisieren, welche die Wiederverwendung fördert.
  • Referenzmodelle: Hier werden Referenzmodelle vorgestellt, welche bei der Konzeption von Anwendungs- und Technologie-Architekturen eingesetzten werden sollen.
  • Architecture Capability Framework: Hier wird beschrieben, wie die Fähigkeit zur Planung, Umsetzung und Steuerung von Architekturen im Unternehmen etabliert wird.

 

Ein wichtiger Schritt in der „Preliminary Phase“ der ADM ist das zuschneiden von TOGAF:

Ohne den Einsatz eines Frameworks wie TOGAF kann es im Unternehmen bei der Architekturplanung zu stilistischen Unterschieden kommen, was den Austausch und die Akzeptanz verringert.

Wer „TOGAF by the book“ betreibt findet seine Bedürfnisse nicht adressiert. Das „Zuviel“ und „Zuwenig“ ist frustrierend und führt zu Enttäuschungen über TOGAF selbst. Weil man sich so leicht verheddern kann, raten wir vom führen schwerer Maschinen ab.

TOGAF ist dann am Besten, wenn man es auf seine Bedürfnisse anpasst und dabei nicht mehr als notwendig benutzt. Wer den Zuschnitt gut hinbekommen hat wird auch bei agilen Bewegungen und glamourösen Auftritten eine gute Figur machen.

 

Wer mehr über TOGAF erfahren möchte, findet hier die HTML Seite der Open Group oder fragt uns einfach!

Einführung in die Enterprise Architecture

/0 Kommentare/in

Eine genaue Definition von Enterprise Architecture (EA), zu Deutsch Unternehmensarchitektur, gibt es nicht. Das ist soweit nichts ungewöhnliches und zeigt, daß es ein größeres Themengebiet ist mit Raum für Interpretation.

Den Versuch alles was EA ausmacht in einem Satz auszudrücken, mündet dabei so:

  • „Die Unternehmensarchitektur beschreibt aus einer ganzheitlichen Sicht, wie die IT mit ihren einzelnen Elementen und Prozessen mit dem Unternehmen verzahnt ist und zwar sowohl in aufbau- wie auch ablauforganisatorischer Sicht.“ – Quelle: Gabler Wirtschaftslexikon
  • „Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes.“ – Quelle: Gartner IT Glossary
  • “By being inclusive with all other management frameworks, EA is a discipline that helps the Enterprise define , develop and exploit the boundaryless information flow […] capabilities in order to achieve the Enterprise’s Strategic Intent.” – Quelle: The Open Group

Wir nehmen uns etwas mehr Zeit und erzählen die Geschichte der Enterprise Architektur von Anfang an. Am Schluss gibt es eine Zusammenfassung in wenigen Worten. Wer sich nicht für Geschichte interessiert, kann also bis zum Ende des Beitrags blättern.

Alles fing 1987 mit einer Publikation von John Zachman im IBM Systems Journal an. In diesem formulierte er die Vision für Enterprise Architecture und adressierte dabei folgende Herausforderungen seiner Zeit:

  • Die zunehmende Komplexität der Systeme und die dadurch steigende Kosten für Planung, Implementierung und Betrieb.
  • Die schlechter werdende Vereinbarkeit von Unternehmenszielen mit der wachsenden System-Landschaft

Dabei legte er den Grundstein für seinen Ordnungsrahmen, dass als „Zachman Framework“ noch heute genutzt wird. Beeinflusst von seinen Ideen, nahm sich das US Verteidigungsministerium des Themas an und schuf 1994 mit TAFIM ein Rahmenwerk, welches 1996 an die Open Group weitergegeben wurde Seither arbeitet die Open Group mit Enterprise Architekten aus der Forschung und Industrie an TOGAF, welches zur Zeit in der Version 9.1 vorliegt.

Wenn Systeme komplizierter werden, benötigen sie mehr Planung!

Im Alltag und für andere Ingenieurs-Disziplinen leuchtet das sofort ein. Um eine Hütte im Schrebergarten zu bauen, braucht man keinen Architekten. Aber es gibt womöglich Vorschriften, wie und wo die Hütte aufgebaut werden darf. Sind die Gebäude größer werden Architekten benötigt, sogar gesetzlich vorgeschrieben.

Auch bei IT-Systemen gilt dieser Grundsatz. Aber ebenfalls das Gegenteil findet Anhänger und wird je nach Jahrzehnt als „Quick & Dirty“ oder „Agil“ bezeichnet. Agilität ist sehr wichtig, aber ab einer gewissen Komplexität kein Ersatz für eine gute Planung und umgekehrt. 

Moderne Ansätze der EA berücksichtigen dies und lassen in ihren iterativen Prozessen genug Platz für Agilität um Planungslücken und den unvorhersehbaren Wandel zu berücksichtigen.

Generell hat die Notwendigkeit zugenommen, schnell auf neue Anforderungen zu reagieren. Weshalb wir den Problemfeldern der EA von 1987 noch einen Punkt hinzufügen müssen:

  • Schnelle Anpassung der Organisation und Systeme durch den Wandel des Kundenverhaltens, gesetzlicher Auflagen und des technologischen Fortschritts.

Die Bedeutung von Enterprise Architecture heute

„Er ist der Messias, ich weiß es genau, denn ich bin schon vielen gefolgt“. Dieses Zitat aus Monty Python’s Film „Das Leben des Brain“ bringt es ziemlich gut auf den Punkt. Oft wird vorschnell das Potential einer neuen Technologie oder neuer Methoden überzogen dargestellt.

Zum Teil geschieht die Übertreibung mit Absicht um gezielt Nachfrage zu generieren.

Gartner hat dafür schon länger den „Hype Cycle“ eingeführt um Orientierung zu geben. Im Verlauf einer Neuerung erklimmt diese zuerst die „Spitze der überzogenen Erwartungen“ und stürzt danach regelrecht in das „Tal der Desillusion“, bevor es schließlich das „Plateau der Produktivität“ erreicht.

Die Enterprise Architecture gilt heute als etabliert und befindet sich auf dem Weg der realen Einschätzung der Möglichkeiten. Viele Organisationen nutzen Frameworks und Tools um ihre Unternehmensarchitekturen zu verwalten sowie Praktiken der EA um die Evolution und den Wandel der Architekturen zu beherrschen und zu steuern.

Es soll nicht unerwähnt bleiben, dass durch die überzogenen Erwartungen am Zenit des Hypes auch viele kritische Stimmen laut wurden, die der EA und deren Praktiken kein gutes Zeugnis ausstellten. Diese Kritik ist richtig und wichtig um die Praktiken der Enterprise Architecture zu verbessern. Die Praktiken der EA zielen darauf die „Fitness“ (fit-for-purpose) einer Architektur sicherzustellen. Dies wird der Enterprise Architecture gelingen, da es noch über viele Jahre nötig sein wird die Problembereiche der Unternehmensarchitektur, wie Komplexität, Business Value und Evolution, zu adressieren und eine „best practice“ zu betreiben. Welches Framework und welches Tool diesen Wandel zum fit-for-purpose für sich selbst hinbekommt bleibt abzuwarten. TOGAF ist allerdings wegen seiner großen und aktiven Community der aussichtsreichste Kandidat.

Der Trend zur Cloud dürfte durchaus stimulierend wirken, schliesslich handelt es sich bei Cloud-Services um die Enterprise Architecture des Cloud-Providers. Der Cloud-Service ist die Erweiterung der organisations-spezischen Architektur eines Unternehmens wie Amazon und Google auf Kundenebene. Es ist somit eine erweiterte Enterprise im Sinne von TOGAF, und zwar der Enterprise von Amazon, Google und Co. Dabei verlieren Unternehmen die Autonomie über die Evolution der Unternehmensarchitektur. Andererseits bieten Cloud-Services die Möglichkeit an der Reife und Effizienz der Enterprise Architecture des Provides zu partizipieren.

Einige Probleme sind aber nicht Ausdruck unreifer Frameworks und Tools, sondern Resultat eines einseitigen Vorgehens der IT-Division im Unternehmen. EA wirkt am besten, wenn es ganzheitlich über die gesamte Organisation praktiziert wird, insbesondere im Verbund mit der Business-Seite. Ein weiteres Problem ist die Tendenz Unerfahrenheit durch ein starkes Festhalten an das Framework oder das Tool zu kompensieren. Hierbei kann es leicht zum Over-Engineering kommen. Charlie Parker, ein bekannter Saxophonist, brachte es für sich auf den Punkt: „Um ein guter Musiker zu sein, musst Du erst alles lernen um es dann wieder zu vergessen!“

In den vergangenen 12 Monaten zeigt das Interesse an Enterprise Architecture (Blau) und TOGAF (Rot) ein stabiles Niveau. Wobei sich mehr als doppelt so viele für die konkrete Praktik TOGAF interessieren als für Enterprise Architecture im Allgemeinen. Dies unterstreicht auch die hohe Zahl, von über 50.000, nach TOGAF zertifizierten Architekten.

Die Weltkarte links zeigt die Google Trends der letzten fünf Jahre für den Suchbegriff „Enterprise Architecture“. In Europe zeigen die Niederlande das größte Interesse an diesem Themen. Deutschland liegt im internationalen Vergleich auf dem neunten Platz. Dies ist nicht notwendigerweise ein Nachteil, wenn man in der Lage ist aus den vorhandenen Erfahrungen zu lernen.

 Zusammenfassung

Enterprise Architecture zielt darauf die Effizienz bei der Erstellung und Steuerung von komplexen System-Landschaften zu erhöhen. Der stete Wandel ist dabei ebenso wichtig wie die Ausrichtung auf den Business Value.

Das Interesse an Praktiken und populären Frameworks hat heute ein stabiles Plateau erreicht. Deutschland hat als EA-Entwicklungsland die Möglichkeit aus den Erfahrungen der Vergangenheit zu profitieren.

Praktiken der Enterprise Architecture sind auch für iterative und agile Entwicklungsprozesse geeignet, verlangen aber ein Mindestmaß an Planung und Steuerung der Architektur-Landschaft einer Organisation.

Cloud-Services sind die offenen Unternehmensarchitekturen der Cloud-Provider. Organisationen, welche diese Nutzen werden ein Teil dieser Unternehmensarchitektur. Gewinnen dabei an Effizienz und verlieren an Einfluss auf die Evolution der Unternehmensarchitektur.

Die Enterprise Architecture ist hier um zu bleiben, in welcher Form auch immer.