連邦エンタープライズアーキテクチャ

提供: miniwiki
移動先:案内、検索
ファイル:Structure of the FEAF Components ja.jpg
2001年に発表された米国『連邦事業体仕組フレームワーク』（FEAF）構成要素の構造[1]。

連邦エンタープライズアーキテクチャ (Federal Enterprise Architecture、FEA) はアメリカ合衆国連邦政府のエンタープライズアーキテクチャフレームワークである。それは、連邦政府における情報技術の取得、利用、及び廃止のための共通の方法論を提供する[2]。

エンタープライズアーキテクチャ(EA)はビジネス性能を改善し、そして行政機関が彼らの中核事業（English版）をより良く実行することを助ける、資源の調整のためのマネジメントの実践である。EAは、機関の現在及び将来の状態を記述し、現在状態から望ましい将来状態へ移行する計画をレイアウトする。FEAはこれらの目標を達成させる過程で働く[3]。

米国FEAはClinger-Cohen法に準じて米国連邦政府における情報技術取得のための共通の方法論を提供するため、米国OMB（English版）で始められた。それは、連邦機関を横断し、コストを縮減し、そして市民サービスを向上させる、情報と資源の容易に共有するため設計された [4]。

歴史

1999年9月に、連邦CIO協議会は、複数の機関間相互の境界を跨るシステムのため、連邦機関内のEAを開発するための『連邦エンタープライズアーキテクチャフレームワーク』（FEAF）バージョン1.1を発表した。それは、とりわけ、共通の事業実践の上で、組織的境界を越えて、NIST事業体仕組モデル（English版）を構築した。FEAFは高い優先領域の仕組記述を開発し、文書化するための永久的な標準を提供する。それは、連邦政府の複数組織横断的の機能セグメントのための仕組を記述するガイドラインを提供する[1]。

これらの連邦アーキテクチャセグメントは一括してFEAを構成する。2001年に、連邦エンタープライズワーキング・グループ（FAWG）は、連邦アーキテクチャセグメントを利用しかつ供与するためのEA製品の開発を後援した。規定された方法で特定の問題にアプローチする方法。図に示されるように、FEAFは与えられたアーキテクチャを、EA、データアーキテクチャ、アプリケーションアーキテクチャ、及び技術アーキテクチャに分割する。創られたFEAFの全体的フレームワークは、Zachmanフレームワークの最初の3つのカラム、及びSteven Spewakのエンタープライズアーキテクチャプランニング（English版）方法論を含みます[1]。

参照モデル

ファイル:FEA Reference Models.jpg
FEA[2]。

FEAは、IT資源を記述するための共通の分類体系と概念体系の開発を参照モデルの組合せを使って構築される。これらは以下を含む。

  • 性能参照モデル (Performance Reference Model)
  • 事業参照モデル (Business Reference Model)
  • サービス／コンポーネント参照モデル (Service Component Reference Model)
  • データ参照モデル (Data Reference Model)
  • 技術参照モデル (Technical Reference Model)

それは、連邦機関を横断して情報と資源を容易に共有し、コストを縮減し、市民サービスを改善するため設計される。それは、Clinger-Cohen法に準じ、米国OMBで始められた。

性能参照モデル

ファイル:Performance Reference Model.jpg
性能参照モデル, 2005.[2]

性能参照モデル(PRM)は主要なIT投資の性能と計画された性能へのそれらの貢献を測る標準のフレームワークである[2]。PRM は、次の3つの目的を持つ。

  1. 戦略と日々の意思決定を改善する拡張された性能情報を作るのを助ける。
  2. 整合性－そして貢献のより明確化ー出力及び成果への入力を改善する、それによって、望まれる結果への明確な『見通し』を改善する。
  3. 伝統的組織と境界を跨る性能改善の機会を識別する。

PRMは、バランスト・スコアカード、Baldrige Criteria、価値測定方法論（English版）、ロジックモデル（English版）、バリューチェーン、及び制約理論を含む、性能測定への複数の既存のアプローチ使う。加えて、PRMは、PART評価、GPRA、エンタープライズアーキテクチャ、及び資金計画と投資制御、を通して、どんな機関が現在測定されているかによって伝えられる。PRMは、4つの測定領域から構成される。

  • 役務及び事業結果（Mission and Business Results）
  • 顧客結果（Customer Results）
  • プロセス及び活動（Processes and Activities）
  • 技術（Technology）

事業参照モデル

ファイル:BRM Overview.jpg
事業参照モデルの全貌[2]。

FEAにおける事業参照モデル(BRM)は連邦政府の事業運営を、それらを実行する機関と独立に、記述するための機能駆動的なフレームワークである。このBRMは、機能駆動的アプローチを使う連邦政府の日々の事業運営を記述するため組織化され、階層的に構築される。BRMは、FEAの最初のレイヤーであり、それは、データ分析、サービス・コンポーネント、及び技術の主要な視点である[2]。

