Rahmenwerk für die Unternehmensarchitektur

Ein Enterprise Architecture Framework ( EAF ) definiert die Erstellung und Anwendung einer Enterprise-Architektur . Es bietet Prinzipien und Vorgehensweisen für die Erstellung und Nutzung der Architekturbeschreibung eines Systems. Das EAF strukturiert das Denken von Architekten, indem es die Architekturbeschreibung in Domänen, Schichten oder Sichten unterteilt und Modelle – typischerweise Matrizen und Diagramme – zur Dokumentation jeder Sicht bereitstellt. Dies ermöglicht systemische Designentscheidungen für alle Systemkomponenten sowie langfristige Entscheidungen hinsichtlich neuer Designanforderungen, Nachhaltigkeit und Support. ^{[ 2 ]}

Die Unternehmensarchitektur betrachtet das Unternehmen als ein großes und komplexes System oder System von Systemen . ^{[ 3 ]} Um den Umfang und die Komplexität dieses Systems zu bewältigen, bietet ein Architekturrahmenwerk Werkzeuge und Ansätze, die Architekten dabei helfen, von der Detailebene, auf der Entwickler arbeiten, zu abstrahieren, um die Aufgaben des Unternehmensdesigns in den Fokus zu rücken und eine wertvolle Architekturbeschreibungsdokumentation zu erstellen.

Die Komponenten eines Architektur-Frameworks bieten eine strukturierte Anleitung, die in drei Hauptbereiche unterteilt ist: ^{[ 4 ]}

• Architekturbeschreibungen: Wie dokumentiert man das Unternehmen als System aus verschiedenen Perspektiven? Jede Perspektive beschreibt einen Ausschnitt der Architektur; sie umfasst jene Entitäten und Beziehungen, die für bestimmte Interessengruppen relevant sind; sie kann in Form einer Liste, einer Tabelle, eines Diagramms oder einer komplexeren Kombination dieser Elemente vorliegen.
• Methoden zur Architekturgestaltung: Prozesse, die Architekten befolgen. Üblicherweise handelt es sich um einen übergeordneten Enterprise-Architekturprozess, der aus Phasen besteht, die wiederum in detailliertere Prozesse mit feineren Aktivitäten unterteilt sind. Ein Prozess wird durch seine Ziele, Eingaben, Phasen (Schritte oder Aktivitäten) und Ausgaben definiert. Er kann durch Ansätze, Techniken, Werkzeuge, Prinzipien, Regeln und Praktiken unterstützt werden.
• Organisation von Architekten: Leitfaden zur Teamstruktur und zur Führung des Teams, einschließlich der erforderlichen Fähigkeiten, Erfahrungen und Schulungen.

Die frühesten Anfänge der schrittweisen Planungsmethodik, die derzeit vom Open Group Architecture Framework (TOGAF) und anderen EA-Frameworks befürwortet wird, lassen sich auf den Artikel von Marshall K. Evans und Lou R. Hague mit dem Titel „Master Plan for Information Systems“ ^{[ 7 ]} zurückführen, der 1962 in der Harvard Business Review veröffentlicht wurde.

Seit den 1970er Jahren suchen IT-Fachleute nach Möglichkeiten, die Geschäftswelt einzubinden, um Geschäftsprozesse und -rollen zu ermöglichen und Investitionen in betriebliche Informationssysteme und -technologien zu beeinflussen – mit Blick auf den umfassenden und langfristigen Nutzen für das Unternehmen. Viele der Ziele, Prinzipien, Konzepte und Methoden, die heute in EA-Frameworks Anwendung finden, wurden in den 1980er Jahren entwickelt und sind in IS- und IT-Architektur-Frameworks aus diesem und dem darauffolgenden Jahrzehnt wiederzufinden. ^{[ 8 ]}

Bis 1980 wurde IBMs Business Systems Planning (BSP) als Methode zur Analyse und Gestaltung der Informationsarchitektur einer Organisation mit folgenden Zielen propagiert:

1. die Probleme und Chancen der aktuellen Anwendungen und der technischen Architektur verstehen;
2. einen zukünftigen Zustand und einen Migrationspfad für die Technologie entwickeln, die das Unternehmen unterstützt;
3. Bereitstellung eines Leitfadens und Entscheidungsrahmens für IT-Investitionen für Führungskräfte;
4. Dem Informationssystem (IS) einen Entwicklungsplan zur Verfügung stellen.

