エンタープライズアーキテクチャフレームワーク

エンタープライズアーキテクチャ フレームワーク( EA フレームワーク) は、エンタープライズ アーキテクチャの作成方法と使用方法を定義します。アーキテクチャ フレームワークは、システムのアーキテクチャ記述の作成と使用に関する原則と実践を提供します。アーキテクチャ記述をドメイン、レイヤー、またはビューに分割することでアーキテクトの思考を構造化し、各ビューを文書化するためのモデル (通常はマトリックスとダイアグラム) を提供します。これにより、システムのすべてのコンポーネントについて体系的な設計決定を下し、新しい設計要件、持続可能性、およびサポートに関する長期的な決定を下すことができます。^[2]

エンタープライズアーキテクチャは、エンタープライズを大規模で複雑なシステム、またはシステムオブシステムと見なします。^[3]このシステムの規模と複雑さを管理するために、アーキテクチャフレームワークは、ビルダーが作業する詳細レベルからアーキテクトを抽象化し、エンタープライズ設計タスクに焦点を当て、価値のあるアーキテクチャ記述ドキュメントを作成するのに役立つツールとアプローチを提供します。

アーキテクチャフレームワークのコンポーネントは、3つの主要な領域に分かれた構造化されたガイダンスを提供します。^[4]

• アーキテクチャの説明: 複数の視点から、企業をシステムとして文書化する方法。各ビューは、アーキテクチャの 1 つのスライスを説明します。これには、特定の利害関係者の関心事に対応するエンティティと関係が含まれます。リスト、表、図、またはそれらの複合レベルの形式を取ることができます。
• アーキテクチャを設計する方法: アーキテクトが従うプロセス。通常、包括的なエンタープライズ アーキテクチャ プロセスはフェーズで構成され、より細かいアクティビティで構成される下位レベルのプロセスに分割されます。プロセスは、その目的、入力、フェーズ (ステップまたはアクティビティ)、および出力によって定義されます。アプローチ、テクニック、ツール、原則、ルール、およびプラクティスによってサポートされる場合があります。
• アーキテクトの組織: 必要なスキル、経験、トレーニングを含む、チーム構造とチームのガバナンスに関するガイダンス。

現在、 The Open Group Architecture Framework (TOGAF) やその他の EA フレームワークで提唱されている段階的な計画方法論の最も初期の原型は、1962 年にハーバード ビジネス レビューに掲載されたMarshall K. Evans と Lou R. Hague の「情報システムのためのマスター プラン」^[7]という論文にまで遡ることができます。^[8]

1970 年代以降、IS/IT に携わる人々は、企業の広範かつ長期的な利益を視野に入れて、ビジネス パーソンを関与させ、ビジネスの役割とプロセスを有効にし、ビジネス情報システムとテクノロジへの投資に影響を与える方法を模索してきました。現在 EA フレームワークで採用されている目的、原則、概念、方法の多くは、1980 年代に確立され、その 10 年間と次の 10 年間に公開された IS および IT アーキテクチャ フレームワークに見出すことができます。^[9]

1980 年までに、IBM のビジネス システム プランニング(BSP) は、次の目標を掲げて組織の情報アーキテクチャを分析および設計する方法として推進されました。

1. 現在のアプリケーションと技術アーキテクチャに関する問題と機会を理解する。
2. 企業をサポートするテクノロジーの将来の状態と移行パスを開発する。
3. 経営幹部に IT 資本支出の方向性と意思決定の枠組みを提供します。
4. 情報システム (IS) に開発の青写真を提供します。

1982年、IBMおよびBSPで働いていたジョン・ザックマンは、エンタープライズレベルの「情報システムアーキテクチャ」のフレームワークの概要を説明しました。その後の論文では、ザックマンはエンタープライズという言葉をビジネスの同義語として使用しました。「多くの一般的な情報システム計画方法論、設計アプローチ、およびさまざまなツールとテクニックは、エンタープライズレベルの分析を排除したり矛盾したりすることはありませんが、それらのうち、エンタープライズアーキテクチャを明確に扱ったり定義しようとしたりするものはほとんどありません。」^[10]ただし、この記事では「エンタープライズアーキテクチャ」という用語は特定の定義なしに一度​​だけ言及され、その後のザックマンのすべての論文では「情報システムアーキテクチャ」という用語が使用されました。^{[11] [12]}

