Ｅｎｔｅｒｐｒｉｓｅ　Ａｒｃｈｉｔｅｃｔｕｒｅについて～　ＥＡの策定方法～

Ｅｎｔｅｒｐｒｉｓｅ　Ａｒｃｈｉｔｅｃｔｕｒｅについて～　ＥＡの策定方法～Ｅｎｔｅｒｐｒｉｓｅ　Ａｒｃｈｉｔｅｃｔｕｒｅについて～　ＥＡの策定方法～平成１６年１月１９日経済産業省　　村上敬亮　

目　次 ■EA導入の目的と背景－　ＩＴ投資管理市場で起きている変化について。ＩＴ投資管理の全体像について－　EAとは。EAのフレームワーク。ＥＡ成果物の全体像－　参照モデル、EA導入手順、EAプロセス ■　EAの策定方法－　業務・システムの概要と最適化の方向性－　各体系の成果物の作成方法－　参照モデル、個別調達案件への反映方法 ■　EAの策定・管理体制と評価－　プログラム管理とプロジェクト管理－　CEO、CIO、CIO補佐官、業務部門長それぞれの役割－　政策評価、行政評価

業務・システム最適化計画（EA）の全体像 ■　業務・システム最適化計画（EA）の全体像 • 業務・システムの概要と最適化の方向性＝＞　EA導入の目的　（ミッションと原則） • 業務・システムの現状、理想及び次期モデルの内容＝＞　開発・利用の対象となる狭義の「EA成果物」 • 最適化の実施内容＝＞　EAが当面目指す最適化の目標値 • 最適化工程表＝＞　EAの開発・利用のスケジュールまた、これらとは別に、府省横断的に各種参照モデルを整備。

業務・システムの概要と最適化の方向性 ■　府省横断的、部局横断的な政策・業務分析の開始－　政策・業務参照モデルが定義する、「公共資産管理」、「統計管理」などの共通の定義に基づき、各府省が行っている行政機能を確認。府省横断的、部局横断的に、類似の業務の有無、IT化の有無などをチェックする。

