ザックマンフレームワーク

ザックマンフレームワークはエンタープライズオントロジーであり、エンタープライズ アーキテクチャの基本構造であり、エンタープライズを形式的かつ構造的に表示および定義する方法を提供します。オントロジーは、2 つの歴史的分類の交差点を反映する 2 次元の分類スキーマです。1 つ目は、What、How、When、Who、Where、Why という基本的な疑問文です。2 つ目は、抽象的なアイデアをインスタンスに変換する哲学的概念である具体化から派生したものです。ザックマン フレームワークの具体化変換は、識別、定義、表現、仕様、構成、インスタンス化です。^[1]

ザックマンフレームワークは、それが記述する情報を収集、管理、または使用するための特定の方法やプロセスを意味するものではないという点で方法論ではありません。 ^[2]むしろ、アーキテクチャ成果物（つまり、設計文書、仕様、およびモデル）を整理するためのスキーマを使用して、成果物が誰を対象としているか（たとえば、ビジネスオーナーとビルダー）と、対処されている特定の問題（たとえば、データと機能）の両方を考慮に入れるオントロジーです。^[3]

このフレームワークは、1980年代にIBMで最初にこの概念を開発した作成者のジョン・ザックマンにちなんで名付けられました。それ以来、何度か更新されています。^[4]

「Zachman Framework」というタイトルは、バージョン 3.0 が最新であるエンタープライズ アーキテクチャ用の Zachman Framework を指します。Zachman Framework は 30 年の歴史の中で進化し、次の機能を備えています。

• 最初のフレームワークは、ジョン・ザックマンによる「情報システムアーキテクチャのフレームワーク」と名付けられ、1987年にIBM Systemsジャーナルの記事に掲載されました。^[5]
• エンタープライズアーキテクチャのためのザックマンフレームワークは、1987年のオリジナルの更新版であり、1990年代に拡張され、名前が変更されました。^[6]
• Zachman International が業界標準として提供している Zachman Framework の後のバージョンの 1 つ。

他の情報源では、ザックマン フレームワークは、ジョン ザックマンが考案し、ジョン ザックマンにちなんで名付けられたフレームワークとして紹介されており、さまざまな方法で表現されています (画像を参照)。このフレームワークは、たとえば次のように説明されています。

• データを整理し分析するためのフレームワーク、^[7]
• エンタープライズアーキテクチャのフレームワーク。^[8]
• 分類システム、または分類体系^[9]
• マトリックス（多くの場合6x6マトリックス形式）
• 2次元モデル^[10]または解析モデル。
• 企業の詳細な表現を整理するために使用される2次元スキーマ。^[11]

John Zachman によって開発されたフレームワークの他に、多数の拡張機能やアプリケーションが開発されており、これらは Zachman フレームワークと呼ばれることもありますが、一般的には実際のフレームワーク自体のグラフィカル オーバーレイである傾向があります。

ザックマンフレームワークは、エンタープライズアーキテクチャに関わるさまざまな視点をまとめたものです。これらの視点は、行に沿ってステークホルダーの種類を定義し、列でアーキテクチャの側面を定義する2次元マトリックスで表されます。フレームワークはアーキテクチャの方法論を定義するものではありません。むしろ、マトリックスは、組織が特に必要とする目標/ルール、プロセス、材料、役割、場所、イベントで埋めなければならないテンプレートです。フレームワークの列間のマッピングによるさらなるモデリングにより、組織の文書化された状態のギャップが特定されます。^[12]

フレームワークは、企業の記述表現を分類および整理するための論理構造です。これは、企業の経営陣と、企業システムの開発に携わる関係者の両方にとって重要です。 ^[13]フレームワークの列に優先順位はありませんが、行の上から下への順序は、ビジネスコンセプトと実際の物理的な企業の整合に重要です。フレームワークの詳細レベルは、各セルの機能であり、行の機能ではありません。IT によって実行される場合、低いレベルの焦点は情報技術にありますが、物理的な材料 (ボールバルブ、配管、変圧器、ヒューズボックスなど) と、それらのアイテムに関連する物理的なプロセス、役割、場所などにも同様に適用できます。^[要出典]