1986年、IBMを含む企業グループが後援する研究プロジェクトの結果としてPRISMアーキテクチャフレームワークが開発され、これが最初に公開されたEAフレームワークであったと思われる。^[13]

1987年、IBMのマーケティング専門家であったジョン・ザックマンは、 「情報システムアーキテクチャのフレームワーク」という論文を発表しました。^[11]この論文では、情報システムの「何」「どのように」「どこで」「誰が」「いつ」「なぜ」を（いくつかの抽象レベルで）記述する成果物の分類体系が示されていました。IBMがすでにBSPを採用していたため、ザックマンは計画プロセスを提供する必要はありませんでした。この論文ではエンタープライズアーキテクチャについては触れられていませんでした。

1989年、米国国立標準技術研究所（NIST）はNISTエンタープライズアーキテクチャモデルを発表しました。^[14]これは、ビジネス、情報システム、テクノロジーの各ドメインの相互関係を示す5層の参照モデルでした。これは米国連邦政府内で推進されました。これは現在見られるEAフレームワークではありませんでしたが、EAをアーキテクチャドメインまたはレイヤーに分割するという概念を確立するのに役立ちました。NISTエンタープライズアーキテクチャモデルは、一貫して「エンタープライズアーキテクチャ」という用語を使用した最初の出版物であると思われます。^[13]

1990年に、「エンタープライズアーキテクチャ」という用語は、「データ、ハードウェア、ソフトウェア、通信リソース、およびアーキテクチャに必要な全体的な物理構造を維持するために必要なサポート組織を定義および相互に関連付ける」アーキテクチャとして初めて正式に定義されました。^{[13] [15]}

^{1992年、ザックマンとソーワ[12]}による論文は、「ジョン・ザックマンは、システムアナリストやデータベース設計者に広く採用されている情報システムアーキテクチャ（ISA）のフレームワークを紹介した」という一文で始まっていました。エンタープライズアーキテクチャという用語は出てきませんでした。この論文は、ISAフレームワークを使用して「...全体的な情報システムと、それがエンタープライズとその周囲の環境とどのように関係しているか」を説明することについて書かれていました。エンタープライズという言葉は、ビジネスの同義語として使われていました。

1993 年、スティーブン・スペワックの著書「エンタープライズ アーキテクチャ プランニング(EAP)」では、ビジネスをサポートする情報の使用に関するアーキテクチャを定義するプロセスと、それらのアーキテクチャを実装するための計画が定義されました。ビジネス ミッションが主な推進力です。次に、ミッションを満たすために必要なデータ、次にそのデータを保存および提供するために構築されたアプリケーション、最後にアプリケーションを実装するためのテクノロジです。エンタープライズ アーキテクチャ プランニングは、アーキテクチャ プランニングに対するデータ中心のアプローチです。目的は、データ品質、データへのアクセス、変化する要件への適応性、データの相互運用性と共有、およびコスト抑制を改善することです。EAP は、IBM のビジネス システム プランニング(BSP) にルーツがあります。^[13]

1994 年、Open Group は米国国防総省のTAFIM をTOGAF 開発の基盤として選択しました。ここでのアーキテクチャとは IT アーキテクチャを意味します。TOGAF は、戦略的かつ企業全体にわたる、しかし技術指向の視点から始まりました。乱雑な IT 資産を合理化したいという願望から生まれました。バージョン 7 に至るまで、TOGAF は、企業全体がビジネス アプリケーションをサポートするために使用するテクノロジに必要なプラットフォーム サービスを定義するために、技術参照モデル (または基盤アーキテクチャ) の定義と使用に重点を置いていました。^[9]

1996 年、米国IT 管理改革法(通称クリンガー・コーエン法) は、米国連邦政府機関の IT 投資は、明確なビジネス上のメリットに結び付ける必要があることを繰り返し指示しました。さらに、同法では、機関の CIO に「行政機関のための健全で統合された IT アーキテクチャの開発、維持、実装の促進」の責任を負わせました。

1997 年までに、ザックマンは ISA フレームワークの名前を変更し、焦点を EA フレームワークに再設定しました。ISA フレームワークは、システムやシステムの変更を計画するためのプロセスではなく、記述的成果物の分類スキームのままでした。

