Weil die Geschäfte immer komplexer werden, braucht es leistungsfähige IT-Lösungen, die aber ihrerseits auch zunehmend komplexer werden. Dabei den Überblick zu behalten, fällt oft nicht leicht. Der Anspruch einer Enterprise-Architektur ist es, Unternehmen beim initialen Entwurf, der Implementierung und der Weiterentwicklung solcher fachlich und technisch komplexen Lösungen zu unterstützen.

Dafür muss zunächst jedoch der Rahmen richtig abgesteckt werden. Wird die Enterprise Architektur einer Organisation nämlich ganzheitlich betrachtet, umfasst sie ein breiteres Gebiet als nur die Informationstechnologie. Berücksichtigt werden müssen dann auch betriebswirtschaftliche Themen, wie zum Beispiel die strategischen Inhalte und eine daraus abgeleitete fachliche Gestaltung der Organisation.

Die zusammenhängende Beschreibung der unterschiedlichen Bereiche ist nicht einfach zu realisieren. An dieser Stelle kommen Enterprise Architecture Frameworks ins Spiel. Ihr Anspruch ist es dabei zu helfen, eine Organisation von der Strategie, über die betriebswirtschaftliche Beschreibung - zum Beispiel der Geschäftsprozesse - bis zur erforderlichen IT-Unterstützung zu entwerfen, zu dokumentieren und deren Weiterentwicklung zu steuern.

Wie sieht eine Enterprise-Architektur aus?

Bis heute hat sich kein allgemeingültiges Verständnis entwickelt, was eine Enterprise-Architektur im Detail alles beinhaltet. Es existieren Definitionen unterschiedlicher Gremien, wie zum Beispiel:

• dem American National Standards Institute (ANSI),

• dem Institute of Electrical and Electronics Engineers (IEEE),

• dem Zachman Institue for Framwork Architecture oder

• der Open Group.

Grundsätzlich kann für ein Enterprise Architecture Framework angegeben werden, ob es statisch oder dynamisch bzw. generisch oder spezialisiert ist:

• Ein statisches Framework definiert Artefakttypen, die im Rahmen einer Enterprise Architecture zu erfassen sind (zum Beispiel Prozesse, Fachanwendungen, Rollen usw.), enthält aber keine oder nur minimale Vorgaben wie diese zu erheben und zu aktualisieren sind.

• Demgegenüber ist ein Framework dynamisch, wenn es primär ein Vorgehensmodell zur Entwicklung und langfristigen Pflege einer Enterprise-Architektur beschreibt (zum Beispiel sequenzielle Vorgaben zur Erhebung, Dokumentation und Auswertung der Architekturinhalte), aber die Artefakttypen selbst nur am Rand definiert.

• Generische Frameworks unterstützen die Entwicklung einer Enterprise Architecture aus einer allgemeinen und neutralen Perspektive.

• Spezialisierte Frameworks fokussieren auf einen bestimmten thematischen oder fachlichen Bereich.

Enterprise Architecture Frameworks werden oft nach ihrem Schwerpunkt in diesen Dimensionen verortet. Es ist aber wichtig zu beachten, dass die Einordnung meist nur den primären Schwerpunkt des Frameworks darstellt. Zum Beispiel liefert das TOGAF Framework der Open Group, welches als dynamisches und generisches Framework einzuordnen ist, auch in geringem Umfang Inhalte zur Statik. Das Department of Defense Architecture Framework (DoDAF), welches vom US-amerikanischen Militär genutzt wird, fokussiert auf den Verteidigungsbereich und ist primär ein dynamisches und spezialisiertes Framework. Es enthält in Teilen aber auch interessante Informationen für Hersteller von Verteidigungsprodukten.

Das Zachman Framework

Aus der Vielzahl verschiedener Enterprise Architecture Frameworks sticht das Zachman Framework heraus. Oftmals wird es als "Mutter" aller Enterprise Architecture Frameworks bezeichnet, obwohl bereits vor seiner erstmaligen Publizierung im Jahr 1987 Arbeiten zum Thema existierten. Ein Beispiel dafür ist das 1975 von Duane "Dewey" Walker bei IBM entwickelte Business Systems Planning (BSP). Auch wenn der Begriff Enterprise-Architektur damals noch gar nicht etabliert war, enthält das BSP bereits Strukturen, die heute eindeutig der Disziplin zugeordnet werden.

