Definition EAM – erster Teil

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. Die anderen Beiträge sind die hier: Teil 2, Teil 3.

Den Text habe ich erstmals in [Gri15] veröffentlicht. Die darin verwendeten Quellen werden an dieser Stelle gesondert aufgeführt. Die Liste wächst mit jedem Beitrag dieser Serie.

Architektur und Unternehmensarchitektur

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.

Begriffsbildung Architektur

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.

Definition 1. Architektur

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.

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.

Weiter geht’s in Definition EAM – Teil 2.