ＥＡの概念
ＥＡとは□
参照：「ＥＡの発展経緯」 （std-ea-keii）
ＥＡの構造
４つの体系□
標準的な図表□
各体系の説明
政策･業務体系（ＢＡ）
民間企業では，ビジネスアーキテクチャのままで，経営戦略の明確化とかビジネスモデルの策定というほうがわかりやすいでしょう。対象となる業務・システムの範囲と最適化の方向性を優先順位をつけて明確に示す体系です。この体系で作成されるドキュメントには，業務説明書，機能構成図，機能情報関連図，業務流れ図があります。
- 業務説明書
- 業務・システムの管理・運用体制や最適化に向けた責任体制を明確化したものです。一般に簡潔な文章で記述されます。以下の文書は，それを具体的に詳細化したものであると位置づけられます。
- 機能構成図（ＤＭＭ：Diamond Mandala Matrix）
- 業務機能を階層的に３×３のマトリックスで表現します。中央のマスに業務名を書き，その周囲のマスに中央の業務を構成するサブ業務を，左上から時計周りに業務の順序に合わせて記述します。中央のマスを目的だとすれば，周囲のマスはそれを実現するための機能だともいえます。
最初の左上のマスには「計画」が入り，最後の左中のマスには「モニタリング」が入ります。これはＰＤＣＡサイクルのＰとＡに合致します。
ＤＭＭは階層化しています。上のサブ業務を中央の業務にして，その周りにサブ業務を書きます。このように階層的に業務を分解することにより，複雑な全体の業務を具体的な個々の業務にすることができます。 - 機能情報関連図 （ＤＦＤ：Data Flow Diagram）
- ＤＦＤは，機能と機能の間で主要な情報の流れを図式化したものです。情報システム開発の分野で従来から用いられてきました。ＤＭＭが機能の静的な構造を示しているのに対して，ＤＦＤは機能間の動的な関係を示したものだといえます。
- 業務流れ図（ＷＦＡ：Work Flow Architecture）
- ＤＦＤは抽象的な機能をしたものなので，どの部門が行うのか，情報はどのような形式で伝達されるのかという具体的な記述には向いていません。それを記述したのがＷＦＡです。
改革を検討するときは，現実の組織や帳票をベースにして検討するよりも，機能や情報という抽象的なものにして，あるべき姿を検討するほうがやりやすいものです。しかし，それを実現するには，抽象的なものではなく具体的にする必要があります。それで目標（ToBe）モデルを作成するときには，「現状のＷＦＡ」→「現状のＤＦＤ」→「目標のＤＦＤ」→「目標のＷＦＡ」の順に考えるのがよいのです。
データ･情報体系（ＤＡ）
データ体系とは，業務を遂行するための情報処理に必要となるデータ及びデータ間の関係を示す体系です。個々の業務の処理に基づいて情報システムを構築するよりも，対象とする業務全体で必要となるデータを洗い出して整理することにより，全体最適のシステムにすることができます。
- 情報体系整理図（ＵＲＬクラス図）
- 対象とする業務に関係するすべての情報について，各情報間の関連及び構造を明確化したものです。
ＵＲＬ（Unified Modeling Language）とは，オブジェクト指向で情報システムを図化する標準であり，多様な図法がありますが，そのなかでクラス図は最もポピュラーなものの一つです。また，クラス図には記述のレベルがいろいろありますが，ここで示しているのは最も単純な形式で，クラス（オブジェクト）の列挙とその関連だけを示したものです。
業務に使われている情報を徹底的に洗い出して，それらの情報がどこで創成（Create）され，参照（Read）され，更新（Update）され，消滅（Delete）されるのかを情報分析図（ＣＲＵＤ図）といいます。これは，情報体系整理図や実体関連ダイアグラム（ＥＲＤ）を作成するのに役立ちます。
- 実体関連ダイアグラム（ＥＲＤ：Entity Relationship Diagram）
- 対象業務で主要な実体をエンティティといい，エンティティ間の関連をリレーションシップといいます。それを図化したのがＥＲＤです。ＥＲＤはデータの正規化の手段でもあり，リレーショナルデータベース（ＲＤＢ）の設計に広く利用されています（ＥＲＤに関しては「ＥＲ図」を参照）。
従来から，情報システムの設計ではＥＲＤとＤＦＤが重要な文書とされてきましたが，最近はオブジェクト指向が普及してきたのに伴い，ＵＭＬの図法が普及してきました。一般にＥＲＤはクラス図で表現することができますが，ここではクラス図を単純にしたので，詳細なリレーションシップに関してはＥＲＤで表すことにしています。 - データ定義表
- ＥＲＤにより，データの構造が示されました。データ定義表では，それらの個々のデータについて属性や意味などを一覧にして整理したものです。これにより，データベースが作成できるので，情報システム構築に必要なものですし，業務でも用語が統一できる効果があります。
適用処理体系（ＡＡ）
業務を遂行するための情報処理に関し，データ処理と業務との関係を示す体系です。必要とされる処理機能をモジュールという細かい機能に分解します。これにより，共通機能をまとめたり，参照モデルで提供されるモジュールを利用することができます。
- 情報システム関連図
- 個々の情報システムの間の関連を示したものです。業務・システムの処理過程において情報システム間でやりとりされる情報の種類及び方向を図式化することにより明確にします。これにより，システム全体をいくつかのサブシステムに切り分けるときに，全体の観点からどうまとめるかを検討することができます。
- 情報システム機能構成図
- 情報システム関連図をベースにして，個々の情報システムがどのような機能を持てばよいかに図式化したものです。ここまでの策定により，構築するべき情報システムの論理的な概要が作成されたことになります。
技術体系（ＴＡ）
適用処理体系の方針に従って，それを実現するためのネットワーク，ハードウェア，ソフトウェアなどの技術を具体的に明確化します。技術参照モデルを参照して，理想モデルや次期モデルで採用する技術を決定します。
あくまでもデータ体系や適用処理体系に従って採用する技術を検討するのが正当ですが，現実には技術発展の成果を取り入れることも最適化には重要ですので，技術体系がデータ体系や適用処理体系に影響を与えることもあります。
- ネットワーク構成図
- 通信のプロトコル，サーバやクライアントなどの機器の接続などを明確にします。
- ソフトウエア構成図
- 実際に利用するべきソフトウエアについて，ＯＳ，プログラミング言語，サーバやクライアントでのソフトウェアなどを明確にします。
- ハードウエア構成図
- サーバやクライアントのＣＰＵ，メモリ，ハードディスクなどハードウェアの機能構成を明確化します。
ＥＡプロダクト一覧
全体のＥＡプロダクトの一覧は左のようになります。特にハードウェア構成図，ソフトウェア構成図および情報システム関連図は，技術動向の発展や設計や開発により変化するので，次期モデル，理想モデルについては設計開発に合わせて順次作成します。
工程表
ここまでで次期モデルの仕様が決まりました。それを実施に移すまでの具体的な工程を図示します。業務・システム最適化計画では最適化工程表といっています。
工程表には，全体を示したもの，そのなかの部分的な作業について詳細を示したもの，近時点の工程を詳細に記述したものなど多様なものがありますが，マクロからミクロに階層的に展開することが必要です。
実際にプロジェクトを円滑に運営するためには，プロジェクトマネジメントの体系がありますが，ここでは省略します。
移行プロセス
次期モデルの策定
次期モデルを策定するには，政策業務参照モデル（ＢＲＭ）と自組織での検討が必要です。自組織の検討では，まず企業の目的（Mission）と経営での原則（Principles）を明示することが必要です。そして，業務環境分析（ＳＷＯＴ分析）をして主要課題（ＣＳＦ）を決定するなどにより，また，業績測定参照モデル（ＰＲＭ）を参照することにより，実際の行動計画（アクションプラン）を作り，それにより，何をどのレベルにまで到達させるかを管理する項目（コントロール目標）を定めます。このようにして策定した目標（ToBe）と現行（AsIs）のギャップや目標達成への段階を考慮して，次期モデルの政策・業務のありかたを策定します。
次にデータ体系や適用処理体系を策定しますが，そのときにデータ参照モデル（ＤＲＭ）やサービスコンポーネント参照モデル（ＳＲＭ）を参照します。ＤＲＭには，対象とする業務で必要なデータの構造が示されています。ＳＲＭとは，業務をシステム化するのにあたって，それに類似した情報システムあるいはその部品の一覧です。
データ体系や適用処理体系に影響を与えるのが技術体系です。ハードウェア，ソフトウェア，ネットワークなど情報技術の動向から検討する必要もありますし，開発や運用の方法など全社的な観点から標準化を推進する観点で検討する必要があります。そのときに参照するのが技術参照モデル（ＴＲＭ）です。
ＥＡサイクル
組織を取り巻く環境は激変していますし，情報技術の発展は急速です。組織内外でのＥＡの認識も変化します。また，十分に検討して構築した次期モデルも，実際に運用したときに多様な不都合が生じることもあります。そのために，ＥＡは一度策定したらそれに向かって猪突猛進すればよいものではなく，常に状況をチェックして軌道修正することが大切です。
マネジメントの手法にＰＤＣＡサイクルがあります。これはＰ（計画）－Ｄ（実施）－Ｃ（チェック）－Ａ（対処）のサイクルをまわすことにより，計画と実施の違いを早期に発見して，実施の仕方を変えるとか，次の計画を見直すことで，以前から広く認識され活用されている手法です。
そのＰＤＣＡをＥＡの運営で考えれば，「管理体制とコントロールの確立」－「アプローチ」－「現状モデルの作成」－「理想モデルの作成」－「次期移行計画の策定」－「ＥＡの利用（実施）」－「ＥＡの保守」－「モニタリング・コントロール」と分解できます。これをＥＡサイクルといいますが，ＥＡサイクルを円滑にまわすことが，ＥＡの効果をあげる基本となります。
ＥＡサイクルを円滑にまわすには，参照モデルの整備，成功（失敗）の事例，各部局の状況など多様な知識をデータベースにしておき，それを組織の全員が必要に応じて参照できるようにしておく必要があります。