1980年代、ジョン・ザックマンはIBMでビジネスシステムプランニング（BSP）の開発に携わっていた。これは組織の情報アーキテクチャを分析、定義、設計するための手法である。1982年にザックマン^{[14]は、これらの分析は}システム設計の自動化やデータ管理をはるかに超えて、戦略的ビジネスプランニングや経営科学全般の領域にまで及ぶ可能性があると結論づけていた。これは、当時はより難解と考えられていたエンタープライズアーキテクチャ、データ駆動型システム設計、データ分類基準などの分野でも活用できる可能性がある。^[14]

1987 年の論文「情報システム アーキテクチャのフレームワーク」^[15]で、ザックマンは、「アーキテクチャ」という用語は情報システムの専門家によって漠然と使用されており、プランナー、設計者、プログラマー、通信専門家などによって異なる意味を持っていると指摘しました。^[16]情報システム アーキテクチャのフレームワークを開発するための客観的で独立した基盤を探す中で、ザックマンは古典的なアーキテクチャの分野と、産業界のさまざまな複雑なエンジニアリング プロジェクトに着目しました。彼は同様のアプローチを見て、アーキテクチャは多くのレベルに存在し、原材料またはデータ、プロセスの機能、場所またはネットワークという少なくとも 3 つの観点を含むという結論に達しました。^[16]

情報システムアーキテクチャは、アーキテクチャモデルを体系化するための分類スキーマとして設計されています。エンタープライズアーキテクチャに必要なモデルの概要を提供します。情報システムアーキテクチャは、モデルに含まれるべき内容を詳細に定義しておらず、各モデルに使用されるモデリング言語を強制しておらず、これらのモデルを作成する方法を提案していません。^[17]

1992年の論文「情報システムアーキテクチャのフレームワークの拡張と形式化」で、ジョン・F・ソーワとジョン・ザックマンはフレームワークとその最近の拡張を紹介し、概念グラフの表記法でどのように形式化できるかを示しています。 ^[18] 1992年には次の 論文も発表されています。

John Zachman の共著者 John Sowa は、「プランナー」のスコープ パースペクティブ (企業とその環境に共通する境界リスト) と、「下請け業者」の詳細な表現パースペクティブ (コンテキスト外のベンダー ソリューション コンポーネント) の追加を提案しました。Who、When、Why の列が公開され、メタフレームワークの 4 つのレベルの概念とパースペクティブ間の統合関連の描写がすべて論文で概説されました。Keri Anderson Healey は、モデルのモデル (フレームワーク メタモデル) の作成を支援し、これも論文に含められました。

— スタン・ロック、「私たちの人生におけるエンタープライズ・コンバージェンス」、エンタープライズ・ニュースレターより^[19]

1990年代後半^[19]

• Clive Finkelsteinのような方法論者は、エンタープライズ エンジニアリングと名付けたフレームワークの上位 2 行に再び焦点を当て、ビジネス ニーズと情報技術エンジニアリングの実装を統合し、各部分の論理的な構築シーケンスを決定する最も成功した方法の 1 つを実現しました。

1997 年の論文「エンタープライズ アーキテクチャのフレームワークの概念」で、ザックマンは、このフレームワークは「エンタープライズ アーキテクチャのフレームワーク」と呼ばれるべきであり、最初からそう呼ばれるべきだったと述べています。しかし、ザックマンによると、1980 年代初頭には「エンタープライズ リエンジニアリングやエンタープライズ モデリングの考え方にはほとんど関心がなく、形式主義やモデルの使用は、情報システム コミュニティ内のアプリケーション開発の一部の側面に限定されていました」。^[20]

2008 年に、Zachman Enterprise は、新しい Zachman Framework 標準として 「Zachman Framework: The Official Concise Definition」を導入しました。

