Dr. Eldar Sultanow

Teil 2: 55 Frameworks im Vergleich

Ersteres ist eine der unter dem Begriff “IT-Governance” zusammengefassten Führungsaufgaben. Zweitgenanntes hat als Baustein von IT-Governance deren Zweckerfüllung zum Gegenstand, indem er Hilfsmittel zur strategischen Ausrichtung und zum geschäftsorientierten Ausbau der IT zusammenführt. Dieser Beitrag untersucht die Frage, wie sich Methoden oder Methodensammlungen (Frameworks) in einem Ordnungssystem systematisch erfassen und anhand einer gegebenen Problemstellung aus diesem auswählen lassen. Organisationale Problemstellungen umfassen die Anpassung eines Unternehmens an die Einflüsse auf sowie aus dessen Umwelt. Anpassungsfähigkeit ist im vorliegenden Sinne gleichzusetzen mit Gronaus Begriff der Wandlungsfähigkeit, das heißt die Fähigkeit zur aktiven, schnellen strukturellen Anpassung aus eigener Substanz auf zeitlich nicht vorhersehbar wechselnde Anforderungen.

Einführung

Im Folgenden werden die grundlegenden Begriffe ­erläutert und vor dem Hintergrund des zu entwickelnden Ordnungssystems in einen Zusammenhang gestellt.

Framework, Methode und Modell

Vorab ist eine Klärung der Grundbegriffe und ihrer Zusammenhänge angebracht, die für das Verständnis von Unternehmensarchitekturmanagement ­notwendig sind. Drei wesentliche Begriffe sind Framework, Methode und Modell.

Ein Framework stellt eine Sammlung von aufeinander abgestimmten Methoden dar. Methoden im Kontext der gestaltungsorientierten Wirtschaftsinformatik unterteilen Gericke und Winter (2009, S. 196) in Konstruktionsforschungsmethoden (“Wie sollen Artefakte konstruiert und evaluiert werden?”) und Artefaktkonstruktionsmethoden (“Wie sind konkrete, für die Lösung von Problemen im Zusammenhang mit Informationssystemen bestimmte, Artefakte zu gestalten und evaluieren?”).

Zur Definition von Methodenelementen und Beschreibung ihrer Beziehungen zueinander greift Braun (2007, S. 14) auf die wegweisenden Arbeiten Gutzwillers zurück, der Metamodell, Aktivitäten, Rollen, Werkzeuge, Techniken und Ergebnisse als die Grundbestandteile von Methoden ansieht. Methoden, stellt Braun fest, definieren ein in Form von Aktivitäten festgelegtes Vorgehen und Techniken beschreiben das – die Erstellung und Dokumentation von Ergebnissen regelnde – “Vorgehen im Kleinen” (Abbildung 1). Bei näherer Betrachtung der Modellierungstechnik als Technik im hier verstandenen Sinne stellen Modelle die Ergebnisse dar. Notation, Syntax und Semantik charakterisieren die Modellierungssprache.

Wie in Abbildung 2 dargestellt, sind Modelle entlang der drei von Braun (2009, S. 18) zusammengefügten Dimensionen, Generalisierungsgrad (spezieller vs. genereller Anwendungskontext), Aggregationsgrad (Grob- vs. Detailmodell) und ­Unternehmensabstraktionsgrad (von Strategien über Prozesse bis zu Informationssystemen und Systemkomponenten) klassifizierbar. Aus der letztgenannten Dimension, dem Unternehmensabstraktionsgrad, leitet sich die häufig in der Literatur (z.B. Dern, 2009, S. 6; Niemann, 2005, S. 17) zitierte, so genannte Unternehmensarchitekturpyramide ab. Diese Pyramide besitzt die aufeinander aufbauenden Schichten Systemarchitektur (teilweise auch Technologiearchitektur genannt), Anwendungsarchitektur (auch zwei separate Schichten Datenarchitektur und Anwendungsarchitektur möglich) und Geschäftsarchitektur. Oftmals wird auch von so genannten Architekturdomänen gesprochen.

Corporate und IT-Governance

