Ansätze zur Optimierung einer bestehenden Unternehmensarchitektur

Inhaltsverzeichnis

Abstract

Kurzfassung

Inhaltsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Definition der Aufgabenstellung
1.1 Projektumfeld
1.2 Zielsetzung und Aufbau der Arbeit

2 Architekturmanagement als strategisches Werkzeug zur Optimierung einer bestehenden Architektur
2.1 Grundlagen des Architekturmanagements
2.1.1 Definition Architektur und Unternehmensarchitektur
2.1.2 Definition des Architekturmanagements
2.2 Ziele und Nutzen des Architekturmanagements
2.2.1 Typische Problemstellungen in der Praxis
2.2.2 Treiber und Ziele des Architekturmanagements
2.2.3 Quantifizierung strategischer Nutzenpotenziale
2.3 Entwicklung einer Vorgehensweise zur Architekturoptimierung
2.3.1 Grundlagen zur Optimierung einer Architektur
2.3.2 Zusammenhang Geschäftsstrategie, IT-Strategie und IT-Architektur
2.3.3 Dokumentation der bestehenden Architektur
2.3.4 Planung der Soll-Architektur
2.3.5 Beschreibung der gewählten Vorgehensweise

3 Ist-Analyse der Architektur als Voraussetzung zur Optimierung
3.1 Einsatz des IBM Rational System Architects als Architekturwerkzeug
3.2 Vorbereitung der Ist-Analyse
3.2.1 Ermittlung der notwendigen Informationsobjekte und Definition eines geeigneten Metamodells
3.2.2 Analyse bestehender Informationssysteme
3.2.3 Anbindung vorhandener Datenquellen
3.3 Durchführung der Ist-Dokumentation
3.3.1 Datenübernahme aus bestehenden Informationssystemen
3.3.2 Manuelle Übernahme existierender Architekturpläne
3.4 Erzielter Nutzen durch die Ist-Analyse

4 Ansätze zur Optimierung der Unternehmensarchitektur
4.1 Architekturanforderungen aus der Geschäfts- und IT-Strategie
4.2 Auswahl geeigneter Prinzipien zur Optimierung der Architektur
4.2.1 Überblick über mögliche Architekturprinzipien
4.2.2 Bewertung der Architekturprinzipien auf Basis der Architekturanforderungen
4.3 Schwachstellenanalyse anhand der entwickelten Architekturprinzipien
4.4 Entwicklung von Optimierungsansätzen
4.4.1 Einführung einer Serviceorientierten Architektur
4.4.2 Konsolidierung der vorhandenen Portallösungen
4.4.3 Erstellung eines konsistenten Datenkonzepts

5 Fazit und Ausblick
5.1 Zusammenfassung und Diskussion der erzielten Ergebnisse
5.2 Ausblick für das Architekturmanagement

Quellenverzeichnis

Anhang
Anhang A: Experten-Interview mit H. Hüttner, IBM Deutschland GmbH
Anhang B: Technisches Konzept zur Anbindung des Rational System Architect an bestehende Informationssysteme
Anhang C: Übersicht der Schnittstellen der vorhandenen Middleware

Ehrenwörtliche Erklärung

Abbildungsverzeichnis

Abbildung 1: Architekturpyramide

Abbildung 2: Entwicklung einer Architektur mit und ohne Architekturmanagement

Abbildung 3: Treiber des Architekturmanagements

Abbildung 4: Wertbeitrag des Architekturmanagements auf den Unternehmensumsatz

Abbildung 5: Wertbeitrag des Architekturmanagements auf das IT-Budget

Abbildung 6: Relationen zwischen der Geschäfts- und IT-Strategie und der IT-Architektur

Abbildung 7:Metamodell aus Basis der Architekturpyramide

Abbildung 8:Entwicklung der Soll-Architektur auf Basis verschiedener Soll-Szenarien

Abbildung 9: Erarbeitetes Vorgehensmodell zur Entwicklung von Optimierungsansätzen

Abbildung 10: Hauptphasen des entwickelten Vorgehensmodells

Abbildung 11: Relevante Ebenen der Architekturpyramide

Abbildung 12: Datenobjekte des entwickelten Metamodells

Abbildung 13: Mehraufwand bei doppelter Pflege durch die Fachbereiche

Abbildung 14: Datenquellen zur Übernahme der relevanten Architektur-Ebenen

Abbildung 15: Dokumentation der Anwendungskomponenten und Datenflüsse im SAP-Umfeld

Abbildung 16: Relation der SLA-Kategorien

Abbildung 17: Analyse der bestehenden SLA-Kategorien und Datenflüsse

Abbildung 18: Ziele der Geschäfts- und IT-Strategie

Abbildung 19: Übersicht ausgewählter Architekturprinzipien

Abbildung 20: Bewertung und Priorisierung der Architekturprinzipien

Abbildung 21: Ergebnis der Schwachstellenanalyse für die ausgewählten Architekturprinzipien

Abbildung 22: Zuordnung der Optimierungsansätze zu den identifizierten Problemfeldern

Abbildung 23: Ist-Architektur der Middleware-Umgebung

Abbildung 24: Soll-Architektur der Middleware-Umgebung

Abbildung 25: Abbildung der Alignment-Architektur im entwickelten Metamodell

Abbildung 26: Ist-Architektur der Portal-Umgebung

Abbildung 27: Soll-Architektur der Portal-Umgebung

Abbildung 28: Vorgehensmodell zur Einführung eines konsistenten Datenkonzepts

Abbildung 29: Konsolidierung vorhandener Datenbestände

Tabellenverzeichnis

Tabelle 1: Umfang der automatischen Übernahme

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Definition der Aufgabenstellung

Die Informationstechnik (IT) eines Unternehmens steht vor der Herausforderung, immer schneller auf wechselnde Geschäftsanforderungen reagieren zu müssen (vgl. Lochmaier 2009, S. 56). Um diese Flexibilität und Agilität bei gleichbleibenden IT-Budgets bieten zu können, bedarf es einer signifikanten Steigerung der IT-Effizienz (vgl. Capgemini 2012, S. 11). Demgegenüber steht die stetig wachsende Komplexität der IT-Landschaft, welche kurze Planungszyklen und eine schnelle Reaktionen auf neue Anforderungen erheblich erschwert. Um die Komplexität der Landschaft zu beherrschen und den stetig wechselnden Geschäftsanforderungen gerecht zu werden, hat sich die Disziplin des Enterprise Architecture Management (EAM)^[1] etabliert.