1998 年、連邦 CIO 評議会は、Clinger-Cohen で表明された優先事項に従って連邦エンタープライズ アーキテクチャ フレームワーク (FEAF) の開発を開始し、1999 年に発行しました。FEAF は、TOGAF の ADM によく似たプロセスで、「アーキテクチャ チームは、[ベースライン アーキテクチャとターゲット アーキテクチャ間の] 詳細なギャップ分析に基づいて、システム、アプリケーション、および関連するビジネス プラクティスの移行のシーケンス プランを作成します。」

2001 年に、米国最高情報責任者 (CIO) 協議会は、「エンタープライズ アーキテクチャ (EA) は、効率的な情報技術 (IT) 環境内でコア ビジネス プロセスを最適に実行することにより、機関のミッションを達成するための機関全体のロードマップを確立します」という一文で始まる「連邦エンタープライズ アーキテクチャの実践ガイド」を発行しました。その時点では、TOGAF、FEAF、EAP、および BSP のプロセスは明らかに関連していました。

2002/3 年に、TOGAF 8 のEnterprise Editionでは、テクノロジー アーキテクチャ レイヤーから、より高次のビジネス、データ、アプリケーション レイヤーに重点が移されました。情報技術エンジニアリングに倣って、構造化分析が導入され、たとえば、組織単位からビジネス機能へのマッピングや、データ エンティティからビジネス機能へのマッピングが特徴となっています。今日では、ビジネス機能はビジネス機能と呼ばれることがよくあります。また、多くのエンタープライズ アーキテクトは、ビジネス機能/機能の階層/マップを基本的なエンタープライズ アーキテクチャ成果物と見なしています。データ エンティティ、ユース ケース、アプリケーション、テクノロジーを機能/機能に関連付けます。

2006 年、人気の書籍「戦略としてのエンタープライズ アーキテクチャ^」[16]で、MIT の情報システム研究センターの研究結果が報告されました。この本では、エンタープライズ アーキテクトがコア ビジネス プロセス (「企業が成功するのは、どのプロセスを適切に実行する必要があるかを [決定し]、それらのプロセスをデジタル化する IT システムを実装しているためです。」) に重点を置き、戦略的な組織間プロセス統合や標準化がもたらすメリットをビジネス マネージャーに伝える必要があることを強調しています。

英国コンピュータ協会（BCS）による2008年のエンタープライズおよびソリューションアーキテクチャの専門資格開発研究プロジェクトでは、エンタープライズアーキテクチャは常に情報システムアーキテクチャと切り離せない関係にあることが示されました。これは、ビジネスマンが意思決定を行い、ビジネスプロセスを実行するために情報を必要とするため、当然のことです。^[9]

2011 年の TOGAF 9.1 仕様では、「戦略レベルでのビジネス計画は、エンタープライズ アーキテクチャへの最初の方向性を示します」と述べられています。 ^[17]通常、組織のビジネス原則、ビジネス目標、および戦略的推進要因は、他の場所で定義されます。^[9]つまり、エンタープライズ アーキテクチャは、ビジネス戦略、計画、または管理方法論ではありません。エンタープライズ アーキテクチャは、ビジネス情報システム技術を、特定のビジネス戦略、目標、および推進要因に合わせることを目指しています。TOGAF 9.1 仕様では、「完全なエンタープライズ アーキテクチャ記述には、4 つのアーキテクチャ ドメイン (ビジネス、データ、アプリケーション、テクノロジ) すべてが含まれている必要がありますが、リソースと時間の制約という現実により、エンタープライズ スコープが [...] エンタープライズ全体の全範囲に満たない場合でも、4 つのアーキテクチャ ドメインすべてを網羅するトップダウンの包括的なアーキテクチャ記述を作成するための時間、資金、またはリソースが十分でないことがよくあります」と明確にされています。^[18]

2013年、TOGAF ^[19]は最も人気のあるアーキテクチャフレームワークであり（公開された認証数から判断）、EAを定義していると考える人もいます。^[9]ただし、ビジネス、データ、アプリケーション、テクノロジーの4つのアーキテクチャドメインすべてをカバーするのではなく、エンタープライズアーキテクチャという用語をビジネスアーキテクチャの同義語として使用する人もいます。

1993 年のStephen Spewak によるEnterprise Architecture Planning (EAP) 以来 (おそらくそれ以前から)、エンタープライズ アーキテクチャを 4 つのアーキテクチャ ドメインに分割するのが一般的でした。

• ビジネスアーキテクチャ、
• データアーキテクチャ、
• アプリケーションアーキテクチャ、
• テクノロジーアーキテクチャ。