John Zachman arbeitete mit Walker in den 1970er Jahren bei IBM zusammen, weshalb die Ideen zu seinem Framework zumindest als von BSP beeinflusst gelten dürfen. Erwähnung findet das BSP in der Literatur jedoch nur selten. Ganz anders verhält es sich mit dem Zachman Framework. In nahezu jedem Buch über Enterprise-Architekturen findet sich mindestens ein Hinweis auf Zachman. Betrachtet man das Zachman Framework genauer, stellt sich heraus, dass es eigentlich nur einen überschaubaren Umfang hat. Es handelt sich um ein Schema, welches zwei Dimensionen zur Klassifikation von Enterprise-Architekturinhalten kombiniert:

1. Die erste Dimension basiert auf der Annahme, dass eine umfassende Beschreibung einer Architektur Antworten auf die Fragen erfordert: was, wie, wann, wer, wo und warum, um den Gegenstand, der "entworfen" werden soll, ganzheitlich zu erfassen. Erst die Antworten auf diese W-Fragen ermöglichen die Beschreibung eines komplexen Systems.

2. Die zweite Dimension leitet sich aus der Annahme ab, dass zur Beschreibung eines komplexen Systems eine tiefergehende Detaillierung als Hierarchie aufgebaut werden muss: Ausgehend von einer übergreifenden Perspektive, die den gesamten Kontext des zu entwerfenden Systems in den Blick nimmt, über mehrere Ebenen bis zum realen instanziierten System.

Zachman hat beide Dimensionen in einer Matrix kombiniert und für jeden Schnittpunkt definiert, welche Inhaltstypen darin zu erfassen sind, um zu einer vollständigen Beschreibung einer Architektur zu gelangen. Ausgangspunkt war Zachmans Beobachtung von Ähnlichkeiten architektonischer Beschreibungen. Für ihn bestehen Analogien zwischen dem Entwurf komplexer technischer Produkte, einschließlich dem Entwurf von Informationssystemen, die verallgemeinert werden können. Zachman liefert aber keine Vorgaben zu Notationen, zur Abbildung der Inhalte oder wie die Artefakte der Matrix im Detail zu beschreiben sind.

Einfach und logisch ...

Das Framework wird dennoch häufig erwähnt, weil es auf den ersten Blick eine einfache und logische Struktur von Architekturzusammenhängen abbildet. Es ist fast so, als wenn es die Entsprechung des anthropischen Prinzips in der Enterprise Architecture wäre. Allgemein besagt das anthropische Prinzip, dass ein System nur deshalb in der vorliegenden Form beobachtbar ist, weil jemand da ist, der es beobachten kann. Gäbe es diese erforderlichen Rahmenbedingungen nicht, die ein System beobachtbar machen, wäre auch niemand da, der es beobachten könnte.

Übertragen auf das Zachman Framework liegt mit dem Rahmenwerk genau die Struktur vor, die erforderlich ist um eine Enterprise-Architektur zu beschreiben. Wäre dem nicht so, würde es auch nicht so oft erwähnt. Das Framework scheint eine Architektur demnach logisch und nachvollziehbar zu strukturieren.

... oder unangemessen und verwirrend

Svyatoslav Kotusev, der an der University of Melbourne zu Enterprise Architecture forscht, kommt zu einer ganz anderen Bewertung: "Als Ergebnis von Zachmans brillanten und beharrlichen Bemühungen entstand eine rein symbolische Taxonomie, die als grundlegend gilt, aber auf unangemessenen und verwirrenden Annahmen basiert, echte EA-Artefakte nicht klassifizieren kann, keine nachgewiesenen Beispiele für eine praktische Anwendung, keine Anwendungsfälle in Organisationen, keine Auswirkungen auf den EA-Praktiker und keinen theoretischen oder praktischen Wert zur Enterprise Architecture liefert".