Die Ziele des EAMs - Homogenisierung der IT-Landschaft, Ausrichtung der IT an den Anforderungen des Geschäfts und Senkung der IT-Betriebskosten - sind hoch gesteckt. Auf der anderen Seite herrscht meist eine erhebliche Unsicherheit, das Management der Unternehmensarchitektur erfolgreich in der eigenen Organisation zu etablieren. Eine Vielzahl von Unternehmen ist sich allerdings der bestehenden Komplexität ihrer IT-Landschaft bewusst - die versprochenen Ziele des Architekturmanagements klingen daher verlockend. Zahlreiche Großunternehmen und zunehmend auch der Mittelstand starten daher EAM-Projekte in Erwartung erheblicher Kostensenkungen. So plant der deutsche Automobilhersteller BMW Einsparungen im IT-Betrieb in Höhe von 300 Millionen Euro durch ein vereinheitlichtes Architekturmanagement (vgl. Lochmaier 2009, S. 57).

Eine Gartner-Studie belegte, dass die meisten dieser Projekte aufgrund eines mangelhaft individualisierten Vorgehensmodells scheiterten (vgl. Gall 2012, S. 5). So lassen sich die in der Theorie zahlreich vorhandenen Modelle selten unverändert auf ein Unternehmen anwenden. Die vorliegende Arbeit soll daher anhand eines konkreten Unternehmens die Entwicklung eines geeigneten Vorgehensmodells zur Einführung des Architektur-managements erläutern. Der Nutzen des Architekturmanagements wird dabei durch die Ableitung von Ansätzen zur Optimierung der bestehenden Architektur demonstriert.

1.1 Projektumfeld

Diese Arbeit begleitet die Einführung des Architekturmanagements bei einem großen, regionalen Energieversorger in Deutschland. Das börsennotierte Unternehmen beschäftigt circa 2.500 Mitarbeiter und erwirtschaftete im Jahr 2010 einen Umsatz von etwa zwei Milliarden Euro. Als Energieversorger betreibt das Unternehmen ein eigenes Netzgebiet, über welches die Kunden mit Strom, Gas, Wasser und Fernwärme versorgt werden. Das Unternehmen gliedert sich in verschiedene Tochtergesellschaften, welchen jeweils unterschiedliche Aufgabenbereiche zugeordnet sind. Die IT-Tochter des Unternehmens übernimmt dabei die Planung, Bereitstellung und den Betrieb sämtlicher Informations- und Telekommunikationssysteme.

Der Energiemarkt in Deutschland wird durch eine Vielzahl von gesetzlichen Regulationen geprägt. Diese Auflagen, Richtlinien und Gesetze haben einen maßgeblichen Einfluss auf die Geschäftstätigkeit der Versorgungsunternehmen (vgl. Hüttner 2012). Dabei bedeutet die stetige Erfüllung der gestellten Auflagen auch einen permanenten Wandel der geschäftlichen Anforderungen. Diese Wandel des Geschäfts verlangen stets auch Anpassungen im IT-Betrieb. Es liegt daher im Aufgabenbereich der IT-Tochter, eine flexible Unterstützung des Geschäfts zu gewährleisten und in der Lage zu sein, zeitnah und kostengünstig auf geänderte Anforderungen reagieren zu können.

Die IT hat im Wettbewerb der Energieversorger in den letzten Jahren konstant an Bedeutung gewonnen. Zwar ist der Stellenwert der IT in der Energiebranche noch nicht mit der Finanz- und Bankenbranche vergleichbar, dennoch etablieren sich IT- und Kommunikationssysteme zunehmend als wettbewerbsentscheidende Faktoren. Die Branche befindet sich aktuell im Umbruch. Innovationen wie Smart Grid und Smart Meter ("intelligente" Stromnetze und -zähler) werden nach Gartner das bisherige Geschäft der Versorger erheblich verändern (vgl. Sumic 2011, S. 3). Auch hierfür bedarf es agiler und flexibler IT-Landschaften, um wettbewerbsfähig agieren zu können. Die bestehenden Landschaften erfüllen dieses Ziel jedoch nicht befriedigend. Die stetig wachsende Komplexität lässt die Kosten für den IT-Betrieb konstant steigen. Bei gleichbleibenden Budgets bleibt hierdurch immer weniger Geld für Innovationen.

Um dieser Abwärtsspirale entgegenzuwirken und die IT-Systeme auf den in Aussicht stehenden Umbruch vorzubereiten, wurde im vorliegenden Unternehmen im Oktober 2011 das Architekturmanagement als fester Bestandteil in der IT-Organisation verankert. Die neu geschaffene Abteilung befindet sich daher noch in einer frühen Aufbau- und Entwicklungsphase.

1.2 Zielsetzung und Aufbau der Arbeit

Im Rahmen der vorliegenden Arbeit soll das Architekturmanagement durch die Einführung eines Architektur-Werkzeuges, dem IBM Rational System Architect, unterstützt werden. Während ein Werkzeug den Prozess des Architekturmanagements wesentlich effizienter gestaltet, bedarf es dennoch einer detaillierten Planung. Hierbei müssen die angestrebten Ziele definiert und die Teilschritte zur Erreichung des Zieles erarbeitet werden. Durch einen pragmatischen Ansatz verspricht sich das Unternehmen sowohl schnelle als auch langfristige Optimierungen der Unternehmensarchitektur.

Das Ziel der vorliegenden Arbeit ist es, die Methoden und Prozesse des Architekturmanagements anzuwenden, um Ansätze zur Optimierung der bestehenden Unternehmensarchitektur zu entwickeln. Hierzu wird auf Basis von Fachpublikationen eine eigene Vorgehensweise entwickelt, welche - angepasst auf das betreffende Unternehmen - genutzt wird, um die bestehende Architektur zu optimieren. In diesem Zusammenhang soll außerdem gezeigt werden, wie ein Architekturmanagement-Werkzeug eingesetzt und angewendet werden kann, um die Optimierungsansätze möglichst effizient zu identifizieren. Dies geschieht am Beispiel des IBM Rational System Architects stellvertretend für ein beliebiges Architekturmanagement-Werkzeug.