BRMは以下の4つの領域に分けられる。

  • 市民へのサービス（Services For Citizens）
  • 配給の様式（Mode of Delivery）
  • サービスの配給支援（Support Delivery of Services）
  • 資源統治の管理（Management of Government Resources）

事業参照モデルは、それを実行する機関、部局、及び事務所と独立なその内部の運営やその市民へのサービスを含む、連邦政府の事業ライン（LOB）の（組織的ではない）機能的ビューを促進する一つの枠組みを提供する。BRMは、ストーブパイプ的、あるいは機関ごとのビューに代えて、連邦政府を巡る共通の事業領域を記述ことによって、機関の協力とFEAや電子政府（e-Gov）戦略のための基盤としてのサービスを促進する[2]。

BRMは、政府の運営について考える改善された方法を提供する一方で、それは、その真の活用は、それが効果的に利用されたときのみ実現できる、単なる一つのモデルである。BRMによって推進される機能的アプローチは、もしそれが、EAビジネスアーキテクチャと連邦機関の全てとOMBのプロセス管理に取り入れられなければ、電子政府の目標達成にはほとんど助けにならないであろう[2]。

サービス参照モデル

ファイル:Service Component Reference Model.jpg
サービス／コンポーネント参照モデル[5]

サービス／コンポーネント参照モデル（SRM）は、サービス／コンポーネントがどのように事業あるいは性能目的を支援するかに関するそれらを分類する事業と性能駆動の機能的フレームワークである[2]。SRMは、IT投資と資産における、政府ワイドな事業とアプリケーション・サービス／コンポーネントの発見を支援するのに使うことを意図します。SRMは、その事業機能と独立に、アプリケーション、アプリケーション能力、コンポーネント、あるいは事業サービスの再利用を支援する効果的基盤を提供できる、水平及び垂直のサービス・ドメインを横断して構造化される。

SRMは、以下のドメインで確立される。

  • 顧客サービス（Customer Services）
  • プロセス自動化サービス（Process Automation Services）
  • 事業管理サービス（Business Management Services）
  • デジタル資産サービス（Digital Asset Services）
  • 事業分析的サービス（Business Analytical Services）
  • バック・オフィス・サービス（Back Office Services）
  • 支援サービス（Support Services）

各サービス・ドメインは、サービス・タイプに分割される。例えば、顧客サービス・ドメインは次の3つのサービス・タイプに対応する。

  1. 顧客の好み
  2. 顧客関係管理
  3. 及び顧客の初期支援

そして各サービスタイプは、さらにコンポーネントに分割される。例えば、顧客の好みサービス・タイプ内に含む4つのコンポーネントは

  1. 個人化
  2. 購読
  3. 警告と通知
  4. 及びプロファイル管理

となる[5]。

データ参照モデル

ファイル:DRM Collaboration Process.jpg
DRMのプロセス協調[2]。

データ参照モデル(DRM)は総合的レベルで、政府のプログラムと事業ラインの運営を支援するデータと情報を記述する。このモデルは、連邦政府と市民の間で起こる相互アクションと交換のタイプを記述することを機関に可能にする[2]。DRMは、詳細のレベルをより大きく分類する。それはまた、連邦データの分類を確立し、そして重複したデータ資源を識別する。一つの共通データモデルは、連邦政府内、及び政府と外部の利害関係者間の情報交換を合理的にするであろう。

DRMのボリューム1は、構造、利用、及びデータ識別構築の高レベルな全貌を提供する。それは下記を解説する。

  • そのモデルの2ー4に詳細化される、コンテンツの紹介と高レベルな全貌を提供する。
  • 残りのボリュームの関心のコミュニティ開発を奨励する。
  • 更なる開発に使うべき基本概念、戦略、及び構造を提供する。

DRMのデータ構造は、モデリング標準と概念を開発すべきであることから出発点である。DRMの結合されたボリュームは、縦横のデータ分類と情報共有を支援する。

技術参照モデル

ファイル:Technical Reference Model.jpg
Technical Reference Model.[2]

The TRM is a component-driven, technical framework categorizing the standards and technologies to support and enable the delivery of Service Components and capabilities. It also unifies existing agency TRMs and E-Gov guidance by providing a foundation to advance the reuse and standardization of technology and Service Components from a government-wide perspective.[2]

The TRM consists of:

  • Service Areas : represent a technical tier supporting the secure construction, exchange, and delivery of Service Components. Each Service Area aggregates the standards and technologies into lower-level functional areas. Each Service Area consists of multiple Service Categories and Service Standards. This hierarchy provides the framework to group standards and technologies that directly support the Service Area. (Purple headings)
  • Service Categories : classify lower levels of technologies and standards with respect to the business or technology function they serve. In turn, each Service Category comprises one or more Service Standards. (Bold-face groupings)
  • Service Standards : define the standards and technologies that support a Service Category. To support agency mapping into the TRM, many of the Service Standards provide illustrative specifications or technologies as examples.(Plain text)

The figure on the right provides a high-level depiction of the TRM.

