In dieser zweiten Serie zum Thema Enterprise Architecture Management geht es um Frameworks für Enterprise Architecture Management (EAM). Die erste EAM-Serie hat sich in drei Teilen ausführlich den Definitionen der Begriffe Architektur, Unternehmensarchitektur (Enterprise Architecture) und Unternehmensarchitekturmanagement (Enterprise Architecture Management) gewidmet.

Im ersten Teil der aktuellen Serie will ich zunächst eine Definition für Enterprise Architecture Frameworks, hier abgekürzt mit EAF, herleiten. Quellenangaben zu dieser Serie finden sich gesammelt an zentraler Stelle.

Enterprise Architecture Management Frameworks

Allein in der Informatik gibt es eine Vielzahl unterschiedlicher Frameworks. Exemplarisch seien hier drei genannt, die Programmierern die Arbeit durch vorgefertigte Bausteine erleichtern sollen. So liefern Frameworks für ContentManagement-Systeme wie TYPO3 beispielsweise Module für Datenbankzugriffe mit. Im bekannten Webframework JSF (Java Server Faces) wird das Model-View-Controller Konzept umgesetzt. View-Komponenten werden häufig durch JSP (Java Server Pages) realisiert, während der Controller in Java geschrieben werden kann und Java-Beans für das Modell vorgesehen sind. Diese bei weitem unvollständige Liste soll durch das Test-Framework JUnit abgeschlossen werden, welches dabei hilft, Java-Programme automatisiert auf Fehler zu überprüfen.

Da es auch außerhalb der Informatik, unter anderem in der Medizin (vgl. [GMC13]), Frameworks gibt, unternimmt dieser Beitrag zunächst den Veruch einer Definition, um Begriffsklarheit zu schaffen. Die Vorstellung zweier Meta-Enterprise-Architecture-Frameworks in einem weitere Beitrag dieser Serie soll einen Überblick über zentrale Elemente von EAFs geben. Konkrete Frameworks werden dann schließlich in gesonderten Beiträgen vorgestellt.

Begriffsbildung

Frameworks für Unternehmensarchitekturen haben sich von den Anfängen, in denen alle wesentliche Informationen in einem Diagramm dargestellt werden sollten ([EE03]) bis hin zu Frameworks, die für einzelne Fragestellungen Stakeholder spezifische Sichten anbieten (z.B. [BELM08]), weiterentwickelt.

Das Zachman-Framework, nach heutiger Wahrnehmung das erste Framework für Enterprise Architecture Management ([Zac87]), erkennt die Notwendigkeit, die vielen Architekturkonzepte und Spezifikationen zu strukturieren, um Missverständnisse in der professionellen Kommunikation zu vermeiden. Methoden und Werkzeuge zur Entwicklung von Architekturen sollen ebenso berücksichtigt werden. Als Ergebnis soll ein Framework glaubhafte und vertrauenswürdige IT-Investitionen ermöglichen. Die Definitionen der ersten EAM-Serie entstammen direkt aus ISO/IEC/IE-EE 42010 oder bauen auf den dort genannten Definitionen auf.

Der ISO/IEC-Standard enthält ebenfalls eine Definition von Frameworks, mit der wir hier starten werden:

Definition 1: Framework

Ein Framework ist eine Menge von Konventionen, Vorgaben und Verfahrensweisen für Architekturbeschreibungen in einer bestimmten Anwendungsdomäne für eine Gruppe von Stakeholdern.

Diese Serie beschäftigt sich ja mit Frameworks für EAM. Also erarbeiten wir aus der allgemeinen Definition eines Frameworks eine konkrete für EAFs: Die Anwendungsdomäne dieser allgemeinen Definition lässt sich für uns natürlich leicht durch Enterprise Architecture Management konkretisieren. Die allgemeinen Architekturbeschreibungen aus der Definition werden zu Unternehmensarchitekturbeschreibungen. In diesem Kontext sind die Unternehmensarchitekten (auch EA-Architekt) diejenigen, die das EAF benutzten, und damit die primäre Gruppe von Stakeholdern.