1982 entwarf John Zachman während seiner Tätigkeit für IBM und BSP sein Rahmenwerk für eine unternehmensweite „Informationssystemarchitektur“. Damals wie auch in späteren Veröffentlichungen verwendete Zachman den Begriff „Unternehmen“ synonym mit „Geschäft“. „Obwohl viele gängige Planungsmethoden, Entwurfsansätze und verschiedene Werkzeuge und Techniken für Informationssysteme eine unternehmensweite Analyse nicht ausschließen oder ihr widersprechen, befassen sich nur wenige explizit mit Unternehmensarchitekturen oder versuchen, diese zu definieren.“ ^{[ 9 ]} In diesem Artikel wurde der Begriff „Unternehmensarchitektur“ jedoch nur einmal ohne spezifische Definition erwähnt, und in allen nachfolgenden Arbeiten Zachmans wurde der Begriff „Informationssystemarchitektur“ verwendet. ^{[ 10 ] [ 11 ]}

Im Jahr 1986 wurde das PRISM-Architekturframework als Ergebnis eines Forschungsprojekts entwickelt, das von einer Gruppe von Unternehmen, darunter IBM, gefördert wurde und anscheinend das erste veröffentlichte EA-Framework war.

1987 veröffentlichte John Zachman, Marketingspezialist bei IBM, die Arbeit „ A Framework for Information Systems Architecture“ ^{[ 10 ]} . Darin stellte er ein Klassifizierungsschema für Artefakte vor , die (auf verschiedenen Abstraktionsebenen) das Was, Wie, Wo, Wer, Wann und Warum von Informationssystemen beschreiben. Da IBM bereits BSP einsetzte, musste Zachman keinen Planungsprozess beschreiben. Die Unternehmensarchitektur wurde in der Arbeit nicht erwähnt.

1989 veröffentlichte das National Institute of Standards and Technology (NIST) das NIST Enterprise Architecture Model ^{[ 12 ]} . Dieses fünfschichtige Referenzmodell veranschaulicht die Wechselbeziehungen zwischen Geschäfts-, Informationssystem- und Technologiebereichen. Es wurde innerhalb der US-Bundesregierung gefördert. Obwohl es kein Enterprise-Architektur-Framework im heutigen Sinne war, trug es dazu bei, die Idee der Unterteilung von Enterprise Architecture in Architekturbereiche oder -schichten zu etablieren. Das NIST Enterprise Architecture Model war vermutlich die erste Publikation, die den Begriff „Enterprise Architecture“ durchgängig verwendete.

Im Jahr 1990 wurde der Begriff „Unternehmensarchitektur“ erstmals formal als eine Architektur definiert, die „Daten-, Hardware-, Software- und Kommunikationsressourcen sowie die unterstützende Organisation, die zur Aufrechterhaltung der durch die Architektur erforderlichen physischen Gesamtstruktur notwendig ist, definiert und miteinander verknüpft“. ^{[ 13 ]}

1992 veröffentlichten Zachman und Sowa ^{[ 11 ]} eine Arbeit mit folgendem Anfang: „John Zachman stellte ein Rahmenwerk für die Informationssystemarchitektur (ISA) vor, das von Systemanalysten und Datenbankdesignern weite Verbreitung gefunden hat.“ Der Begriff Unternehmensarchitektur tauchte dabei nicht auf. Die Arbeit befasste sich mit der Anwendung des ISA-Rahmenwerks zur Beschreibung „…des gesamten Informationssystems und seiner Beziehung zum Unternehmen und seinem Umfeld“. Der Begriff „Unternehmen“ wurde synonym mit „Geschäft“ verwendet.

