4 Frameworks für die Unternehmensarchitektur

Der Begriff eines Frameworks ist erst in der zweiten Hälfte des 20. Jahrhunderts aufgekommen. In diesem Beitrag möchte ich auf der folgenden Definition eines Frameworks aufbauen:

«Ein Framework ist eine dokumentierte bewährte Grundstruktur einer Kategorie gleichartiger Systeme, welche bei deren Entwurf und Evolution als Orientierungshilfe dient.»

Ein Framework soll also seinen Anwender beim initialen Aufbau eines Systems, aber auch bei dessen Weiterentwicklung unterstützen. Im Zusammenhang mit Unternehmensarchitektur ist mit «System»ein Unternehmen gemeint, welches aus Personen besteht, die ein bestimmtes Ziel verfolgen und dabei durch technische Mittel wie z.B. IT-Systeme unterstützt werden. Zentral an einem Framework für Unternehmensarchitektur ist die Anforderung, dass es das Geschäft eines Unternehmens gleichermassen adressieren muss, wie die technischen Hilfsmittel, die es zu dessen Ausübung benötigt.

An dieser Stelle möchte ich vier typische Vertreter solcher Architektur-Frameworks kurz vorstellen.

1 Das Zachman Framework

Eines der ersten und gleichzeitig bekanntesten Frameworks für Unternehmensarchitektur ist das Zachman Framework. Bereits 1987 entwickelte John Zachman die erste Version des Frameworks, welches heute durch eine Matrix aus 6 Kolonnen mal 5 Zeilen dargestellt wird.

Abbildung: Marcel Douwe Dekker based on earlier work of Phogg2 et al. (CC BY-SA 3.0)

Das Zachman Framework ist ein leichtgewichtiger Ordnungsrahmen, mit dem verschiedenste Aspekte eines Unternehmens ganzheitlich unterschieden und beleuchtet werden. Die Kolonnen gliedern die Betrachtung eines Unternehmens in 6 separate Dimensionen:

• Womit arbeitet das Unternehmen?
• Was tut das Unternehmen?
• Wo finden die Tätigkeiten des Unternehmens statt?
• Wer sind die Ausführenden dieser Tätigkeiten?
• Wann werden welche Tätigkeiten ausgeführt?
• Warum werden sie überhaupt, genau so und nicht anders ausgeführt?

Diese 6 Dimensionen werden aus 5 verschiedenen Perspektiven betrachtet, welche verschiedenen Rollen im Unternehmen entsprechen und im Framework als 5 Zeilen dargestellt werden:

• Geschäftsleitung
• Business Analyst
• IT-Analyst
• IT-Designer
• Entwickler

Wichtig zu wissen ist, dass diese 5 Zeilen nicht eine schrittweise Detaillierung darstellen, sondern ganz unterschiedliche Zwecke erfüllen:

Die Zeilen 1 und 2 beschreiben das Geschäft des Unternehmens. Die Zeilen 3 bis 5 beschreiben die Konzeption der IT-Systeme des Unternehmens, welche es zu dessen Geschäftsausübung nutzt. An der Grenze zwischen den Zeilen 2 und 3 findet das Requirements Engineering auf Unternehmensebene statt – eine Aufgabe, die eine absolut zentrale Rolle für das Business-IT-Alignment spielt!

In der Praxis lässt sich das Zachman Framework am besten als Checkliste einsetzen. Einerseits können die 30 Zellen des Frameworks als Fragen aufgefasst werden, ob die jeweilige Dimension (z.B. das “Was”) eines Unternehmens für eine bestimmte Rolle (z.B. für den IT-Analyst) dokumentiert ist und wenn nein, warum nicht. Nicht jede Zelle muss notwendigerweise dokumentiert sein: Besitzt ein Unternehmen beispielsweise lediglich einen einzelnen Standort, so sind nicht alle Zellen der “Wo”-Kolonne erforderlich. Andererseits lässt sich das Zachman Framework auch als Raster für architektonische Vorgaben nutzen: Es kann beispielsweise von Projekten gefordert werden, welche Zellen wie zu dokumentieren sind, um so ein einheitliches Bild der gesamten Unternehmenslandschaft zu erhalten.

2 TOGAF

TOGAF (The Open Group Architecture Framework) ist ein umfassendes Framework für Unternehmensarchitektur, welches seit Mitte der 1990er Jahre von der Open Group (weiter-) entwickelt wird. Kern von TOGAF ist einerseits die Architecture Development Method (ADM), welche die Aufgabe eines Unternehmensarchitekten als kontinuierlichen Evolutionsprozess rund um die zentralen Anforderungen eines Unternehmens an seine IT darstellt.

Der zweite Kernbestandteil von TOGAF ist ein Metamodell, welches die zentralen Elemente, die im Rahmen einer Unternehmensarchitektur zu managen sind sowie ihre Beziehungen untereinander identifiziert. Diese Elemente werden in vier verschiedene Basisarchitekturen unterteilt:

Geschäftsarchitektur: Eine formale Beschreibung von Geschäftszielen, – treibern, -funktionen, -ereignissen und -prozessen, aber auch von Produkten und Services.
Datenarchitektur: Eine formale Beschreibung wichtiger Daten sowie logischen und physischen Containern, in denen diese Daten zusammengefasst sind.
Anwendungsarchitektur: Eine formale Beschreibung der eingesetzten Applikationen auf funktionaler und technischer Ebene sowie der Schnittstellen, die sie untereinander verbinden.
Technologiearchitektur: Eine formale Beschreibung der eingesetzten Technologien und Infrastruktur-Komponenten.

Im Gegensatz zum leichtgewichtigen Zachman Framework ist TOGAF ausgesprochen umfassend. Es definiert in detaillierter Form sowohl das “Was” des Enterprise Architecture Managements (EAM), d.h. was genau in einem Architektur-Repository verwaltet werden soll, als auch das “Wie”, d.h. Prozesse, Aufgaben, Rollen und erforderliche Fähigkeiten für das EAM

Sein enormer Umfang und Detaillierungsgrad erfordert aber ein massives Tailoring von TOGAF, damit es in der Praxis überhaupt sinnvoll eingesetzt werden kann. Nicht zuletzt deswegen ist wohl ein eigenständiges Geschäft rund um TOGAF-Ausbildung und -Zertifizierung entstanden. Es macht TOGAF aber auch zu einer sehr wertvollen Wissensquelle für Unternehmensarchitekten, die zudem kostenlos auf der Website der Open Group zur Verfügung steht.

Jetzt mit dem CAS als IT-Architekt durchstarten Bald starten wieder unseren beliebten CAS IT Architecture Lehrgänge in Kooperation mit der HWZ. Wählen Sie zwischen zwei Vertiefungen: CAS IT Architecture – Enterprise- und Softwarearchitektur  CAS IT Architecture – System- und Infrastrukturarchitektur  Nächster Infoabend

Bald starten wieder unseren beliebten CAS IT Architecture Lehrgänge in Kooperation mit der HWZ. Wählen Sie zwischen zwei Vertiefungen:

• CAS IT Architecture – Enterprise- und Softwarearchitektur 
• CAS IT Architecture – System- und Infrastrukturarchitektur 

Nächster Infoabend

3 RAMI 4.0

Ein jüngeres Framework für Unternehmensarchitektur ist das Referenzarchitekturmodell Industrie 4.0, kurz  RAMI 4.0. Es wurde ab 2013 von den drei Industrieverbänden Bitcom, VDMA und ZVEI in Deutschland spezifisch für die Bedürfnisse der Industrie 4.0 entwickelt. Im Zentrum von RAMI 4.0 steht die Entwicklung und Herstellung von Industrieprodukten. Dazu ist das Framework als dreidimensionales Modell aufgebaut, welches von unten nach oben in die folgenden 6 Layer unterteilt ist:

1. Im Asset-Layer sind die physischen Produktionsanlagen, Maschinen und Devices abgebildet.
2. Darauf baut der Integrations-Layer auf, in dem die physischen Assets des Asset-Layers virtuell als digitale Zwillinge abgebildet werden.
3. Im Communication-Layer werden die virtuell abgebildeten Assets über verschiedene Kommunikationswege und -protokolle miteinander verbunden.
4. Der Information-Layer kapselt die für die Entwicklung und Produktion notwendigen Informationen wie Konstruktionspläne oder Fertigungspläne.
5. Mit dem Functional-Layer werden alle für die Entwicklung und Produktion notwendigen Funktionen formal beschrieben.
6. Im Business-Layer schliesslich werden die im Functional-Layer beschrieben Funktionen zu ganzen Geschäftsprozessen integriert.

Diese 6 Layer werden in zwei weitere Dimensionen strukturiert: Mit der Hierarchie-Dimension werden verschiedene Kontexte aufgespannt, beginnend mit dem einzelnen Produkt über Fertigungsmaschinen und -zellen bis hin zu Standorten und Firmenclustern.
In der Wertschöpfungs-Dimension werden im Wesentlichen die Entwicklung von Produkten auf Typ-Ebene und die Fertigung von Produkten auf Instanz-Ebene unterschieden.

RAMI 4.0 bietet eine umfassende und branchenunabhängige Orientierungshilfe, um bestehende und neue Industrieunternehmen in Richtung Industrie 4.0 weiterzuentwickeln. An der Struktur von RAMI 4.0 lassen sich nun auch für die Fertigungsindustrie wichtige Standards wie… Komponentenidentifikation (GS1 oder RFID) oder Kommunikation und Steuerung (z.B. OPC UA) anknüpfen und zu einem integrierten Ganzen kombinieren. RAMI 4.0 ist ein Architektur-Framework welches spezifisch für die Fertigungsindustrie entwickelt wurde. Seine solide Grundstruktur muss aber noch mit konkreten Details ausgearbeitet werden. In den kommenden Jahren muss sich zeigen, wie RAMI 4.0 bei der Umsetzung von Industrie 4.0 Projekten nutzbringend eingesetzt werden kann.

4 MDEE

