EAとは、組織全体を記述・整理し、業務やシステムを改善する仕組みの総称である。
EA（Enterprise Architecture）とは、企業や政府機関・自治体などの組織を包括的かつ体系的に記述することによって、組織のあらゆる構成要素を階層化して整理し、経営の効率化を図る方法、またはそのような組織構造を実現するための基本理念である。構成要素には、組織の目標や業務プロセスモデル、業務ルール、情報システム、人的資源なども含まれる。全体最適の観点から業務やシステムを改善する仕組みであり、業務プロセスや情報システムの構造、利用する技術などを組織全体として整理し体系化することによって、複雑化した組織を包括的に見直し、組織全体の総合的な効率化を図ることが期待できる。また、現状（As Is）とあるべき姿（To Be）を定義することで、これらの差から組織を目指すべき形に近づけていくためのプランニングにつなげることができる。
EAでは、次の4つの体系を策定する。

1. 政策・業務体系（BA：Business Architecture）
   政策・業務の内容、実施主体、業務フローなどの姿を体系的に示したものである。
   組織全体の構造や役割などを定義し、業務プロセスや情報をモデル化したもの。現在と将来のビジネス内容を反映した設計図である。これがIT投資を決断する際のガイドとなる。
2. データ体系（DA：Data Architecture）
   各業務・システムにおいて利用される情報（システム上のデータなど）の内容、各情報間の関連性を体系的に示したものである。
   業務に必要なデータの構造。データの再利用性やセキュリティ、品質といった、多様な意味を記述する。それぞれのデータがどこで発生し、どう処理され、いつ消去されるのか、といったことも明らかにする。
3. 適用処理体系（AA：Application Architecture）
   業務処理に用いられる情報システムの形態を体系的に示したものである。
   業務プロセスを支援するシステムの機能と、その実現能力を定義したもの。ビジネスの機能を実現するソフトウェアの構造を記述し、システムの役割と機能を業務の視点からまとめたものである。
4. 技術体系（TA：Technology Architecture）
   実際にシステムを構築する際に利用する諸々の技術的構成要素（ハード、ソフト、ネットワーク）を体系的に示したものである。
   ソフトウェア、ハードウェア、ネットワークなどの技術を用いて、システムの基盤部分を実現する構造。情報システムを将来にわたって安定的に構築・運用・拡張するために必要なIT基盤を定義したものである。具体的には、求められる性能やセキュリティ要件、標準化動向、技術の将来性などから、組織全体の技術標準を設定する。これが、新たに採用する技術や製品が全体最適に合致しているかどうかの評価基準になる。新しいニーズに適応するために新技術を標準に追加するなど、EAの内容を変更するきっかけにもなる。

これらの4つの体系における成果物では、それぞれ、現状を分析した現状モデル（AsIs）を整理し、目標とする理想モデル（ToBe）を描き、最後に現状と理想目標を比較したうえでの現実的な次期モデルを作成する。これらの成果物を一定の標準的な記述様式に従って作成することによって、現状から理想に至る業務・システムの分析、現実的な次期モデル策定を行うことが、EA導入の目的に近づく道筋となる。

【 ザックマン・フレームワーク 】（Zachman framework）
エンタープライズ・アーキテクチャ（EA）を考えるためのフレームワークで、組織（enterprise）という複雑な構造物を体系的に記述・観測できるように、各要素の範囲や関係を分類・整理したもの。EAにおけるフレームワークとは、EAを設計・構築・評価するためのガイドラインとなるもので、ここに実際の組織の構成要素をあてはめていくことで、構造の整理・分析が行える枠組みをいう。ザックマンフレームワークは、企業階層（関与者）の観点を縦軸、5W1Hの観点を横軸に取った6行6列のマトリクスで表現される。ザックマン・フレームワークは横軸の視点（誰が見るのか）と縦軸の焦点（何を見るのか）から成るマトリックスで構成されています。
表1にあるように横軸の5種類の異なる立場の視点としては、プランナ(Planner＝株主・経営者の視点)、オーナ(Owner＝幹部社員の視点)、デザイナ(Designer＝ビジネスアーキテクトの視点)、ビルダ(Builder ＝ITアーキテクトなど技術アーキテクトの視点)、サブコントラクタ(Subcontractor＝プログラマなど外部委託先の視点)といった視点が挙げられています。上流ほど都市計画者のように、方針や目的、要求、指標といった全体的な事項が検討の対象となっているのに対し、下流は具体的・物理的な決定、選択、取捨、組み合わせといった上流に対して制約条件の課せられた詳細事項になっています。最下行に“Functioning Enterprise”とあるが、これは組織の設計図（アーキテクチャ）ではなく、実装（インプリメンテーション）を意味し、オペレーション状態にあるお客様組織そのものを指している。
縦軸の焦点としては、5W1Hの特定内容が挙げられています。左から順に、データ（材料：名詞）、機能（働き：動詞）、ネットワーク（場所、配置）、人（組織）、タイミング（時間）、戦略（動機）といったように、専門的に検討しなければならないフォーカスを与えています。