アプリケーション アーキテクチャは、企業のアプリケーション ポートフォリオ内のアプリケーションの選択とアプリケーション間の関係に関するものであり、単一のアプリケーションの内部アーキテクチャ (多くの場合、アプリケーション アーキテクチャと呼ばれます) に関するものではないことに注意してください。

多くの EA フレームワークは、データとアプリケーション ドメインを単一の (デジタル化された) 情報システム レイヤーに統合し、ビジネス (通常は人間の活動システム) の下、テクノロジー (プラットフォームIT インフラストラクチャ) の上に配置します。

長年にわたり、アーキテクチャ ドメインをレイヤーと見なすことが一般的でした。各レイヤーには、プロセスを実行し、上位レイヤーにサービスを提供するコンポーネントが含まれているという考えです。アーキテクチャ ドメインのこの見方は、TAFIM と POSIX の哲学に非常によく従い、「技術参照モデル」で定義されたプラットフォーム サービスの背後にあるテクノロジ コンポーネント レイヤーをカプセル化した TOGAF v1 (1996) に明らかでした。

アーキテクチャドメインをレイヤーとして見ると、次のように表すことができます。

• 環境 (ビジネスによって監視、サポート、または指示される外部のエンティティとアクティビティ)。
• ビジネス レイヤー (相互に、および外部エンティティにサービスを提供するビジネス機能)。
• データ レイヤー (ビジネス情報やその他の貴重な保存データ)
• 情報システム層（ビジネスアプリケーション同士およびビジネス機能に情報サービスを提供する）
• テクノロジー レイヤー (汎用ハードウェア、ネットワーク、およびプラットフォーム アプリケーションが相互に、またビジネス アプリケーションにプラットフォーム サービスを提供します)。

各レイヤーは、作業を下のレイヤーに委任します。各レイヤーでは、コンポーネント、プロセス、およびサービスを粗い粒度で定義し、より細かい粒度のコンポーネント、プロセス、およびサービスに分解できます。この図は、このテーマのバリエーションを示しています。

上記で説明した 3 つの主要なフレームワーク コンポーネントに加えて、

1. 説明のアドバイス: 何らかの建築アーティファクトマップまたはビューポイントライブラリ
2. プロセスのアドバイス: サポートガイダンス付きの、ある種のアーキテクチャ開発方法。
3. 組織に関するアドバイス: EAガバナンスモデルを含む

理想的な EA フレームワークには次の機能が必要です。

1. ビジネス価値測定指標
2. EAイニシアチブモデル
3. EA成熟度モデル
4. エンタープライズコミュニケーションモデル

最新の EA フレームワーク (TOGAF、ASSIMPLER、EAF など) のほとんどには、上記のほとんどが含まれています。Zachman は常にアーキテクチャ記述のアドバイスに重点を置いてきました。

アプリケーション ドメインとテクノロジ ドメイン (ビジネス ドメインと混同しないでください) は、ドメイン機能とドメイン サービスによって特徴付けられます。機能はサービスによってサポートされます。アプリケーション サービスは、サービス指向アーキテクチャ(SOA) でも参照されます。技術サービスは通常、ソフトウェア製品によってサポートされます。

データ ビューは、データ クラスから始まり、データ サブジェクトに分解でき、さらにデータ エンティティに分解できます。最も一般的に使用される基本データ モデル タイプは、merda (マスター エンティティ リレーションシップ ダイアグラム評価、エンティティ リレーションシップ モデルを参照) と呼ばれます。クラス、サブジェクト、エンティティは、データの階層ビューを形成します。企業には、数百万のデータ エンティティ インスタンスが存在する場合があります。

エンタープライズ アーキテクチャ リファレンス トラディショナル モデルでは、アーキテクチャ ドメイン (ビジネス、情報/データ、アプリケーション/統合、技術/インフラストラクチャ) が明確に区別されています。これらのドメインは、さらにサブ ドメイン分野に分割できます。EA ドメインとサブドメインの例は、右の図に示されています。

多くのエンタープライズ アーキテクチャ チームは、エンタープライズ アーキテクチャ ドメインとサブドメインの分野に沿ったスキルを持つ個人で構成されています。例としては、エンタープライズ ビジネス アーキテクト、エンタープライズ ドキュメンテーション アーキテクト、エンタープライズ アプリケーション アーキテクト、エンタープライズ インフラストラクチャ アーキテクト、エンタープライズ情報アーキテクトなどがあります。