1990 年代以降、次のようないくつかの拡張フレームワークが提案されてきました。

• マシュー＆マギー（1990）^[21]は、当初の3つの視点「何」「どのように」「どこで」を、出来事（「いつ」）、理由（「なぜ」）、組織（「誰」）に拡張した。^[16]
• Schoch & Laplante (1995) は、IBM Systems Journal (第 34 巻、第 1 号、1995 年 1 月、22 ～ 38 ページ) に「リアルタイム システム アーキテクチャのフレームワーク」を発表しました。これは、リアルタイム システムに適用するオリジナルの Zachman フレームワークの拡張です。
• Evernden (1996) は、代替の情報フレームワークを提示しました。
• 1996年以来キャップジェミニが開発してきた統合アーキテクチャフレームワーク。 [ ^22]
• Vladan Jovanovicら（2006）は、ザックマンフレームワークを多次元ザックマンキューブに拡張したザックマンキューブを提示した。^[23]

ザックマンフレームワークの基本的な考え方は、同じ複雑なものやアイテムを、異なる種類の記述（テキスト、グラフィックなど）を使用して、異なる方法で異なる目的で記述できるというものです。ザックマンフレームワークは、あらゆるもの、特に製造品（家電製品など）、建築構造物（建物など）、企業（組織とそのすべての目標、人々、テクノロジー）などの複雑なものを完全に記述するために必要な36のカテゴリを提供します。このフレームワークは、6つの異なる視点から抽象的なアイデアを6つの異なる方法で変換します（詳細を増やすのではなく、変換します）。^[24]

これにより、異なる人々が同じものを異なる視点から見ることができるようになります。これにより、環境の全体的な見方が生まれ、図に示されている重要な能力が生まれます。^[25]

各行は、特定の視点から見たソリューションの全体像を表しています。上位の行または視点は、必ずしも下位の視点よりも全体を包括的に理解しているわけではありません。各行は、明確でユニークな視点を表していますが、各視点からの成果物は、視点レベルでソリューションを定義するのに十分な詳細を提供し、次の下位の行に明示的に翻訳する必要があります。^[26]

各視点は、他の視点の要件とそれらの視点が課す制約を考慮に入れなければなりません。各視点の制約は付加的です。たとえば、上位の行の制約は下位の行に影響します。下位の行の制約は上位の行に影響を与える可能性がありますが、必ずしも影響を与えるわけではありません。要件と制約を理解するには、視点から視点への知識と理解の伝達が必要です。フレームワークは、視点間のコミュニケーションの垂直方向を示しています。^[26]

Zachmanフレームワークの現在のバージョン（3）では、行は次のように分類されます。

• エグゼクティブ パースペクティブ(範囲の内容) – 最初のアーキテクチャ スケッチは「バブル チャート」またはベン図で、最終的な構造のサイズ、形状、部分的な関係、および基本的な目的を大まかに表したものです。これは、システムの範囲、コスト、およびシステムが動作する一般的な環境との関係の概要または見積もりを求めるプランナーまたは投資家向けのエグゼクティブ サマリーに相当します。
• ビジネス管理の観点(ビジネス コンセプト) - 次は、日々の業務でその建物とともに暮らすことになるオーナーの視点から最終的な建物を描いた建築家の図面です。これらは、ビジネスの設計を構成するエンタープライズ (ビジネス) モデルに対応し、ビジネス エンティティとプロセス、およびそれらの関連性を示します。
• 建築家の視点(システム ロジック) – 建築家の計画は、設計者の視点から図面を詳細な要件表現に変換したものです。これらは、ビジネス エンティティとプロセスを表すデータ要素、論理プロセス フロー、および機能を決定する必要があるシステム アナリストによって設計されたシステム モデルに対応しています。
• エンジニアの視点(技術物理学) - 請負業者は、ツール、技術、および材料の制約を理解するのに十分な詳細さで、建築家の計画を再描画してビルダーの視点を表現する必要があります。ビルダーの計画は技術モデルに対応しており、情報システム モデルをプログラミング言語、入出力 (I/O) デバイス、またはその他の必要なサポート技術の詳細に適合させる必要があります。
• 技術者の視点(ツール コンポーネント) – 下請業者は、部品やサブセクションの詳細を指定したショップ プランに基づいて作業します。これらは、システム全体のコンテキストや構造を考慮せずに個々のモジュールをコーディングするプログラマーに提供される詳細な仕様に対応します。または、構築ではなく調達および実装されるさまざまな商用オフザシェルフ (COTS)、政府オフザシェルフ (GOTS)、またはモジュール システム ソフトウェアのコンポーネントの詳細な要件を表すこともできます。
• エンタープライズの視点または（運用インスタンス）