Hierzu werden im folgenden Kapitel 2 die verschiedenen Begriffe des Architekturmanagements definiert und voneinander abgegrenzt. Darauf aufbauend werden die strategischen Ziele und Nutzenpotenziale des Enterprise Architecture Management unter Berücksichtigung der betriebswirtschaftlichen Zusammenhänge erläutert. Aus der Basis von Literatur, Artikeln aus Fachzeitschriften und aktuellen Studien des Marktforschungsunternehmens Gartner wird eine konkrete Vorgehensweise erarbeitet, nach welcher die Unternehmensarchitektur im betrachteten Unternehmen weiterentwickelt und optimiert werden kann. In Kapitel 3 wird basierend auf der erarbeiteten Vorgehensweise die Ist-Situation der Unternehmensarchitektur dokumentiert. Anschließend werden in Kapitel 4 gemäß der entwickelten Vorgehensweise konkrete Ansätze zur Optimierung der bestehenden Architektur identifiziert. Schlussendlich werden in Kapitel 5 die erzielten Ergebnisse diskutiert. Es folgt ein abschließender Ausblick auf die Entwicklung des Architekturmanagements im betreffenden Unternehmen.

2 Architekturmanagement als strategisches Werkzeug zur Optimierung einer bestehenden Architektur

Die Ziele des EAM, eine flexiblere und agilere IT-Landschaft mit geringeren Kosten zu entwickeln, welche optimal auf das Geschäft eines Unternehmens ausgerichtet ist, lassen das Architekturmanagement als Lösung für einige grundlegende Probleme vieler IT-Abteilungen erscheinen. Dabei ist besonders eine mangelnde Ausrichtung der IT-Landschaft auf die Anforderungen des Geschäfts ein Hemmnis in vielen Unternehmen. 2007 befragte das Marktforschungsinstitut Vanson Bourne 140 Finanzdienstleister im deutschen Markt zur IT-Unterstützung ihres Geschäfts (vgl. Pütter 2007). Dabei befanden 48% der Befragten, dass die vorhandenen IT-Strukturen nicht ausreichend flexibel für die Geschäftsaktivitäten seien. Weiterhin gaben 38% der befragten Unternehmen an, dass sie ihre Geschäftsprozesse den bestehenden IT-Systemen anpassen mussten. Aus zeitlichen und finanziellen Gründen wurde dies der Ausrichtung der IT an den Geschäftsprozessen vorgezogen.

Dieses Ergebnis ist bezeichnend für die vorherrschende Trägheit und unbeherrschbare Komplexität der IT-Landschaften. Es ist davon auszugehen, dass die Erkenntnis über unbeherrschbare Komplexität zuerst in informationsgetriebenen Branchen wie dem Finanz- und Versicherungsbereich angetroffen wird. Dementsprechend lässt sich das Ausmaß der Ergebnisse der erwähnten Studie noch nicht auf andere Branchen übertragen. Spätestens wenn sich die IT-Unterstützung in einer Branche als wettbewerbsdifferenzierend erweist, stehen die Unternehmen vor der Herausforderung, die im Wandel befindlichen Geschäftsprozesse bestmöglich zu unterstützten. Diese Unterstützung wird gehemmt durch die unüberschaubare Komplexität, welche zwangsläufig aus dem fortwährenden unkontrollierten Wachstum bestehender IT-Landschaften verursacht wird. Dr. Wolfram Jost, CTO der software AG und Vorstand der ehemaligen IDS Scheer, bestätigt die Trägheit in der Reaktion auf neue Anforderungen aufgrund einer enormen Komplexität (2010, S. 73).

Dieser Komplexität zu entgegnen bedarf es Methoden und Hilfsmittel des Architekturmanagements, um die Entwicklung einer Landschaft gezielt zu kontrollieren, steuern und zu planen. Im Folgenden werden die Grundlagen des Architekturmanagements zur Optimierung einer Architektur erläutert. Hierfür werden zunächst die elementaren Begriffe des Architekturmanagements definiert und in Zusammenhang gebracht. Anschließend wird in Kapitel 2.2 der strategische Nutzen, welchen sich Unternehmen durch EAM versprechen, untersucht. Schließlich wird in Kapitel 2.3, auf Basis aktueller Literatur, eine eigene Vorgehensweise für die Optimierung der vorliegenden Unternehmensarchitektur entwickelt.

2.1 Grundlagen des Architekturmanagements

2.1.1 Definition Architektur und Unternehmensarchitektur

Im Folgenden werden die grundlegenden Begriffe im Bereich des Architekturmanagements definiert. Diese Definitionen bilden die Grundlage für die weitere Vorgehensweise. Um dem gestellten Ziel - der Optimierung einer bestehenden Unternehmensarchitektur - gerecht zu werden, ist zunächst zu klären, was unter einer Architektur und genauer einer Unternehmensarchitektur zu verstehen ist. Der ANSI/IEEE Std. 1471-2000 definiert den Begriff der Architektur als:

„The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.“

(IEEE 2000, S. 3)

Übersetzt handelt es sich bei einer Architektur also um die globale Organisation eines Systems, welches durch seine Komponenten, deren Beziehungen zueinander und zu externen Objekten und Prinzipien, die die Ausprägung und Weiterentwicklung des Systems beeinflussen, verkörpert wird. Der Architektur-Begriff wird anhand eines Gebäudes greifbar. Hierbei beschreibt die Architektur alle Gebäudebestandteile wie Türen, Fenster, Wände und Treppen und deren Relation zueinander in Architektur-Plänen. Diese Pläne enthalten ebenfalls die Anbindung des Gebäudes an externe Objekte wie beispielsweise der Grundwasser- oder Elektrizitätsanschluss. Dabei liegt es in der Natur einer Architektur, dass sie sich stets weiter untergliedern lässt. Die Architektur eines Gebäudes kann in die Architektur der jeweiligen Etagen untergliedert werden. Auch eine funktionelle Untergliederung in eine gestalterische Architektur (Design) und eine planerische Architektur (Detailplanung, Fachplanung) sind denkbar.

Basierend auf der Definition einer Architektur lässt sich das Beispiel der Gebäude-Architektur auch auf Unternehmen übertragen. Keuntjes und Barkows definieren eine Unternehmensarchitektur dabei als:

"zentrale, systematische, ggf. modellbasierte Darstellung der Gesamt-Architektur eines Unternehmens auf hoher Abstraktionsebene [...]."

(Keuntje und Barkow 2010, S. 430).