業務・システムの概要と最適化の方向性 業務内容担当課業務実施方法業務支援ツール規制標準等に計画と規基づくと資内部制の活動源配資源情報策定・の承業務機能（業務サブ機能）施策内容／業務内容直接顧客置管理管理管理認公安・社会秩序維持（財産保護等）ｾｷｭﾘﾃｨ認証制度個人／企業セキュリティ室 ○ ○ ○ ○ 公共資産管理（公的記録、ﾃﾞｰﾀ、情報管理）情報収集・提供内部職員情報政策課 ○ 公共資産管理（公的記録、ﾃﾞｰﾀ、情報管理）文書管理内部職員情報政策課産業支援（基準認証）マルチ協力（ｱｼﾞｱPKI、OECD等）海外／企業国際室 ○ ○ ○ ○ 情商資貿産商産業支援（基準認証）二国間協力（欧米、中国、韓国等）海外／企業国際室 ○ ○ ○ ○ 報務源易貿業製務消産業支援（基準認証）ＩＴ機器の標準化企業情報政策課 ○ 政流エ産業支援（基準認証）ＩＴ投資と産業競争力強化業界情報経済課 ▲ ○ ○ ○ ○　業務を実施経易技造情費策通ネ産業支援（基準認証）ｲﾝｼﾃﾞﾝﾄ対応個人／企業セキュリティ室・・・・・・ ●　汎用システム済管術産報経ユグル産業支援（基準認証）ｾｷｭﾘﾃｨ監査個人／企業セキュリティ室 ★　独自システム協理環業政済ニルギ産業支援（基準認証）ｾｷｭﾘﾃｨ人材育成個人／企業セキュリティ室 ○ 力部境局策部ーーッ産業支援（基準認証）ｾｷｭﾘﾃｨ認証制度個人／企業セキュリティ室 ○ ○ ○ ○ 局局局産業支援（基準認証）ＩＣカード個人／企業ﾌﾟﾛｼﾞｪｸﾄ室 ○ ○ ○ トプ庁・産業支援（基準認証）地域情報化個人／企業ﾌﾟﾛｼﾞｪｸﾄ室 ○ ○ ・産業支援（技術研究・開発支援）マルチ協力（ｱｼﾞｱPKI、OECD等）海外／企業国際室 ○ ○ ○ ○ 産業支援（技術研究・開発支援）二国間協力（欧米、中国、韓国等）海外／企業国際室 ○ ○ ○ ○ ・・基準認証 ○ ○ ○ ○ ○ ○ 新規市場創出 ○ ○ ○ ○ ○ 産業支援技術研究・開発支援 ○ ○ ○ ○ セーフティネット ○ ○ ○ ○ エネルギー配送管理 ○ エネルギー・資源管理エネルギー製造管理 ○ ○ エネルギー・資源管理 ○ ・・・・業務内容担当課業務実施方法業務支援ツール規制標準等に計画と規基づくと資内部制の活動源配資源情報策定・の承業務機能（業務サブ機能）施策内容／業務内容直接顧客置管理管理管理認公安・社会秩序維持（財産保護等）ｾｷｭﾘﾃｨ認証制度個人／企業セキュリティ室 ● ○ ○ ○ 公共資産管理（公的記録、ﾃﾞｰﾀ、情報管理）情報収集・提供内部職員情報政策課 ● 公共資産管理（公的記録、ﾃﾞｰﾀ、情報管理）文書管理内部職員情報政策課産業支援（基準認証）マルチ協力（ｱｼﾞｱPKI、OECD等）海外／企業国際室 ● ● ▲ ○ 産業支援（基準認証）二国間協力（欧米、中国、韓国等）海外／企業国際室 ● ● ▲ ○ 産業支援（基準認証）ＩＴ機器の標準化企業情報政策課 ○ 産業支援（基準認証）ＩＴ投資と産業競争力強化業界情報経済課 ● ● ▲ ▲ 産業支援（基準認証）ｲﾝｼﾃﾞﾝﾄ対応個人／企業セキュリティ室産業支援（基準認証）ｾｷｭﾘﾃｨ監査個人／企業セキュリティ室産業支援（基準認証）ｾｷｭﾘﾃｨ人材育成個人／企業セキュリティ室 ● 産業支援（基準認証）ｾｷｭﾘﾃｨ認証制度個人／企業セキュリティ室 ● ● ○ ○ 産業支援（基準認証）ＩＣカード個人／企業ﾌﾟﾛｼﾞｪｸﾄ室 ● ● ▲ 産業支援（基準認証）地域情報化個人／企業ﾌﾟﾛｼﾞｪｸﾄ室 ● ▲ 産業支援（技術研究・開発支援）マルチ協力（ｱｼﾞｱPKI、OECD等）海外／企業国際室 ● ● ● ▲ 産業支援（技術研究・開発支援）二国間協力（欧米、中国、韓国等）海外／企業国際室 ● ● ● ○ ■　最適化対象の抽出－更に各行政機能を以下の視点から分析 • 業務内容（予算、税等） • 業務実施方法 • サービス対象 • IT化の有無－　Enterpriseとして最適化　すべき対象を抽出－　先進事例等を踏まえ　業務オーナーと業務改革　の方向性について討議－　最適化対象となる業務と業務改革の方向性（組織目的　と原則(Mission & Principles)の抽出　現状似たような業務を多くの府省で実施していることが分かる。同じようなツールを使っている業務が分かり、共通ツールの可能性が見えてくる。（○部分を共通の▲・△にしていく可能性）いくつもの組織で、同じような業務を実施していることが見えてくる。　将来像一つの共通かつ最適化された業務プロセスを持てば、いくつか（もしくは全部の）府省で流用・活用できる。