Stephen Spewaks Buch „Enterprise Architecture Planning “ (EAP) aus dem Jahr 1993 definierte einen Prozess zur Entwicklung von Architekturen für die Informationsnutzung im Geschäftsbetrieb sowie zur Planung ihrer Implementierung. Die Geschäftsmission bildet den primären Treiber. Darauf folgen die zur Erfüllung dieser Mission benötigten Daten, die Anwendungen zur Speicherung und Bereitstellung dieser Daten und schließlich die Technologie zur Implementierung der Anwendungen. Enterprise Architecture Planning ist ein datenzentrierter Ansatz zur Architekturplanung. Ziel ist die Verbesserung der Datenqualität, des Datenzugriffs, der Anpassungsfähigkeit an sich ändernde Anforderungen, der Dateninteroperabilität und -freigabe sowie der Kostenkontrolle. EAP basiert auf IBMs Business Systems Planning (BSP).

1994 wählte die Open Group TAFIM des US-Verteidigungsministeriums als Grundlage für die Entwicklung von TOGAF, wobei Architektur hier die IT-Architektur meinte. TOGAF verfolgte von Anfang an einen strategischen und unternehmensweiten, aber technologieorientierten Ansatz. Es entstand aus dem Wunsch heraus, eine unübersichtliche IT-Landschaft zu rationalisieren. Bis einschließlich Version 7 konzentrierte sich TOGAF weiterhin auf die Definition und Verwendung eines technischen Referenzmodells (oder einer Basisarchitektur), um die Plattformdienste zu definieren, die von den Technologien benötigt werden, die ein gesamtes Unternehmen zur Unterstützung von Geschäftsanwendungen einsetzt. ^{[ 8 ]}

Der US-amerikanische IT-Management-Reformgesetz von 1996 , besser bekannt als Clinger-Cohen-Gesetz , legte wiederholt fest, dass die IT-Investitionen einer US-Bundesbehörde nachweislich mit konkreten Geschäftsvorteilen verknüpft sein müssen. Darüber hinaus wurde der CIO der Behörde für die „Entwicklung, Pflege und Unterstützung der Implementierung einer soliden und integrierten IT-Architektur für die Exekutivbehörde“ verantwortlich gemacht.

Bis 1997 hatte Zachman sein ISA-Framework umbenannt und neu ausgerichtet und es in ein EA-Framework umgewandelt; es blieb ein Klassifizierungsschema für beschreibende Artefakte, kein Prozess zur Planung von Systemen oder Systemänderungen.

Im Jahr 1998 begann der Federal CIO Council mit der Entwicklung des Federal Enterprise Architecture Framework (FEAF) gemäß den in Clinger-Cohen dargelegten Prioritäten und veröffentlichte es 1999. FEAF war ein Prozess, der dem ADM von TOGAF sehr ähnlich war, bei dem „das Architekturteam einen Sequenzierungsplan für die Umstellung von Systemen, Anwendungen und zugehörigen Geschäftspraktiken auf der Grundlage einer detaillierten Gap-Analyse [zwischen Basis- und Zielarchitekturen] erstellt“.

Im Jahr 2001 veröffentlichte der US-amerikanische Chief CIO Council den Leitfaden „A practical guide to Federal Enterprise Architecture“ , der mit folgender Aussage beginnt: „Eine Unternehmensarchitektur (EA) legt den behördenweiten Fahrplan fest, um die Mission einer Behörde durch die optimale Durchführung ihrer Kernprozesse in einer effizienten IT-Umgebung zu erreichen.“ Zu diesem Zeitpunkt bestanden klare Zusammenhänge zwischen den Prozessen in TOGAF, FEAF, EAP und BSP.

In der Enterprise Edition 2002/03 verlagerte TOGAF 8 den Fokus von der Technologiearchitekturebene auf die höheren Geschäfts-, Daten- und Anwendungsebenen. Es führte, angelehnt an das Information Technology Engineering , die strukturierte Analyse ein, welche beispielsweise die Zuordnung von Organisationseinheiten zu Geschäftsfunktionen und von Datenentitäten zu Geschäftsfunktionen umfasst. Heute werden Geschäftsfunktionen oft als Geschäftsfähigkeiten bezeichnet. Viele Enterprise-Architekten betrachten ihre Hierarchie bzw. Abbildung der Geschäftsfunktionen/-fähigkeiten als das grundlegende Artefakt der Enterprise-Architektur. Sie verknüpfen Datenentitäten, Anwendungsfälle, Anwendungen und Technologien mit den Funktionen/Fähigkeiten.

