Der Artikel liefert einen fundierten Einstieg in die Begriffswelt rund um Enterprise Architecture und Enterprise Architecture Management (EAM). Er beleuchtet die Ursprünge der Disziplin, stellt zentrale Definitionen vor und grenzt EAM als dauerhafte Managementaufgabe klar vom klassischen Projektbegriff ab.
Blogartikel lesen
In dieser Beitragsserie will ich den Versuch unternehmen, die Begriffe Enterprise Architecture (Unternehmensarchitektur) und Enterprise Architecture Management zunächst zu definieren und danach einen Einblick in die typischen Aufgaben dieser Disziplinen zu geben.
In einem Artikel von 1987 wurden Analogien zwischen „klassischer“ Architektur im Sinne der Baukunst, und der Architektur von Informationssystemen verwendet, um ein Framework zu motivieren, das Informationssysteme und deren Umwelt als Modelle erfasst ([Zac87]). Das Zachman Framework wird allgemein als Grundstein der Disziplin der Unternehmensarchitektur betrachtet.
In der Literatur ist trotz der bisher vergangenen Zeit noch keine allgemein anerkannte Definition der Begriffe Unternehmensarchitektur und des Managements einer Unternehmensarchitektur zu finden (vgl. [ARW08, BEL+09, vdRBSvV10, vdRSPvV04, Rad11, Sch08, SW09]). Im nächsten Abschnitt sollen daher ein entsprechender Anlauf unternommen werden.
Das Wort Unternehmensarchitektur ist ein Kompositum aus zwei Substantiven. Mit dem Begriffsbestandteil Unternehmen ist die abstrakte Beschreibung einer eine wirtschaftliche Einheit bildenden Organisationseinheit gemeint. Diese kann wiederum mehrere andere Organisationseinheiten umfassen, die ein gemeinsames Ziel verfolgen.
In der Betriebswirtschaftslehre ist ein Betrieb definiert als eine „planvoll organisierte Wirtschaftseinheit, in der Produktionsfaktoren kombiniert werden, um Güter und Dienstleistungen herzustellen und abzusetzen“. Ein Unternehmen ist ein „Betrieb im marktwirtschaftlichen Wirtschaftssystem“, einer liberalen „Wirtschaftsordnung, die den Wirtschaftssubjekten Vertragsfreiheit und Privateigentum garantiert“ ([WU05]).
Ein Unternehmen ist ein mehrheitlich privater Betrieb, der autonom und nach erwerbswirtschaftlichen Prinzipien handelt, d.h. er strebt nach Gewinnmaximierung (vgl. [VSK12]). Damit sind die drei konstitutiven Merkmale Autonomieprinzip, erwerbswirtschaftliches Prinzip und das Prinzip des Privateigentums, für ein Unternehmen erfüllt ([SW08]).
Für die weitere Definition EAM ist sowohl die weitere rechtliche und betriebswirtschaftliche Differenzierung der Begriffe öffentlicher/privater Betrieb und öffentliches/privates Unternehmen, als auch ihre weitere Präzisierung unmaßgeblich. Darüber hinaus wäre die Beschränkung auf nur profitorientierte Unternehmen irreführend, da auch gemeinnützige Organisationen (non-profit) und öffentliche Institutionen wie Behörden Betrachtungsgegenstand von Unternehmensarchitekturen sind.
Der IEEE Standard 1471-2000 ([IEE00]) enthält eine der ersten formalen Beschreibungen des Begriffs Architektur ([Hil01]). Die in 2011 aktualisierte Fassung ISO/IEC/IEEE 42010:2011 ([ISO11]) definiert, was die Architektur eines Systems ausmacht. Der Systembegriff ist dabei explizit nicht beschränkt und kann somit mehr als Hardware-/Softwaresysteme umfassen.
Die Architektur eines Systems umfasst die Grundkonzepte und Eigenschaften eines Systems in seiner Umwelt, verkörpert durch dessen Elemente, Relationen und durch die Prinzipien seines Entwurfs und seiner Evolution.
Die für die Architektur des Systems verantwortliche Rolle wird Architekt genannt. Die folgende Abbildung zeigt ein UML-Klassendiagramm mit einigen Entitäten und Relationen des konzeptuellen Modells aus ISO/ IEC/IEEE 42010.
![Die Entitäten und Relationen des konzeptuellen Modells für Architekturbeschreibungen nach [ISO11].](https://cdn.prod.website-files.com/67fd0d76c7a5198b98bc3451/6819e4479a69d39edfa8c364_architektur.jpeg)
Ein Stakeholder kann eine Person oder eine Organisationseinheit sein, die eine Rolle innehaben und aus dieser heraus ein Interesse an einem System haben. Stakeholder werden oft durch ihre Rolle identifiziert (Entwickler, Tester, Architekt, etc). Ein Concern beschreibt das Anliegen eines Stakeholders, das dieser im Bezug auf ein System hat. Die Architektur des Systems, das in seine Umwelt eingebettet ist, wird in der Architekturbeschreibung formuliert.
Darüber hinaus enthält die Architekturbeschreibung Views, die bestimmte Anliegen von Stakeholdern adressieren. Ein Viewpoint adressiert die Anliegen von Stakeholdern, indem er die Konventionen zur Erstellung, Interpretation und Benutzung von Views spezifiziert, d.h. er ist die formale Beschreibung des für den Stakeholder relevanten Teils der Architektur. Zu den Konventionen gehören auch Model Kinds, d.h. Typen von Architekturmodellen.
Beispielsweise kann ein Viewpoint vorgeben, dass ereignisgesteuerte Prozessketten genutzt werden, um Prozessmodelle zu beschreiben, die in einem View genutzt werden sollen, um Concerns einiger Stakeholder in Bezug auf ein System zu adressieren.
Ein Framework hat einen bestimmten Anwendungskontext und unterstützt die identifizierten Stakeholder bei ihren Concerns beispielsweise durch Richtlinien, die im jeweiligen Kontext gelten. Die Bestandteile einer Architekturbeschreibung können je paarweise an einer Relation teilnehmen, die Correspondence heißt und gemeinsam mit Correspondence Rules dazu dienen kann, die Konsistenz von Modellen zu sichern.
Gibt es beispielsweise in Unternehmensmodellen die Correspondence abteilungHatMitarbeiter kann es zusätzlich eine Regel geben, die fordert, dass es keine Abteilungen ohne Mitarbeiter geben darf.
Im Gegensatz zur deutschen Sprache gibt es neben dem Substantiv architecture im Englischen das Verb to architect. Das Verb beschreibt nach [ISO11] den Prozess, die Architektur eines Systems während dessen Lebenszyklus zu konzipieren, zu definieren, zu formulieren, zu dokumentieren, zu kommunizieren, ihre ordnungsgemäße Umsetzung zu zertifizieren, sie zu warten und zu verbessern. Die Architekturbeschreibung aus der obigen ist ein Arbeitsergebnis dieser Tätigkeit.
Jedes System hat eine Architektur und es kann Teil eines anderen Systems
sein. Wird die Architektur des Gesamtsystems betrachtet, so ist es wichtig, ein zu sammenhängendes – kohärentes – Bild zu erstellen. Der Standard ISO/IEC/IEEE 42010 trifft keine Aussagen über die Elemente, die ein System ausmachen. Damit lässt sich der Systembegriff auf Unternehmen anwenden. Ein Unternehmen setzt sich demnach aus seinen Teilen zusammen, die eine Architektur haben, und folglich hat das Unternehmen selbst eine Architektur, die Unternehmensarchitektur.
Einige Veröffentlichungen (vgl. [Roh05, Sch05, Wit07, WS08, TOG11b]) leiten ihre Definition der Unternehmensarchitektur von IEEE 1471 und ISO/IEC/IEEE 42010 ab ([IEE00, ISO11]). Nach diesem Vorgehen definiert [Lan13] Unternehmensarchitektur als ein kohärentes Ganzes, bestehend aus Prinzipien, Methoden und Modellen, die während des Entwurfs und der Umsetzung der Organisationsstruktur, der Geschäftsprozesse, der Informationssysteme und der Infrastruktur eines Unternehmens genutzt werden.
Die in [Lan13] aufgeführte Definition überträgt den von IEC/ISO/IEEE 42010 abstrakt definierten Architekturbegriff auf ein Unternehmen. Dabei verliert sie an Explizität und schränkt auf die vier Ebenen Organisationsstruktur, Geschäftsprozesse, Informationssysteme und Infrastruktur ein. Die nach [Add10] drei wesentlichen Ebenen Geschäftsebene, Anwendungsebene und IT-Infrastrukturebene werden berücksichtigt. Die Ausdrucksfähigkeit der fünf Ebenen, die in [WF06, WF07] vorgestellt und in [ARW08] präzisiert wurden, wird nicht erreicht. Damit komme ich für diese Beitragsreihe zu folgender Definition.
Eine Unternehmensarchitektur (engl. Enterprise Architecture, EA; Plural: EAs) umfasst als kohärentes Ganzes die wesentlichen Konzepte eines in seine Umwelt eingebetteten Unternehmens, verkörpert durch seine Elemente und deren Beziehungen untereinander und zur Umwelt sowie die Methoden, Modelle und Prinzipien, die beim Entwurf und bei der gesteuerten Evolution des Unternehmens genutzt werden.
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“.
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.
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.
Wie daraus in der Praxis konkrete Visualisierungen entstehen, erfährst du im Artikel „Eine EAM Visualization entsteht …“.
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]). Wie EAM dabei helfen kann, auch sicherheitskritische IT-Bereiche transparent darzustellen, erfährst du im Artikel „Visualisierungen für IT-Security Management“. 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. Wie du diese strukturiert und überzeugend visualisierst, zeigt der Beitrag „Best-Practice EAM Visualisierungen“. 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.
Was genau ist eigentlich „Enterprise Architecture Management“ – und warum ist es so schwer, eine einheitliche Definition zu finden? In diesem Artikel starte ich eine Serie, die Begriffe wie Unternehmensarchitektur und EAM verständlich erklärt – fundiert, aber zugänglich.