業務・システムの概要と最適化の方向性 ■業務・システムの概要と最適化の方向性－　抽出された最適化の方向性（原則：Principles) と対象業務・システム（組織目的： Mission)、及び対象業務の責任者（業務オーナー）を文章で明確に記述する。 • 最適化の方向性本計画は、△△△及び×××に係る業務の担当者内部での□□□による業務コストの削減を図るとともに、全ての業務の○○化を行い、ペーパレス業務を実現する。 • 　最適化計画の対象業務・システム各府省で実施する△△△及び×××に係る□□□申請等の処理、△△△料の徴収、××に係る監督、□□の管理、□×の障害防止、技術計算、統計作成、電子情報提供等の△△△及び×××に係る一連の事務を総合的に処理する。 • 　業務部門長本計画を策定するに当たり、業務部門の責任者は●●●とする。

業務・システムの概要と最適化の方向性 (Mission & Principles) 狭義のEA成果物現状次期理想業務説明書業務説明書業務説明書 BA 機能構成図（ＤＭＭ）機能構成図（ＤＭＭ）機能構成図（ＤＭＭ）政策・業務体系機能情報関連図（ＤＦＤ）機能情報関連図（ＤＦＤ）機能情報関連図（ＤＦＤ）業務流れ図（ＷＦＡ）業務流れ図（ＷＦＡ）業務流れ図（ＷＦＡ）情報体系整理図（ＵＭＬ）情報分析図（ＣＲＵＤ）情報体系整理図（ＵＭＬ）情報分析図（ＣＲＵＤ）情報体系整理図（ＵＭＬ）情報分析図（ＣＲＵＤ） DA 実体関連ダイアグラム（ERD) 実体関連ダイアグラム（ERD) 実体関連ダイアグラム（ERD) データ体系データ定義表データ定義表データ定義表情報システム関連図 AA 情報システム関連図情報システム関連図適用処理体系情報システム機能構成図情報システム機能構成図情報システム機能構成図ネットワーク構成図ネットワーク構成図ネットワーク構成図 TA ソフトウェア構成図ソフトウェア構成図ソフトウェア構成図技術体系ハードウェア構成図ハードウェア構成図ハードウェア構成図淡色文字は設計開発に合わせ順次作成（注） ■　狭義のEA成果物

政策・業務体系(Business Architecture) ■　業務説明書－　狭義のEA成果物を開発するためのプロジェクト憲章に該当する。「業務・システムの概要と最適化の方向性」を踏まえ、開発すべきEA成果物の内容、そのための体制とスケジュール、リスク要因などEA成果物策定に先立って業務オーナー側と決めておくべきことを確認する。 ■　機能構成図(Data Mandala Matrix(DMM)) －　業務の現場から業務の実際を引き出す役割を担う。－　業務を構成する機能を、3行3列の格子様式を用い階層的に分解・抽出する。－　DMMは、ソフトウエアエンジニアリングに特段の知見を持たない業務の現場から見て難解な機能情報関連図（後述）を理解できるようにつなぐ役割を果たすとともに、CIO補佐官とそのスタッフがお互い理解できる共通の言語で現場とのコミュニケーションを確立するための手段としても有効に機能する。

政策・業務体系(Business Architecture) ■　機能構成図(Data Mandala Matrix(DMM))

政策・業務体系（Business Architecture） ■機能情報関連図(Data Flow Diagram(DFD)) －　DFDは、対象業務と情報の流れを明確化する。－　DFDは、対象となる業務がシステム化されているか否かにかかわらず作成される。具体的にどのようなソフトウエアや情報技術が適用されるかは、全く関係しない。総務省共済組人事院人事院人材職員行政管理局財務省合省内各被災職員課室機構定員希望・発令機構定員合格者情報定数改定内定通知申請・承認＆定数改定要求項目申請・支払採用・配共済組合属結果厚生個人票申請・承認申請・承認機構定員内閣府人事記録設定改正規程掲載依頼省内各共済利用料回収指示課室研修計画案・募集宮内庁指示人事ファイル人事記録表彰・叙利用料回収指示勲結果通知・受講者推薦・内示業界団アンケート体等役職別人数結果人事評価内示受講記録依頼講師研修結果公表プレス表彰人事評価出勤状況昇任・昇格出退勤給与等支発令・処分・超勤管理払勤務日数勤務報告書職員支払出勤簿・調整税・申告・源実績報告休暇簿記入給与明細書泉徴収票／確認職員アルバイト税務署財務省併任先職員アルバイト