EAF-Bestandteile

Modellierungstechniken, Viewpoints und die wechselseitigen Beziehungen werden in [Lan13] als EAF-Bestandteile genannt. Darüber hinaus wird gefordert, dass die EAFs keine Konzepte für die eigentliche Modellierung enthalten. Es wird jedoch eingeräumt, dass einige Frameworks eng mit einer Modellierungssprache verbunden sind. Dies gilt zum Beispiel für die Sprache ArchiMate ([TOG13]) und TOGAF ([TOG11b]). ArchiMate ist eine standardisierte Notation mit der Aspekte einer EA beschrieben werden können ([dBBvB+07]) und seit 2008 unter der Verwaltung der Open Group steht. Aktuell ist seit 2013 die Version 2.1 ([TOG13]). TOGAF versteht sich als Framework und definiert sich selbst als eine Struktur für Inhalte und Verfahren, um zum einen Denkprozesse zu strukturieren und zum
anderen um Konsistenz und Vollständigkeit sicherzustellen (vgl. den entsprechenden Teil dieser Serie).

weitere Bestandteils

Ausführlicher und konkreter nennt [Sch04b] EAF-Bestandteile. Demnach gehören Modelle, Grundsätze, Services, Vorgehensweisen, Standards, Designkonzepte, Bausteine, Visualisierungen und Konfigurationen, die die Entwicklung einer Architektur leiten, zu einem EAF. Darüber hinaus wird ein EAF als ein Kommunikationsmodell zur Entwicklung einer EA definiert. Ein EAF beschreibt somit,
welche Kommunikation notwendig ist, um eine EA zu entwickeln. Damit knüpft die Definition an die von [Zac87] an, die am Beginn dieses Abschnitts zur Begriffsbildung steht.

Ein EAF dient dazu, viele unterschiedliche Architekturen zu entwickeln. Daher sollte es nach [TOG11a] eine Methode für den Entwurf von Informationssystemen enthalten, die wiederverwendbare Building Blocks (BB, Bausteine im Sinne von Vorlagen) verwendet und aufzeigt, wie die BBs zusammenpassen ([SEK07]). Zusätzlich sollen Werkzeuge, ein verbindliches Glossar und eine Liste empfohlener Standards und Produkte enthalten sein, die bei der Implementierung der BBs unterstützen.

Demgegenüber definiert [ZW06] ein EAF bewusst abstrakt als eine Dokumentationsstruktur für Unternehmensarchitekturen, um keine Implikationen bezüglich des intendierten Abstraktionsgrades der Architekturdokumentation zu geben.

In der bisherigen Diskussion können mindestens zwei Sichten auf EAFs identifiziert werden: Zum einen ist ein EAF ein strukturgebendes Instrument und zum anderen liefert es Beschreibungen für bestimmte Tätigkeiten, in [Pos11] zusammengefasst als methodisches Wissen. Dies spiegelt sich auch im Standard ISO/IEC/IEEE 42010 wieder, der neben der oben genannten Definition in Bezug
auf einen aktiven Anteil, wieder allgemein für Frameworks, wie folgt ausführt: Ein Framework etabliert übliche Vorgehensweisen, um Architekturbeschreibungen zu erstellen, zu interpretieren und zu analysieren ([ISO11]). Explizit unbeschränkt wird eine Liste von Verwendungsmöglichkeiten von Frameworks genannt, auf deren Auflistung hier verzichtet wird.

Als Ergebnis dieser Diskussion wird ein EAF für diese Arbeit wie folgt definiert.

Definition 2: Enterprise Architecture Framework

