In den Teilen eins und zwei dieser dreiteiligen Beitragsreihe habe ich an die Begriffe Architektur und Unternehmensarchitektur herangeführt. Der Spannungsbogen findet hier nun mit der Definition EAM, als des Enterprise Architecture Managements seinen Höhepunkt und gleichzeitg seinen Abschluss.

Unternehmensarchitektur als Disziplin

Die für die Unternehmensarchitektur verantwortliche Rolle ist der Unternehmensarchitekt. Um den aktiven Anteil im Umgang mit Unternehmensarchitekturen explizit zu berücksichtigen, definiert [EHH+08] die Architekturdisziplin, die die Menge von Prinzipien und Methoden umfasst, um die Architektur eines Systems zu erstellen. Die Definition der Architekturdisziplin ist nicht so weitreichend, wie die Beschreibung der Tätigkeit architecting aus ISO/IEC/IEEE 42010. Auch in [Kel12] wird die Trennung der zwei Aspekte betont. So werden das Substantiv „Unternehmensarchitektur als Struktur“ und die Tätigkeit „Unternehmensarchitektur als Management“ unterschieden. Die Tätigkeit im Wortsinne findet sich auch in der Definition der „EA-Function“ in [vdRBSvV10].

Als kontinuierliche Aufgabe, und damit den aktiven Teil von Unternehmensarchitekturen betonend, berücksichtigt [vdM09] die Definitionsbestandteile nach [Vak09] und definiert wie folgt: Enterprise Architecture is the continuous practice of describing the essential elements of a sociotechnical organization, their relationships to each other and to the environment, in order to understand complexity and manage change. Diese Definition zählt zu den fünf als am passendsten von den Mitgliedern der Open Group bewerteten Definition des Begriffs „Enterprise Architecture“.

Wettbewerb um die Definition EAM

Einen regelrechten Wettbewerb um eine 160 Zeichen kurze Beschreibung des Zwecks von Unternehmensarchitekturen wird in [Pra10] beschrieben. Das Ergebnis ist jedoch nicht eine von einem einzelnen gegebene Antwort, sondern eine aus allen über 200 Einreichungen synthetisierte Antwort: Der Zweck einer Unternehmensarchitektur ist to enable an enterprise to realise its Vision, by Strategic Planning, Architecture and Governance, using Models, Guidance, Processes and Tools. Die offensichtlich vorhandene Notwendigkeit nach einem von vielen Mitgliedern getragenen definierten Begriffsverständnis zeigt auf, dass die Definitionslücke nicht nur in der wissenschaftlichen Literatur bekannt ist (vgl. z.B. [MBDS11]).

In [TD13] wird der architecting-Prozess aus ISO/IEC/IEEE 42010 zusammengefasst als architecure management. Aus der Diskussion ergibt sich mit der Definition 2: Unternehmensarchitektur das Unternehmensarchitekturmanagement, das wie folgt definiert wird.

Definition 3: Unternehmensarchitekturmanagement

Unternehmensarchitekturmanagement (engl. Enterprise Architecture Management, EAM) ist die kontinuierliche und andauernde Managementaufgabe, die essenziellen Elemente (EA) eines Unternehmens, ihre wechselseitigen Beziehungen untereinander und zur Umwelt, zu beschreiben, zu analysieren und zu planen, um die Komplexität verständlich zu machen und die Evolution der Organisation zu managen.

In dieser Definition wird EAM nicht als einmaliges Projekt aufgefasst, sondern als eine kontinuierlich durchzuführende Tätigkeit beschrieben. Bereits in [AKL99a] und [AKL99b] wird darauf hingewiesen EAM nicht als Projekt, sondern als Prozess zu begreifen. Ein Projekt wird vom Deutschen Institut für Normung in seiner Normenreihe DIN 69901 als ein Vorhaben beschrieben, das im
Wesentlichen durch die Einmaligkeit der Bedingungen wie zum Beispiel Zielvorgabe, zeitliche, finanzielle, personelle und andere Begrenzungen, sowie einer spezifischen Organisation und durch die Abgrenzung zu anderen Vorhaben, gekennzeichnet ist. Das Project Management Institute (PMI) definiert ähnlich in [PMI08a, PMI08b]. EAM ist nicht durch eine Einmaligkeit, sondern im Gegenteil durch eine Dauerhaftigkeit ohne zeitliche Begrenzung gekennzeichnet, sodass es nicht das eine EAM-Projekt in Unternehmen gibt.

In der Definition 3 ist EAM explizit als Aufgabe des Managements eines Unternehmens charakterisiert. Eine typische Herausforderung, die im EAM beispielsweise gemeistert werden muss, ist, dass die bei den Mitarbeitern zum Teil nicht beliebten EA-Aufgaben, wie Datenerfassungen ([MJBS09]), nicht zeitnah und korrekt umgesetzt werden. Daher ist ein sich zum EAM bekennendes Management
für den Erfolg essenziell ([AKL99b]). Ein Mangel an Strenge (Striktheit) in der Umsetzung im Bereich des EA-Governance kann nach [Lam04, SEK07, SHL09] ein Stolperstein für EAM werden. Für weitere Gründe, die eine EA-Initiative negativ beeinflussen können, siehe [Ant07, AKL99b, Der09, LKL10, Lam04, SEK07, SHL09].

Einzelne Arbeitsergebnisse, die im Rahmen von EAM erzeugt werden und die bestimmte Architekturaspekte beschreiben, heißen Artefakte. Beispiele für solche Artefakte sind Stakeholderlisten, Matrizen, die Akteuren bestimmte Rollen zuweisen oder Diagramme von Wertschöpfungsketten. Ein Ergebnisdokument (engl. deliverable) umfasst in der Regel mehrere Artefakte und hat einen formaleren Charakter. Ergebnisdokumente stellen Ergebnisse von einzelnen EAM-Arbeitspaketen oder Phasen dar, die von Stakeholdern abgenommen werden. Hierzu zählen unter anderem die Anforderungsdefinition oder die Architekturdefinition.

Zusammenfassung

Hiermit endet die Beitragsreihe „Definition EAM – ein ausführlicher Versuch“. Im ersten Teil wurde definiert, was eine Architektur ist, der zweite Teil hat das Unternehmen ins Spiel gebracht. Der Bogen zum Management und damit zum Enterprise Architecture Management wurde von diesem Beitrag geschlagen. Die verwendeten Quellen habe ich an zentraler Stelle aufgelistet.

Beiträge zu den eigentlichen Aufgaben des EAM und wie Visualisierungen sinnvoll dabei eingesetzt werden können, sind in Planung. Bis es soweit ist, finden Sie hier eine Serie zu Enterprise Architecture Management Frameworks.