アプリケーションおよび情報アーキテクチャ ドメインの参照アーキテクチャ パターンのリストの例は、「アーキテクチャ パターン (コンピューター サイエンス)」で参照できます。

ビューモデルは、システム分析、システム設計、またはエンタープライズ アーキテクチャの構築で使用されるビューまたはアプローチのセットを定義するフレームワークです。

1990 年代初頭以来、システム アーキテクチャを記述および分析するための標準的なアプローチを定義するための取り組みが数多く行われてきました。最近のエンタープライズ アーキテクチャ フレームワークの多くでは、何らかのビュー セットが定義されていますが、これらのセットは必ずしもビュー モデルと呼ばれるわけではありません。

おそらく、ソフトウェア アーキテクチャとシステム アーキテクチャの分野で最もよく知られている標準は、2000 年に承認された ソフトウェア集約型システムのアーキテクチャを記述するためのIEEE 標準であるIEEE 1471として始まりました。

この規格の最新バージョンは、ISO/IEC/IEEE 42010:2011として公開されています。この規格では、アーキテクチャ フレームワークを、特定のアプリケーション ドメインや利害関係者のコミュニティ内で確立されたアーキテクチャの記述に関する規則、原則、および実践として定義し、アーキテクチャ フレームワークを次のように指定することを提案しています。

1. 当該分野の関係者、
2. その領域で生じる懸念の種類、
3. 建築の視点からそれらの懸念を整理し、
4. 前述の観点を統合した対応規則。

標準に準拠するアーキテクチャ フレームワークには、指定されたもの以外の追加の方法、ツール、定義、およびプラクティスを含めることができます。

現在では、EA フレームワークは数え切れないほど存在し、次のリストにあるものよりもはるかに多くあります。

• ARCON – コラボレーションネットワークのリファレンスアーキテクチャ – 単一の企業ではなく、企業のネットワークに焦点を当てています^{[23] [24]}
• クラウドセキュリティアライアンス（Trusted Cloud Initiative）TCIリファレンスアーキテクチャ。^[25]
• 一般化されたエンタープライズ リファレンス アーキテクチャと方法論(GERAM)
• RM-ODP – オープン分散処理の参照モデル (ITU-T 勧告 X.901-X.904 | ISO/IEC 10746) は、オープン 分散システムの仕様を構造化するエンタープライズ アーキテクチャ フレームワークを定義します。
• IDEAS グループ– 建築の相互運用性のための共通オントロジーを開発する 4 か国の取り組み
• ISO 19439エンタープライズモデリングのフレームワーク
• TOGAF (The Open Group Architecture Framework) は、アーキテクチャ開発方法とさまざまな種類のアーキテクチャを記述するための標準を含む、広く使用されているフレームワークです。

• AGATE – フランス DGA アーキテクチャ フレームワーク
• DNDAF ^[26] – DND/CFアーキテクチャフレームワーク（CAN）
• DoDAF – 米国国防総省のアーキテクチャフレームワーク
• MODAF – 英国国防省のアーキテクチャフレームワーク
• NAF – NATOアーキテクチャフレームワーク

• 欧州宇宙機関アーキテクチャフレームワーク（ESAAF） - 欧州の宇宙ベースのシステム・オブ・システムのフレームワーク^[27]
• FDIC エンタープライズ アーキテクチャ フレームワーク
• 連邦エンタープライズ アーキテクチャ フレームワーク(FEAF) – 1999 年に米国連邦 CIO 評議会によって米国政府内での使用のために作成されたフレームワーク (米国連邦行政管理予算局が発行した IT 投資の分類とグループ化に関する 2002 年の連邦エンタープライズ アーキテクチャ (FEA) ガイダンスと混同しないでください)
• 政府エンタープライズアーキテクチャ（GEA） –クイーンズランド州政府の各部門が使用するために制定された共通のフレームワーク
• Nederlandse Overheid Referentie Architectuur (NORA) – オランダ政府の E-overheid NORA による参照フレームワーク
• NIST エンタープライズ アーキテクチャ モデル
• 財務エンタープライズアーキテクチャフレームワーク（TEAF） – 2000年7月に米国財務省によって発行された財務のためのフレームワーク 。 ^[28]
• コロンビアのエンタープライズアーキテクチャフレームワーク - MRAE - Marco de Referenceencia de Arquitectura Empresarial 2021-05-10にWayback Machineでアーカイブされたすべてのコロンビアの公共機関向けのフレームワーク
• インド エンタープライズ アーキテクチャ (IndEA) フレームワーク - IndEA は、インド政府の参照フレームワークです。