Ein Enterprise Architecture Framework (EAF) ist ein Werkzeugkasten, den ein EA-Architekt nutzen kann, um die Entwicklung verschiedener EAs zu begleiten und kontinuierlich gesteuert weiter zu entwickeln. Zu den Werkzeugen zählen methodisches Wissen und strukturierende Elemente.

Zu den wichtigsten Bausteinen des methodischen Wissens zählen Richtlinien, Entwurfskonzepte und Vorgehensweisen, um eine EA zu erstellen, zu interpretieren und zu analysieren und dabei den strukturierenden Rahmen eines EAFs zu nutzen. Dieser Rahmen sollte Konzepte enthalten wie ein Glossar, Empfehlungen für Modellierungssprachen, bewährte Metamodelle und Standards. Es sollen konkrete Sichten auf die Informationsmodelle und Teilmodelle im Sinne von Bausteinen definiert werden, um bestimmte Fragestellungen von Rollen zu adressieren. Daneben können Werkzeuge beschrieben werden, die die Anwendung des methodischen Wissens erleichtern und den strukturierenden Rahmen in Form eines Repositories zugänglich machen. Unabhängig von der technischen Realisierung
bietet ein Repository Zugriff auf alle EA bezogenen Daten, auf Instanz- wie auf Metamodellebene.

Bekannte Vertreter der EAFs sind Zachman, TOGAF und DoDAF ([Abr13, LJJ+06, LM11]). Sie beschreiben Strukturierungsaspekte und Prozesse, die zum Aufbau und Nutzung einer EA herangezogen werden können, wobei die Prozessunterstützung von EAM an einigen Stellen verbesserungswürdig ist ([GSS12]). Dennoch helfen die Vorgaben und Prozesse dabei Abweichungen festzustellen, um frühzeitig gegensteuern zu können, damit EAM-Aufgaben nicht in schwer aufzuholenden Rückstand geraten. Rückstände, die auf Planungsfehler zurückzuführen sind, lassen sich meist nicht durch Personalaufstockung aufarbeiten, denn Brook’s Law sagt: „adding manpower to a late […] project makes it later“([Bro95]). Dies gilt insbesondere für Aufgaben wie EAM, deren Erfolg von den Erfahrungen und dem Wissen der involvierten Personen abhängig ist ([Mat11]).

Exkurs in die Meta-Ebene

In einem weiteren Teil dieser Serie werden zwei Frameworks vorgestellt, die vorgeben, welche Inhalte ein EAF haben sollte und wie diese zueinander in Beziehung stehen. Damit werden diese Frameworks zu Meta-EAFs. Auf diesen Meta-EAFs basierende konkrete EAFs erfüllen die in diesem Abschnitt erarbeitete Definition eines EAFs. Im Verständnis von [Fav04a, Fav04b] können Systeme die Rolle eines Modells bzgl. eines anderen Systems einnehmen. Modelle sind Abstraktionen eines Systems und dafür geeignet, einen bestimmten Zweck zu erfüllen, beispielsweise Aussagen über das System zu treffen, ohne das System selbst zu untersuchen.

Modelle werden in einer Modellierungssprache formuliert und beschreiben in ihr das System oder Teile dessen. Sprachen werden als Menge von Systemen aufgefasst. Eine Modellierungssprache ist eine Menge von Modellen. So sind alle UML Modelle selber Elemente der UML, auch wenn sie jedes für sich genommen unterschiedliche Systeme modellieren. Das Modell einer Modellierungssprache, also das Modell einer Menge von Modellen, wird Metamodell genannt. Ein Metamodell ist somit nicht das Modell eines Modells.

Zusammenfassung

Dieser Beitrag wurde länger als gedacht.

Auf Basis einer ausführlichen Literaturdiskussion habe ich zunächst die Begriffe Framework und Enterprise Architecture Management Framework definiert. Im nächsten Teil der Serie werde ich auf die zeitliche Entwicklung, sowie einige grundsätzlich Vor- und Nachteile von Frameworks eingehen.