Das 2006 erschienene, vielbeachtete Buch „Enterprise Architecture As Strategy “ ^{[ 14 ]} präsentierte die Ergebnisse einer Studie des Center for Information System Research am MIT. Darin wird betont, wie wichtig es für Unternehmensarchitekten ist, sich auf die Kernprozesse des Unternehmens zu konzentrieren („Unternehmen sind erfolgreich, weil sie entschieden haben, welche Prozesse sie optimal ausführen müssen, und die IT-Systeme implementiert haben, um diese Prozesse zu digitalisieren.“) und Führungskräfte von den Vorteilen einer strategischen, organisationsübergreifenden Prozessintegration und/oder -standardisierung zu überzeugen.

Ein Forschungsprojekt der British Computer Society (BCS) aus dem Jahr 2008 zur Entwicklung von Berufsqualifikationen in Unternehmens- und Lösungsarchitektur zeigte, dass Unternehmensarchitektur schon immer untrennbar mit Informationssystemarchitektur verbunden war, was naheliegend ist, da Geschäftsleute Informationen benötigen, um Entscheidungen zu treffen und Geschäftsprozesse durchzuführen. ^{[ 8 ]}

Die TOGAF-Spezifikation 9.1 aus dem Jahr 2011 besagt: „Die Geschäftsplanung auf Strategieebene gibt die erste Richtung für die Unternehmensarchitektur vor.“ ^{[ 15 ]} Normalerweise werden die Geschäftsprinzipien, Geschäftsziele und strategischen Treiber der Organisation an anderer Stelle definiert. ^{[ 8 ]} Anders ausgedrückt: Unternehmensarchitektur ist keine Geschäftsstrategie, Planungs- oder Managementmethodik. Sie zielt darauf ab, die Informationstechnologie des Unternehmens mit der gegebenen Geschäftsstrategie, den Zielen und Treibern in Einklang zu bringen. Die TOGAF-Spezifikation 9.1 stellt klar: „Eine vollständige Beschreibung der Unternehmensarchitektur sollte alle vier Architekturdomänen (Geschäft, Daten, Anwendung, Technologie) umfassen. Aufgrund von Ressourcen- und Zeitbeschränkungen reichen jedoch oft weder Zeit noch finanzielle Mittel oder Ressourcen aus, um eine umfassende Top-Down-Architekturbeschreibung zu erstellen, die alle vier Architekturdomänen abdeckt, selbst wenn der Unternehmensumfang [...] kleiner ist als der gesamte Umfang des Unternehmens.“ ^{[ 16 ]}

Im Jahr 2013 war TOGAF ^{[ 17 ]} das populärste Architektur-Framework (gemessen an den veröffentlichten Zertifizierungszahlen), und manche gehen davon aus, dass es die Unternehmensarchitektur definiert. ^{[ 8 ]} Allerdings wird der Begriff Unternehmensarchitektur immer noch synonym mit Geschäftsarchitektur verwendet, anstatt alle vier Architekturbereiche – Geschäft, Daten, Anwendungen und Technologie – abzudecken.

Seit Stephen Spewaks Enterprise Architecture Planning (EAP) im Jahr 1993 – und vielleicht schon davor – ist es üblich, die Unternehmensarchitektur in vier Architekturdomänen zu unterteilen .

• Geschäftsarchitektur ,
• Datenarchitektur ,
• Anwendungsarchitektur ,
• Technologiearchitektur .

Beachten Sie, dass es bei der Anwendungsarchitektur um die Auswahl der Anwendungen und die Beziehungen zwischen den Anwendungen im Anwendungsportfolio des Unternehmens geht, nicht um die interne Architektur einer einzelnen Anwendung (die oft als Anwendungsarchitektur bezeichnet wird).

Viele EA-Frameworks kombinieren Daten- und Anwendungsdomänen zu einer einzigen (digitalisierten) Informationssystemebene, die unterhalb des Geschäfts (in der Regel ein System menschlicher Aktivitäten) und oberhalb der Technologie (der Plattform -IT-Infrastruktur ) angesiedelt ist.

