ＥＡ（エンタープライズアーキテクチャ）は、文字通り、企業全体（Enterprise）にかかわる構造・構成（Architecture）を意味し、その成果物は「企業の設計図」に相当するものとして、経営管理上も極めて大きな価値をもつ資料となります。

ＥＡ（エンタープライズアーキテクチャ）は、特に重複する業務や乱立する情報システムの整理・統合を主たる目的として策定されるものですが、その発祥は「情報システムの投資効率化」にあります。

1990年代前半、米国連邦政府は巨額の財政赤字に苦しんでいました。そこで目を付けられたのが、情報システムに関する投資です。連邦政府全体をひとつの企業としてみた場合、数多くの情報システムが各省庁、あるいは部局ごと個別にバラバラに構築され、それらの多くが決して成功とはいえないものとなっていました。そして、この時期、各種のオープン･アーキテクチャが実用システムとしてビジネス界に浸透してきました。

これらを背景に、米国連邦政府によって策定されたのが「ＥＡフレームワーク Ver1.1 (Federal Enterprise Architecture Framework ver1.1（1999）)」です。これは日本政府にも影響を与え、「電子政府構築計画」（2003年7月）の中で2006年までにＥＡに則って各省庁のIT企画・開発を進めるという方針が発表されました。

「縦割り」に陥りやすい官公庁を発祥とするＥＡ（エンタープライズアーキテクチャ）ではありますが、「縦割り」は官公庁だけの問題ではありません。民間企業でも、企業の規模が大きくなればなるほど全体が見えなくなります。このような問題は、事業本部制を長くとってきた企業や、合併や統合を行った企業では特に顕著になり、また、企業を単体ではなく企業グループで捉えると、「縦割り」の弊害による構造疲労が浮き彫りになります。ＥＡ（エンタープライズアーキテクチャ）は、このような問題を解決し、全体最適を実現するために作成されるものです。

ＥＡ（エンタープライズアーキテクチャ）は、しばしば下記のような参照モデルをベースに語られます。

上記のうち、最上位のビジネス・アーキテクチャは、ビジネスそのものを表現し、データ、アプリケーション、テクニカルの各アーキテクチャは、文字通り情報システムにおけるデータ、アプリケーションプログラム、基盤技術を示します。

ここで特に注目したいのがビジネス・アーキテクチャ（ＢＡ）です。当初は下位の三層（すなわち情報システム）であった概念が、後に「ビジネスも同時に語らないとＥＡは完結しない」「乱立する情報システムの整理・統合を行うためには、まず重複する業務の整理が必要」ということになり、最上位のビジネス・アーキテクチャの概念が追加されました。

このビジネス・アーキテクチャにおけるビジネスの表現には、DFD（Data Flow Diagram）など、本来情報システムの設計書法として使われてきた表記法を主体に表現することとされています（ＩＴアソシエイト協議会「業務・システム最適化計画について（ver.1.1）～ Enterprise Architecture 策定ガイドライン ～（2003年12月）」（経済産業省が作成したサンプルモデルは下図参照）。

このような「ビジネス表現のためにシステム開発の表記法を適用する」ようなやり方は、航空地図を作る際にメルカトル図法を用いるようなもので、ビジネスを的確に表現するための手法が確立されていない証左と考える事ができます。また、目的に合致しない表記法で作成されたEA（エンタープライズアーキテクチャ）の成果物は不必要に膨大になりがちで、このためにEA（エンタープライズアーキテクチャ）の本来の目的を達成しないまま、しっくりこない膨大な成果物がキャビネットに死蔵されてしまうようなケースも多く見られるというのが現実です。

但し、上記のガイドラインは、あくまで政府官公庁向けのガイドラインであって、民間企業用のガイドラインではありません。したがって、民間企業がＥＡ（エンタープライズアーキテクチャ）を策定する際は、その体系や表記法は民間企業が自由に決定すればよいということになります（そういう意味では、データ、アプリケーション、テクニカルなど下位のアーキテクチャは作成せずに、最上位のビジネス・アーキテクチャに様々な要素を集約して作成するといった判断なども十分あり得る選択肢です）。

それでは、ＥＡ（エンタープライズアーキテクチャ）を的確にすすめるための表記法やツールはどのようなものが望まれるのでしょうか。その要件は以下のようにまとめることができます。

• 特に「ビジネス・アーキテクチャ」は、ビジネスの現場にいて、これをよく知る者が理解し、主導しなくてはならないものであるため（あるいは、そうしないと極めて非効率になるため）、可能な限りビジネスマンにとって初見で理解できる分かりやすさをもつこと
• 重複する、あるいは無駄な業務を排するという目的を達成するため、業務の意味・意義（why）、業務の売上・利益やコスト（how much）、業務プロセスの流れや遂行手段（how）、業務の遂行主体（who）など、業務の5W2Hを多角的に表現し、その実態と価値を的確に表現できること
• 無駄な情報システムの整理という点が主眼のひとつであるため、各情報システムに関わる維持・運営コスト、保守コストなどが表現できること
• 重複する業務や情報システムを抽出するために「機能」を軸に、この「機能」に関連する業務や組織、情報システムを串刺しで一覧できること
• 各成果物をバラバラに作成し管理するのではなく、統合的なプラットフォームの上で一体的に分析・評価し管理できること（これは無駄や重複を効率的に検出していくという観点から極めて重要なポイントになります）
• 企業全体や企業グル―プ全体など広域的な領域を分析対象とするため、階層的な分析・モデル化が可能であること
• 作成された成果物を「キャビネットにしまったまま」のような状態にしないため、成果物を業務やシステム管理の中で使い続けるに足るだけの様々な付加価値や多目的性・実用性をもつこと