要約すると、各視点は同じ基本的な質問に注目し、その観点からそれらの質問に答え、異なる記述表現（つまりモデル）を作成し、それが上位の視点から下位の視点へと変換されます。焦点（または製品の抽象化）の基本モデルは一定のままです。各列の基本モデルは一意に定義されますが、マトリックス全体にわたって関連しています。^[26]さらに、エンタープライズアーキテクチャコンポーネントの6つのカテゴリと、それらが答える根本的な質問がザックマンフレームワークの列を形成し、これらは次のとおりです。^[24]

1. 在庫セット – 何
2. プロセスフロー – 方法
3. 流通ネットワーク – どこで
4. 責任の割り当て – 誰
5. タイミングサイクル –
6. 動機付けの意図 – なぜ

ザックマンの意見では、彼のフレームワークをユニークにしている唯一の要素は、マトリックスのどちらの軸上の各要素も、その軸上の他のすべての要素と明確に区​​別できることです。マトリックスの各セルの表現は、単に詳細度が増す連続的なレベルではなく、実際には異なる表現であり、文脈、意味、動機、および使用が異なります。どちらの軸上の各要素も他の要素と明確に異なるため、各セルに何が属するかを正確に定義できます。^[24]

ザックマンフレームワークは、通常、コミュニケーション疑問文を列、具体化変換を行とする境界のある6 x 6の「マトリックス」として表されます。フレームワークの分類は、疑問文と変換の交差点であるセルによって抑制されます。^[29]

セルの説明は、Zachman Framework バージョン 3.0 から直接取得されます。

経営者の視点

1. （何）在庫識別
2. （方法）プロセス識別
3. （場所）配布識別
4. （誰の）責任の特定
5. タイミングの特定
6. （なぜ）動機の特定

ビジネスマネジメントの視点

1. （何）在庫の定義
2. （方法）プロセス定義
3. （どこで）分布定義
4. （誰の）責任の定義
5. タイミングの定義
6. （なぜ）モチベーションの定義

建築家の視点

1. （何）在庫表示
2. （方法）プロセス表現
3. （どこで）分布表現
4. （誰）責任の代表
5. タイミング表現
6. （なぜ）動機づけ表現

エンジニアの視点

1. （何）在庫仕様
2. （方法）プロセス仕様
3. （場所）配布仕様
4. （誰の）責任の規定
5. （いつ）タイミング仕様
6. （なぜ）動機の仕様

技術者の視点

1. （何）在庫構成
2. （方法）プロセス構成
3. （場所）配布構成
4. （誰の）責任構成
5. （いつ）タイミング設定
6. （なぜ）動機の設定

企業の視点

1. （何）在庫インスタンス化
2. （方法）プロセスのインスタンス化
3. （どこで）配布インスタンス化
4. （誰の）責任のインスタンス化
5. (いつ)タイミングインスタンス化
6. （なぜ）動機の具体例