政策・業務体系（ Business Architecture） ■DFDとDMMの対比－　DFD は、DMM が分析した行政機能に情報の流れとイベントが付け加えられた形となる。 DFD DMM 職員業者人事院機構定員採用・配属厚生・共済設定採用・配属厚生・共済機構定員研修設定表彰・叙勲人事給与研修表彰・叙勲イベントと情報を明らかに稼動給与等人事評価稼動人事評価支払給与等支払

政策・業務体系（Business Architecture） ■　トップダウンアプローチ－　DMMとDFDでは、行政機能をトップダウンで分析する。－　現在の業務処理の方法や、既存の組織に引っ張られずに、行政機能はトップダウンで、情報はボトムアップで分析することにより、最適化への入り口が得られる。

政策・業務体系（Business Architecture） ■DFDベースでの機能の論理化Ⅰ －　イベントとファンクションを接続しながら、情報の流れを追う。タイムイベント【①個々の情報の流れを探す】職員支払指示厚生給与等支払い利用情報外部イベント共済利用ファイルオーダー（申請）【②流れを大きな流れに接続する】【③機能全体で大きな流れを見つける】ファンク A ション DFD B （ファンクション）＊＊ファイル C ファンクション B ファンクション DFD C （ファンクション）＊＊ファイル D ファンクション

政策・業務体系（Business Architecture） 健康管理健康診断宿舎管理各種情報公務災害厚生共済提供事務レクレー保養施設割引チション助提供ケット斡旋成 ■DFDベースでの機能の論理化Ⅱ －　タイムイベントが少なくなるよう、行政機能を無駄のない配置に再構成する。－　再構成の流れを基に、機能名称を論理的に再構成する。【②上位レベルを再構成する】【①下位レベルで再構成する】【③機能名称を論理的に再構成する】現行体系将来体系申込み調査計画調整受付利用料厚生共済論理化ファンクションの審査回収（便益提供）利用料利用利用許可請求

政策・業務体系（Business Architecture） ■　計画・評価機能を追加し、理想（ToBe）モデルのDFDを完成【 ②DFDベースで各レベルに　　　　　計画・評価機能を追加】【①DMMベースで各レベルに　　　　　計画・評価機能を追加】

政策・業務体系（Business Architecture） ■　業務流れ図（Work Flow Architecture）の作成－　システム化を行う業務処理過程の中で、個々のデータが処理される組織・場所と順序をわかりやすく記述したもの－　DFDやUMLクラス図では見えにくい、内部組織や業務手順の変更の必要性など実務との対応関係がより明確になる。－　人間が行う処理とコンピュータが行う処理のインターフェースがどこにあって人間系の処理との相性が良いかどうか、異なるコンピュータ同士での業務処理の繋ぎがどこで行われるのかも、一層可視化される。

データ体系（Data Architecture） ■情報体系整理図（UMLクラス図）－　政策・業務分析が明らかにした業務機能で扱う全ての情報間にある論理的な関連及び構造を明確化するため、情報体系図（UMLクラス図）を作成する。－　更に情報を丹念に分析し抽象化することにより、データ資産を組織で最大限有効に活用するための基盤を整える。 ■　クラス図作成を通じた情報の抽象化－　理想像の情報体系整理図（UMLクラス図）は、以下の手順で作成される。 • 　現行情報の収集と分析 • 　情報の抽象化 • 　情報分析図（CRUD）の作成 • 　情報の抽象化後の情報体系整理図（ UMLクラス図）の作成 • 計画／評価機能追加をし、理想（ToBe）モデルの情報体系整理図（UMLクラス図）の作成