Die Gesamt-Architektur des Unternehmens umfasst dabei alle Komponenten eines Unternehmens (wie Geschäftsprozesse, Organisationseinheiten, IT-Anwendungen, Hardware und Software). Deren Relation zueinander wird in den verschiedenen Plänen und Modellen der Unternehmensarchitektur abgebildet. Auch die Unternehmensarchitektur lässt sich untergliedern. Diese Untergliederung erfolgt in der Literatur zum Beispiel anhand einer Architekturpyramide, welche aus verschiedenen Architektur-Ebenen zusammengesetzt ist. Im Jahr 2005 verwendete Niemann (2005, S. 76) bereits diese Darstellungsform. Die Ausprägung und Begrifflichkeiten der Pyramiden haben sich im Laufe der Jahre je Autor geringfügig verändert. Barkow (2010, S. 24) hat die Variationen der unterschiedlichen Pyramiden von Keller (2007), Dern (2009) und Riege et al. (2008) vereint (vgl. Abb. 1). Die einzelnen Ebenen der Pyramide beinhalten die unterschiedlichen Komponenten der Unternehmensarchitektur. Weiterhin beinhaltet die Pyramide Relationen zwischen Elementen der Unternehmensarchitektur, welche in zwei Kategorien gegliedert werden können: Relationen zwischen den Elementen verschiedener Ebenen und Relationen innerhalb einer Ebene.

Die Spitze der Pyramide stellt die Strategie eines Unternehmens dar. Jede darunter liegende Ebene operationalisiert diese Strategie sukzessive. Die Elemente der Ebenen werden dabei zunehmend technischer und abnehmend fachlicher. So werden in der Ebene der Geschäftsarchitektur die Geschäftsprozesse und -objekte des Unternehmens abgebildet. Die Relationen innerhalb dieser Ebene setzen die verschiedenen Prozesse in einen Zusammenhang. Hierdurch kann eine Aussage über die zeitliche Anordnung und inhaltliche Abhängigkeit der Geschäftsprozesse und -objekte getroffen werden. Die darunter liegende Schicht der Alignment-Architektur bildet die Brücke zwischen den fachlichen und informationstechnischen Komponenten innerhalb der Unternehmensarchitektur, indem sie abstrakte IT-Fähigkeiten und IT-Funktionen abbildet. Unterhalb der Alignment-Architektur befindet sich die Anwendungslandschaft. Diese enthält die konkreten im Unternehmen vorhandenen IT-Anwendungen und deren Anordnung und Abhängigkeit in Form von Datenflüssen und Schnittstellen. Die Basis der Architekturpyramide bildet die Basisinfrastruktur, welche die verschiedenen Software- und Hardware-Komponenten beinhaltet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Architekturpyramide, Quelle: Barkow (2010, S. 24); leicht modifiziert

Die erwähnten Relationen zwischen den Elementen verschiedener Ebenen erlauben Aussagen über den Zusammenhang der fachlichen und technischen Domäne des Unternehmens. Meist existieren diese Relationen nur für angrenzende Ebenen, so dass es beispielsweise selten eine Relation der Basisinfrastruktur zu den Geschäftsprozessen gibt. Die Relationen zwischen angrenzenden Ebenen sind dafür aber umso zahlreicher vorhanden. So lassen sich die Elemente der Geschäftsstrategie direkt zu den Geschäftsprozessen in der darunterliegenden Ebene zuordnen. Die Geschäftsprozesse wiederrum sind konkreten IT-Funktionen zugeordnet, welche durch eine Anzahl von Anwendungen unterstützt wird. Die verschiedenen Anwendungen werden schließlich von den Hardware- und Softwarekomponenten aus der Basisinfrastruktur unterstützt.

Die Architektur eines Unternehmens ist entweder geplant oder historisch gewachsen (vgl. Schmidt 2007, S. 229). Eine gute Unternehmensarchitektur zeichnet sich durch eine gezielte Planung aus, die einzelnen Komponenten sind aufeinander abgestimmt und wurden nicht ohne sorgfältige Prüfung installiert. Eine ungeplante Unternehmensarchitektur lässt vielversprechende Potentiale meist ungenutzt. Der Ansatzpunkt des Architekturmanagements ist es, diese Potentiale identifizieren und zu nutzen.

2.1.2 Definition des Architekturmanagements

Niemann definiert im Jahr 2005 das Architekturmanagement als "verantwortlich für die Planung, Entwicklung, Nutzung und Pflege der Unternehmensarchitektur" (2005, S. 23). An diesem Verständnis zum Architekturmanagement hat sich bis heute nichts geändert. Ahlemann et al. (2012a, S. 20) bezeichnen EAM als eine Managementpraktik, im Rahmen welcher Leitplanken, Architekturprinzipien und Steuerungsgremien etabliert und gepflegt werden, welche richtungsweisend für den Entwurf und die Weiterentwicklung einer Unternehmensarchitektur sind, damit diese die ihr gestellte Vision und Strategie erreicht. Damit wird die bestehende Definition erweitert um konkrete Hilfsmittel, welche zur Pflege und Steuerung der Unternehmensarchitektur eingesetzt werden sollen: Leitplanken, Architekturprinzipien und Steuerungsgremien. Die Definition von Ahlemann et al. enthält ebenfalls eine Aussage über das Ziel, welches durch das Architekturmanagement verfolgt wird: die Unternehmensarchitektur in die gewünschte strategische und visionäre Richtung zu entwickeln.

Dabei ist es von zentraler Bedeutung, dass das Management der Unternehmensarchitektur die Übersetzung der real existierenden Komponenten in ein Modell wie beispielsweise die Architekturpyramide bedingt. Dennoch beschränkt sich das Architekturmanagement keinesfalls auf diese Modellierung und Dokumentation, diese dient lediglich als Grundlage für weitere Analysen und Aktivitäten (vgl. Schwarzer 2009, S. 22). Gartner identifizierte die Konzentration auf die Modellierung als einen typischen Fehler bei der Einführung von EAM (vgl. Sholler 2011a, S. 83). Das Ziel der Dokumentation der Unternehmensarchitektur sollte hierbei ein Modell sein, welches die reale Situation im Unternehmen vereinfacht abbildet, aber dennoch die vorhandene Komplexität hinreichend verdeutlicht (vgl. Gerlach und Zeiler 2011). Auch ist das Architekturmanagement keine IT-Funktion, sondern trägt stets den Fokus des gesamten Unternehmens. Dabei wird EAM in der Praxis häufig als Werkzeug zur Weiterentwicklung der Unternehmensstrategie angesehen, genau genommen unterstützt EAM jedoch vielmehr die Umsetzung der bereits entwickelten Strategie in operative Maßnahmen (vgl. Butler Group 2008, S. 214)