①5種類の異なる立場の視点（Planner＝株主・経営者の視点、Owner＝幹部社員の視点、Designer＝ビジネスアーキテクトの視点、 Builder ＝ITアーキテクトなど技術アーキテクトの視点、Subcontractor＝プログラマなど外部委託先の視点）からの設計図を用意すべきである。これらはそれぞれお客様組織のスコープ、ビジネスモデル、システムモデル、テクノロジーモデル、詳細表現を表す、としている。ここでシステムモデルとは、“情報システム”に限定しておらず、情報システムのように自動化されるシステムもあれば、人手で行うシステムもある。また、最下行に“Functioning Enterprise”とあるが、これは組織の設計図（アーキテクチャ）ではなく、実装（インプリメンテーション）を意味し、オペレーション状態にあるお客様組織そのものを指している、という点である。そして次に、②それら5つの設計図を5W1H（What、How、Where、Who、When、 Why）という側面（アスペクト）で分析・記述すべきである、ということを示している。さらには、③最上位の行で示されるスコープが、お客様の考える全体最適を行うスコープと合致していること、④すべてのセル（マス目）に収まるようなモデル（Primitiveモデル）が記述されること、つまり、複数のセルにまたがるモデル（Compositeモデル）は望ましくないこと、⑤上位行のセルとその下位行のセルとの整合（Alignment）がとれていること、そして⑥それぞれの行・列・セルが一体化（Integration）されていること、としている。

【 業務説明書 】
業務・システムの管理・運用体制や最適化に向けた責任体制を明確化したものであり、成果物策定チームで共有されるプロジェクト憲章に当たる。

