連邦エンタープライズアーキテクチャ
 連邦エンタープライズアーキテクチャ（れんぽうエンタープライズアーキテクチャ、Federal Enterprise Architecture、FEA）はアメリカ合衆国連邦政府のエンタープライズアーキテクチャフレームワークである。それは、連邦政府における情報技術の取得、利用、および廃止のための共通の方法論を提供する[2]。 エンタープライズアーキテクチャ(EA)はビジネス性能を改善し、そして行政機関が彼らの中核事業をより良く実行することを助ける、資源の調整のためのマネジメントの実践である。EAは、機関の現在および将来の状態を記述し、現在状態から望ましい将来状態へ移行する計画をレイアウトする。FEAはこれらの目標を達成させる過程で働く[3]。 米国FEAはClinger-Cohen法に準じて米国連邦政府における情報技術取得のための共通の方法論を提供するため、行政管理予算局(OMB)で始められた。それは、連邦機関を横断し、コストを縮減し、そして市民サービスを向上させる、情報と資源の容易に共有するため設計された [4]。 歴史1999年9月に、連邦CIO協議会は、複数の機関間相互の境界を跨るシステムのため、連邦機関内のEAを開発するための『連邦エンタープライズアーキテクチャフレームワーク』（FEAF）バージョン1.1を発表した。それは、とりわけ、共通の事業実践の上で、組織的境界を越えて、NIST事業体仕組モデルを構築した。FEAFは高い優先領域の仕組記述を開発し、文書化するための永久的な標準を提供する。それは、連邦政府の複数組織横断的の機能セグメントのための仕組を記述するガイドラインを提供する[1]。 これらの連邦アーキテクチャセグメントは一括してFEAを構成する。2001年に、連邦エンタープライズワーキング・グループ（FAWG）は、連邦アーキテクチャセグメントを利用しかつ供与するためのEA製品の開発を後援した。規定された方法で特定の問題にアプローチする方法。図に示されるように、FEAFは与えられたアーキテクチャを、EA、データアーキテクチャ、アプリケーションアーキテクチャ、および技術アーキテクチャに分割する。創られたFEAFの全体的フレームワークは、Zachmanフレームワークの最初の3つのカラム、およびSteven Spewakのエンタープライズアーキテクチャプランニング方法論を含みます[1]。 参照モデル FEAは、IT資源を記述するための共通の分類体系と概念体系の開発を参照モデルの組合せを使って構築される。これらは以下を含む。
それは、連邦機関を横断して情報と資源を容易に共有し、コストを縮減し、市民サービスを改善するため設計される。それは、Clinger-Cohen法に準じ、米国OMBで始められた。 性能参照モデル 性能参照モデル(PRM)は主要なIT投資の性能と計画された性能へのそれらの貢献を測る標準のフレームワークである[2]。PRM は、次の3つの目的を持つ。
PRMは、バランスト・スコアカード、Baldrige Criteria、価値測定方法論、ロジックモデル、バリューチェーン、および制約理論を含む、性能測定への複数の既存のアプローチ使う。加えて、PRMは、PART評価、GPRA、エンタープライズアーキテクチャ、および資金計画と投資制御、を通して、どんな機関が現在測定されているかによって伝えられる。PRMは、4つの測定領域から構成される。
事業参照モデル FEAにおける事業参照モデル(BRM)は連邦政府の事業運営を、それらを実行する機関と独立に、記述するための機能駆動的なフレームワークである。このBRMは、機能駆動的アプローチを使う連邦政府の日々の事業運営を記述するため組織化され、階層的に構築される。BRMは、FEAの最初のレイヤーであり、それは、データ分析、サービス・コンポーネント、および技術の主要な視点である[2]。 BRMは以下の4つの領域に分けられる。
事業参照モデルは、それを実行する機関、部局、および事務所と独立なその内部の運営やその市民へのサービスを含む、連邦政府の事業ライン（LOB）の（組織的ではない）機能的ビューを促進する一つの枠組みを提供する。BRMは、ストーブパイプ的、あるいは機関ごとのビューに代えて、連邦政府を巡る共通の事業領域を記述ことによって、機関の協力とFEAや電子政府（e-Gov）戦略のための基盤としてのサービスを促進する[2]。 BRMは、政府の運営について考える改善された方法を提供する一方で、それは、その真の活用は、それが効果的に利用されたときのみ実現できる、単なる一つのモデルである。BRMによって推進される機能的アプローチは、もしそれが、EAビジネスアーキテクチャと連邦機関の全てとOMBのプロセス管理に取り入れられなければ、電子政府の目標達成にはほとんど助けにならないであろう[2]。 サービス参照モデル サービス／コンポーネント参照モデル（SRM）は、サービス／コンポーネントがどのように事業あるいは性能目的を支援するかに関するそれらを分類する事業と性能駆動の機能的フレームワークである[2]。SRMは、IT投資と資産における、政府ワイドな事業とアプリケーション・サービス／コンポーネントの発見を支援するのに使うことを意図します。SRMは、その事業機能と独立に、アプリケーション、アプリケーション能力、コンポーネント、あるいは事業サービスの再利用を支援する効果的基盤を提供できる、水平および垂直のサービス・ドメインを横断して構造化される。 SRMは、以下のドメインで確立される。
各サービス・ドメインは、サービス・タイプに分割される。例えば、顧客サービス・ドメインは次の3つのサービス・タイプに対応する。
そして各サービスタイプは、さらにコンポーネントに分割される。例えば、顧客の好みサービス・タイプ内に含む4つのコンポーネントは
となる[5]。 データ参照モデル データ参照モデル(DRM)は総合的レベルで、政府のプログラムと事業ラインの運営を支援するデータと情報を記述する。このモデルは、連邦政府と市民の間で起こる相互アクションと交換のタイプを記述することを機関に可能にする[2]。DRMは、詳細のレベルをより大きく分類する。それはまた、連邦データの分類を確立し、そして重複したデータ資源を識別する。一つの共通データモデルは、連邦政府内、および政府と外部の利害関係者間の情報交換を合理的にするであろう。 DRMのボリューム1は、構造、利用、およびデータ識別構築の高レベルな全貌を提供する。それは下記を解説する。
DRMのデータ構造は、モデリング標準と概念を開発すべきであることから出発点である。DRMの結合されたボリュームは、縦横のデータ分類と情報共有を支援する。 技術参照モデル 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:
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] 
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:
"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. 脚注
関連項目
外部リンク |
Portal di Ensiklopedia Dunia