Zusammenfassend wird Architekturmanagement in der vorliegenden Arbeit als die Gesamtheit der Prozesse, Methoden und Hilfsmittel verstanden, welche den Entwurf, die Entwicklung und die Optimierung einer Unternehmensarchitektur durch die ganzheitliche Betrachtung von fachlichen und technischen Aspekten ermöglicht. Die Beweggründe der Unternehmen, ein EAM-Projekt zu starten und Architekturmanagement als festen Bestandteil innerhalb ihrer Organisation zu verankern, sind vielfältig. Im folgenden Abschnitt werden die Motive und Ziele des Architekturmanagements sowie die möglichen Nutzenpotentiale, die Unternehmen aus der Etablierung von EAM erwarten können, erläutert.

2.2 Ziele und Nutzen des Architekturmanagements

Die Disziplin des EAM ist kein neuartiger Trend, sondern blickt auf eine langjährige Historie zurück. Die Methoden und Hilfsmittel haben sich in den letzten Jahrzehnten stetig weiterentwickelt. Die Anfänge des Architekturmanagements gehen nach Aier et al. (2008, S. 292) auf Forschungsprojekten in Universitäten und Unternehmen vor allem im anglo-amerikanischen Raum in den 1970er und 1980er Jahren zurück. Seit dieser Zeit entwickelte sich EAM vom Nischendasein in vereinzelten Forschungsprojekten zu einer anerkannten Managementpraktik (vgl. Dern 2009, S. 11).

2.2.1 Typische Problemstellungen in der Praxis

Eingangs wurde bereits eine mangelnde Ausrichtung der IT auf die Geschäftsaktivitäten der Unternehmen als typische Motivation für die Etablierung eines Architekturmanagements genannt. Tatsächlich sind die Problemstellungen, welche die Unternehmen zur Einführung von EAM bringen, vielfältig. Durch die Finanzkrise stehen viele IT-Bereiche und stellvertretend die CIOs unter stetigem Kostendruck. Um diesem Kostendruck gerecht zu werden, wird meist das ohnehin knappe Innovationsbudget gekürzt. Nach Pfeifer senken die Unternehmen unabhängig von der Krise in den letzten Jahren ihr Innovationsbudget bereits seit den 1980er Jahren (2004, S. 43). Dabei handelt es sich zwar auf den ersten Blick um eine schnelle und wirkungsvolle Methode der Kostensenkung. Langfristig begibt sich der IT-Bereich dadurch aber auf eine Abwärtsspirale.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Entwicklung einer Architektur mit und ohne Architekturmanagement

Quelle: Durst (2007, S. 104); leicht modifiziert

Die Investitionen in Innovationen ermöglichen den Einsatz neuer Technologien und Systeme, durch welche die Kosten gesenkt oder die Effektivität gesteigert werden kann. Durch die Reduktion oder den gänzlichen Verzicht auf Innovationsinvestitionen beschneiden sich die Unternehmen des technologischen Fortschritts. Die bisherigen Kosten des Betriebs der IT-Landschaft werden dadurch langfristig steigen, so Niemann (2005, S. 32). Da auch in den Folgejahren mit immer neuen Anforderungen des Geschäfts zu rechnen ist, müssen diese Anforderungen stets zwangsläufig mit den bestehenden, veralteten Technologien realisiert werden. Hierdurch steigt die Komplexität der bestehenden Landschaft wodurch die IT-Betriebskosten ebenfalls signifikant ansteigen werden. Niemann (2005, S. 33) sieht das Architekturmanagement als geeignetes Werkzeug zum Durchbrechen dieser Abwärtsspirale. Durst (2007, S. 104) veranschaulichte diesen Effekt, welchen er anhand eines empirischen Kennzahlensystems nachweisen konnte (vgl. Abb. 2). Dabei vertritt Niemann die Meinung, dass Erfahrung und Qualifikation der IT-Mitarbeiter eine nachhaltige Pflege und Planung der Architektur zwar hinauszögern, aber nicht verhindern können (2005, S. 15).

Zusätzlich zur Abwärtsspirale des IT-Budgets existieren, eine Liste weiterer Problemstellungen, welche in der Praxis die Motivation für Architekturmanagement-Projekte darstellt. Die IT-Landschaften der Unternehmen sind im Laufe der Jahre historisch gewachsen (vgl. Barkow 2010, S. 15), nach Schmidt geht ihre Grundstruktur häufig bis auf die 1970er und 1980er Jahre zurück (2007, S. 230). Dabei wurden die verschiedenen Systeme, Komponenten und Strukturen durch immer neue Anforderungen des Geschäfts Schritt für Schritt um neue Elemente ergänzt. Insgesamt lief dieser Prozess jedoch ohne eine Steuerung und Planung ab. Die hierdurch wachsende Diskrepanz zwischen geschäftlichen Anforderungen und der IT-Landschaft verhindert eine schnelle und akkurate Entscheidungsfindung (vgl. Butler Group 2008, S. 213). Sämtliche Entscheidungen wurden auf reiner Kosten-Basis oder aufgrund der Abdeckung fachlicher Anforderungen getroffen, ohne den Blick auf die gesamte Architektur zu richten.