Der englische Begriff “Governance” wird ins Deutsche mit “Führung” und “Steuerung” übersetzt. Der Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V. (BITKOM, 2011, S. 22) bezeichnet als Governance die “Spezifikation von übergreifenden Zielen und Vorgaben, Definition von Entscheidungs- und Informationsprozessen sowie Verantwortlichkeiten”.

Corporate Governance ist die “an der langfristigen Wertschöpfung” orientierte, “sowohl den juristischen Rahmenbedingungen als auch ethischen Grundsätzen” folgende Führung und Kontrolle des Unternehmens (Hofmann & Schmidt, 2010, S. 356). Die Autoren sehen IT-Governance als einen, ebenfalls in die Zuständigkeit des Topmanagements fallenden, Bestandteil von Corporate Governance.

Hofmann und Schmidt (2010, S. 355) sowie Meyer, Zarnekow und Kolbe (2003) lehnen sich an die Definition des IT-Governance Institute (ITGI) an, welche besagt, dass IT-Governance eine durch Vorstand und ­Management zu verantwortende Führungsaufgabe ist, die, so Hofmann und Schmidt, “die zielgerichtete, ­effektive Steuerung und Nutzung der IT zum ­Gegenstand hat”. IT-Governance-Maßnahmen sollen laut Meyer et al. “sicherstellen, dass mit Hilfe der eingesetzten IT die Geschäftsziele abgedeckt, Ressourcen verantwortungsvoll eingesetzt und Risiken angemessen überwacht werden”.

EAM-Governance ist ein Schlüsselelement von IT-Governance (Hanschke, 2010, S. 262). Es umfasst managementseitige Maßnahmen zur Ingangsetzung und nachhaltigen Verankerung von EAM in Unternehmen, etwa die Bestimmung der “Rollen, Verantwortlichkeiten, Prozesse, Gremien, Steuerungsgrößen” für das Architekturmanagement, dessen Integration in die ­organisationale Planung, Entscheidungsfindung und IT-Abläufe (Hanschke, 2012, S. 54) sowie die Festlegung von Richtlinien über Modellierung, einzusetzende Werkzeuge und von “Anzahl und Verteilung der Unternehmensarchitekten” (Hanschke, 2012, S. 24, 26). Tabelle 1 nennt die drei wesentlichen Bausteine, die IT-Governance steuert und in Einklang bringt.

Unternehmensarchitektur und EAM

Der Architekturbegriff hat seinen Ursprung im ­Latein. Steinbach (1734, S. 909) übersetzt den ­lateinischen Originalterminus “architectura” mit Baukunst. Das daraus abgeleitete Fremdwort Architektonik ­überträgt Petri (1861, S. 76) ebenfalls mit den Worten Baukunst und Baukunstlehre ins Deutsche. Die Architektur gibt demzufolge Aufschluss darüber, wie etwas ­aufgebaut ist.

Niemann (2005, S. 13-14) sieht die Unternehmensarchitektur als Aggregation von Plänen, etwa beginnend bei Strategieplänen, Organigrammen, Verfahrensanweisungen über Geschäftsprozessmodelle bis hin zu Applikationslandschafts- und Netzwerkplänen sowie Softwarestruktur- und Datenmodellen. Er betont, dass eine Unternehmensarchitektur nicht gezwungenermaßen genutzt wird, nur weil sie vorhanden ist. Von selbst finden weder die Dokumentation der ­Informationssystem-seitigen Abbildung von Geschäftsprozessen etwa durch Schaffen von Beziehungen zwischen Prozess- und Systemkomponentendiagrammen noch die Analyse dieser Beziehungen im Hinblick auf Abhängigkeiten, Kosten und Auslastung statt (Niemann, 2005, S. 14). Konkret motiviert er den dedizierten Aufbau und Gebrauch von Unternehmensarchitekturen als unabdingbares “Analyse- und Steuerungsinstrument” mit den Anforderungen an die IT, die aus der Komplexität, Dynamik und räumlichen Verteilung des ­Unternehmens sowie aus der ­Volatilität dessen Geschäftsumfelds hervorgehen. Niemann (2005, S. 45) ­liefert folgende Definition:

“Eine Unternehmens-­architektur unterstützt die Steuerung der IT dabei, mit minimalem ­Risiko die richtigen Dinge richtig zu tun.”

Als erfolgsentscheidend sieht er hierfür das Gespür für den richtigen, sich auf die Zielorientierung beziehenden, Aggregationsgrad, der mitunter von Größe, Struktur und Ausgangssituation des Unternehmens abhängt.

Mit einer zu Niemanns kompatiblen Sichtweise zählt BITKOM (2011, S. 6) zu EAM konkret die Managementaufgaben, eine Unternehmensarchitektur zu erstellen, umzusetzen und instand zu halten – sie bietet den “strategischen, konzeptionellen und organisatorischen Rahmen inklusive der erforderlichen Prinzipien, Methoden und Werkzeuge für die zielorientierte Ausgestaltung und Veränderung der IT-Landschaft”. Die Eigenschaften und Zusammensetzung der Unternehmensziele, nach denen sich Akteure und Prozesse auf jeder Ebene der Unternehmensarchitekturpyramide zu orientieren haben, beschreibt die Zielstruktur. In Abbildung 3 ist das von Niemann vorgeschlagene Modell für die Zielstruktur eines EAM dargestellt, welche drei grundlegende Nutzendimensionen, nämlich die Effizienz, Effektivität und Sicherheit definiert, wobei je nach Ausgangssituation des Unternehmens die Ausprägung, Priorisierung und Akzentuierung der Ziele variieren (Niemann, 2005, S. 46).

In der Auffassung, dass die ­Unternehmensarchitektur Modelle umfasst, sind diese entlang der Dimension des Unternehmensabstraktionsgrades (Abbildung 2) klassifizierbar und somit einer EA-Pyramidenebene zuordenbar. ­Abbildung 4 zeigt ein vereinfachtes Metamodell von Braun und Winter (2005), das die Modellelemente der drei Ebenen, Strategie, Geschäftsprozesse, Informationssysteme, in Beziehung setzt.

Inwieweit ein EA-Framework mit seinen Methoden die Ebenen abdeckt oder auf welchen der Ebenen es seinen Schwerpunkt hat, ist eine mögliche Dimension des zu entwickelnden Ordnungssystems für EA-Frameworks.

Ein Ordnungssystem für EA-Frameworks

Dimensionen bilden ein Ordnungssystem. Sie müssen zunächst identifiziert und zusammengeführt werden. Sie spannen einen Raum auf, so dass im Falle von beispielsweise drei Dimensionen dreidimensional bestimmbare EAM-Handlungsfelder als Tripel formuliert werden können. Die Ausprägungen der Dimensionen können eine Kumulation, Komplementarität (wechselseitige Ergänzung) oder Progression bilden:

• Kumulation: die Ausprägungen sind entlang ihrer Dimension so geordnet, dass jede der geordneten Eigenschaften in der darauffolgenden inbegriffen ist.
• Komplementarität: alle Ausprägungen unterliegen nicht zwangsläufig einer Ordnung. Sie sind komplementär zu ­einander.
• Progression: die Ausprägungen sind entlang ihrer Dimension derart geordnet, dass jede der geordneten Eigenschaft zwar eine Steigerung der ihr vorausgehenden ist, diese aber nicht kumuliert.

Schwerpunkt in ­EA-Pyramide

Die EA-Pyramide ist eine mögliche Dimension, sie bietet eine Möglichkeit, Frameworks danach zu klassifizieren

• entweder auf welcher Unternehmensarchitekturschicht (Architekturdomäne) der Schwerpunkt eines Frameworks liegt oder
• bis zu welcher Schicht ein ­Framework die Architekturschichten abdeckt

Im ersteren Fall bilden die Ausprägungen eine Komplementarität, im zweiteren eine Kumulation. Diese Abdeckung von oder Schwerpunktlage auf den Schichten der EA-Pyramide verwenden ebenfalls Herden und Zenner (2011) in ihrem Klassifikationsrahmen und sie stimmt mit der Dimension des Unternehmensabstraktionsgrads (­Abbildung 2) überein.