データ体系（Data Architecture） ■現行情報の収集と分析－　論理化後のDFDを元に、最初のイベントに着目しながら、入力される情報を丹念に洗い出す。－　各申込書や領収書レベルを確認し、「職員」という情報レベルではなく、その情報を構成する、「性別」、「住所」などのデータ属性レベルまで降りて分析を行う。－　分析の結果は、データ捕捉分類シートに書き出す。

データ体系（Data Architecture） ■情報の抽象化Ⅰ －　情報の抽象化とは、すなわち第三レベルまでのデータの正規化の作業を行う。通常の正規化の方法に則り、抽出された情報のグループ化（データエンティティにまとめる作業）と分類を徹底して行う。

データ体系（Data Architecture） ■情報の抽象化Ⅱ －　抽象化した結果を、「ヒト」「モノ」「カネ」などのエンティティに分けて整理する。

データ体系（Data Architecture） Web サービス Web サービスファイル Store) 蓄積（ E) 抽出（ Move Move Input Time Stamp Time Stamp ■情報分析図（CRUD）の作成－　具体的に各々の業務がどのように起動し行動が起こされていくのか、抽象化後の情報を元に、業務機能に即してデータエンティティの動きを具体的に分析する。－　その際は、右図のようなCRUD図を作成するのが便利である。調整・資格利用料回登録申込受付利用許可利用利用料計算審査収 ENTITY 　組織 I E （E)、E （E)、E （E)、E （E)、E （E)、E 　職員 I E （E)、E （E)、E （E)、E （E)、E （E)、E サービス提供者 I E （E)、E （E)、E （E)、E （E)、E （E)、E 　厚生サービス I E （E) （E) （E) （E) （E) 　勘定科目 I E （E) （E) （E) （E) （E) EVENT 　申込受付 I M M M M M 調整・資格審査 I M M M M 　利用許可 I M M M 　利用 I M M 　利用料計算 I M 　利用料回収 I 情報健康診断健康診断健康診断健康診断請健康診断健康診断資格確認利用書＋受診書＋求書＋確認領収書＋申込書書、タイム確認タイム確認タイムタイムスタン確認タイムスタンプスタンプスタンププスタンプ注）：IはInput、EはExtract、MはMove、（E)は抽出されたものがそのまま移動している

データ体系（Data Architecture） ■情報体系整理図（UMLクラス図）の作成－　情報分析図の成果を元に、UMLクラス図を作成する。

データ体系（Data Architecture） ■情報体系整理図（UMLクラス図）の作成－　DFDの時と同じように、計画・評価プロセスを追加することにより、理想（ToBe)モデルのUMLクラス図が完成する。－　先ずは、情報分析図（CRUD）に戻って、計画・評価プロセスを追加する。

データ体系（Data Architecture） ■情報体系整理図（UMLクラス図）の作成－　次に、情報分析図（CRUD）に基づいて、UMLクラス図に展開する。

データ体系（Data Architecture） ■　実体関連ダイアグラム（Entity Relationship Diagram;ERD）－　実体関連ダイアグラムでは、管理対象となるエンティティ及びリレーションシップの概念を用いて、業務処理等に必要なデータの関係を統一記述規則に基づき実装ベースのデータ体系を明らかにする。－　UMLクラス図に代えてERDを論理データ体系とすることも、UMLクラス図をもって実装ベースのDAとすることも状況によっては可能である。

データ体系（Data Architecture） ■ERDの作成－　UMLクラス図及び分析した情報を元に、ERDを作成する。－　ERDは、論理的に全体を捉えるにはやや細かい面もあるが、情報を捕捉する、必要な情報の全体像、所在を把握するには、非常に理解しやすく使いやすいツールである。

データ体系（Data Architecture） ■ERDの作成例（人事・給与のレベル1）