Ein Beispiel für eine solche Entscheidung lässt sich in einem Unternehmen, in welchem bisher eine SAP-Architektur aus verschiedenen Komponenten und Systemen dominierte, aufzeigen. In diesem Fallbeispiel laute die Anforderung aus dem Fachbereich an die IT, ein CRM-System zum Zweck der intensiveren Kundenbindung einzuführen. Hierzu evaluiert der IT-Bereich zwei mögliche Applikationen, welche hinsichtlich verschiedener Kriterien bewertet werden: diese seien die SAP CRM-Komponente und eine Komponente eins kleineren, regionalen Anbieters. Das System des regionalen Anbieters überzeugt besonders durch seinen Preis, welcher 30% unter dem der SAP-Komponente liegt. Hinsichtlich ihrer fachlichen Funktionalität seien die Angebote kongruent. Ohne Architekturpläne und ein etabliertes Architekturmanagement erscheint die Wahl des regionalen Anbieters als die günstigere Variante. Ein gewissenhaftes EAM zeigt in solchen Fällen ebenfalls die architektonischen Auswirkungen dieser Entscheidung auf. Durch die Wahl einer zusätzlichen Technologie entstehen bei der Einführung des Systems zusätzliche Kosten für die Integration und Anbindung an die SAP-Landschaft. Die Mitarbeiter benötigen zusätzliche Schulungen um Anpassungen an dem neu eingeführten CRM-System, da sich dieser Vorgang vom gewohnten Customizing im SAP-System unterscheidet. Die Liste der nicht bedachten Folgekosten ließe sich noch fortsetzen. Dieses Beispiel zeigt, dass Unternehmen ohne ganzheitliches Architekturmanagement zu sogenannten "Best of Breed"-Lösungen (Durst 2007, S. 23) greifen, welche im begrenzten Kontext als sinnvoll erscheinen, sich aber nicht in die Gesamtarchitektur integrieren lassen.

Aufgrund dieser und weiterer Problemstellungen starten die Unternehmen EAM-Projekte und versuchen das Architekturmanagement in ihrer Organisation zu etablieren. Meist haben sie dabei durchaus ambitionierte Ziele. Eine Auswahl dieser wird im Folgenden erläutert.

2.2.2 Treiber und Ziele des Architekturmanagements

Die unterschiedlichen Ziele der Unternehmen teilt Schwarzer (2009, S. 74) nach einer eingehenden Literaturanalyse in interne und externe Treiber ein (vgl. Abb. 3). Ein Großteil der Publikationen legt hierbei den Schwerpunkt auf die internen Treiber (vgl. Ahlemann et al. 2012b; Dern 2009; Keuntje und Barkow 2010).

Die internen Treiber des Architekturmanagements lassen sich dabei in die Steigerung der Effizienz der IT, Steigerung der Effektivität der IT, und die Qualität der IT gliedern (vgl. Schwarzer 2009, S. 74ff; Niemann 2005, S. 45). Die Effizienz der IT wird in bestehenden IT-Landschaften meist durch die vorherrschende Heterogenität der Systeme (sowohl Software- als auch Hardwaresysteme) bestimmt. Der Einsatz vieler unterschiedlicher Technologien ist maßgeblicher Kostenfaktor für den IT-Betrieb. So müssen die Mitarbeiter, die mit dem Betrieb der Systeme betraut sind jeweils auf die entsprechenden Technologien geschult werden. Der Einsatz verschiedener Technologien bedingt ebenfalls die Anschaffung und Pflege von Entwicklungstools. Hierbei sind vor allem die verschiedenen Lizenzen ein entscheidender Kostentreiber. Die heterogenen Landschaften verhindern in den meisten Fällen auch die sinnvolle Integration von Lösungen und die Wiederverwendung von bestehenden Komponenten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Treiber des Architekturmanagements, Quelle: Schwarzer (2009, S. 74); leicht modifiziert

Das Architekturmanagement bietet mit der ganzheitlichen Sicht auf die IT-Landschaft das Potential zur Reduktion der vorhandenen Komplexität und Homogenisierung der eingesetzten Technologien (vgl. Koll 2009a, S. 8). In der Praxis wird diese Homogenisierung und Standardisierung der Landschaft von den Unternehmen als Hauptziel des Architekturmanagements verstanden. Schmidt führte hierzu eine Untersuchung basierend auf 14 Experteninterviews durch. Die ausgewählten Experten verantworten das EAM in den jeweiligen Unternehmen (vgl. Schmidt 2009, S.62). Die Homogenisierung der Landschaft zielt gleichzeitig auch auf eine Kostensenkung der IT-Betriebskosten ab, weswegen diese Kostensenkung meist als explizites Ziel des EAM angeführt wird (vgl. Lochmaier 2009, S. 58; Buckl et al. 2010, S. 34-35).

Die Steigerung der Effektivität stellt einen weiteren internen Treiber des Architekturmanagements dar. Eine effiziente IT-Landschaft trifft keine Aussage über Sinnhaftigkeit der eingesetzten Komponenten. Daher wird unter der Effektivität der IT die Ausrichtung ebendieser auf die Geschäftsanforderungen verstanden. Dieses bereits eingangs erwähnte Ziel des Architekturmanagements ist vor allem langfristiger Natur. Zahlreiche Publikationen sehen diese Ausrichtung der IT als das zentrale Ziel des Architekturmanagements an (Dern 2009 S. 11; Godinez et al. 2010, S. 14; Schmidt 2007, S. 231). Die Optimierung der IT-Ausrichtung auf die Geschäftsanforderungen resultiert in der Praxis in einer Steigerung der Abdeckung der geschäftlichen Anforderungen. Da die flexible und zeitnahe Reaktion auf Änderungen meist eine eigene Anforderung der Fachbereiche darstellt, geht der Wunsch der optimalen Ausrichtung von IT und Geschäft auch mit einer gesteigerten Flexibilität der Landschaft einher. Hierdurch können neue fachliche Anforderungen schnell und kostengünstig realisiert werden. Denn eine aktuell optimal auf das Geschäft ausgerichtete Architektur ist nur bis zur nächsten fachlichen Anforderungen optimal ausgerichtet und steht dann unter Anpassungsdruck.

Die Steigerung der IT-Qualität stellt die letzte intern getriebene Zielkategorie des Architekturmanagements dar. Die hierunter fallenden Ziele decken sich teilweise mit denen des IT-Service-Managements. Die Qualitätsmerkmale der IT-Landschaft, welche durch ein gezieltes Architekturmanagement verbessert werden können, sind vielfältig. In erster Linie soll EAM durch die Schaffung von Transparenz die Risiken aufzeigen und minimieren, welche mit dem Betrieb der bisherigen IT-Landschaft verbunden sind. Durch die geschaffene Transparenz und das detaillierte Verständnis über die gesamte Architektur steigt ebenfalls die Sicherheit dieser. Im selben Zusammenhang soll die gesamte Architektur durch die Planung und Steuerung stabiler und belastbarer werden. Für den Betrieb der IT bedeutet dies eine geringere Anzahl an Störungen und eine effizientere Wartung der dennoch auftretenden Probleme (vgl. Durst 2007, S. 116). Stabilität bezieht sich jedoch nicht nur auf laufenden Betrieb, gleichzeitig gewinnen die einzelnen Architekturkomponenten durch das Architekturmanagement auch an Stabilität hinsichtlich möglicher Umgestaltungen oder Technologiewechsel (vgl. Schmidt 2007, S. 233). Dieser Effekt wird durch eine gezielte Skalierbarkeit der Architektur unterstützt. Im Gegensatz zur Flexibilität geht es hierbei nicht um inhaltliche Änderungen der fachlichen Anforderungen, sondern, um die Größe und den Umfang der benötigten Leistungen. Ziel des EAMs ist es somit, eine Architektur bereitzustellen, welche eine agile Änderung des Volumens der IT-Dienstleistung ermöglicht.

