Im ersten Teil dieser Serie wurde an den Begriff des Enterprise Architecture Management Frameworks (EAF) herangeführt. Der zweite Teil enthält einen kurzen historischen Abriss zum Thema und einige Vor- und Nachteile von EA-Frameworks.
Nach der Definition von EA-Frameworks wissen wir aber irgendwie immer noch nicht genau, welche konkreten Bestandteile so ein EAF hat. Um zu beschreiben, welche Elemente zu einem vorliegenden Untersuchungsgegenstand gehören, nutzen Informatiker gerne die „Meta-Ebene“ und bedienen sich der Meta-Modellierung. Aus meiner eigenen leidigen Erfahrung weiß ich, dass Meta-Modellierung die Hirnwindungen von nicht Eingeweihten ganz schön verknoten kann.*
<Exkurs>
Das Thema Meta-Modellierung allein ist schon wieder mehrere Beiträge wert, daher verweise ich an dieser Stelle auf zwei Artikel von Jean-Marie Favre, der sich dem Thema auf unkonventionelle aber dennoch lesenswerte Art genähert hat. So viel sei verraten: seine beiden Texte spielen im alten Ägypten. Teil 1 [PDF], Teil 2 [PDF]. Eine kurzen Exkurs auf die Meta-Ebene findet sich auch gegen Ende des ersten Teils dieser Serie.
*Die weiteren Teile dieser Serie sind auch nachvollziehbar ohne diesen Beitrag gelesen zu haben.
</Exkurs>
Aber nun zurück zum eigentlichen Gegenstand dieses Beitrags: Frameworks für Enterprise Architecture Management bzw. der Beschreibung ihrer Bestandteile. Gleich werden zwei Frameworks (GERAMund EAF2) 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 (z.B. TOGAF) erfüllen die im ersten Teil dieser Serie erarbeitete Definition eines EAFs.
Meta-Frameworks für Enterprise Architecture Management: GERAM und EAF2
Der Standard ISO 15704:2000 Requirements for Enterprise Reference Architectures and Methodologies wurde als Framework entwickelt, um Anforderungen an EAFs zu formulieren, damit EAM-Aktivitäten ausreichend adressiert werden.
Die Generalised Enterprise Reference Architecure and Methodology (GERAM) wurde in den 1990er Jahren entwickelt und in der Version 1.6.3 im Jahre 2000 als Anhang zum Standard ISO 15704 publiziert (vgl. [IFI99, ISO00]). Entworfen wurde es mit der Intention „to organise existing enterprise integration knowledge“. Daher umfasst es „all knowledge needed for enterprise engineering/integration“ und stellt nach eigenem Verständnis ein allgemeines Framework dar, um Komponenten zu beschreiben, die „in all types of enterprise engineering/enterprise integration processes“ benötigt werden. Nach heutigem Verständnis kann GERAM’s „enterprise engineering/ integration“ mit EA und EAM gleichgesetzt werden. Daher wird in der Vorstellung von GERAM vom ursprünglichen Wortlaut abgewichen.
GERAM erfüllt die Anforderungen von ISO 15704 hinsichtlich eines Frameworks für EAFs. Somit können EAFs gegen GERAM in Bezug auf Vollständigkeit analysiert werden. GERAM nimmt die Rolle eines Meta-EAFs bzgl. EAFs ein.
GERAM enthält neun Hauptkomponenten und beschreibt deren Zusammenspiel. Im Folgenden werden die Komponenten vorgestellt.
Dabei ist zu beachten, dass GERAM zum einen an mehreren Stellen explizit herausstellt, dass die enthaltenen Konzepte erweiterbar sind, und zum anderen der ganze Standard in diesem Beitrag natürlich nicht reproduziert werden soll. Die folgenden Konzepte und enthaltenen Beispiele haben damit keinen Anspruch auf Vollständigkeit, decken jedoch den für diese Beitragsserie Informationsbedarf ab. Für Details sei auf [ISO00] und [IFI99] verwiesen.
GERA – Generic Enterprise Reference Architecture
GERA definiert allgemeine unternehmensbezogene Konzepte, die sich in drei Hauptkategorien unterteilen lassen und für EAM empfohlen werden.
Personenorientierte Konzepte
Diese Konzepte umfassen Fertigkeiten (skill), Fähigkeiten (capability), Wissen, Kompetenzen und Rollenbeschreibungen. Letztere definieren die Rolle von Personen in der Aufbauorganisation und in den
operativen Teilen eines Unternehmens. Mit Bezug zur Aufbauorganisation geht es um Entscheidungsebenen, Verantwortlichkeiten und Autorität. Die operativen Rollen beziehen sich auf Personen als Ressource, die in den Prozessen des Unternehmens eingesetzt werden. Demzufolge sollen Modellierungskonzepte vorhanden sein, die die beschriebenen Informationen abbilden.
Technologieorientierte Konzepte
Technologie wird nach ihren Fokussen, entweder auf Produktionsabläufe oder auf Managementtätigkeiten, unterschieden. Die Informationen, an welchen Produktions-, Monitoring- und Verwaltungsprozessen
die Technologien verwendet werden, wird in entsprechenden Modellen beschrieben. Typische Modelle sind in diesem Bereich Kommunikationsmodelle wie Netzwerktopologiemodelle, Ressourcenmodelle, Grundrisse und Infrastrukturmodelle.
Prozessorientierte Konzepte
Um die Beschreibung von Prozessen (Geschäftsprozesse und Organisationsprozesse) zu ermöglichen, sollten die folgenden Konzepte adressiert werden können.
- Lebenszyklusphasen
- Lebensdauer
- Entitäten
- Modellierungs-Framework
EEM – Enterprise Engineering Methodology
EEMs sollen den gesamten Lebenszyklus von Entitäten abdecken. Sie enthalten Prozesswissen über EAM und beziehen die Rollen von Personen im Unternehmen als aktive und passive Elemente einer EEM explizit mit ein. Eine Prozessbeschreibung mit Inputs/Outputs, genutzten Ressourcen und involvierten Rollen ist notwendig, um einen reibungslosen Ablauf zu ermöglichen. Dazu können die Prozesse in einer im Unternehmen vorhandenen Modellierungssprache (siehe EML) formuliert werden. EEMs können andere Methoden enthalten, so zum Beispiel eine Modellierungsmethode, die eine EML einsetzt. Um wirtschaftlich zu sein, sollten EEMs ebenfalls Projektmanagementwissen enthalten und dabei zumindest die drei Phasen Start-up, Monitoring und Controlling während der Ausführungsphase und eine Abschlussphase berücksichtigen.
EMLs – Enterprise Modelling Languages
EMLs definieren allgemeine Modellierungskonzepte, die genutzt werden, um EA-Modelle zu erstellen. Die Sprachen sollen alle Aspekte des Lebenszyklusmodells und des GERA-Modellierungs-Frameworks abdecken können. Da die Modelle unterschiedliche Anforderungen erfüllen müssen, können parallel mehrere Sprachen im Einsatz sein, z.B. BPMN zur Prozessbeschreibung, ER-Diagramme zur Datenmodellierung und RACI zur Beschreibung von Verantwortlichkeiten (vgl. [OMG11a, SJ05]). Die Auswahl der passenden Sprachen und der notwendigen Ausdrucksstärke ist abhängig von der EEM.
GEMCs – Generic Enterprise Modelling Concepts
GEMCs definieren und formalisieren die allgemeinen Konzepte von EA-Modellen. Die Konzepte können in natürlichsprachlichen Glossaren, Metamodellen, Taxonomien oder Ontologien festgehalten werden. Unabhängig davon, welche und wie viele der vorstehenden Möglichkeiten gewählt wird, ist auf Konsistenz zu achten. Dies gilt auch in Bezug auf die verwendeten EMLs.
PEMs – Partial Enterprise Models
PEMs sind wiederverwendbare (Teil-) Modelle, die typische Unternehmenseigenschaften enthalten und so in vielen EA-Szenarien genutzt werden können. Um konkrete Modelle für ein Unternehmen aus PEMs zu erstellen, müssen diese ggfs. erweitert werden. Beispiele für PEMs sind Vorlagen für die Aufbauorganisation eines Unternehmens mit Rollenbeschreibungen oder branchenspezifische Prozesse. PEMs
können den Modellierungsaufwand verringern.
EETs – Enterprise Engineering Tools
EETs unterstützen EAM-Aufgaben dadurch, dass sie Aktivitäten oder Prozesse von EEMs implementieren, EMLs unterstützen und Zugriff auf Modelle des Unternehmens und deren Analyse ermöglichen. Weiterhin enthalten EETs ein Repository, das alle relevanten EA-Elemente speichert.
EMOs – Enterprise Modules
EMOs können konkrete am Markt vorhandene Produkte sein oder Personen, die ein bestimmtes Fertigkeitenprofil (Skills) erfüllen. EMOs können Realisierungen von PEMs sein.
EMs – Enterprise Models
EMs sind Modelle von konkreten Entitäten, die die Realität ausreichend gut abbilden, um statt der eigentlichen Entität analysiert werden zu können. EMs werden in EMLs formuliert.
EOSs – Enterprise Operational Systems
EOSs unterstützen den Betrieb bestimmter Entitäten (z.B. Unternehmen). Sie bestehen aus all den materiellen Komponenten (z.B. Hardware/Software), die notwendig sind, um die an die Entität gestellten Anforderungen zu adressieren. Die Implementierung von EOSs wird von EMs geleitet, die die Systemspezifikationen enthalten und die zu nutzenden EMOs identifizieren.
EAF2
In 2009 wurde das Framework for categorizing Enterprise Architecture Frameworks EAF2 veröffentlicht ([FHK+09]). Dieses Meta-EAF formuliert Anforderungen an den Inhalt von EAFs. So soll eine Vollständigkeitsbewertung existierender EAFs ermöglicht werden. Die vom EAF2 deklarierten EAF-Bestandteile werden im Bild dargestellt und im Folgenden mit den bekannten GERAM-Konzepten verglichen.
Die EAF2-Elemente lassen sich in die beiden Kategorien Architecture Governance und Modeling Concepts aufteilen, wobei letztere laut [FHK+09] von GEMCs inspiriert sind. Der Governance-Subprozess Architecture Development Process leitet sich unter anderem aus den Architekturentwicklungsprozessen von TOGAF, DoDAF und MoDAF her. Diese entsprechen dem GERA-Konzept der Lebenszyklusphasen. Der andere Subprozess Architecture Maintenance Process beschreibt die iterative Weiterentwicklung entlang der sich ändernden Anforderungen eines Unternehmens, was durch die GERA-Konzepte Lebenszyklusphasen in Kombination mit der Lebensdauer einer Entität abgedeckt wird.
Entscheidungsaspekte, wie sie durch Architecture Guidelines/Principles beschrieben werden, lassen sich nach [Nor04] durch eine Spezialisierung eines GERAM-Views abdecken, die in der Komponente GERA definiert werden. Auch eine von GERAMs Anforderungen an EMs lautet, dass sie Entscheidungsunterstützung im EAM liefern sollen. Darüber hinaus werden Prinzipien von der EEM-Anforderung der Wirtschaftlichkeit erzeugt, um in der Lage zu sein, Compliance Assessments durchführen zu können.
Die in [FHK+09] beschriebenen Anforderungen an Building blocks und Patterns werden ähnlich von GERAM an PEMs und EMOs gestellt. Architecture Roles/Skills werden von GERA durch Rollenbeschreibungen und von EEMs durch explizite Berücksichtigung von Rollen als aktive und passive Prozesselemente der Methoden berücksichtigt.
GERAM enthält keine explizite Forderung nach einem Maturity Model als Teil eines EAF, adressiert die Weiterentwicklung einer EA jedoch durch deren Lebensdauer. Die in einer EEM vorgesehene Review-Phase zur Bewertung der Compliance von Architekturprojekten adressiert teilweise das EAF2-Element Architecture Guideline and Review Process.
Angedeutet wurde die gedankliche Verwandtschaft von GEMCs und den Modelling Concepts, die in den Teilelementen Model Taxonomie sowie Metamodels deutlich wird. Reference Models entsprechen den PEMs und Viewpoints werden, wie im Absatz zu GERAs Modellierungs-Framework besprochen, von Views adressiert. GERAs erweiterbares Entitätenkonzept erfüllt die in [FHK+09] formulierten Eigenschaften von Entity Type, Attribute Type und Relationship Type.
Zwischen den beiden Veröffentlichungen von GERAM und EAF2 liegen zehn Jahre. Aus der Diskussion der beiden Meta-EAFs wird gefolgert, dass sich das Verständnis über EAF-Inhalte gefestigt hat. Dieser Eindruck wird bestätigt durch einzelne Veröffentlichungen, die keine Meta-EAFs beschreiben, sondern für ihren Forschungskontext zentrale EAF-Elemente auflisten und beschreiben. Die bei-
spielsweise in [BMR+10, LM11, THC04a, Wie04] genannten Elemente werden von GERAM und zum Teil auch von EAF2 abgedeckt.
Zusammenfassung
Dieser Beitrag hat hauptsächlich die beiden Meta-EAFs GERAM und EAF2 vorgestellt. Warum? Nunja, irgendwie muss man ja einen Bezugspunkt schaffen, um beschreiben zu können, welche Elemente ein Framework für Enterprise Architecture Management hat.
Im nächsten Teil schauen wir uns aber endlich ein erstes EAF an: TOGAF. Das wohl am weitesten verbreitete Framework der Open Group. Das beste: es ist öffentlich zugänglich. Hier gehts direkt zum The Open Group Architecture Framework. Das gedruckte PDF ist ca. 700 Seiten lang.