オープンソースとしてリリースされているエンタープライズ アーキテクチャ フレームワーク:

• アーキメイト
• リーンアーキテクチャフレームワーク（LAF）^[29]は、IT環境が一貫した形式を維持しながら、変化するビジネス状況に一貫して迅速に対応するための優れたプラクティスの集合体です。
• MEGAF（メガモデリングアーキテクチャフレームワーク）^[30]は、ISO/IEC/IEEE 42010で規定されているアーキテクチャフレームワークの定義に準拠したアーキテクチャフレームワークを実現するための基盤である。
• オープンエンタープライズ方法論であるPraxemeには、エンタープライズシステムトポロジ（EST）と呼ばれるエンタープライズアーキテクチャフレームワークが含まれています。
• TRAK – MODAF 1.2 をベースにし、GPL / GFDLの下でリリースされた汎用システム指向フレームワーク。
• シャーウッド応用ビジネスセキュリティアーキテクチャ（SABSA）^[31]は、リスクベースでビジネスとIT管理にセキュリティを統合することに重点を置いているエンタープライズセキュリティアーキテクチャとサービス管理のためのオープンフレームワークと方法論です。

• ASSIMPLER フレームワーク – 2002 年に Wipro で Mandar Vanarse が行った作業に基づくアーキテクチャ フレームワーク
• Avancier Methods（AM）^[32]トレーニングと認定によってサポートされる、エンタープライズおよびソリューションアーキテクト向けのプロセスとドキュメントのアドバイス。
• BRM (Build-Run-Manage) フレームワーク - 2000 年に IBM に入社したばかりの頃に Sanjeev "Sunny" Mishra によって作成されたアーキテクチャ フレームワーク。
• Capgemini統合アーキテクチャ フレームワーク(IAF) – 1993 年にCapgemini社から
• Dragon1 - オープンなビジュアルエンタープライズアーキテクチャメソッドで、最近The Open Groupによってアーキテクチャフレームワークとして認められました。
• 2004 年からSogetiによって開発されたDYAフレームワーク。
• ダイナミックエンタープライズWeb 2.0テクノロジーに基づくエンタープライズアーキテクチャコンセプト
• 拡張エンタープライズ アーキテクチャ フレームワーク- 2003 年に Institute For Enterprise Architecture Developments から提供
• EACOEフレームワーク[3] – ジョン・ザックマンの研究成果を発展させたエンタープライズアーキテクチャフレームワーク
• IBM Information FrameWork (IFW) – 1996年にRoger Everndenによって考案されました。
• Infomet - 1990 年に Pieter Viljoen によって考案されました
• ラボナフ^[33] - 企業変革を推進するための統一フレームワーク
• プラグマティックエンタープライズアーキテクチャフレームワーク（PEAF）^[34] - プラグマティックEAのケビン・リー・スミスが2008年から開発したプラグマティックフレームワークファミリーの一部。
• 1990 年代初頭にパデュー大学のTheodore J. Williamsによって開発されたパデュー エンタープライズ リファレンス アーキテクチャ。
• 2015 年から CGI によって開発されているリスクおよびコスト主導型アーキテクチャ (RCDA)。
• SAP エンタープライズ アーキテクチャ フレームワーク
• マイケル・ベルの研究に基づくサービス指向モデリングフレームワーク（SOMF）
• ソリューションアーキテクチャメカニズム（SAM）^[35] – 一連の統合モジュールから構成される一貫したアーキテクチャフレームワーク。^[36]
• Zachman Framework – 1980年代のIBMのJohn Zachman氏の研究に基づいたアーキテクチャフレームワーク

• アーキテクチャ パターン (EA リファレンス アーキテクチャ)
• EABOK (エンタープライズ アーキテクチャ知識体系ガイド)
• エンタープライズアーキテクチャ
• エンタープライズアーキテクチャアーティファクト
• エンタープライズアーキテクチャ計画
• エンタープライズエンジニアリング
• IEEE 42010 規格
• リファレンスアーキテクチャ

• エンタープライズ アーキテクチャ フレームワーク: 世紀の流行 (2016 年 7 月)
• 上位 4 つのエンタープライズ アーキテクチャ フレームワークの比較 (2021 年 7 月)