Zachman Framework

Einleitung

Enterprise Architecture (EA) ist eine Disziplin, die Unternehmensstrukturen und -Workflows definiert, organisiert, standardisiert und dokumentiert. Ziel ist es, effizientere Prozesse zu erstellen und zu verwalten. Enterprise Architecture nimmt eine besondere Rolle ein – als Spezialgebiet, das sich gleichermaßen der IT- und der Geschäftswelt widmet, führt EA abteilungs- und teamübergreifende Standards ein, um Prozesse durch eine intelligente gemeinsame Ressourcennutzung zu optimieren. 

Die Entstehungs- und Entwicklungsgeschichte von Enterprise Architecture brachte mehrere Frameworks mit sich, derer sich Architects bedienen können. Eines dieser Frameworks ist das Zachman-Framework. Alle EA-Frameworks beschreiben eine beispielhafte Taxonomie der verschiedenen „Architekturansichten“, die Architects entwickeln können, und liefern Leitlinien für die Auswahl und Entwicklung ebenjener Ansichten. 

Weitere EA-Frameworks sind TOGAF, FEAF und das Gartner Enterprise Architecture Framework. 

Das Zachman-Framework: Ein Überblick 

Das Zachman-Framework ist ein bekannter Ordnungsrahmen für Enterprise Architecture, das Architekturartefakte (z.B. Designdokumente, Spezifikationen und Modelle) schematisch organisiert. Dieses Framework berücksichtigt sowohl die Artefakt-Ziele (Business Owner und Systementwickler) als auch das zu behandelnde Thema (z.B. Daten und Funktionalität) und schafft Synergien aus diesen beiden Aspekten.

Die früheste Version dieses Frameworks wurde von John Zachman entwickelt, der in den 1980er Jahren das Paper „A Framework for Information Systems Architecture“ veröffentlichte. Im Jahr 1992 schlug Zachman sechs Fokusbereiche vor – Daten, Funktion, Netzwerk, Menschen, Zeit und Motivation – sowie sechs Perspektiven (auch als „Player“ bekannt) – Planer, Owner, Designer, Entwickler, Dienstleister und Unternehmen. 

A Framework for Information Systems Architecture” (1987), der konzeptuelle Vorläufer des Zachman-Frameworks. IBM System Journal: Vol. 26, Nr. 3.

Dies stellte nicht nur die Basis des modernen Zachman-Frameworks dar, sondern war gleichzeitig auch ein Wendepunkt in der Geschichte der Enterprise Architecture, da es eine völlig neue Herangehensweise an diese Disziplin ermöglichte.

Zachman erkannte, dass Informationssysteme eine Komplexität mit sich brachten, die durch eindeutige Klassifizierungen und Schnittstellen abgebildet werden mussten. Es braucht also eine echte Blaupause oder eben „Architektur“ der IT-Komponenten innerhalb eines Unternehmens. Seitdem wurde das Original-Framework kontinuierlich weiterentwickelt. 

Enterprise Architects setzen auf diese und einige andere Frameworks, wenn sie Strategien für die Entwicklung von Informationssystemarchitekturen erarbeiten. 

Ontologie vs. Methodologie 

Das Zachman-Framework ist keine Methodologie und funktioniert daher anders. In der Informationswissenschaft ist die Ontologie eine Methode zur Darstellung der Eigenschaften eines Fachgebiets und ihrer Zusammenhänge. Es handelt sich um einen Prozess, in dem Konzepte und Kategorien definiert werden, die das Thema darstellen.

Das Zachman-Framework ist also eine Struktur, wohingegen eine Methodologie einen Prozess beschreibt. Eine Struktur ist kein Prozess. Eine Struktur legt Definitionen fest – Prozesse sorgen für die Umsetzung. Daher ist das Framework (Ontologie) unvorhersehbar und verändert sich, was wiederum zu unterschiedlichen, nicht reproduzierbaren Ergebnissen führt. Eine Methodologie ist ein Transformationsprozess von einem Zustand in einen anderen. Das Zachman-Framework ist eine Ontologie, was es von anderen EA-Frameworks unterscheidet. 

Elementare Komponenten (Primitives) vs. Verbundkomponenten (Composites) 

An ontology is the classification of the total set of present “primitive” (elemental) components that are important to the existence of an object. A methodology, on the other hand, produces “composite” (compound) implementations of the primitives. Primitives are timeless, whereas composites are temporal. For example, a periodic table of elements is an ontology (primitive), but the chemical process of turning bleach and alkali into saltwater is a process–it uses a defined methodology with a predictable outcome (composite).

Warum Zachman?

