Lesezeit ca. 7 Min.

Zachman Framework: Rahmen für den Bau einer Enterprise Architektur


Logo von Computerwoche
Computerwoche - epaper ⋅ Ausgabe 43/2021 vom 18.10.2021

Sie möchten tiefer in die Themen Enterprise Architecture und Prozessmodellierung einsteigen? Auf der Website der COMPUTERWOCHE finden Sie mehr dazu:

BPM richtig strukturieren: Zentrale Bausteine des Prozessmanagements www.cowo.de/3547412

BPM-, EAM- und IT-Modell: Im Dreiklang zur integrierten Modellierung www.cowo.de/3548137

End-to-End-Modellierung im BPM: Wie ein stabiles Prozessmodell entsteht www.cowo.de/3545970

Weil die Geschäfte immer komplexer werden, braucht es leistungsfähige IT-Lösungen, die aber ihrerseits auch komplexer werden. Dabei den Überblick zu behalten, fällt oft nicht leicht. Der Anspruch einer Enterprise Architektur ist es, Unternehmen beim 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 ...

Artikelbild für den Artikel "Zachman Framework: Rahmen für den Bau einer Enterprise Architektur" aus der Ausgabe 43/2021 von Computerwoche. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: Computerwoche, Ausgabe 43/2021

Weiterlesen
epaper-Einzelheft 10,99€
NEWS Jetzt gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Computerwoche. Alle Rechte vorbehalten.
Lesen Sie jetzt diesen Artikel und viele weitere spannende Reportagen, Interviews, Hintergrundberichte, Kommentare und mehr aus über 1000 Magazinen und Zeitungen. Mit der Zeitschriften-Flatrate NEWS von United Kiosk können Sie nicht nur in den aktuellen Ausgaben, sondern auch in Sonderheften und im umfassenden Archiv der Titel stöbern und nach Ihren Themen und Interessensgebieten suchen. Neben der großen Auswahl und dem einfachen Zugriff auf das aktuelle Wissen der Welt profitieren Sie unter anderem von diesen fünf Vorteilen:

  • Schwerpunkt auf deutschsprachige Magazine
  • Papier sparen & Umwelt schonen
  • Nur bei uns: Leselisten (wie Playlists)
  • Zertifizierte Sicherheit
  • Freundlicher Service
Erfahren Sie hier mehr über United Kiosk NEWS.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 43/2021 von Wenn Manager den Cloud-Trend bremsen. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Wenn Manager den Cloud-Trend bremsen
Titelbild der Ausgabe 43/2021 von Celonis und Service Now verknüpfen ihre Plattformen. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Celonis und Service Now verknüpfen ihre Plattformen
Titelbild der Ausgabe 43/2021 von Alle elf Sekunden ein Angriff: mehr Ransomware – größere Schäden. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Alle elf Sekunden ein Angriff: mehr Ransomware – größere Schäden
Titelbild der Ausgabe 43/2021 von VMworld 2021: Multicloud ohne Nachteile?. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
VMworld 2021: Multicloud ohne Nachteile?
Mehr Lesetipps
Blättern im Magazin
Im Schattenreich des Darknet blüht der Handel mit Verbotenem
Vorheriger Artikel
Im Schattenreich des Darknet blüht der Handel mit Verbotenem
Gebäudemanagement – eine Spielwiese für Enterprise -Architekten
Nächster Artikel
Gebäudemanagement – eine Spielwiese für Enterprise -Architekten
Mehr Lesetipps

... ganzheitlich betrachtet, müssen neben der IT auch betriebswirtschaftliche Themen wie zum Beispiel die strategischen Inhalte und eine daraus abgeleitete fachliche Gestaltung der Organisation berücksichtigt werden. Dafür kommen Enterprise Architecture Frameworks ins Spiel. Ihr Anspruch ist es, dabei zu helfen, eine Organisation von der Strategie über die betriebswirtschaftliche Beschreibung bis zur erforderlichen IT-Unterstützung zu entwerfen, zu dokumentieren und ihre Weiterentwicklung zu steuern.

Deshalb ist es auch nicht als umfassendes Enterprise Architecture Framework im engeren Sinn zu betrachten. Es stellt lediglich einen Ordnungsrahmen dar, um Inhaltstypen, die für den Entwurf einer Enterprise Architecture relevant sind, zu definieren und abzugrenzen. Das lässt sich als Grundlage für die Definition einer Enterprise Architecture Ontologie nutzen. Die von Zachman eingeführte Matrix, bei der Spalten voneinander abgegrenzte Perspektiven und Zeilen aufeinander aufbauende Detaillierungsniveaus definieren, bildet die Basis. Um den Ansatz für aktuelle Fragen einer Enterprise-Architektur besser nutzbar zu machen, ist die Definition der Spalten und Zeilen aber zu überarbeiten (siehe Abbildung oben).

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 selten 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 Ebenen detaillieren die Inhalte. 

• 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. 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.

Beim Aufbau einer Enterprise-Architektur sind verschiedene Punkte von Interesse:

• Definition und Strukturierung der Inhalte und deren Beziehungen;

• Festlegung der Notationen zur Dokumentation;

• Auswahl von Werkzeugen zur Erfassung und Analyse.

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 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 Perspek tive aufzubauen. Das Beispiel in der Abbildung links 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 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 – aber in geringerem Umfang, da sich weiter voneinander entfernte Ebenen oft im Detaillierungsgrad unterscheiden.

Notationen zur Dokumentation

Die aufgebaute Ontologie unterstützt im zweiten Schritt die Auswahl geeigneter Notationen, um Artefakttypen und deren Beziehungen zu dokumentieren. So lassen sich Inhalte zu „Subund Detailprozessen“, „Mensch-Maschine-Interaktionen“ und „technischen Prozessen und Automatisierungen“ mit der Business Process Model and Notation (BPMN) abbilden. Zur Beschreibung von Inhalten zu „Mensch-Maschine-Interaktionen“ und deren Beziehungen zu „Fachanwendungen und logischen Schnittstellen“ können die Application Processes, Application Components und Application Interfaces aus dem Application Layer der Open Group Archimate Notation kombiniert werden. Bei der Auswahl sollte man immer versuchen, bereits in der Organisation genutzte Notationen zu verwenden. Vielfach sind schon Notationen definiert, die sich integrieren lassen.

Werkzeuge 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 allein 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 Framework 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.