Ein typisches Geschäftsszenario für diese Anforderung ist der Zu- oder Verkauf von Unternehmensteilen. Kann die IT diese Änderungen durch eine entsprechende Skalierbarkeit realisieren, bleiben die eigentlich eingesetzten Anwendungen und Technologien unverändert und behalten ihre Stabilität.

Die externen Treiber für die Einführung eines Architekturmanagements gliedern sich in die Erfüllung gesetzlicher Vorschriften, externe Beziehungen und Übernahmen & Fusionen. Als externe Treiber werden alle Kräfte bezeichnet, welche von außen auf das Unternehmens einwirken. Je nach Branche und Umfeld des Unternehmens können die externen Treiber stärker oder schwächer ausgeprägt sein.

Die Erfüllung nationaler und internationaler Vorgaben und Auflagen nimmt hierbei eine gesonderte Stellung ein. Die Unternehmen haben in diesen Fällen meist keine Wahlmöglichkeit, sondern müssen sich der neuen Regelung innerhalb eines bestimmten Zeitrahmens anpassen. Ein Großteil dieser Auflagen bedingt auch eine Anpassung und Umgestaltung der Geschäftsprozesse und der IT-Landschaft des Unternehmens, um die sogenannte "Compliance" zu gewährleisten (vgl. Schmidt 2007, S. 230). Da die Unternehmen die gesetzlichen Auflagen in jedem Fall erfüllen müssen, sollte die IT-Landschaft auch hier eine größtmögliche Flexibilität aufweisen. Aufgrund der Erfahrungswerte der Unternehmen hinsichtlich der Häufigkeit und Strenge gesetzlicher Änderungen in ihrer Branche werden diese Vorschriften ein relevanter externer Treiber für die Einführung eines Architekturmanagements.

Die externen Beziehungen eines Unternehmens stellen einen weiteren Treiber einer EAM-Funktion dar. Hierbei ergeben sich ebenfalls Anforderungen an die Unternehmen, welchen sie gerecht zu werden versuchen. Im Gegensatz zu den gesetzlichen Auflagen, existiert bei externen Beziehungen meist Spielraum bei der angestrebten Umstellung der Prozesse und IT-Landschaften. Gründe für diese Umstellungen sind beispielsweise Anforderungen der Geschäftspartner aus der Liefer- und Absatzkette des Unternehmens. So kann die vertikale Integration des Unternehmens mit einem Hauptzulieferer konkrete technologische Anforderungen bedingen, welche durch die IT-Architektur erfüllt werden müssen. Auch die Zusammenarbeit in strategischen Allianzen oder die Auslagerung einzelner Geschäftsfunktionen im Rahmen eines Outsourcings kann die Einführung eines Architekturmanagements vorantreiben (vgl. Schwarzer 2009, S. 84). Hierbei benötigen die Unternehmen nach Schwarzer ein gewisses Maß an Transparenz über ihre Prozesse, Systeme und Architekturen, um die Leistungserbringung auslagern zu können (vgl. Durst 2007, S. 113). Diese Transparenz kann durch das EAM geliefert werden.

Fusionen und Übernahmen können ebenfalls eine Weiterentwicklung der bestehenden Architektur bedingen (vgl. Dern 2009, S. 154). Hierbei steht das Architekturmanagement vor der Herausforderung, die IT-Landschaften verschiedener Unternehmen effizient und effektiv zusammenzuführen. Nach Buchta et al. wird die Rolle der IT in der Vorbereitung und Durchführung eines solchen Zusammenschlusses immer wichtiger, um mögliche Synergieeffekte nutzen zu können (2010, S. 65). Schmidt sieht das Architektur-management in diesem Rahmen als Voraussetzung an, die gewünschten Synergien der Fusion oder Übernahme auch realisieren zu können (2009, S. 36).

Dennoch gilt sowohl bei Fusionen und Übernahmen als auch bei den restlichen internen und externen Treibern, dass die konkreten Beweggründe eines Unternehmens, ein Architekturmanagement zu etablieren, stets vom Umfeld und der jeweiligen Situation des Unternehmens abhängig sind. Dadurch besitzt jedes Unternehmen einen individuellen Zielkatalog, welcher mit der Einführung der EAM-Funktion realisiert werden soll. Die internen Treiber können unmittelbar als Ziele des Architekturmanagements verstanden werden. Die externen Kräfte, welche Unternehmen für die Einführung eines Architekturmanagement motivieren, sind verbunden mit dem Ziel der Steigerung der Flexibilität der Architektur, kürzeren Reaktionszeiten auf geänderte Geschäftsa-nforderungen und einer höheren Transparenz der bestehenden Architektur.

Zusammenfassend werden die Ziele des Architekturmanagements in der vorliegenden Arbeit als Schaffung von Transparenz über die bestehende Architektur und Steigerung der Effizienz, Effektivität, Flexibilität und Qualität der IT-Landschaft verstanden. Dabei ist zu beachten, dass häufig Konflikten zwischen den einzelnen Zielen auftreten können. So lässt sich eine angestrebte Kostensenkung meist nur bedingt mit einer optimalen Abdeckung aller fachlichen Anforderungen bei gleichzeitig exzellenter Qualität der IT-Landschaft realisieren. In diesem Fall muss zum Zeitpunkt der Einführung eines EAM eine klare Priorisierung der einzelnen Ziele vorgenommen werden. Hierbei legt das einführende Unternehmen individuell fest, welche Ziele zulasten anderer Ziele vorrangig erreicht werden sollen.

2.2.3 Quantifizierung strategischer Nutzenpotenziale