Lange Zeit war es üblich, Architekturdomänen als Schichten zu betrachten, wobei jede Schicht Komponenten enthält, die Prozesse ausführen und Dienste für die darüberliegende Schicht bereitstellen. Diese Sichtweise der Architekturdomänen zeigte sich bereits in TOGAF v1 (1996), das die Technologiekomponentenschicht hinter den im „Technischen Referenzmodell“ definierten Plattformdiensten kapselte – ganz im Sinne der Philosophie von TAFIM und POSIX.

Die Sichtweise von Architekturdomänen als Schichten kann folgendermaßen dargestellt werden:

• Umfeld (die externen Einheiten und Aktivitäten, die vom Unternehmen überwacht, unterstützt oder gesteuert werden).
• Geschäftsschicht (Geschäftsfunktionen, die einander und externen Einheiten Dienstleistungen anbieten).
• Datenschicht (Geschäftsinformationen und andere wertvolle gespeicherte Daten)
• Informationssystemschicht (Geschäftsanwendungen, die einander und Geschäftsfunktionen Informationsdienste anbieten)
• Technologieschicht (generische Hardware, Netzwerk- und Plattformanwendungen, die untereinander und für Geschäftsanwendungen Plattformdienste anbieten).

Jede Schicht delegiert Aufgaben an die darunterliegende Schicht. Innerhalb jeder Schicht lassen sich die Komponenten, Prozesse und Dienste grob definieren und in feinere Komponenten, Prozesse und Dienste untergliedern. Die Grafik veranschaulicht eine Variante dieses Konzepts.

Zusätzlich zu den drei oben genannten Hauptkomponenten des Rahmens.

1. Beschreibungsvorschlag: eine Art Architektur-Artefaktkarte oder Aussichtspunktbibliothek
2. Prozessberatung: eine Art Architekturentwicklungsmethode mit unterstützender Anleitung.
3. Organisationsberatung: einschließlich eines EA-Governance-Modells

Ein ideales EA-Framework sollte folgende Merkmale aufweisen:

1. Kennzahlen zur Messung des Geschäftswerts
2. EA-Initiativemodell
3. EA-Reifegradmodell
4. Unternehmenskommunikationsmodell

Die meisten modernen EA-Frameworks (z. B. TOGAF, ASSIMPLER, EAF) beinhalten die meisten der oben genannten Punkte. Zachman hat sich stets auf Empfehlungen zur Architekturbeschreibung konzentriert.

Anwendungs- und Technologiedomänen (nicht zu verwechseln mit Geschäftsdomänen) zeichnen sich durch Domänenfähigkeiten und Domänendienste aus. Die Fähigkeiten werden durch die Dienste unterstützt. Die Anwendungsdienste werden auch in der serviceorientierten Architektur (SOA) erwähnt. Die technischen Dienste werden typischerweise durch Softwareprodukte bereitgestellt.

Die Datensicht beginnt mit den Datenklassen, die in Datensubjekte und diese wiederum in Datenentitäten unterteilt werden können. Der am häufigsten verwendete grundlegende Datenmodelltyp heißt MERDA (Master Entity Relationship Diagrams Assessment, siehe Entity-Relationship-Modell ). Klasse, Subjekt und Entität bilden eine hierarchische Datensicht. Unternehmen können Millionen von Instanzen von Datenentitäten besitzen.

Das traditionelle Referenzmodell für Unternehmensarchitektur (Enterprise Architecture Reference Traditional Model) unterscheidet klar zwischen den Architekturdomänen (Geschäftsarchitektur, Informations-/Datenarchitektur, Anwendungs-/Integrationsarchitektur und technische/Infrastrukturarchitektur). Diese Domänen lassen sich weiter in Subdomänen untergliedern. Ein Beispiel für die EA-Domäne und ihre Subdomänen ist in der Abbildung rechts dargestellt.

Viele Enterprise-Architekturteams bestehen aus Einzelpersonen mit Fachkenntnissen, die den Domänen und Subdomänen der Enterprise-Architektur entsprechen. Beispiele hierfür sind: Enterprise-Business-Architekt, Enterprise-Dokumentationsarchitekt, Enterprise-Anwendungsarchitekt, Enterprise-Infrastrukturarchitekt, Enterprise-Informationsarchitekt usw.

Ein Beispiel für die Liste von Referenzarchitekturmustern in den Bereichen Anwendungs- und Informationsarchitektur finden Sie unter Architectural pattern (computer science) .