2006 haben wir bei KnowGravity begonnen, unser eigenes “Weltbild” zur Unternehmensarchitektur zu entwickeln. Daraus entstand das Framework Model Driven Enterprise Engineering(tm) (MDEE), welches verschiedenste Modellierungssprachen der Object Management Group (OMG) zu einem Framework zur ganzheitlichen Beschreibung eines Unternehmens integriert.

MDEE organisiert die Beschreibung eines Unternehmens in vier Quadranten, welche sowohl das “Was?” vom “Wie?” als auch die Beschreibung des Unternehmensgeschäfts von der Beschreibung der genutzten Technologie unterscheiden:

• Im Strategie-Modell werden strategische Überlegungen angestellt, die dazu erforderlichen Fähigkeiten (Capabilities) identifiziert und eine einheitliche Unternehmensterminologie geschaffen.
• Das Operationelle Modell zeigt auf, mit welchen Geschäftsprozessen die strategischen Vorgaben umgesetzt werden, welche Regeln dabei gelten und wie Verantwortlichkeiten auf Organisationsstrukturen abgebildet sind.
• Das Support-Modell umfasst die Anforderungen an technologische Hilfsmittel, welche die Bedürfnisse des Geschäfts optimal unterstützen, die funktionale Spezifikation dieser Hilfsmittel sowie Massnahmen zu deren Überprüfung.
• Das Implementations-Modell schliesslich dokumentiert die Anatomie der eingesetzten technischen Hilfsmittel sowie deren betrieblichen Aspekte und konkrete Konfiguration.

Der “fünfte Quadrant” von MDEE, das Management-Modell, befasst sich mit dem Management der ersten vier Quadranten:

• Welche Variationen und Varianten in den ersten vier Quadranten bekannt sind und wie genutzt werden können
• Welche Veränderungsvorhaben (Projekte und Programme) im Unternehmen geplant oder in Bearbeitung sind
• Welche Dokumente in welcher Form dazu erforderlich sind,
• Mit welchen Transformationen die konsistente Evolution aller Beschreibungen erleichtert wird
• Welche Qualitätsaspekte bei der Entwicklung und Evolution dieser Beschreibungen zu beachten sind

Ergänzende Frameworks

Neben Architektur-Frameworks im engeren Sinn gibt es eine ganze Reihe von “benachbarten” Frameworks auf Unternehmensebene, welche ein Unternehmensarchitekt im Auge behalten sollte:

ISO 9000

Eine Reihe von ISO Standards, welche die Konzeption, Umsetzung und Pflege eines unternehmensweiten prozessorientierten Management Systems zur Qualitätssicherung regeln. In etlichen Branchen ist ein solches QMS üblich oder es wird sogar explizit der Nachweis einer ISO 9000 Zertifizierung für Lieferanten eingefordert.

ISO 27000

Eine Reihe von ISO Standards, welche die Konzeption, Umsetzung und Pflege eines unternehmensweiten Information Security Management Systems (ISMS) standardisieren. Ein solches ISMS ist zumindest sehr empfehlenswert, um regulatorische Vorgaben zum Datenschutz wie z.B. das europäische GDPR, den deutschen IT-Grundschutz oder das schweizerische Datenschutzgesetz zu erfüllen.

ISO 31000

Ein ISO Standard, welcher die Konzeption, Umsetzung und Pflege eines unternehmensweiten Risk Management Systems standardisieren. Dieses Framework adressiert jegliche Art von Risiken und ist branchenunabhängig anwendbar. Im Bereich der Informationssicherheit ist es eine gute Ergänzung zur ISO 27000 Serie.

ITIL und COBIT

IT-bezogene Frameworks zum Aufbau einer unternehmensweiten IT durch standardisierte Prozesse (ITIL) sowie deren Steuerung und Governance entsprechend postulierter Unternehmensziele (COBIT). Allerdings überschneiden sich die beiden Frameworks auf Prozessebene substantiell.
GxP und daraus insbesondere GMP und GLP: Im pharmazeutischen und medizinischen Bereich spielen Good Manufacturing Practice (GMP) und Good Laboratory Practice (GLP) eine zentrale Rolle. GMP stellt sicher, dass Arzneimittel in der geforderten Qualität produziert werden, wogegen GLP sicherstellt, dass nicht-klinische Prüfungen solcher Arzneimittel für deren Zulassung regelkonform und nachvollziehbar durchgeführt werden.

Die meisten dieser ergänzenden Frameworks sind sehr umfangreich und müssen auf die spezifischen Bedürfnisse eines Unternehmens massgeschneidert werden. Und jedes dieser Frameworks hat ausgeprägte Berührungspunkte mit der Unternehmensarchitektur, welche als zentraler Integrationspfeiler für diese benachbarten Themen dienen kann.

Quellen:

• https://www.zachman.com/ea-articles-reference/54-the-zachman-framework-evolution
• https://www.opengroup.org/togaf
• https://www.isa.org/intech/20190405/

Lesen Sie auch: Unternehmensarchitektur im Kontext der digitalen Transformation