各セル内の製品開発（すなわち、アーキテクチャ成果物）またはセルによって具体化された問題解決は、ある観点からの質問に対する答えであるため、通常、モデルまたは説明は、セルの高レベルの描写または表面的な答えです。その答えをサポートする洗練されたモデルまたは設計は、セル内の詳細な説明です。分解（すなわち、より詳細なレベルへのドリルダウン）は、各セル内で行われます。セルが明示的（定義済み）にされていない場合、それは暗黙的（未定義）です。暗黙的である場合、これらのセルについて仮定を行うリスクが存在します。仮定が有効な場合は、時間と費用が節約されます。ただし、仮定が無効な場合は、コストが増加し、実装のスケジュールが超過する可能性があります。^[26]

このフレームワークには一連のルールが付属しています: ^[30]

• ルール1 列には順序がない : 列は交換可能だが、減らしたり作成したりできない
• ルール2 各列には単純な汎用モデルがあります 。各列には独自のメタモデルを設定できます。
• ルール 3 各列の基本モデルは一意である必要があります 。各列の基本モデル、関係オブジェクト、およびその構造は一意です。各関係オブジェクトは相互に依存していますが、表現の目的は一意です。
• ルール 4 各行は、明確で固有の観点を表します 。各行は、特定のビジネス グループの観点を表し、そのグループに固有のものです。通常、ほとんどの階層型組織には、すべての行が存在します。
• ルール 5 各セルは一意です 。2、3、4 の組み合わせにより、各セルが特定のケースを表す一意のセルが生成される必要があります。例: A2 は、最終的に構築されるものを表すビジネス出力を表します。
• ルール 6 1 つの行にあるすべてのセル モデルを合成または統合すると、その行の観点から完全なモデルが構成されます 。行と列を追加しないのと同じ理由で、名前を変更すると、フレームワークの基本的な論理構造が変わる可能性があります。
• ルール 7 ロジックは再帰的です 。ロジックは同じエンティティの 2 つのインスタンス間で関係的です。

このフレームワークは、企業などの概念的オブジェクトだけでなく、あらゆる物理的オブジェクトの記述表現を分類するために使用できるという点で汎用的です。また、それ自体のアーキテクチャ構成を分析するために使用できるという点で再帰的です。フレームワークは、ある列から別の列に関係を伝達しますが、それでも企業の基本的な構造表現であり、フロー表現ではありません。

ザックマンフレームワークの強みの1つは、エンタープライズアーキテクチャで対処できる包括的なビューセットを明示的に示していることです。 ^[12]このモデルに完全に従うと、フレームワーク内の30個のセルのそれぞれに成果物が必要になるため、ドキュメントに重点が置かれすぎる可能性があると考える人もいます。しかし、ザックマンは、分析中の問題を解決するために必要な事実のみを入力する必要があると述べています。

John Zachman は、その文書、プレゼンテーション、セミナーで、フレームワークとして、特定の組織にとっての重要性に基づいて、マトリックスの各セルに必要な詳細の深さと幅に柔軟性があることを明確に述べています。ビジネス目標に在庫とプロセス主導の焦点が必要な自動車メーカーの場合、文書化の取り組みをWhat 列とHow列に集中させると効果的です。対照的に、ビジネスが人とイベントのタイミングに関係する旅行代理店の場合、文書化の取り組みをWho列、 When 列、Where列に集中させると効果的です。ただし、 Why列は他のすべての列のビジネス ドライバーを提供するため、その重要性から逃れることはできません。

1990年代以降、ザックマンフレームワークは、情報技術エンジニアリングスタイルのエンタープライズモデリングの構造を提供する手段として広く使用されてきました。^[31]ザックマンフレームワークは、民間企業と政府機関の両方に適用できます。政府組織内では、フレームワークを抽象的なレベルで機関全体に適用することも、さまざまな部門、オフィス、プログラム、サブユニット、さらには基本的な運用エンティティに適用することもできます。^[32]

Zachman フレームワークは、同様のフレームワークであるTEAFマトリックスを中心に構築されたTEAFなどのカスタマイズされたフレームワークに適用されます。

• 
  TEAF の視点と観点のマトリックス。
• 
  EA の方向性、説明、および達成の概要のフレームワーク。
• 
  TEAF製品。
• 
  EA の方向、説明、達成のための TEAF 作業成果物。