Das Zachman-Framework bietet eine neue Perspektive für die Betrachtung und Entwicklung von EA. Es werden viele wichtige Fragen gestellt und beantwortet, etwa das „Was“, „Wie“, „Wann“, „Wer“, „Wo“ und „Warum“. Dadurch können Unternehmen einen umfassenden Überblick über komplexe Idee schaffen, die zur Planung, Implementierung, Verarbeitung und Bewertung der Unternehmensstruktur einer Organisation verwendet werden.

Zachman beabsichtigte, das Framework auf die gesamte Enterprise Architecture auszudehnen und nicht nur auf die Informationsarchitektur zu beschränken.

Zachmans Framework ist als proaktives Business-Tool konzipiert. Es kann für die Modellierung bestehender Funktionen, Elemente, Prozesse und Geschäftsstrukturen verwendet werden.

Im Gegensatz zu TOGAF und anderen bekannten Frameworks, die sich auf eine Reihe von Lebenszyklen oder Schritten stützen, berücksichtigt der ontologische Ansatz von Zachman den Blickpunkt unterschiedlicher Akteure (sog. Player) im Unternehmen, die im Framework abgebildet werden. Dies ermöglicht eine Bewertung der Vollständigkeit von Softwareentwicklungsprozessmodellen im Hinblick auf den Informationsbedarf eines Unternehmens. 

Die Struktur des Zachman-Frameworks 

Das Zachman-Framework besteht aus 36 Kategorien, mit denen fast alle Dinge beschrieben werden können – insbesondere komplexer Dinge wie etwa Industriegüter. Die Struktur des Frameworks besteht aus 36 Kategorien, die in sechs Zeilen und sechs Spalten angeordnet sind und somit eine zweidimensionale Matrix bilden. 

Die fertige Struktur liefert Standpunkte und Perspektiven von jedem „Player“, der am Entwicklungsprozess des Systems beteiligt ist. So bietet das Framework einen umfassenden Überblick für jeden Player, der mit ihm arbeitet. 

Spalten

Die Spalten des Zachman-Frameworks stellen in der Regel Fragen dar, auf die Unternehmen eine Antwort suchen. Dazu zählen die oben bereits erwähnten W-Fragen. 

• Was – Was sind die Objekte? Welche Daten müssen untersucht werden?
• Wie – Wie funktioniert es? Was sind die Geschäftsprozesse?
• Wo – Wo können die Geschäftsvorgänge gefunden werden?
• Wann – Wann müssen diese Prozesse durchgeführt werden? Wie häufig, etc.?
• Warum – Warum wurde sich für diesen Weg/diese Lösung entschieden? Was sind die Prozesse und Gründe, um zur Lösung zu gelangen? 

Zeilen

Die sechs Zeilen hingegen stehen für die verschiedenen Standpunkte oder Perspektiven der „Player“ (Akteure). Dies können alle Personen innerhalb eines Unternehmens sein, einschließlich Planer, Owner, Designer, Entwickler, Dienstleister usw. Die Perspektiven können aber auch als Standpunkte dargestellt werden: Kontext des Anwendungsbereichs, Geschäftskonzepte, Systemlogik, Technologie, usw.  

• Perspektive des Planers: Kontext des Anwendungsbereichs – Definition des Geschäftszwecks sowie der Geschäftsstrategie.
• Perspektive des Owners: Geschäftskonzept: Dieser Blickwinkel definiert sich durch Personen, die ein Unternehmen leiten und eine Beschreibung der wichtigsten Leitlinien auf hoher Ebene in Übereinstimmung mit den in den Spalten gestellten Fragen liefern.
• Perspektive des Designers: Systemlogik – Hier wird festgelegt, wie das System und die Prozesse die IT-Anforderungen des Unternehmens erfüllen.
• Perspektive des Entwicklers: Technologie – Hier werden die Produktionseinschränkungen während der Systemimplementierung berücksichtigt.
• Perspektive des Dienstleisters: Komponentenzusammensetzung – Hier werden die implementierungsspezifischen Details der einzelnen Komponenten des Systems beschrieben.
• Perspektive des Benutzers: Betriebsklassen – Wie das System in seiner Betriebsumgebung funktionieren wird. 

Regeln

Zachman schlug sieben Grundregeln für sein Framework vor. Diese Regeln helfen Architects und IT-Managern bei der effizienten Nutzung des Tools. 

