Im vorherigen Teil dieser Serie habe ich einige grundlegenden Begriffe von Enterprise Architecture Management Frameworks (EAF) erläutert. In diesem Beitrag möchte ich einen Überblick über die Zeitliche Entwicklung von EAF und einige Vor- und Nachteile nennen.

Enterprise Architecture Management Frameworks – sind nicht neu

Das Bild setzt einige Frameworks zeitlich zueinander in Beziehung.

Grundlage für diese Darstellung sind angepasste Graphiken aus [Mat11, Min08, Sch04b]. Die X-Koordinate der linken Kante eines jeweiligen Rechtecks gibt den Zeitpunkt auf der X-Achse an, zu welchem das Framework erschienen ist. Die Ausnahme bildet links oben die „GRAI Method“, die aus Gründen der Darstellbarkeit optisch im Jahr 1987 liegt, jedoch schon 1980 erschien. Die Y-Koordinate der Rechtecke hat keine Semantik. Direkte Vorgänger-/Nachfolgerbeziehungen werden durch eine Linie repräsentiert. Ist ein Framework die Grundlage für ein anderes, so verbindet sie ein Pfeil. Es wird nur die erste und jeweils aktuelle Version der Frameworks, sowie relevante Zwischenversionen angezeigt. Die Leserichtung der Linien und Pfeile ist immer chronologisch.

Die oben platzierten ISO/IEC/IEEE Standards sind zwar keine Frameworks im Sinne der anderen, enthalten jedoch für die meisten nach ihnen erschienenen Werke terminologische Grundlagen. Für weitere Details zu den einzelnen Frameworks siehe [Mat11, Sch04a], bzw. die jeweilige, zum Teil öffentlich zugängliche, Originaldokumentation.

Vorteile und Nachteile

In [Mat11] sind Vor- und Nachteile von EAFs aufgeführt, die hier als Tabelle wiedergegeben werden. Für die ausführliche Analyse sei auf die Quelle und die dort zitierten Primärquellen verwiesen.

Pro	Contra
Unterstützung des Geschäftszwecks	Investitionsaufwand
Komplexitäten beherrschen	Treibende Kräfte erforderlich
Flexibilität und Versatilität	Erfolgsfaktor: Erfahrung
Entscheidungshilfe leisten
Standardisierung gewährleisten
Integration unterstützen
Interoperabilität
Ganzheitlichkeit
Strukturierung
Datenmanagement unterstützen
Geschäftsprozesse mit der IT-Infrastruktur verbinden
Geschäftsprozesse optimieren
Sicherheit erhöhen
Unterstützung bei der Mitarbeiterausbildung

Fast nur Vorteile?

Bei der kurzen Liste der Nachteile kann der Eindruck erweckt werden, dass kein Weg an Frameworks für das Enterprise Architecture Management vorbeiführt. Jedoch fasst der dritte Punkt der gelisteten Nachteile, Erfolgsfaktor: Erfahrung, viele Gefahren des EAF-Einsatzes zusammen. Der Einsatz darf nicht zum Selbstzweck werden. EAFs schlagen viele Modelle und Sichten vor. Daraus ergeben sich Kritikpunkte, die auch von [SLJ+05] aufgegriffen wurden. Bei der Vielzahl der zur Verfügung stehenden Modelle ist oft nicht zweifelsfrei zu entscheiden, warum welches Modell gegenüber einem anderen zu bevorzugen ist, oder es bleibt unklar, welche Fragestellungen mit den Modellen beantwortet werden sollen. Da EAFs alle möglichen Aspekte abdecken wollen, entsteht bisweilen eine lange und im schlimmsten Fall schwammige Dokumentation.

Relevante Informationen werden nicht erkannt und bleiben für Unerfahre-ne verschlossen. Ein Parameter des Erfolgsfaktors „Erfahrung“ ist es, sich nicht auf die Methoden und Werkzeuge zu fokussieren, sondern den Menschen „dahinter“ einen größeren Stellenwert einzuräumen [ML12]. Denn diese haben in der Regel eine natürliche Abneigung gegen Veränderungen ihrer bekannten Arbeitsabläufe ([SEK07]). Damit werden das Stakeholdermanagement und das ChangeManagement neben den zentralen EAM-Methoden zu den wichtigsten Elementen, die von einem EAF adressiert werden sollten.

Enterprise Architecture Principles für die Kommunikation nutzen

Für die Kommunikation im Stakeholdermanagement und Change-Management spielen neben einem Glossar die EA-Prinzipien (EAP) eine wichtige Rolle. Sie stellen allgemeine und dauerhaft gültige Regeln und Richtlinien dar. Dabei unterliegen sie seltenen Änderungen und bieten involvierten Stakeholdern einen Rahmen, an welchem sie ihre Entscheidungen orientieren können. Beispielsweise soll nach einem EAP die Wiederverwendung von Anwendungen im Unternehmen maximiert werden, da redundante Systeme unnötige Kosten verursachen. So ist bei der Entwicklung und beim Zukauf abzuwägen, ob eine neue Anwendung notwendig ist, oder ob vorhandene Systeme die anfallenden Aufgaben bereits abdecken ([TOG11b]).

Es gibt keine fundierte Theorie, wie EAP auf Korrektheit, Konsistenz und Vollständigkeit hin untersucht werden könnten. Dazu wird in [ZML12] auf Basis einiger Prinzipien aus TOGAF die Kybernetik als passender theoretischer Rahmen für EAP identifiziert. Nach klassischem Verständnis untersucht die Kybernetik die Kommunikation von Tieren mit Maschinen. In der Gegenwart hat sie sich weitläufiger der Steuerung und Kommunikation in Systemen zugewandt, inklusive soziotechnischen Systemen wie Unternehmen ([ZML12]).

Stakeholder sollen die EAP als Rahmen für ihre Entscheidungen nutzen, dabei aber nicht die Unternehmensziele vernachlässigen. Daher sollen die Treiber und Ziele eines Unternehmens in Einklang mit den vorgeschriebenen EAP sein. In [GP11] wird ein Prozess vorgestellt, der diesen Zusammenhang berücksichtigt und Prinzipien aus den Unternehmenstreibern entwickelt.

Zusammenfassung

In diesem Beitrag habe ich die zeitliche Entwicklung von Frameworks für das Enterprise Architecture Management aufgerollt und einige Vor- und Nachteile von EAFs angeführt und die vermeitlich kurze Liste von Nachteilen relativert.

my 2 cents

Aus meiner Sicht ist der kritische Erfolgsfaktor für den Einsatz eines EAF die Erfahrung. Ich betrachte Frameworks als große Werkzeugkiste und bediene mich an den einzelen Tools, wenn sie im jeweiligen Kontext sinnvoll sind. Weiterhin nutze ich sie als „Checkliste gegen das Vergessen“. Meist ist es für ein Unternehmen ein ziemlicher Overkill ein komplettes Framework „Wort für Wort“ einzuführen. Die dadurch entstehenden zwangsläufigen Reibungsverluste verhindern zeitnah nutzbare Resultate (Quick Wins), was das ganze Unterfangen fast immer zum Scheitern verurteilt.

Bald geht es weiter mit Meta-Frameworks, TOGAF und ArchiMate.