Metaebene der ­Wandlungsfähigkeit

Sich ständig ändernde Anforderungen im Markt, die Entwicklung neuer Technologien für neue ­Produkte und Dienstleistungen, die Veränderung von rechtlichen und wirtschaftlichen Rahmenbedingungen führen zu neuen Anforderungen an die IT eines Unternehmens. Unter der Annahme, dass die von Gronau (2008) als Wandlungsfähigkeit bezeichnete Fähigkeit zur aktiven, schnellen strukturellen Anpassung aus eigener Substanz an zeitlich unvorhersehbar wechselnde Anforderungen selbst keine ­persistente Eigenschaft ist, kann von einer “Meta-Wandlungsfähigkeit” gesprochen werden:

Aus eigener Substanz sich ­anpassen zu können, ist keine Eigenschaft, die – nachdem sie ein Unternehmen einmal angenommen hat – aus einem Selbstverständnis heraus für immer bestehen bleibt. Das Unternehmen muss sich diese Eigenschaft bewahren. Die mit der Anpassungsfähigkeit verbundene Dynamik ist demnach selbst nicht “dynamisch”, sondern von äußeren Umständen und inneren Zuständen abhängig. Eine übergeordnete ­Dynamik, die in der Selbsterhaltung der Wandlungsfähigkeit etwa durch die Bildung neuer Reaktions- und Entscheidungsmechanismen besteht, heißt “Meta-Wandlungsfähigkeit”.

Übertragen auf das Ordnungssystem für EA-Frameworks stellt sich zur Klassifizierung eines Frameworks entlang der Dimension der Wandlungsfähigkeits-Metaebene die Frage: Verfügt das Framework über eine Methode zur einmaligen Umgestaltung der Architektur eines Unternehmens, damit es sich an die neu gegebenen Bedingungen in seiner Umwelt anpassen kann oder verfügt es über einen dauerhaften Mechanismus (etwa einen zyklischen Prozess), der die ­Unternehmensarchitektur dynamisch so anpasst, dass das Unternehmen seine Eigenschaft der Wandlungsfähigkeit ­aufrechterhält?

Abdeckungsweite von Organisationen

Entlang dieser Dimension lassen sich Frameworks danach klassifizieren, wie weit sich die Organisationsdefinition mit einem solchen fassen lässt. Die Ausprägungen reichen von einer lokalen Geschäftseinheit über einen Zusammenschluss von Organisationseinheiten, die räumlich verteilte Organisation bis hin zum Verbund global kollaborierender, unabhängiger Unternehmen (Netzwerke von Lieferanten, Partnern und Kunden).

Die Ausprägungen dieser Dimension der Abdeckungsweite sind kumulativ, das heißt ein Framework kann beispielsweise in Organisationen, die von lokal bis zu weiträumlich verteilt sind, eingesetzt werden. Eine alternative Variante dieser Dimension mit progressiven statt kumulativen Ausprägungen ist die Adäquanz für Unternehmensgröße, die angibt, für Organisationen welcher Reichweite ein EA-Framework primär geeignet ist. Etwa kann ein Framework für den Einsatz in globalen Unternehmensnetzwerken geeignet sein, nicht aber in einer lokalen Mittelstandsfirma.

Weitere Dimensionen

Eine weitere Dimension ist die zeitliche, aus der das Alter von Frameworks hervorgeht. Außerdem lässt sich eine intentionale Dimension heranziehen, für die Matthes (2011, S. 39-40) sieben Ausprägungen identifiziert: Regierungsstellen und Behörden, Management, Militär, Fertigung, Technische Orientierung, Interoperabilität, Add-On. Die eben genannten Dimensionsausprägungen lassen sich zusammenfassen. Die Ausprägungen Management und Technische Orientierung sind eher den Architekturebenen zuzuordnen. Den Interoperabilitäts-Frameworks ordnet Matthes nur Vertreter der Government-Frameworks zu, wobei das technisch ausgerichtete C4IF (Connection, Communication, Consolidation, CollaborationInteroperability Framework) eine Ausnahme bildet.