Aligning agency capital investments to the TRM leverages a common, standardized vocabulary, allowing interagency discovery, collaboration, and interoperability. Agencies and the federal government will benefit from economies of scale by identifying and reusing the best solutions and technologies to support their business functions, mission, and target architecture. Organized in a hierarchy, the TRM categorizes the standards and technologies that collectively support the secure delivery, exchange, and construction of business and application Service Components that may be used and leveraged in a component-based or service-oriented architecture.[2]

FEA アーキテクチャレベル

In the FEA enterprise, segment, and solution architecture provide different business perspectives by varying the level of detail and addressing related but distinct concerns. Just as enterprises are themselves hierarchically organized, so are the different views provided by each type of architecture. The Federal Enterprise Architecture Practice Guidance (2006) has defined three types of architecture:[3]

ファイル:Architectural Levels and Attributes.jpg
Federal Enterprise Architecture levels and attributes[3]
  • Enterprise architecture,
  • Segment architecture, and
  • Solution architecture.

By definition, Enterprise Architecture (EA) is fundamentally concerned with identifying common or shared assets – whether they are strategies, business processes, investments, data, systems, or technologies. EA is driven by strategy; it helps an agency identify whether its resources are properly aligned to the agency mission and strategic goals and objectives. From an investment perspective, EA is used to drive decisions about the IT investment portfolio as a whole. Consequently, the primary stakeholders of the EA are the senior managers and executives tasked with ensuring the agency fulfills its mission as effectively and efficiently as possible.[3]

By contrast, "segment architecture" defines a simple roadmap for a core mission area, business service, or enterprise service. Segment architecture is driven by business management and delivers products that improve the delivery of services to citizens and agency staff. From an investment perspective, segment architecture drives decisions for a business case or group of business cases supporting a core mission area or common or shared service. The primary stakeholders for segment architecture are business owners and managers. Segment architecture is related to EA through three principles:

  • structure: segment architecture inherits the framework used by the EA, although it may be extended and specialized to meet the specific needs of a core mission area or common or shared service.
  • reuse : segment architecture reuses important assets defined at the enterprise level including: data; common business processes and investments; and applications and technologies.
  • alignment : segment architecture aligns with elements defined at the enterprise level, such as business strategies, mandates, standards, and performance measures.[3]

"Solution architecture" defines agency IT assets such as applications or components used to automate and improve individual agency business functions. The scope of a solution architecture is typically limited to a single project and is used to implement all or part of a system or business solution. The primary stakeholders for solution architecture are system users and developers. Solution architecture is commonly related to segment architecture and enterprise architecture through definitions and constraints. For example, segment architecture provides definitions of data or service interfaces used within a core mission area or service, which are accessed by individual solutions. Equally, a solution may be constrained to specific technologies and standards that are defined at the enterprise level.[3]

FEA ツール

A number of modeling tools enable you to capture the Federal Enterprise Architect reference models and align your enterprise architecture against them; some of these are listed below.

The CIO Council's ET.gov site can be used to identify technical specifications (standards) that are not yet included in the TRM but should be. Those that have been identified thus far can be discovered using the advanced ET.gov search service hosted by IntelligenX.

関連項目

脚注

  1. ↑ 1.0 1.1 1.2 Chief Information Officer Council (2001) A Practical Guide to Federal Enterprise Architecture. Feb 2001.
  2. ↑ 2.00 2.01 2.02 2.03 2.04 2.05 2.06 2.07 2.08 2.09 2.10 2.11 2.12 2.13 FEA Consolidated Reference Model Document. at whitehouse.gov May 2005. This document is revised to FEA Consolidated Reference Model Document Version 2.3 October 2007. Accessed 28 April 2009.
  3. ↑ 3.0 3.1 3.2 3.3 3.4 3.5 Federal Enterprise Architecture Program Management Office (2007). FEA Practice Guidance.
  4. ↑ Overall the FEA is mandated by a series of federal laws and mandates. These federal laws have been:
    • GPRA 1993 : Government Performance and Reform Act：政府の性能とリフォーム法
    • PRA 1995 : Paperwork Reduction Act ：ペーパー縮減法
    • CCA 1996 : Clinger-Cohen Act：Clinger-Cohen法
    • GPEA 1998 : The Government Paper work Elimination Act：政府のペーパー削減法
    • FISMA 2002 : Federal Information Security Management Act：連邦情報セキュリティ管理法
    • E-Gov 2002 : Electronic Government：電子政府
    OMBサーキュラーの補完には:
    • A-11 : Preparation, Submission and Execution of the Budget：予算の準備、申請、及び執行
    • A-130 : OMB Circular A-130 Management of Federal Information Resources：連邦情報資源のマネージメント
    • A-76 : Performance of Commercial Activities：商用活動の性能.
  5. ↑ 5.0 5.1 FEA (2005) FEA Records Management Profile, Version 1.0. December 15, 2005.
  6. ↑ [1]
  7. ↑ Envision VIP

外部リンク

en:Federal enterprise architecture



「http:///http:///mymemo.xyz/mymemo.xyz/wiki/index.php?title=連邦エンタープライズアーキテクチャ&oldid=130117」から取得