次期モデルのBAとDA ■　次期モデルのDMMとDFD －　完成した理想（ToBe）モデルに従い、次期モデルを設計する。 0 DFD) 次期レベル（総務省総務省内々定共済組内々定共済組人事院人事院人事院職員人事院職員財務省行政管理局行政管理局財務省者合者合省内各省内各職員職員課室課室機構定員希望・発令機構定員定数改定合格者情報申請・承認内定通知要求項目＆定数改定申請・支払採用・配採用・配共済組合共済組合属属結果厚生共済厚生共済申請・承認行政目標計画計画（抽象化）（抽象化）行政目標内閣府（行政目標設定内閣府（行政目標設定改正規程掲載依頼追加）追加）人事記録利用料請求省内各行政目標省内各課室課室研修計画案・募集宮内庁宮内庁指示行政目標ファイル人事ファイル役職別人数結果結果通知・受講者受講者推薦・内示行政目標研修業界団研修受講記録アンケート業界団体等体等人事評価行政目標結果公表依頼講師行政目標講師行政目標人事評価人事評価プレスプレス稼働稼働表彰出勤状況（抽象化）出勤簿・（抽象化）昇任・昇格給与等支給与等支休暇簿記入発令・処分／確認払払勤務日数職員職員勤務報告書職員職員アルバイトアルバイト実績報告支払調整税・申告・源泉徴収票給与明細書税務署財務省職員税務署財務省部分が追加、変更のあるプロセス職員併任先併任先アルバイトアルバイト

次期モデルのBAとDA ■　次期モデルのCRUDとUMLクラス図－　完成した理想（ToBe）モデルに従い、次期モデルを設計する。

次期モデルのBAとDA ■　次期モデルのWFA －　完成した理想（ToBe）モデルに従い、次期モデルを設計する。－　これらの各種次期モデルは、　次期個別システム調達の際の　技術要件等として、直接引用　されていくこととなる。

BAとDAの総括 ■最適化に向けた三つのポイント • 　海外等先進事例を参照しつつ改革の方向性と枠組みを合意する • 業務・システムの概要と最適化の方向性（討議と決断） • 　与えられた枠組みの中で「機能の論理化」及び「情報の抽象化」を行う • DFDとUMLクラス図における理想（ToBe）モデルの作成作業（方法論的） • BA／DAそれぞれに計画／評価プロセスを追加、行政評価・政策評価を内生化 • DFDとUMLクラス図における理想（ToBe）モデルの作成作業（方法論的） ■　BAとDAにおける作業－　DFD、UMLクラス図、ERDなど各成果物毎に解説を行っているが、現実の作業は、現状（AsIs）モデル　＞＞　理想（ToBe）モデル　＞＞　次期モデルの順で、それぞれのモデルについて政策・業務体系の策定とデータ体系の作業は完全に一体的に行うことが必要である（次ページ参照）。－　適用処理体系、技術体系の成果とも逐次整合性を図らねばならないので注意が必要である。

BAとDAの総括 　業務システム体系（BA）　　データ体系（DA）　現状（AsIs) モデル　 DMM （AsIs） DFD （AsIs）情報の抽出 ERD データ定義表機能の論理化情報の抽象化 CRUD 分析 DFD UML ｸﾗｽ図 ERD データ定義表計画／評価の追加先進事例の参照計画／評価の追加先進事例の参照 CRUD 分析理想（ToBe) モデル　 DMM （ToBe） DFD （ToBe）ｸﾗｽ図 (ToBe) ERD データ定義表 CRUD 分析 DMM （次期） DFD （次期）ｸﾗｽ図 (次期) ERD 次期モデルデータ定義表

適用処理体系（Application Architecture） ■　サービスコンポーネント参照モデルの活用－　適用処理体系は、政策・業務体系分析及びデータ体系分析によって得られた技術中立的な業務・システムの最適化理想像を、技術的、物理環境的制約を考慮して実現するためのサービスの固まりの構成である。－　米国では、技術的に実現可能な業務機能の構成、サービスコンポーネントを標準的に参照できるようサービスコンポーネント参照モデルが用意されている。同参照モデルが提供するサービス領域の定義は、下図のとおり。

