Der Artikel beleuchtet Ursprung, Aufbau und Nutzen von Enterprise Architecture Frameworks (EAFs) wie TOGAF und Zachman. Neben Definitionen und Bestandteilen werden auch typische Schwächen und Risiken diskutiert – etwa der hohe Komplexitätsgrad und die Abhängigkeit vom Erfahrungsstand der Beteiligten. Ein persönliches Fazit zeigt, wie man Frameworks sinnvoll und pragmatisch einsetzt.
Blogartikel lesen
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.
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.
Der ISO/IEC-Standard enthält ebenfalls eine Definition von Frameworks, mit der wir hier starten werden:
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.
Wenn du noch tiefer ins Thema einsteigen willst: Im Beitrag Enterprise Architecture Management (EAM) verständlich erklärt bekommst du eine kompakte Einführung in Begriffe, Ziele und Rollen im EAM.
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.
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.
Wie sich komplexe Architekturkonzepte visuell und zielgruppengerecht darstellen lassen, zeigen wir im Artikel Best-Practice EAM Visualisierungen.
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.
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]).
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.
Das Bild setzt einige Frameworks zeitlich zueinander in Beziehung.
Grundlage für diese Darstellung sind angepasste Graphiken aus [Mat11, Min08, Sch04b]. Die X-Koordinate der linken Kante eines jeweiligen Rechtecks gibt den Zeitpunkt auf der X-Achse an, zu welchem das Framework erschienen ist. Die Ausnahme bildet links oben die „GRAI Method“, die aus Gründen der Darstellbarkeit optisch im Jahr 1987 liegt, jedoch schon 1980 erschien. Die Y-Koordinate der Rechtecke hat keine Semantik.
Direkte Vorgänger-/Nachfolgerbeziehungen werden durch eine Linie repräsentiert. Ist ein Framework die Grundlage für ein anderes, so verbindet sie ein Pfeil. Es wird nur die erste und jeweils aktuelle Version der Frameworks, sowie relevante Zwischenversionen angezeigt. Die Leserichtung der Linien und Pfeile ist immer chronologisch.
Die oben platzierten ISO/IEC/IEEE Standards sind zwar keine Frameworks im Sinne der anderen, enthalten jedoch für die meisten nach ihnen erschienenen Werke terminologische Grundlagen. Für weitere Details zu den einzelnen Frameworks siehe [Mat11, Sch04a], bzw. die jeweilige, zum Teil öffentlich zugängliche, Originaldokumentation.
In [Mat11] sind Vor- und Nachteile von EAFs aufgeführt, die hier als Tabelle wiedergegeben werden. Für die ausführliche Analyse sei auf die Quelle und die dort zitierten Primärquellen verwiesen.
Pro
Contra
Bei der kurzen Liste der Nachteile kann der Eindruck erweckt werden, dass kein Weg an Frameworks für das Enterprise Architecture Management vorbeiführt. Jedoch fasst der dritte Punkt der gelisteten Nachteile, Erfolgsfaktor: Erfahrung, viele Gefahren des EAF-Einsatzes zusammen. Der Einsatz darf nicht zum Selbstzweck werden.
EAFs schlagen viele Modelle und Sichten vor. Daraus ergeben sich Kritikpunkte, die auch von [SLJ+05] aufgegriffen wurden. Bei der Vielzahl der zur Verfügung stehenden Modelle ist oft nicht zweifelsfrei zu entscheiden, warum welches Modell gegenüber einem anderen zu bevorzugen ist, oder es bleibt unklar, welche Fragestellungen mit den Modellen beantwortet werden sollen. Da EAFs alle möglichen Aspekte abdecken wollen, entsteht bisweilen eine lange und im schlimmsten Fall schwammige Dokumentation.
Relevante Informationen werden nicht erkannt und bleiben für Unerfahre-ne verschlossen. Ein Parameter des Erfolgsfaktors „Erfahrung“ ist es, sich nicht auf die Methoden und Werkzeuge zu fokussieren, sondern den Menschen „dahinter“ einen größeren Stellenwert einzuräumen [ML12]. Denn diese haben in der Regel eine natürliche Abneigung gegen Veränderungen ihrer bekannten Arbeitsabläufe ([SEK07]).
Damit werden das Stakeholdermanagement und das ChangeManagement neben den zentralen EAM-Methoden zu den wichtigsten Elementen, die von einem EAF adressiert werden sollten.
Für die Kommunikation im Stakeholdermanagement und Change-Management spielen neben einem Glossar die EA-Prinzipien (EAP) eine wichtige Rolle. Sie stellen allgemeine und dauerhaft gültige Regeln und Richtlinien dar. Dabei unterliegen sie seltenen Änderungen und bieten involvierten Stakeholdern einen Rahmen, an welchem sie ihre Entscheidungen orientieren können.
Beispielsweise soll nach einem EAP die Wiederverwendung von Anwendungen im Unternehmen maximiert werden, da redundante Systeme unnötige Kosten verursachen. So ist bei der Entwicklung und beim Zukauf abzuwägen, ob eine neue Anwendung notwendig ist, oder ob vorhandene Systeme die anfallenden Aufgaben bereits abdecken ([TOG11b]).
Es gibt keine fundierte Theorie, wie EAP auf Korrektheit, Konsistenz und Vollständigkeit hin untersucht werden könnten. Dazu wird in [ZML12] auf Basis einiger Prinzipien aus TOGAF die Kybernetik als passender theoretischer Rahmen für EAP identifiziert. Nach klassischem Verständnis untersucht die Kybernetik die Kommunikation von Tieren mit Maschinen. In der Gegenwart hat sie sich weitläufiger der Steuerung und Kommunikation in Systemen zugewandt, inklusive soziotechnischen Systemen wie Unternehmen ([ZML12]).
Stakeholder sollen die EAP als Rahmen für ihre Entscheidungen nutzen, dabei aber nicht die Unternehmensziele vernachlässigen. Welche Fragen in der Praxis besonders häufig gestellt werden – und wie man sie mit einem passenden EAF beantwortet – erfährst du im Beitrag Typische EAM-Fragestellung: Wer nutzt was wofür?.
Daher sollen die Treiber und Ziele eines Unternehmens in Einklang mit den vorgeschriebenen EAP sein. In [GP11] wird ein Prozess vorgestellt, der diesen Zusammenhang berücksichtigt und Prinzipien aus den Unternehmenstreibern entwickelt.
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 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.
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 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 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 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 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 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 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 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.
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 beispielsweise in [BMR+10, LM11, THC04a, Wie04] genannten Elemente werden von GERAM und zum Teil auch von EAF2 abgedeckt.
Die Open Group, eine Vereinigung von aktuell weltweit über vierhundert Firmen, organisiert ihre inhaltliche Arbeit in unterschiedlichen Foren. Das Architecture Forum verantwortet The Open Group Architecture Framework – TOGAF, das seit Ende 2011 in der aktuellen Version 9.1 vorliegt ([TOG11b]). Die erste Version basierte 1995 auf dem Technical Architecture Framework for Information Management (TAFIM) des US amerikanischen Verteidigungsministeriums und ist ebenfalls Vorfahre des bekannten Department of Defense Architecture Framework (DoDAF, [Sch04b]).
In den letzten Jahren hat sich TOGAF neben dem ersten Framework für Enterprise Architecture Management, dem Zachman-Framework, zum in der Literatur am meistgenannten EAF entwickelt ([LJJ+06, LM11]). In Bezug auf die Verbreitung in der Praxis hat TOGAF das Zachman-Framework bereits überholt ([Roh08, Abr13]) und wird als de facto Standard bezeichnet ([BBDF+12]). Die Architekturunterteilung (s.u.) von TOGAF in Geschäftsprozesse, Applikationen, Daten und Infrastruktur wird bereits seit einigen Jahren, z.B. von [LRR03], als allgemein akzeptiert bezeichnet, wobei auch Unterteilungsalternativen bestehen.
TOGAF beschreibt ein EAF als eine Menge von Strukturen, die für die Entwicklung verschiedener Architekturen genutzt werden können. Ein EAF sollte eine Entwurfsmethode enthalten, mit der ein Zielzustand des Unternehmens definiert werden kann. Dabei sollen Building Blocks verwendet werden und diese explizit miteinander in Verbindung gesetzt werden. Darüber hinaus sollten ein Glossar sowie Techniken und Werkzeuge enthalten sein. Auch sollen Standards und Produkte empfohlen werden, die für die Umsetzung der Building Blocks verwendet werden können.
TOGAF ist in neun Teile strukturiert, wovon der erste Teil neben einem Überblick über Inhalte vor allem Definitionen der zentralen Begriffe enthält. Weitere Definitionen finden sich im Anhang von TOGAF.
Der zweite Teil enthält die Archtitecture Development Method (ADM), die im Bild dargestellt ist.
Die ADM definiert ein phasenbasiertes Vorgehen, um eine EA schrittweise zu entwickeln. Dazu werden zunächst Bedürfnisse des Geschäfts adressiert und danach die IT-Planung begonnen. Das Geschäft als Treiber und Ausgangspunkt der Betrachtungen zu nehmen, hat sich als erfolgreiches Muster erwiesen ([SHL09]). Unterstützendes Material, wie Richtlinien und von der ADM genutzte Techniken, sind im dritten Teil zusammengefasst.
Teil vier umfasst das Content Framework. Dessen wesentliche Bestandteile sind das Metamodell, das Entitäten und Relationen zur Modellierung einer EA bereitstellt, sowie die Beschreibungen der Ergebnisdokumente und Artefakte, die von der ADM erzeugt werden.
Mit dem Enterprise Continuum und zugehörigen Werkzeugen wird im fünften Teil ein Repository vorgestellt, das alle relevanten Informationen strukturiert speichert. Dazu gehören unter anderem Modelle, Architekturmuster und Architekturbeschreibungen, übliche Standards und genutzte Building Blocks.
Zwei Referenzmodelle beanspruchen den sechsten Teil von TOGAF. Zum einen das Foundation Architecture: Technical Reference Model (TRM) und zum anderen das Integrated Information Infrastructure Reference Model (III-RM).
Um EAM als Aktivität im Unternehmen umsetzen zu können, sind bestimmte Anforderungen an die Organisationsform, Prozesse, Fähigkeiten, Rollen und Verantwortlichkeiten zu erfüllen. Diese werden letztlich im siebten Teil, im Architecture Capability Framework, diskutiert.
Das Kernelement von TOGAF bildet die ADM, deren Phasen im Folgenden überblicksartig vorgestellt werden. Den Einstieg in einen ADM-Zyklus bildet die Vorbereitungsphase, in der eine Bestandsaufnahme der aktuellen Fähigkeiten des Unternehmens erfolgt und die Rahmenbedingungen für die folgenden Phasen gesetzt werden, beispielsweise in Form von Schlüsseltreibern, Architekturprinzipien und zu nutzenden Werkzeugen.
Phase A sorgt zunächst für den Aufbau einer Infrastruktur für die Architekturarbeit (z.B. Personal, Arbeitsplätze, etc.). Es wird der Umfang (scope) der Architekturarbeit festgelegt und eine high-level Vision der Ziele formuliert, die mit ihr zu erreichen sind. Dafür werden die relevanten Stakeholder identifiziert, deren Concerns aufgenommen und Kennzahlen definiert, mit denen die Zielerreichung gemessen werden soll. Ein iteratives Vorgehen in den ersten beiden Phasen ist möglich.
Phase B erfasst den Ist-Zustand der Geschäftsarchitektur, die unter anderem die Aufbauorganisation mit ihren Standorten und die Geschäftsprozesse (GP) umfasst. Nachdem der Soll-Zustand der Geschäftsarchitektur definiert wurde, werden die Unterschiede (Gaps) zwischen Ist und Soll identifiziert. Die notwendigen Schritte zur Beseitigung der Gaps werden in Form einer Roadmap skizziert, die in den folgenden Phasen verfeinert wird.
Phase C wird in die Schritte Data Architecture und Application Architecture geteilt. Sowohl für die Daten als auch für die Anwendungen werden der jeweilige Ist-Zustand erfasst, ein Soll-Zustand definiert und Gaps identifiziert. Die Roadmap wird mit den Informationen aus dieser Phase ergänzt. Die beiden Teilphasen können iterativ durchlaufen werden.
Phase D geht wie die vorherigen beiden Phasen vor. Hier liegt der Fokus auf den technischen Systemen, die die Softwaresysteme, Daten und letztlich die Prozesse unterstützen. Speziell für die wiederkehrende und für Planungszwecke zentrale Aufgabe der Gap-Analyse eignen sich spezielle Informationsmodelle und Systeme, wie sie in [GP10, PSS09, Sec09] beschrieben werden.
Phase E erstellt die erste vollständige Version der Roadmap und leitet aus dieser Arbeitspakete ab, die in vorläufige Projekte, Programme oder Portfolios zusammengefasst werden. Der in den vorherigen Phasen definierte Zielzustand kann über in dieser Phase definierte Zwischenschritte, so genannte Transitionsarchitekturen, erreicht werden.
Phase F erarbeitet aufbauend auf den Ergebnissen der vorherigen Phasen einen detaillierten Umsetzungsplan, der von vollständig definierten Projekten erfüllt werden soll. Zwischen den Phasen E und F sind Iterationszyklen vorgesehen, wie auch für die Phasen B bis einschließlich F.
Phase G übernimmt die Kontrollfunktion über die Umsetzungsarbeiten und steuert sie kontinuierlich auf die Zielarchitektur hin. Dazu werden Reviews der laufenden Projekte durchgeführt und Projektergebnisse evaluiert.
Phase H beobachtet Veränderungen und stellt Mittel bereit, um auf Veränderungen zu reagieren. Beispielsweise werden Technologieveränderungen oder Änderungen im Geschäft mit möglichen Auswirkungen auf die jeweiligen Ist-Zustände der Architekturen beobachtet. Auch werden Projekte in den Geschäftsbereichen begleitet, damit die Potenziale der Architekturveränderungen der vorherigen Phasen gehoben werden können.
Diese Phase kann iterativ mit Phase G ausgeführt werden und einen neuen Durchlauf des gesamten ADM-Zyklus verursachen, wenn festgestellt wird, dass die festgestellten Veränderungen zu große Konsequenzen haben, als das sie parallel zum Tagesgeschäft durchgeführt werden können.
Das Requirements Management schließlich ist mit allen Phasen verbunden, um Anforderungen zu jeder Zeit erfassen zu können.
Anforderungen werden kontinuierlich verwaltet, bewertet, priorisiert und an den entsprechenden Stellen in einen ADM-Zyklus zurückgeführt. Dadurch können Iterationen ausgelöst und der gesamte ADM-Zyklus neu angestoßen werden.
ArchiMate ist eine EA-Modellierungssprache, die seit 2008 von der Open Group betreut wird und seit 2013 in der Version 2.1 vorliegt ([TOG13]). Die Entwicklung ist unabhängig von bestimmten Werkzeugen oder Herstellern. Die konkrete graphische Syntax der Sprache soll dazu genutzt werden, einheitliche Diagramme von Sichten auf Unternehmensarchitekturen zu erstellen.
Das Metamodell enthält verschiedene Entitäten und entsprechende Relationen, um EAs inklusive ihrer Veränderungen über die Zeit, d.h. Transformation- und Migrationsplanung, sowie die Treiber hinter den Veränderungen abzubilden. Zusätzlich enthält der Standard verschiedene Viewpoints. So werden Fragestellungen von verschiedenen Stakeholdern adressiert. ArchiMate verfolgt einen 80:20-Ansatz, um so minimal wie möglich zu sein und dabei so viele Einsatzszenarien wie möglich abzudecken.
Mechanismen zur Erweiterung ermöglichen die Anpassung der Sprache, um Entitäten und Relationen zu modellieren, die vom Standard nicht abgedeckt werden.
Wie viele Definitionen von Unternehmensarchitekturen unterscheidet der Kern des Metamodells drei Ebenen. Unterschieden werden Business Layer, Application Layer und Technology Layer. Es werden Relationen zwischen den Entitäten der Ebenen und ebenenübergreifende Relationen definiert. Für die Entitäten des Metamodells und die Relationen werden jeweils graphische Elemente vorgeschrieben. Diese werden in den Diagrammen genutzt, um die Typen der Modellelemente schnell erkennen und von einander unterscheiden zu können.
Die Entitäten jeder Ebene werden einem von drei Typen zugeordnet. Aktive Strukturen (active structures) wie Akteure, Applikationen sind definiert als Entitäten, die in der Lage sind, Verhalten zu zeigen. Das Verhalten (behavior element) ist definiert als eine Aktivität, die von einer oder mehreren aktiven Strukturen durchgeführt wird. Das Verhalten wird an passiven Elementen (passive structure) wie Datenobjekten durchgeführt. Die Namen der drei Konzepte sind von natürlichen Sprachen inspiriert, wo Subjekt (active structure), Verb (behavior element) und Objekt (passive structure) die wesentlichen Sprachelemente bilden.
Die drei Ebenen und drei Typen werden erweitert durch Elemente, die die Beweggründe und Begründungen hinter einer EA beschreiben (motivational element), um die Ziele und Bedürfnisse einzelner Stakeholder modellieren zu können (motivation extension).
Die zweite Erweiterung (implementation and migration extension) dient dazu, die Planungselemente wie Arbeitspakete, Meilensteine und Projekte zu modellieren, die geplant und durchgeführt werden, um unterschiedliche Zustände einer EA zu planen und zu realisieren. Der Anspruch ist, die wesentlichen Konzepte von Projektmanagementstandards wie PMBOK abzudecken.
Zu allen Entitäten und Relationen des Metamodells inkl. den zwei Erweiterungen liegen textuelle Beschreibungen der Semantik vor. ArchiMate ist in der aktuellen Version von der Open Group auf das Content Metamodell von TOGAF 9.1 abgestimmt, so dass sich die Viewpoints, die in TOGAF unabhängig von einer konkreten Modellierungssprache definiert werden, konsistent mit ArchiMate realisieren lassen.
Frameworks sind im EAM unverzichtbar – aber oft auch überfrachtet. In diesem Artikel zeige ich dir, was Enterprise Architecture Frameworks leisten sollen, wo ihre Grenzen liegen und warum Erfahrung im Umgang mit ihnen der eigentliche Schlüssel zum Erfolg ist.