【 DMM ( Diamond Mandala Matrix ：機能構成図） 】
業務を構成する各種機能を３行３列の格子様式で抽出し、階層的に分析して業務・システムの対象範囲を明らかにするものである。業務説明書の内容を客観的に補足しつつ、機能情報関連図を作成するための基礎資料として作成する。

マンダラ・マトリクスでは、9つに区切られたセルの中央に業務名を記入し、周囲にその構成要素を記入します。各構成要素は、次の階層の中央の業務名となり、その周囲に構成要素を記入していきます。階層的に業務を整理するための手法です。

【 DFD(機能情報関連図) 】
機能構成図で抽出された機能間の情報の流れを図式化したもので、業務をシステムにつなげていくための論理構成の基礎となる。
データがどこで発生して、何らかの処理が行われ、その結果がどこへ行くのかを図式化したもの。

【 WFA ( Work Flow Architecture ：業務流れ図） 】
システム化を行う業務処理過程の中で、個々のデータが処理される組織・場所・処理の順序を記述したものである。
業務流れ図（WFA）では、手作業とコンピュータでの処理の範囲を明確にし、組織を具体的に示す必要がある。このため、縦軸方向には機能、横軸方向には機能を実行する主体を記載し、手作業とコンピュータ化されている作業を明確にするとともに、人的処理とシステム処理の間や異なるシステムの間のインターフェースを明確にする。業務流れ図（WFA）は、人間的な要素と情報および機械的な要素の接点を明らかにし、課題を浮き彫りにするという意味で、極めて重要な役割を果たす。

【 UML 】
オブジェクト指向の考えを取り入れ、業務をモデリングするための言語
基礎理論 - 2.アルゴリズムとプログラミング - 5.その他の言語 - 2.その他の言語　を参照

【 データ定義表 】
実体関連ダイアグラム（ERD）に示したすべてのエンティティ、アトリビュート/データ項目、コード項目の定義を明確化し、一覧として整理したデータの辞書である。

【 情報体系整理図（UMLのクラス図） 】
最適化計画に基づき決定された業務対象領域の全情報（伝票、帳票、文書等）を整理し、各情報間の関連および構造を明確化したものである。

【 実体関連ダイアグラム(E-R図) 】
情報関連体系整理図（UMLクラス図）を、システム実装を意識したデータ構造用語辞書（構造定義を含む）に書き換えたものである。

【 情報システム関連図 】
業務・システムの処理過程において情報システム間でやり取りされる情報の種類および方向を図式化したものである。

【 情報システム機能構成図 】
情報システム関連図で得られた方針を基に、情報システム（ハードウェアやソフトウェアなど）で実装する機能の構成を明確に図式化したものである。

【 SOA ( Service Oriented Architecture ：サービス指向アーキテクチャ） 】
業務上の処理単位となるソフトウェアの機能をサービスととらえ、これらをネットワーク上で連携させてシステムを構築する考え方。
業務の変化にサービスを組み替えるだけですばやく対応できる。

SOAで大事なポイント

• 業務上の処理単位(サービス)ごとにソフトウェアが部品化されていること
• 標準化された技術仕様によりサービスのインターフェースが定義されていること
• ネットワーク上でサービスを連携させる機能があること

【 ハードウェア構成 】
情報システムを構成するサーバ、クライアントなどの機器のCPU、メモリ、ハードディスクなどの機能構成を明確化したものである。

【 ソフトウェア構成 】
情報システムを構成するサーバ、クライアントなどの機器に実装するソフトウェアの構成を明確化したものである。

【 ネットワーク構成 】
適用処理体系を受けて、それを実装するための情報システムを構成するサーバ、クライアントなどの機器の物理的または論理的な接続関係を明確化したものである。

現状モデル（AsIs）は、対象の現在の状況を表現するモデルである。
EAでは、「政策・業務体系」「データ体系」「適用処理体系」「技術体系」の４つの体系で、それぞれ、最初に現状を分析した現状モデル（AsIs）を整理し、目標とする理想モデル（ToBe）を描き、最後に現状と理想目標を比較した現実的な次期モデルを作成する。
このように、業務・システムの現状を誰が見ても理解可能な現状（AsIs）モデルに整理すること、すなわち現状の可視化からEAの策定が始まる。
現状モデル分析の作業は、最初に政策・業務とデータ資産を分析し、業務の現状を明確化する。次いで、アプリケーション構成の分析、システム技術の分析を行い、システムの現状を明確化する。

次期モデルは、現実的な目標として達成を目指す姿をあらわすモデルである。
EAでは、「政策・業務体系」「データ体系」「適用処理体系」「技術体系」の４つの体系で、それぞれ最初に現状を分析した現状モデル（AsIs）を整理し、目標とする理想モデル（ToBe）を描き、最後に現状と理想目標を比較した現実的な次期モデルを作成する。
現状（AsIs）モデルで示された組織全体での現状と理想モデル（ToBe）で示された理想目標とを比較しつつ、個々の業務・システムの見直しについてどこまで改善するのかを整理して、現実的な次期の業務・システムの内容を詳細に表したものが次期モデルである。
理想目標に至るまでの移行計画および業務・システム開発に当たっての組織内共通のルール・標準の策定も同時に検討されることになる。

理想モデル（ToBe）は、対象の理想的な将来像・目標を表現するモデルである。
EAでは、「政策・業務体系」「データ体系」「適用処理体系」「技術体系」の４つの体系で、それぞれ、最初に現状を分析した現状モデル（AsIs）を整理し、目標とする理想モデル（ToBe）を描き、最後に現状と理想目標を比較した現実的な次期モデルを作成する。
理想モデル（ToBe）は現状（AsIs）モデルの次に作成されるが、現状モデルを参考にしつつも、現在の制約条件にはとらわれない。本来のあるべき姿を示すために、目指すべき電子政府機能の姿、およびそれに伴う長期的な設計思想に基づいて作成される。
一度ルールや標準を定めても、実際に個別システムを開発してみると、やはり変更の必要がある場合が少なくない。また、当初最善だと考えた方向性が、技術革新やビジネス市場の変化によって必ずしも最善とはならなくなる場合もある。このため、理想（ToBe）モデルを描きつつも、現実のシステム調達・更新や業務改革の進展に合わせて組織全体のルールや標準、ひいては理想目標そのものを柔軟に変えていくような、組織レベルでの改善サイクルを確立する必要がある。こうした要請を踏まえ、ＥＡのフレームワークでは、一度書かれたモデルは、現実に合わせてメンテナンスしていくことを求めている。

1. 平成29年度秋期　問62　　SOA
2. 平成28年度春期　問62　　エンタープライズアーキテクチャ
3. 平成28年度秋期　問61　　エンタープライズアーキテクチャ
4. 平成23年度春期　問61　　エンタープライズアーキテクチャ
5. 平成23年度秋期　問62　　エンタープライズアーキテクチャ
6. 平成22年度秋期　問61　　エンタープライズアーキテクチャ
7. 平成21年度春期　問61　　エンタープライズアーキテクチャ
8. 平成21年度秋期　問61　　エンタープライズアーキテクチャ