適用処理体系（Application Architecture） ■　情報システム関連図－　右図は、職員採用のための業務システムを新規に構築する場合。－　これまで分析された機能と　情報の流れを　　　サービス領域＝＞サービスタイプ＝＞サービスコンポーネント　と、徐々にサービスの固まりを絞り込み、技術的に実装する　システムの単位に落とし込む　作業を行う。

適用処理体系（Application Architecture） ■　情報システム関連図－　作られたサービスコンポーネントに対応するシステムと、その関連を情報システム関連図に落とす。 ■　情報システム機能構成図－　各システムの機能を明確化するため、必要に応じ、情報システム機能構成図を作成する。

技術体系（Technology Architecture） 区分カテゴリ現状の技術標準将来の技術アプリケーションソフトウエアユーザアプリケーション C, VB, COBOL, Java Java オフィスオートメーション Office, ワープロ , 表計算 - ビジネスプロセス Work - Flow - BPEL4WS, W3C - CG アプリケーション経路アクセス経路 Motif, Windows, HTML, HTTP HTML, HTTP Web サービスプラットフォーム ( チャネル ) サービス経路 HTTP, JSP, ASP, NDS, LDAP HTT P, JSP, LDAP UDDI, WSDL コミュニケーションサービス X.400, SMTP SMTP 出力サービス G3, G4, 9660, Joliet, HFS G3, 9660 処理アプリケーションサービス COM+, J2EE J2EE ( プロセス ) ソフトウエア工学サービス C, VB, COBOL, Java, PDF, Flash Java, PDF, UML 環境管理 NQS - 技術サポート - - マルチメディアサービス JPEG, GIF, PNG, TIF JPEG JPEG2000 グラフィックス - - 情報データベース ODBC, JDBC, ADO, SQL SQL, JDBC ( データ ) データ管理 RDB, SQL RDB, SQL データ交換 CSV, XML, SGML, RDF, EDI XML, RDF, EDI Xforms, SemanticWeb 土台プラットフォーム通信サービス IPX/SPX, TCP/IP (IPv4) TCP/IP(IPv4) IPv6 ( ベース ) OS サービス UNIX, Windows, メインフレーム UNIX, Windows Linux 物理環境サービス - - 外部環境ハードウエア SCSI, USB, 100BASE USB2, 100BASE SerialATA、1000BASE , 共通基盤セキュリティ GPKI, IC カード , SSL GPKI, IC カード , SSL WS - Security 分散コンピューティング CORB A, HTTP HTTP グリッドシステム / ネットワーク管理 SNMP, MIB SNMP, MIB CIM, WBEM 国際化 Shift - JIS, EUC, UTF - 8 UTF - 8, Shift - JIS ■　技術参照モデルの活用－技術体系は、必要となる技術基盤を示す体系である。－　技術参照モデルは、技術の種類の定義（下図左側）と、TA作成に活用可能な技術を整理する。

技術体系（Technology Architecture） ■　技術参照モデルの活用－技術参照モデルは、各層の技術の世代と相互の互換性を明示する。－　技術参照モデルから理想、次期それぞれのモデルに活用する技術を　選択する際には、これらの技術の世代と相互運用性を明確に整理する　ことが求められる。

技術体系（Technology Architecture） ■　ネットワーク構成図－　技術参照モデルを参照しつつ、現状、理想、次期それぞれのモデルを作成する。

技術体系（Technology Architecture） ■　ソフトウエア構成図－　技術参照モデルを参照しつつ、現状、理想、次期それぞれのモデルを作成する。

技術体系（Technology Architecture） ■　ハードウエア構成図－　技術参照モデルを参照しつつ、現状、理想、次期それぞれのモデルを作成する。