• Regel 1: Es ist wichtig, keine weiteren Spalten oder Zeilen zum Framework hinzuzufügen. Wenn Sie die Wie-Fragen beantworten können, finden Sie auch Antworten auf alle anderen Fragen des Objekts. Das Hinzufügen von Spalten oder Zeilen würde das Klassifikationsschema in ein Ungleichgewicht bringen.  
• Regel 2: Jede Spalte verfügt über ein einfaches generisches Modell und kann ihr eigenes Metamodell innerhalb dieser Spalte haben. 
• Regel 3: Das spezifische Modell für eine bestimmte Zelle muss an die Einschränkungen, die Semantik, das Vokabular, die Begriffe und die Fakten aus der Perspektive der Zeile angepasst werden. Jede Zelle spezialisiert sich auf das generische Modell ihrer Spalte. 
• Regel 4: Das Grundmodell jeder Spalte muss einzigartig sein. Es darf sich nicht mit den Daten einer anderen Spalte überschneiden oder diese wiederholen.  
• Regel 5: Erstellen Sie keine diagonalen Beziehungen zwischen Zellen. Die Spalten können in beliebiger Reihenfolge angeordnet werden, sollten aber von oben nach unten geordnet werden, beginnend mit der wichtigsten Kategorie. Die Matrix soll auf diese Weise klare Antworten auf komplexe Fragen liefern und ist auch so konzipiert - es ist nicht von Vorteil, diagonale Beziehungen zwischen den Zellen herzustellen. 
• Regel 6: Ändern Sie nicht die Namen der Zeilen und Spalten, da dies zu Verwirrung und Missverständnissen unter den Stakeholdern führen würde. 
• Regel 7: Die Logik ist generisch und rekursiv, d. h. sie kann zur Klassifizierung oder Analyse von allem verwendet werden, was mit der Enterprise Architecture zu tun hat. 

Zachman vs. TOGAF

Während Zachman einen agilen und flexiblen EA-Ansatz bietet, wird TOGAF (The Open Group Architecture Framework) im Prinzip als Standardframework der Branche angesehen. Dieses Framework liefert einen methodologischen Ansatz an das EA-Design und erfreut sich unter Architects größerer Beliebtheit.

Das TOGAF-Framework umfasst eine Reihe von praxisorientierten Schritten, auch bekannt als „Architecture Development Method“ (ADM). ADM stellt zwar eine generische Methode dar, kann jedoch an den Enterprise Architecture-Prozess angepasst werden Das TOGAF-ADM-Framework arbeitet mit Lebenszyklen austauschbarer Schritte zur Implementierung von Entscheidungen sowie zur Entwicklung der gewünschten Modelle.

Im Gegensatz zu TOGAF ist das Zachman-Framework, wie bereits beschrieben, eine Ontologie, die sich unterschiedlicher Unternehmensperspektiven annimmt, um komplexe Komponenten des gesamten Unternehmenssystems abzubilden, zu definieren und zu planen.

Ihr EA-Ansatz bestimmt, ob Sie sich für Zachman oder für TOGAF entscheiden werden. Dennoch ergänzen sich die beiden Frameworks. TOGAF beschriebt die detaillierten Prozesse zur Erstellung einer Enterprise Architecture, wohingegen das Zachman-Framework die Artefakte kategorisiert. 

Zachman-Zertifizierungen

Enterprise Architects, die sich in ihrem Feld weiterentwickeln möchten, sollten das „The Zachman Certified – Enterprise Architect Program“ in Betracht ziehen. Dieses Zertifikat liefert ein grundlegendes Verständnis sowie die praktische Anwendung des Zachman-Frameworks zur Entwicklung der theoretischen und praktischen Kompetenzen, die für die Gestaltung von Unternehmensimplementierungen wichtig sind. 

Das Zachman Certified - Enterprise Architecture Program besteht aus 4 Stufen: 

• Enterprise Architect Associate (Level 1)
• Enterprise Architect Practitioner (Level 2) 
• Enterprise Architect Professional (Level 3) 
• Enterprise Architect Educator (Level 4)

Diese Zertifizierung bietet sowohl Engineers als auch Enterprise Architects viele Vorteile. Das Programm ist berufsrelevant und anerkannt. Es kann neue Karrierewege eröffnen und den eigenen Marktwert steigern. Einige Stellen erfordern nicht nur eine Zachman-Zertifizierung, sondern auch eine TOGAF-Zertifizierung oder ähnliches – so können die Bewerber beweisen, dass sie die Rolle des Architects aus unterschiedlichen, dynamischen Blickwinkeln betrachten und ausfüllen können. 

Fazit

Auch wenn das Zachman-Framework in den Jahren etwas von seiner Popularität eingebüßt hat, ist es immer noch ein wichtiges Tool innerhalb der EA-Disziplin – auch für moderne Unternehmen. Als Ontologie zur Abbildung komplexer Informationssysteme und Geschäftsprozesse wird das Zachman-Framework häufig gemeinsam mit anderen bekannten EA-Frameworks verwendet, um Artefakte zu kategorisieren und Deliverables festzulegen.

So können Architects ihrer Arbeit Momentum verschaffen und agilere sowie anpassungsfähigere Methoden in ihrer Herangehensweise an die Disziplin entwickeln.