Dieses vernichtende Urteil ist aber nicht gerechtfertigt. Auch wenn John Zachman es sehr gut versteht, sein Framework zu vermarken, so weist er doch deutlich darauf hin, was das Framework ist und was nicht. Es liefert nach Zachman keine Methodik zur Beschreibung der Implementierung oder Instanziierung der jeweiligen Objekte, sondern nur die Ontologie zur Beschreibung einer Organisation und damit ausschließlich die Struktur, während eine Methodik ein Vorgehensmodell darstellen würde. Es enthält weder Aussagen dazu, wie eine Architektur zu erstellen ist, wie die Inhalte über die verschiedenen Detaillierungsebenen eines Gesamtmodells ausgeglichen werden oder welche Flexibilität erforderlich ist, um aus den einzelnen Zellen der Matrix des Frameworks ein ganzheitliches Modell abzuleiten.

Deshalb ist es auch nicht als umfassendes Enterprise Architecture Framework im engeren Sinn zu betrachten. Es stellt lediglich einen Ordnungsrahmen dar, um Inhaltstypen, die im Zusammenhang mit dem Entwurf einer Enterprise Architecture relevant sind, zu definieren und abzugrenzen. Genau diese Eigenschaft ist der Grund warum es auch noch nach 35 Jahren als Grundlage für die Definition einer Enterprise-Architecture-Ontologie genutzt werden kann.

Enterprise-Architecture-Ontologie auf Basis der Ideen von Zachman

Die von John Zachman eingeführte Matrix, bei der Spalten voneinander abgegrenzte Perspektiven und Zeilen aufeinander aufbauende Detaillierungsniveaus definieren, bildet die Basis der Ontologie. Um den Ansatz für aktuelle Fragen einer Enterprise-Architektur besser nutzbar zu machen, ist die Definition der Spalten und Zeilen aber leicht zu überarbeiten (s. Abbildung 1).

Anstelle der von Zachman aufgeführten Fragen, erfolgt eine Gliederung der Spalten nach den zu dokumentierenden Inhaltstypen. Inhalte werden klarer definiert und reale Modellierungssituationen besser in das Framework übertragen. Betrachtet werden:

• Leistungen

• Domänen

• Systeme

• Geschäftsprozesse

• Organisationsstrukturen

• Informationen

Leistungen beschreiben Ergebnisse einer menschlichen Tätigkeit oder eines technischen Vorgangs. Ausgelöst wird die Erzeugung oder Bereitstellung einer Leistung immer durch den Bedarf eines die Leistung abnehmenden Menschen, einer Organisation oder eines Systems. Domänen definieren Gruppen, in denen Inhalte anderer Perspektiven zusammengefasst werden, die an der Erbringung von Leistungen beteiligt sind.

Systeme beschreiben Komponenten, die genutzt werden um Leistungen zu erbringen. Die Abgrenzung zwischen Domänen und Systemen besteht darin, dass Domänen nur die unter dem gegebenen Kontext sinnvolle Zusammenstellung zur Leistungserbringung enthalten. Systeme hingegen die tatsächlich realisierten beziehungsweise existierenden Strukturen. Beispielsweise würde eine vollständige Umsetzung einer Microservice-Architektur dazu führen, dass die beschriebenen Strukturen von Domänen und Systemen identisch sind.

In der Praxis tritt dieser Fall aber meistens nicht auf, da häufig Altlasten auf fachlicher und technischer Ebene vorhanden sind, die gegebenenfalls zu integrieren sind. Deshalb muss eine Enterprise-Architektur in der Lage sein, diesen Unterschied zu dokumentieren und darauf basierende Vergleiche zu ermöglichen. Systeme beschreiben dabei nicht nur IT-Systeme, sondern sind nach dem systemtheoretischen Ansatz weiter zu fassen. Auch andere technische Strukturen wie zum Beispiel Produktionsmaschinen fallen darunter.

Prozesse beschreiben den sequenziellen Ablauf von aufeinander einwirkenden Vorgängen oder Arbeitsschritten innerhalb eines Systems, die zur Leistungserbringung in Domänen und Systemen ausgeführt werden. Akteure beschreiben die organisatorischen Subjekte, die aktiv Prozesse ausführen können. Informationen beschreiben Wissen, das von einem Akteur in einer konkreten Situation zur Leistungserbringung benötigt wird. Die Zeilen werden nach dem inhaltlichen Detailierungsgrad unterschieden. Dadurch ergibt sich folgende Hierarchie:

• Fachliche Ebene
  -> Kontext
  -> Konzept (externe Perspektive)
  -> Konzept (interne Perspektive)

• Mapping Ebene (fachlich-technische Verbindung)

• Technische Ebene
  -> IT-Entwurf und Dokumentation
  -> Implementierung

Die fachliche Ebene enthält die betriebswirtschaftlichen Artefakte des Gesamtmodells. Unterteilt wird sie in eine Kontext- und jeweils eine externe und interne Konzept-Ebene. Die Kontext-Ebene ermöglicht die übergeordnete Gruppierung der Inhalte jeder Perspektive. Die nachfolgenden Konzept-Ebenen detaillieren die Inhalte der Kontext-Ebene.

• Konzept-Ebene I blickt "nach außen" und beschreibt die externen Zusammenhänge der Inhalte, das heißt eindeutig durch systemtheoretische Grenzen voneinander unterschiedene Inhalte der Perspektiven.

• Konzept-Ebene II blickt "nach innen" und beschreibt die internen Strukturen der Artefakte der Konzept-Ebene I.

Es ist nicht immer leicht, zwischen beiden Ebenen eine klare und über alle Perspektiven balancierte Abgrenzung zu finden. Grundsätzlich führt die Heuristik, dass Inhalte der Konzept-Ebene II in der Regel nicht ohne ein zugeordnetes Artefakt auf der Konzept-Ebene I existieren, zu einer angemessenen Gliederung.

Die technische Ebene beschreibt informationstechnologische Inhalte, welche von den Artefakten der fachlichen Ebenen genutzt werden. Auch diese Ebene wird weiter unterteilt. Unterschieden wird zwischen dem IT-Entwurf, der eine typisierte Beschreibung der jeweils genutzten Artefakte umfasst, und einer Implementierungsebene, die konkrete instanziierte Ausprägungen dokumentiert.

Zwischen der fachlichen und der technischen Ebene befindet sich eine Mapping-Ebene. Sie enthält die Artefakte und Beziehungen zur Verknüpfung der fachlichen und technischen Ebene. Vereinfacht gesagt ist sie der "Klebstoff" zwischen den beiden anderen Ebenen und liefert die Inhalte zum "Business-IT-Alignment".

Die Spalten und Zeilen ergeben eine Matrix aus 36 Feldern (siehe Glossar). Jede Zelle der Matrix kann relevante Inhalte für die Beschreibung einer Enterprise-Architektur enthalten. Dabei ist zu beachten, dass nicht jede Zelle zwingend mit Inhalten zu füllen ist. In jedem Enterprise-Architecture-Projekt müssen relevante Inhalte individuell bestimmt und die Modellierung fokussiert werden.

Nutzen einer Enterprise Architektur Ontologie

Bei dem Aufbau einer Enterprise-Architektur sind verschiedene Punkte von Interesse:

1. Definition und Strukturierung der Inhalte und deren Beziehungen;

2. Festlegung der Notationen zur Dokumentation;

3. Auswahl von Werkzeugen zur Erfassung und Analyse.

Definition und Strukturierung der Inhalte und deren Beziehungen

Die vorliegende Matrix ermöglicht die Abgrenzung von Inhalten im Rahmen eines Enterprise-Architecture-Projektes. Zu jeder Zelle werden die Artefakttypen festgelegt, die im EA-Projekt zu dokumentieren sind. Dabei werden nur die Zellen verwendet, die für das individuelle Projekt einen inhaltlichen Beitrag liefern. Zellen, die im Projektkontext nicht erforderlich sind, bleiben ungenutzt.