参照モデル ■参照モデルの役割－　「相互参照性の高い記述により業務・システムを可視化する」、若しくは、「標準的な業務とシステムの採用を進め全体最適に向けた柔軟性の高いアーキテクチャを実現する」といった目的を実現するためには、相互に理解可能な文法と用語で記載することが望ましく、EA策定を手伝う参照モデルの早期充実は重要課題。－　個々のシステム開発における失敗や成功の知見は、結果として参照モデルにも反映され、参照モデル自体が、一つの知的資産となる。ＥＡ知識ポータル（参照モデルのＤＢと各種ＥＡ） EA更新 EA プロダクト管理体制とコントロールの確立コントロールの確立モニタリングコントロールアプローチの定義ＥＡの保守 EA プロセス現状（ＡｓＩｓ）モデルの策定ＥＡの利用理想（ＴｏＢｅ）モデルの策定次期モデルの策定

参照モデル 　政策・業務参照モデル（Business Reference Model ) 　業績測定参照モデル（Performance Reference Model ) 政策・業務体系　データ参照モデル（Business Architecture） (Data Reference Model) データ体系　サービスコンポーネント参照モデル（Data Architecture） (Service Component Reference Model ) 　技術参照モデル　適用処理体系 (Technical Reference Model ) （Application Architecture）技術体系（Technology Architecture） ■参照モデルの種類－　参照モデルには、各体系に合わせて次のような種類がある。－　我が国では、政策・業務参照モデルが既に政府内部の作業用として策定されているほか、その他の参照モデルについても開発中である。－　次スライド2枚は、本文に触れなかった PRM と DRM を概説する。

参照モデル ■　業績測定参照モデル（Performance Reference Model）－　業績測定参照モデルは、業務・システム最適化の業績測定（Performance）の標準的な評価尺度、すなわち政策評価指標のDBであり、体系的に4つの評価エリアが設けられている。 • －　測定尺度は、 • ・　測定エリア (Measurement Area) • ・　測定カテゴリ（Measurement Category） • ・　測定指標 (Measurement Indicator) • の3階層で整理される。【４つの評価エリアと相互関係】【米国政府予算で求められる業績評価記入例】

参照モデル ■　データ参照モデル（Data Reference Model）－　データ参照モデルは、各府省、将来的には、地方自治体を含めて、組織を超えて流通若しくは共有される可能性の高い情報／データについて、名称、定義及び各種の属性（桁数など）を統一的に記述したモデルである。－　情報の抽象化作業を容易にし、かつ、異なる組織間での情報の相互参照性を高めるためにも、データ参照モデルの充実は重要である。【データ参照モデルの構成】【コアとなるデータタイプ】

個別プロジェクトへの反映 ■　情報提供依頼書（Request for Information:RFI)への反映－　EAが活用されれば、RFIでは、以下のような対応関係で、EA成果物の該当部分の記述がほぼそのまま活用することが出来る。 EA の活用＊ EA を使ってRFIをいかに作成するか【コアとなるデータタイプ】ＲＦ I に盛り込むべき内容（例）内容依頼範囲と内容情報提供依頼概要経営要件戦略、目的 / 狙い、課題等その他要件セキュリティ、標準、サービスレベル（ SLA ）他現行システム現行業務概要概要現行システム概要システム構成他依頼書に盛込むべき項目システムの特徴、機能、（スケジュール、概算費用）依頼事項業務的要件、必要情報等技術的要件、ネットワーク等（

個別プロジェクトへの反映 ■　提案依頼書（Request for Proposal:RFP)への反映－　EAが活用されれば、RFPにおいても、以下のような対応関係で、EA成果物の該当部分の記述がほぼそのまま活用することが出来る。 EA の活用＊ EA を使って RFP をいかに作成するかＲＦＰに盛り込むべき内容（例）内容依頼範囲と内容提案依頼概要経営要件戦略、目的 / 狙い、課題等業務要件業務要件、必要情報等技術要件 IT 化要件、ネットワーク等その他要件セキュリティ、標準、サービスレベル（ SLA ）他現行業務概要現行システム概要現行システム概要システム構成他（提案書に盛込むべき項目提案依頼事項システムの特徴、機能、スケジュール、費用、体制他）

Ｅｎｔｅｒｐｒｉｓｅ Ａｒｃｈｉｔｅｃｔｕｒｅ について ～ ＥＡの策定方法 ～