Drei völlig andere Dimensionen schlagen Urbaczewki und Mrdalj (2006) vor, nämlich die Beinhaltung von Views/Perspektiven für die typischen Zachman-Rollen Planer, Besitzer, Designer/Architekt, Builder, Programmierer und Nutzer (1), die Beinhaltung der nach Zachmans W-Fragen Was, Wie, Wo, Wer, Wann und Warum gliederbaren Inhalte (2) sowie die Beinhaltung der Softwareentwicklungslebenszyklusphasen Planung, Analyse, Entwurf, Implementierung und Wartung (3).

Magoulas, Hadzic, ­Saarikko und Pessi (2012) führen fünf Vergleichs-Dimensionen ein: die sozio-kulturelle Ausrichtung der Bereiche der Informationssysteme, Ziele und Werte (zum Beispiel die Stakeholder-Erwartungen gegenüber gelieferten Beiträgen), die funktionelle Ausrichtung zwischen den Bereichen Informationssystem, Aktivitäten und Prozesse, die Strukturausrichtung des Bereichs der Informationssysteme mit dem der Leistung (Kompetenzen und Verantwortlichkeiten), die infologische Ausrichtung zwischen Informationssystemen und ­individuellen Akteuren (zum Beispiel Verständlichkeit und Aussagekraft) und letztlich die kontextuelle Ausrichtung ­zwischen dem Unternehmen als Ganzes, ­seinen Informationssystemen und der externen ­Unternehmensumwelt.

Quellen für die im Ordungssystem zu ­klassifizierenden EA-Frameworks

Es existieren verschiedene Arbeiten, die EA-Frameworks gegenüberstellen. Herden und Zenner (2011) stellen anhand ihres eigens entwickelten Klassifikationsrahmens das Zachman-Framework, DoDAF, FEAF und TOGAF in Vergleich.

Dieselben vier Frameworks plus zwei weitere (4+1 View und RM-ODP) kontrastieren Tang, Han und Chen (2004) hinsichtlich deren Beinhaltung von Ziel-, ­Input- und Ergebnis-Elementen. Cameron und ­McMillan (2013) liefern ein komparatives ­Auswahlmodell fast derselben Frameworks (Zachmann, TOGAF, ­DoDAF, FEAF und Gartner), welches diese nach zwölf ­Kriterien vergleicht.

Eine Auswahlanleitung für EA-Tools liefert Schekkerman (2011). Urbaczewki und Mrdalj stellen ­mithilfe ihres Vergleichsmodells die fünf Frameworks ­Zachman, DoDAF, FEAF, TEAF und TOGAF gegenüber. Magoulas et al. vergleichen unter Verwendung der durch sie eingeführten Ausrichungsdimensionen die Frameworks Zachman, TOGAF, GERAM und E2AF.

Insgesamt vergleicht Matthes 54 Rahmenwerke, ­welche für die Untersuchung im Folgeartikel Teil 2 als Datengrundlage herangezogen werden.

Dr. Eldar Sultanow

Dr. Eldar Sultanow ist bei Capgemini als Architekt tätig. Er hat langjährige Praxiserfahrung in der Softwareindustrie, insbesondere in den Bereichen JEE, Electronic/Mobile Commerce, Track-&-Trace und Auto-ID im Pharmabereich sowie Requirements & Solutions Engineering im Public Sector.

Literatur

BITKOM (2011). Enterprise Architecture Management: neue Disziplin für die ganzheitliche Unternehmensentwicklung. Berlin, Deutschland: Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V.

Braun, C., & Winter, R. (2005). A Comprehensive Enterprise Architecture Metamodel and Its Implementation Using a Metamodeling Platform. In: J. Desel & U. Frank (Hrsg.): Enterprise Modelling and Information Systems Architectures, Proc. of the Workshop in Klagenfurt, GI-Edition Lecture Notes (LNI). Bonn, Deutschland: Bonner Köllen Verlag, S. 64-79.