Ein Sichtmodell ist ein Rahmenwerk, das die Menge der Sichten oder Ansätze definiert, die bei der Systemanalyse , dem Systemdesign oder dem Aufbau einer Unternehmensarchitektur verwendet werden .

Seit Anfang der 1990er-Jahre gab es zahlreiche Bestrebungen, Standardansätze zur Beschreibung und Analyse von Systemarchitekturen zu definieren. Viele der neueren Enterprise-Architektur-Frameworks definieren bestimmte Sichten, die jedoch nicht immer als Sichtmodelle bezeichnet werden .

Der wohl bekannteste Standard auf dem Gebiet der Softwarearchitektur und Systemarchitektur entstand als IEEE 1471 , ein IEEE-Standard zur Beschreibung der Architektur eines softwareintensiven Systems, der im Jahr 2000 verabschiedet wurde.

In ihrer neuesten Fassung ist die Norm als ISO/IEC/IEEE 42010:2011 veröffentlicht . Die Norm definiert ein Architektur-Framework als Konventionen, Prinzipien und Praktiken zur Beschreibung von Architekturen, die innerhalb eines spezifischen Anwendungsbereichs und/oder einer bestimmten Interessengruppe etabliert sind , und schlägt vor, dass ein Architektur-Framework wie folgt spezifiziert wird:

1. die relevanten Akteure in diesem Bereich,
2. die Arten von Bedenken, die in diesem Bereich auftreten,
3. Architekturperspektiven, die diese Bedenken prägen und
4. Korrespondenzregeln, die die zuvor genannten Standpunkte integrieren.

Architektur-Frameworks, die dem Standard entsprechen, können über die spezifizierten hinaus zusätzliche Methoden, Werkzeuge, Definitionen und Praktiken umfassen.

Heutzutage gibt es unzählige EA-Frameworks, weitaus mehr als in der folgenden Liste.

• ARCON – Eine Referenzarchitektur für kollaborative Netzwerke – nicht auf ein einzelnes Unternehmen, sondern auf Netzwerke von Unternehmen ausgerichtet ^{[ 21 ] [ 22 ]}
• Die Referenzarchitektur der Cloud Security Alliance (Trusted Cloud Initiative) TCI. ^{[ 23 ]}
• Generalisierte Unternehmensreferenzarchitektur und -methodik (GERAM)
• RM-ODP – das Referenzmodell für offene verteilte Verarbeitung (ITU-T Rec. X.901-X.904 | ISO/IEC 10746) definiert ein Unternehmensarchitektur-Framework zur Strukturierung der Spezifikationen offener verteilter Systeme .
• IDEAS-Gruppe – eine Initiative von vier Nationen zur Entwicklung einer gemeinsamen Ontologie für Architekturinteroperabilität
• ISO 19439 Rahmenwerk für die Unternehmensmodellierung
• TOGAF – The Open Group Architecture Framework – ein weit verbreitetes Framework, das eine Architekturentwicklungsmethode und Standards zur Beschreibung verschiedener Architekturtypen umfasst.

• AGATE – das Architektur-Framework der französischen DGA
• DNDAF ^{[ 24 ]} – das DND/CF-Architektur-Framework (CAN)
• DoDAF – das Architektur-Framework des US-Verteidigungsministeriums
• MODAF – das Architektur-Framework des britischen Verteidigungsministeriums
• NAF – das NATO-Architekturrahmenwerk