その他の情報源:

• TEAFマトリックスはカスタマイズサンプルと呼ばれています。こちら、22ページをご覧ください。

ザックマンフレームワークは、医療や医療情報システムの標準などの標準を記述するためのフレームワークとしても使用されます。フレームワークの各セルには、医療や医療情報システムの一連の標準が含まれています。^[33]

Zachman フレームワークのもう 1 つの用途は、他のエンタープライズ アーキテクチャの参照モデルとして使用することです。たとえば、次の 4 つを参照してください。

• 
  EAP を Zachman フレームワークにマッピング (1999 年)
• 
  C4ISRのマッピング、1999
• 
  DoD 製品マップと Zachman フレームワーク セル (2003 年)。
• 
  2007 年のDoDAFの一部をマッピングします。

その他の例:

• 合理的統一プロセスのプロセスとしての分析、 ^[34]
• ソフトウェア開発で使用されるモデル駆動型アーキテクチャ（MDA）モデルがZachmanフレームワークにどのようにマッピングされるか。 ^[35]
• 製品情報トレーサビリティを分析するためのZachmanフレームワークにIEC 62264モデルをマッピングする。^[36]
• TOGAFアーキテクチャ開発方法（例：方法論）をZachmanフレームワークにマッピングする。 ^[6]

あまり知られていないのは、オリジナルの Zachman フレームワークが、 NIST エンタープライズ アーキテクチャ モデル、C4ISR AE、DOE AE、DoDAFなどの他のエンタープライズ アーキテクチャ フレームワークの開発に影響を与えた方法です。

• 
  NISTエンタープライズアーキテクチャモデル^[26]
• 
  C4ISR AE、1997年。
• 
  DOE AE、1998年。
• 
  DODAF、2003年。

• 連邦エンタープライズアーキテクチャフレームワーク（FEAF）はザックマンフレームワークに基づいていますが、ザックマンの最初の3列のみを対象とし、わずかに異なる名前を使用して、3行のうち上部に焦点を当てています。^[37]（こちらを参照）

ザックマンフレームワークの方法論は、例えば、 2001年に米国退役軍人省（VA）がワンVAエンタープライズアーキテクチャを開発し、維持するために使用されました。この方法論では、ビジネスプロセス、データ、技術、場所、人員、要件の観点から、VAエンタープライズのすべての側面を定義する必要がありました。方法論を実装する次のステップは、各ビジネスプロセスに関連するすべての機能を定義し、関連するデータ要素を特定することです。特定されると、機能の重複とデータ定義の不一致を特定して解決できます。^[38]

• 
  VA IT プロジェクトの統合プロセス フロー (2001)
• 
  VA ザックマン フレームワーク ポータル
• 
  VA EA リポジトリの紹介 (2008)
• 
  Zachman アーキテクチャ フレームワークのチュートリアル

21 世紀初頭^{[いつ? ]}に退役軍人省は、Zachman フレームワークに完全に基づいたエンタープライズ アーキテクチャを実装することを計画しました。

• Zachman フレームワークは、2001 年にエンタープライズ アーキテクチャ計画を開始するための参照モデルとして使用されました。
• その間のどこかに VA Zachman フレームワーク ポータルが構築されました。
• この VA Zachman フレームワーク ポータルは、さまざまなビジネスおよびプロジェクト ソース ドキュメントから収集された EA 情報の決定などにおいて、参照モデルとして現在も使用されています。

最終的に、マクロレベルではザックマンフレームワークによって、セルレベルでは以下に概説するメタモデルによってエンタープライズアーキテクチャリポジトリが作成されました。^[39]

この図^[a]は、VA-EA に組み込まれ、使用されているメタモデルのシンボル表現を提供し、One-VA エンタープライズ アーキテクチャを説明し、商用 EA リポジトリ ソフトウェアを使用せずに EA リポジトリを構築します。これは、 Caliber-RM ソフトウェア製品内のオブジェクト指向データベースを使用して開発されました。Caliber-RM は、EA リポジトリとしてではなく、 ソフトウェア構成管理ツールとして使用することを目的としています。