Braun, C. (2007). Modellierung der Unternehmensarchitektur Weiterentwicklung einer bestehenden Methode und deren Abbildung in einem Meta-Modellierungswerkzeug. Dissertation (Nr. 3285). Universität St. Gallen, Hochschule für Wirtschafts-, Rechts- und Sozialwissenschaften (HSG). Logos Verlag, Berlin 2007.

Dern, G. (2009). Management von IT-Architekturen: Leitlinien für die Ausrichtung, Planung und Gestaltung von Informationssystemen (Auflage 3). Deutschland, Wiesbaden: Vieweg+Teubner.

Gericke, A., & Winter, R. (2009). Entwicklung eines Bezugsrahmens für Konstruktionsforschung und Artefaktkonstruktion in der gestaltungsorientierten Wirtschaftsinformatik. In J.

Becker, H. Krcmar & B. Niehaves (Hrsg.), Wissenschaftstheorie und gestaltungsorientierte Wirtschaftsinformatik (S. 195-210). Heidelberg, Deutschland: Physica.

Gronau, N. (2008). Management des Wandels – IT-Business Alignment und Wandlungsfähigkeit von Informationssystemen. In N. Gronau (Hrsg.), Wettbewerbsfähigkeit durch Arbeits- und Betriebsorganisation (S. 145-150). Berlin, Deutschland: Gito.

Hanschke, I. (2010). Strategic IT Management: A Toolkit for Enterprise Architecture Management. Berlin, Deutschland: Springer.

Hanschke, I. (2012). Enterprise Architecture Management – einfach und effektiv: Ein praktischer Leitfaden für die Einführung von EAM. München, Deutschland: Carl Hanser.

Herden, S., &Zenner, U. (2011). Klassifikation von Enterprise-Architecture-Frameworks: Eine Literaturanalyse. Technischer Bericht (Nr.: FIN-007-2011), Elektronisch e Zeitschriftenreihe der Fakultät für Informatik der der Otto-von-Guericke-Universität Magdeburg (ISSN 1869-5078), Institut für technische und betriebliche Informationssysteme.

Hofmann, J., & Schmidt, W. (2010). Masterkurs IT-Management: Grundlagen, Umsetzung und erfolgreiche Praxis für Studenten und Praktiker (Auflage 2). Deutschland, Wiesbaden: Vieweg+Teubner.

Magoulas, T., Hadzic, A., Saarikko, T., Pessi, K. (2012). Alignment in Enterprise Architecture: A Comparative Analysis of Four Architectural Approaches. Electronic Journal of Information Systems Evaluation, 15(1), 88-101.

Matthes, D. (2011). Enterprise Architecture Frameworks Kompendium: Über 50 Rahmenwerke für das IT-Management. Heidelberg, Deutschland: Springer.

Meyer, M., Zarnekow, R., & Kolbe, L. M. (2003). IT-Governance: Begriff, Status quo und Bedeutung. Wirtschaftsinformatik 45(4), 445-448.

Niemann, K. D. (2005): Von der Unternehmensarchitektur zur IT-Governance: Bausteine für ein wirksames IT-Management. Deutschland, Wiesbaden: Springer.

Petri, F. E. (1861). Handbuch der Fremdwörter in der deutschen Schrift- und Umgangsprache (F. E. Petri Ed. Ausgabe 1). Leipzig, Deutschland: Arnoldische Buchhandlung.

Schekkerman, J. (2011). Enterprise Architecture Tool Selection Guide (Version 6.3). Institute For Enterprise ArchitectureDevelopments (IFEAD).

Steinbach, C. E. (1734). Vollständiges Deutsches Wörter-Buch vel Lexicon Germanico-Latinum: A-L (Band 1). Breslau: Johann Jacob Korn.

Tang A., Han, J., & Chen, P. (2004). A Comparative Analysis of Architecture Frameworks. Technical Report (Nr.: SUTIT-TR2004.01). School of Information Technology, Centre for Component Software and Enterprise Systems, Swinburne University of Technology.

Urbaczewki, L. & Mrdalj, S. (2006). Comparison of Enterprise Architecture Frameworks. Issues in Information Systems, 6(2), 18-23.