In der Praxis lässt sich der tatsächlichen Wertbeitrag, den die Etablierung einer EAM-Funktion für ein Unternehmen erbringt, nur schwer messen. Dennoch müssen Unternehmen die Einführung eines Architekturmanagements oft durch eine Wirtschaftlichkeitsanalyse substanziieren (vgl. Schwarzer 2009, S. 105). Dabei gab John Zachmann, EAM-Pionier, bereits 2001 zu denken, dass die Architektur eines Unternehmens einen Vermögenswert darstellt und das Architekturmanagement daher nicht hinsichtlich der Wirtschaftlichkeit untersucht werden sollte. EAM ist in jedem Fall eine Investition in eine bestehende Architektur, aus welcher das Unternehmen einen langfristigen Mehrwert schöpft, so Zachmann (2001, S. 9). Dennoch muss die Einführung einer EAM-Funktion in der Praxis häufig gegenüber Entscheidungsträgern gerechtfertigt werden. Zahlreiche Publikationen haben aus diesem Grund versucht, den Nutzen des Architekturmanagements zu quantifizieren. Der gesamte Wertbeitrag des Architekturmanagements setzt sich dabei aus der Summe zahlreicher Effekte zusammen (vgl. Abb 4).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung in dieser Leseprobe nicht enthaltenAbbildung 4: Wertbeitrag des Architekturmanagements auf den Unternehmensumsatz,Quelle: Durst (2007, S. 97)

Durst unterteilt die Ausgaben eines Unternehmens vereinfacht in Prozesskosten und IT-Kosten (2007, S.97). Hierbei werden unter Prozesskosten sämtliche Kosten verstanden, die nicht durch die IT des Unternehmens verursacht werden. Er argumentiert weiterhin, dass die angestrebten Ziele des Architekturmanagements zu Kostensenkungen beider Kategorien führen (vgl. dazu Kapitel 2.2.1). Eine verbesserte Ausrichtung der IT auf die Geschäftstätigkeit und damit eine gesteigerte Effektivität führt zu Einsparungen der Prozesskosten des Unternehmens. Die IT unterstützt dabei die Geschäftstätigkeit bei Aktivitäten, die zuvor manuell erledigt werden mussten oder nicht erledigt werden konnten. Gleichzeitig können die Prozesse des Unternehmens durch die im Rahmen der Dokumentation der Unternehmensarchitektur geschaffene Transparenz optimiert und standardisiert werden (vgl. Schwarzer 2009, S. 98). Zusätzlich zu Optimierungen der bestehenden Prozesse sorgt eine Steigerung der Flexibilität der Architektur für eine schnellere Reaktion auf geänderte Anforderungen. Hierdurch kann die eingangs in Kapitel 2 erwähnt Problematik, dass sich die Geschäftstätigkeit den IT-Systemen anpassen muss, vermindert oder gänzlich vermieden werden. Ganzheitlich betrachtet sorgt das Architekturmanagement hierdurch für Einsparungen bei den Prozesskosten. Gartner beziffert diese auf etwa 8-12% (vgl. Gall 2010, S. 8).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Wertbeitrag des Architekturmanagements auf das IT-Budget, Quelle: Durst (2007, S. 96)

Die in Abbildung 4 visualisierten Einsparungen der IT-Kosten, lassen sich noch weiter in den IT-Betrieb und IT-Projekte untergliedern (vgl. Abb 5). Diese Gliederung entspricht der in Kapitel 2.2.1 erwähnten Aufteilung des Budgets in Ausgaben für den IT-Betrieb und Innovationen. Kostensenkungen im IT-Betrieb durch Standardisierung und Homogenisierung der Infrastruktur stellen den offensichtlichsten Nutzen des Architekturmanagements dar. Die möglichen Einsparungspotentiale durch eine solche Konsolidierung werden von Niemann (2005, S. 188) auf 20-30% geschätzt. Ein ähnliches Ergebnis liefert Durst, welcher den Wertbeitrag zahlreicher Architekturmanagement-Einführungen auf Basis einer Literaturanalyse untersuchte. Nach Durst liegt das Einsparungspotenzial der IT-Kosten zwischen 5% und 30% (2007, S. 154).

Die Kosteneinsparungen des IT-Betriebs resultieren hauptsächlich aus der Konsolidierung der Infrastruktur. Durch eine homogenere, konsistentere und redundanzfreiere IT-Landschaft können neben den laufenden Betriebskosten auch die Wartungs- und Entwicklungskosten reduziert werden. Dabei steht den Unternehmen frei, die erzielten Kosteneinsparungen entweder für Budgetkürzungen im IT-Bereich oder Innovationen und neue Projekte aufzuwenden, so Schwarzer (2009, S. 94).

Über die bisher quantifizierten Effekte hinaus ergibt sich der Wert des Architekturmanagements meist nur indirekt (vgl. Mach 2010). Die durch die Dokumentation geschaffene Transparenz über die Zusammenhänge der bestehenden Architektur dient der Ermittlung, Bewertung und Vermeidung von Risiken. Dies trägt langfristig zur Senkung von architekturrelevanten Projekten wie beispielsweise der Integration neuer Systeme oder Konsolidierung bestehender Komponenten bei. Dennoch ist eine Quantifizierung dieser Einsparungen im Vorfeld nicht durchführbar, da entsprechende Zusammenhänge meist erst im Laufe der Dokumentation aufgedeckt werden. Auch tragen weitere Nutzenpotenziale wie eine Steigerung der Reaktionsfähigkeit der IT zu einer Vielzahl von weiteren positiven Effekten bei, doch auch diese lassen sich im Vorfeld nicht überschauen und beziffern.

Daher sollte die Einführung eines Architekturmanagements, wie von Zachmann bereits vor über zehn Jahren gefordert, nicht auf Basis einer reinen Wirtschaftlichkeitsanalyse entschieden werden, da sich zahlreiche Potenziale des Architekturmanagements erst während der Durchführung aufzeigen. Die Betrachtung der Unternehmensarchitektur als Vermögenswert eines Unternehmens hilft hierbei einer Argumentation auch abseits einer Wirtschaftlichkeitsanalyse. Andere Vermögenswerte wie Humankapitel oder der Wert der eigenen Marke haben bereits eine selbstverständlichere Daseinsberechtigung, hier besteht für das Architekturmanagement noch Nachholbedarf.

[...]

---

^[1] Die Begriffe Enterprise Architektur Management (EAM), Management der Unternehmensarchitektur und Architekturmanagement werden in der vorliegenden Arbeit synonym verwendet.