ただし、このツールでは、エンティティとリレーションシップの定義、およびエンティティとリレーションシップの両方に対するプロパティの定義が可能であり、2003 年初頭に利用可能なテクノロジを考慮すると、EA リポジトリの構築には十分でした。このツールを選択した個人的な動機は、当時利用可能な商用リポジトリ ツールのいずれもが真の Zachman Framework 表現を提供しておらず、非常に独自性が高く、他のベンダーやオープン ソースのコンポーネントを組み込むのが困難だったことです。

この図は、ザックマン フレームワークのいくつかの重要な解釈と、その情報技術投資管理への適応を強調しています。

1. 上から下へ行を進めていくと、情報産業全体の事実上の標準であるシステム開発ライフサイクル(SDLC)をたどることができます。
2. この図は、しばしば無視されるザックマンの 6 行目 (統合された運用エンタープライズ ビュー) の重要性を強調しています。ザックマンの 6 行目の Zuech の解釈における表現は、主に、2 行目から 5 行目にわたって開発されたビジネス プロセスとテクノロジの革新から得られる測定可能なサービスの改善とコストの節約/回避で構成されています。

6 行目は、個々のプロジェクト、および潜在的には投資ポートフォリオ全体の投資収益率を計測して提供します。6 行目がないフレームワークでは埋没コストのみが特定されますが、6 行目の ROI により、メリットを計測し、継続的な改善プロセスで使用して、ベスト プラクティスをキャプチャし、2 行目を通じて適用することができます。

Zachman フレームワークは広く議論されていますが、その実用的な価値は疑問視されています。

• この枠組みは純粋に推測的であり、非経験的であり、「[製造業と建設業の建築表現間の]同等性は、情報システムを含むあらゆる複雑なエンジニアリング製品を構築する過程で類似の建築表現のセットが生成される可能性が高いという主張を強化するだろう」という概念的な議論のみに基づいています^[5]
• 実践的なフィードバックは、ザックマンフレームワークが示唆する企業の包括的な説明を作成するという一般的な考え方は非現実的であることを示している^[40]
• 2004年にジョン・ザックマンは、このフレームワークは理論上のものであり、完全に実装されたことはないと認めた。「誰がフレームワーク全体をうまく実装しているかと聞かれれば、答えは、私たちが知る限り、まだ誰もいない」^[41]
• このフレームワークの実際の適用が成功したことを示す詳細な例は存在しない^[42]
• EA実践者のスタンレー・ゲイバーは、「ジョン・ザックマンが最初に行った古典建築との類似性は誤りであり不完全である」と主張している^[43]。
• ジェイソン・ブルームバーグは、「企業は機械や建物のような普通のシステムではなく、そのように設計したりエンジニアリングしたりすることはできない」と主張している^[44]
• 詳細な調査により、ザックマンフレームワークは実際には純粋に推測的な議論に基づいており、架空の約束で宣伝されており、実用的な使用例はなく、歴史的観点からも、これまでに欠けていた革新的なアイデアを導入していないことが明らかになりました^{[45] [46]}

この批判は、Zachman フレームワークが EA における実際のベスト プラクティスをほとんど反映できないことを示唆しています。

• 概念スキーマ
• データモデル
• エンタープライズアーキテクチャフレームワーク
• エンタープライズアーキテクチャ計画
• FDIC エンタープライズ アーキテクチャ フレームワーク
• 5つのW
• モデルを表示

• 『ザックマンフレームワーク: 公式簡潔定義』、ザックマンインターナショナルのジョン A. ザックマン著、2009 年。
• Zachman フレームワークの進化: Zachman フレームワークの進化の概要 (Zachman International の John P. Zachman 著、2009 年 4 月)。
• UML、RUP、および Zachman フレームワーク: 一緒に使用すればさらに便利、Vitalie Temnenco 著、IBM、2006 年 11 月 15 日。