Zu den Artefakttypen der ausgewählten Zellen werden anschließend die Beziehungstypen zu anderen Artefakttypen festgelegt. Dabei ist es wichtig zu beachten, Beziehungen zwischen den Artefakttypen verschiedener Perspektiven immer nur auf derselben Ebene zu definieren. Beziehungen zwischen Artefakttypen anderer Ebenen sind im Modell nur innerhalb einer Perspektive aufzubauen. Das Beispiel in Abbildung 2 zeigt die Beziehungen der Mensch-Maschine-Interaktion innerhalb der Mapping-Ebene sowie zu den Sub- und fachlichen Detailprozessen der übergeordneten Konzept-Ebene II und den technischen Prozessen beziehungsweise der Automatisierung der untergeordneten IT-Entwurf-Ebene in der Perspektive Prozesse.

Die Einschränkung, Beziehungen zwischen Ebenen nur in einer Perspektive zu definieren, sorgt dafür, dass das entstehende Modell besser ausbalanciert ist. Die spätere Analyse der Inhalte wird dadurch vereinfacht und Gesamtzusammenhänge übersichtlicher abgebildet. Innerhalb einer Ebene sind darüber hinaus direkte und indirekte Beziehungen zu unterscheiden.

• Eine direkte Beziehung liegt vor, wenn zwei Zellen direkt in Verbindung stehen.

• Eine indirekte Beziehung liegt vor, wenn zwei Zellen nur über mindestens eine weitere Zelle miteinander verknüpft sind.

Aus Sicht der "Mensch-Maschine-Interaktionen" ist dies zum Beispiel die "bilden"-Beziehung zwischen "Fachanwendungen" und "Fachkomponenten". Indirekte Beziehungen können auch zwischen Ebenen einer Perspektive vorliegen, wenn auch in deutlich geringerem Umfang, da sich weiter voneinander entfernte Ebenen oftmals im Detaillierungsgrad unterscheiden.

Festlegung der Notationen zur Dokumentation

Die aufgebaute Ontologie unterstützt im zweiten Schritt die Auswahl geeigneter Notationen zur Dokumentation der Artefakttypen und deren Beziehungen. Zum Beispiel können Inhalte zu "Sub- und Detailprozessen", "Mensch-Maschine-Interaktionen" und "technischen Prozessen und Automatisierungen" mit der OMG Business Process Model and Notation (BPMN) abgebildet werden. Zur Beschreibung von Inhalten zu "Mensch-Maschine-Interaktionen" und deren Beziehungen zu "Fachanwendungen und logischen Schnittstellen" lassen sich die Application Processes, Application Components und Application Interfaces aus dem Application Layer der Open Group ArchiMate Notation kombinieren. Bei der Auswahl sollte immer versucht werden, bereits in der Organisation genutzte Notationen zu verwenden. Vielfach sind durch vorhergehende Projekte bereits Notationen definiert, die sich in die Architektur integrieren lassen.

Auswahl von Werkzeugen zur Erfassung und Analyse

In einem letzten Schritt unterstützt die Enterprise-Architecture-Ontologie die Auswahl geeigneter Werkzeuge, mit denen die projektindividuellen Inhalte am besten erfasst werden können. Häufig werden mehrere Werkzeuge in einem "Best of breed" Ansatz kombiniert, da in aller Regel ein Werkzeug alleine nicht alle Inhalte angemessen abbilden kann.

Fazit: Wichtiger Baustein im Werkzeugkasten

Die vorgestellte Ontologie liefert ein Rahmenwerk, das die Konzeption einer Enterprise-Architektur-Dokumentation von der Struktur bis zu den Werkzeugen unterstützt. Wie auch beim Zachman Framework handelt es sich nicht um ein Vorgehensmodell. Eine Ontologie allein wird daher auch nicht ausreichen, um eine Enterprise Architecture aufzubauen. Notwendig ist sie aber allemal.

Denn selbst in Zeiten von Scrum und Agile benötigt jedes Projekt in der einen oder anderen Form eine gute Dokumentation. Dabei sind immer verschieden detaillierte Ebenen und Perspektiven zu berücksichtigen. Je besser diese aufeinander abgestimmt sind, umso besser wird die Qualität. Die Kritik, dass eine Enterprise-Architecture-Ontologie wie das Zachman Frameworks keinen erklärbaren praktischen Nutzen biete, ist deshalb nicht berechtigt. Vielmehr stellt sie einen wichtigen Baustein im Werkzeugkasten des Enterprise Architekten dar. Nicht mehr, aber auch nicht weniger. (bw/ba)