• Architekturrahmen der Europäischen Weltraumorganisation (ESAAF) – ein Rahmenwerk für europäische weltraumgestützte Systeme von Systemen ^{[ 25 ]}
• FDIC-Unternehmensarchitekturrahmen
• Federal Enterprise Architecture Framework (FEAF) – ein Rahmenwerk, das 1999 vom US Federal CIO Council für die Verwendung innerhalb der US-Regierung erstellt wurde (nicht zu verwechseln mit den 2002 vom US Federal Office of Management and Budget herausgegebenen Federal Enterprise Architecture (FEA)-Leitlinien zur Kategorisierung und Gruppierung von IT-Investitionen ).
• Regierungsarchitektur für Unternehmen (GEA) – ein gemeinsamer, gesetzlich vorgeschriebener Rahmen für die Verwendung durch die Abteilungen der Regierung von Queensland
• Nederlandse Overheid Referentie Architectuur (NORA) – ein Referenzrahmen der niederländischen Regierung E-overheid NORA
• NIST-Unternehmensarchitekturmodell
• Treasury Enterprise Architecture Framework (TEAF) – ein Rahmenwerk für das Finanzministerium , veröffentlicht vom US-Finanzministerium im Juli 2000. ^{[ 26 ]}
• Colombian Enterprise Architecture Framework - MRAE - Marco de Referencia de Arquitectura EmpresarialArchived 2021-05-10 at the Wayback Machine a framework for all the Colombian Public Agencies
• India Enterprise Architecture (IndEA) framework - IndEA is a reference framework from Government of India.
• Medicaid Information Technology Architecture (MITA) - US Center for Medicare and Medicaid Services (CMS) framework to foster integrated business and information technology transformation for Medicaid

Enterprise architecture frameworks that are released as open source:

• ArchiMate
• Lean Architecture Framework (LAF)^[27] is a collection of good practices thanks to which the IT environment will respond consistently and quickly to a changing business situation while maintaining its consistent form.
• MEGAF (Mega-modeling Architecture Framework)^[28] is an infrastructure for realizing architecture frameworks that conform to the definition of architecture framework provided in ISO/IEC/IEEE 42010.
• Praxeme, an open enterprise methodology, contains an enterprise architecture framework called the Enterprise System Topology (EST)
• TRAK – a general systems-oriented framework based on MODAF 1.2 and released under GPL/GFDL.
• Sherwood Applied Business Security Architecture (SABSA)^[29] is an open framework and methodology for Enterprise Security Architecture and Service Management, that is risk based and focuses on integrating security into business and IT management.

• ASSIMPLER Framework – an architecture framework, based on the work of Mandar Vanarse at Wipro in 2002
• Avancier Methods (AM)^[30] Processes and documentation advice for enterprise and solution architects, supported by training and certification.
• BRM (Build-Run-Manage) Framework - an architecture framework created by Sanjeev "Sunny" Mishra during his early days at IBM in 2000.
• Capgemini Integrated Architecture Framework (IAF) – from Capgemini company in 1993
• Dragon1 - An open Visual Enterprise Architecture Method recently recognized by The Open Group as Architecture Framework
• DYA framework developed by Sogeti since 2004.
• Dynamic Enterprise Enterprise architecture concept based on Web 2.0 technology
• Extended Enterprise Architecture Framework - from Institute For Enterprise Architecture Developments in 2003
• EACOE Framework [3] – an Enterprise Architecture framework, as an elaboration of the work of John Zachman
• IBM Information FrameWork (IFW) – conceived by Roger Evernden in 1996
• Infomet - conceived by Pieter Viljoen in 1990
• Labnaf ^[31] - Unified Framework for Driving Enterprise Transformations
• Pragmatic Enterprise Architecture Framework (PEAF)^[32] - part of Pragmatic Family of Frameworks developed by Kevin Lee Smith, Pragmatic EA, from 2008
• Purdue Enterprise Reference Architecture developed by Theodore J. Williams at the Purdue University early 1990s.
• Risk- and Cost-Driven Architecture (RCDA), developed by CGI since 2015.
• SAP Enterprise Architecture Framework
• Service-oriented modeling framework (SOMF), based on the work of Michael Bell
• Solution Architecting Mechanism (SAM)^[33] – A coherent architecture framework consisting of a set of integral modules.^[34]
• Zachman Framework – an architecture framework, based on the work of John Zachman at IBM in the 1980s

• Architecture patterns (EA reference architecture)
• EABOK (The Guide to the Enterprise Architecture Body of Knowledge)
• Enterprise architecture
• Enterprise architecture artifacts
• Enterprise architecture planning
• Enterprise engineering
• ISO/IEC/IEEE 42010
• Reference architecture

• Frameworks für Unternehmensarchitektur: Die Modeerscheinung des Jahrhunderts (Juli 2016)
• Ein Vergleich der vier führenden Enterprise-Architektur-Frameworks (Juli 2021)