Loading article…
連邦エンタープライズアーキテクチャフレームワーク（FEAF ）は、連邦政府の米国参照エンタープライズアーキテクチャです。これは、組織設計とパフォーマンス改善の一環として、戦略、ビジネス、およびテクノロジー管理を統合するための共通のアプローチを提供します。[ 1 ]
最もよく知られている連邦政府のエンタープライズアーキテクチャは、米国連邦政府のエンタープライズアーキテクチャ、すなわち米国の「連邦エンタープライズアーキテクチャ」（FEA）およびそれに対応する米国の「連邦エンタープライズアーキテクチャフレームワーク」（FEAF）です。本稿では、この特定のエンタープライズアーキテクチャとエンタープライズアーキテクチャフレームワークに焦点を当てます。
エンタープライズアーキテクチャ（EA）は、ビジネスとテクノロジーのリソースを整合させて戦略的な成果を達成し、組織のパフォーマンスを向上させ、連邦政府機関が中核的な使命をより良く遂行できるようにするための経営上のベストプラクティスです。EAは、機関の現状と将来の状態を記述し、現状から望ましい将来の状態への移行計画を示します。連邦政府のエンタープライズアーキテクチャは、これらの目標を達成するための進行中の作業です。[ 2 ]
米国連邦政府エンタープライズアーキテクチャ（FEA）は、米国行政管理予算局（OMB）の電子政府・IT局が主導するイニシアチブであり、米国連邦政府におけるエンタープライズアーキテクチャの価値を実現することを目的としています。エンタープライズアーキテクチャは、1996年のクリンガー・コーエン法の成立により、米国連邦政府において戦略的かつ経営上のベストプラクティスとして広く認知されるようになりました。
米国連邦政府内でエンタープライズアーキテクチャを導入・活用することで得られるメリットは数多くあります。その一つは、米国連邦政府におけるIT調達の共通アプローチを提供することです。また、連邦政府機関間での情報やリソースの共有を容易にし、コストを削減し、市民サービスを向上させることも目的としています。
1999 年 9 月、連邦 CIO 協議会は、複数の機関の境界を越えるシステムのために、連邦機関内でエンタープライズ アーキテクチャ(EA) を開発するための「連邦エンタープライズ アーキテクチャ フレームワーク」(FEAF) バージョン 1.1 を公開しました。これは、NIST エンタープライズ アーキテクチャ モデルなど、組織の境界を越える一般的なビジネス プラクティスと設計に基づいています。FEAF は、優先度の高い領域のアーキテクチャ記述を開発および文書化するための永続的な標準を提供します。連邦政府の複数の組織機能セグメントのアーキテクチャを記述するためのガイダンスを提供します。[ 3 ]リリース当時、政府の IT は Y2K 問題と 2001 年 9 月の出来事に集中していたため、EA の実装から注意が逸れましたが、その前後での実践により、これらの出来事の影響が緩和された可能性があります。大統領の管理アジェンダの一環として、2001 年 8 月に、電子政府タスク フォース プロジェクトが開始されました (非公式にはプロジェクト クイックシルバーと呼ばれています)。その戦略における重要な発見は、相当な重複と冗長な機関システムが、ブッシュ政権の「市民中心」の政府を実現する能力を制約していたということだった。タスクフォースは、連邦エンタープライズアーキテクチャプロジェクトの創設と、OMBにFEAオフィスを創設することを勧告した。これは、FEAFの情報工学への焦点から、パフォーマンス結果を事業部門、プロセスサービスコンポーネント、データタイプ、およびテクノロジーコンポーネントにリンクする分類体系を含む参照モデルを使用したJ2EEオブジェクト再利用アプローチへの転換だった。それ以降の中間リリースでは、コア参照モデルの定義が段階的に強化され（下記参照）、連邦セグメントアーキテクチャ方法論（FSAM）とその次世代代替である協調計画方法論（CPM）を構成する一連のテンプレートで実際にアーキテクチャを開発するための非常に堅牢な方法論が提供された。CPMは、より柔軟で、より広く適用可能で、より広範な計画分野を包含するように設計されている。
これらの連邦アーキテクチャセグメントは、まとめて連邦エンタープライズアーキテクチャを構成します。2001 年、連邦アーキテクチャ作業部会 (FAWG) は、貿易および補助金連邦アーキテクチャセグメント向けのエンタープライズアーキテクチャ製品の開発を後援していました。方法 - 特定の問題への対処法として規定された方法。図に示すように、FEAF は、特定のアーキテクチャをビジネス、データ、アプリケーション、およびテクノロジーアーキテクチャに分割します。当時作成された FEAF の全体フレームワーク (画像を参照) には、ザックマンフレームワークの最初の 3 つの列とスペワクのエンタープライズアーキテクチャ計画方法論が含まれています。[ 3 ]
2012 年 5 月、OMB は「連邦政府エンタープライズ アーキテクチャへの共通アプローチ」という新しいガイドを全面的に公開しました。[ 4 ] 連邦政府の CIO の政策ガイダンスおよび IT サービス提供への共通アプローチを増やすための管理ツールの一部として公開されたこのガイドは、連邦政府におけるエンタープライズ アーキテクチャの開発と使用に関する全体的なアプローチを示しています。共通アプローチは、連邦政府機関内および機関間でのアーキテクチャの開発と使用を標準化することにより、ミッションの有効性のレベルを高めることを促進します。これには、EA を使用して機関が無駄や重複を排除し、共有サービスを増やし、パフォーマンスのギャップを解消し、政府、業界、市民間の関与を促進するための原則が含まれます。
2013年1月29日、ホワイトハウスは連邦政府エンタープライズアーキテクチャフレームワーク（FEAF-II）のバージョン2を政府機関に公開し、約1年後に一般公開した。[ 5 ]この文書は共通アプローチで定められた基準を満たしており、戦略目標がビジネスサービスを推進し、それが実現技術の要件を提供するということを強調している。その中核となるのは統合参照モデル（CRM）であり、OMBと連邦政府機関に投資を記述および分析するための共通の言語とフレームワークを提供する。
連邦エンタープライズアーキテクチャ（FEA）は、一連の連邦法および指令によって規定されています。これらの連邦法は以下のとおりです。
補足的なOMB通達は以下のとおりです。
共同計画手法 (CPM) は、リーダー、利害関係者、計画担当者、実装担当者との協力のもとで形成される推奨事項につながる、統合された多分野分析からなるシンプルで反復可能なプロセスです。これは、連邦政府エンタープライズアーキテクチャの共通アプローチで定義されているすべてのレベル (国際、国家、連邦、セクター、機関、セグメント、システム、アプリケーション) で使用するための、完全な計画および実装ライフサイクルとして意図されています。[ 4 ] [ 5 ]
連邦エンタープライズアーキテクチャフレームワーク（FEAF）の統合参照モデルは、OMB（行政管理予算局）および連邦政府機関に対し、投資を記述・分析するための共通言語とフレームワークを提供します。これは、機関横断的な分析を促進し、重複投資、ギャップ、および機関内外における連携機会を特定するために設計された、相互に関連する一連の参照モデルで構成されています。これらの参照モデルは、連邦政府機関の業務における重要な要素を共通かつ一貫した方法で記述するためのフレームワークを構成します。FEAFとその用語を用いることで、連邦政府全体でITポートフォリオをより適切に管理・活用し、連携を強化し、最終的には連邦政府の変革を実現することができます。
バージョン1（下記参照）の5つの参照モデルは、FEAF-IIでは再編成され、6つに拡張されました。
FEAは、 ITリソースを記述するための共通の分類体系を構築する様々な参照モデルを使用して構築されています。FEAバージョン1の参照モデル（画像参照）には、以下のものが含まれていました。
これは、連邦政府機関間での情報やリソースの共有を容易にし、コストを削減し、市民サービスを向上させることを目的としています。米国行政管理予算局（OMB）のイニシアチブであり、クリンガー・コーエン法を遵守することを目的としています。
PRMは、主要なIT投資のパフォーマンスとプログラムパフォーマンスへの貢献度を測定するための標準化されたフレームワークです。[ 1 ] PRMには主に3つの目的があります。
PRMは、バランススコアカード、バルドリッジ基準[ 6 ] 、価値測定方法論、プログラムロジックモデル、バリューチェーン、制約理論など、既存のパフォーマンス測定手法を多数活用しています。さらに、PRMは、PART評価、GPRA、エンタープライズアーキテクチャ、資本計画および投資管理を通じて各機関が現在測定している内容からも影響を受けています。PRMは現在、4つの測定領域で構成されています。
「FEAビジネス参照モデル」は、連邦政府の業務を、業務を実行する機関とは独立して記述するための機能主導型フレームワークです。このビジネス参照モデルは、機能主導型のアプローチを使用して、連邦政府の日常業務を記述するための組織化された階層構造を提供します。BRMは連邦エンタープライズアーキテクチャの最初のレイヤーであり、データ、サービスコンポーネント、およびテクノロジーの分析のための主要なビューポイントです。[ 1 ]
BRMは4つの領域に分けられます。
ビジネス参照モデルは、連邦政府の業務領域（LoB）を、組織的な視点ではなく機能的な視点から捉えることを容易にするフレームワークを提供します。これには、業務を遂行する機関、局、事務所とは独立した、内部業務や国民へのサービスが含まれます。BRMは、縦割り型の機関ごとの視点ではなく、共通の業務領域を中心に連邦政府を記述することで、機関間の連携を促進し、FEAおよびE-Gov戦略の基盤となります。[ 1 ]
BRMは政府業務に関する考え方を改善するものであるが、あくまでモデルに過ぎず、その真価は効果的に活用されて初めて発揮される。BRMが提唱する機能的なアプローチは、すべての連邦機関およびOMBのEAビジネスアーキテクチャと管理プロセスに組み込まれなければ、電子政府の目標達成にはほとんど役立たないだろう。[ 1 ]
サービスコンポーネント参照モデル（SRM）は、ビジネスおよびパフォーマンス主導の機能フレームワークであり、サービスコンポーネントがビジネスおよび/またはパフォーマンス目標をどのようにサポートするかに基づいて分類します。[ 1 ] SRMは、政府全体のIT投資および資産におけるビジネスおよびアプリケーションのサービスコンポーネントの発見をサポートするために使用することを目的としています。SRMは、水平および垂直のサービスドメインにわたって構成されており、ビジネス機能とは独立して、アプリケーション、アプリケーション機能、コンポーネント、およびビジネスサービスの再利用をサポートする活用可能な基盤を提供できます。
SRMは以下のドメインを確立する。
各サービスドメインはサービスタイプに分解されます。たとえば、カスタマーサービスドメインに関連付けられている 3 つのサービスタイプは、顧客設定、顧客関係管理、および顧客主導のサポートです。また、各サービスタイプはさらにコンポーネントに分解されます。たとえば、顧客設定サービスタイプの 4 つのコンポーネントには、パーソナライゼーション、サブスクリプション、アラートと通知、プロファイル管理が含まれます。[ 7 ]
データ参照モデル（DRM）は、政府のプログラムや事業部門の運営を支えるデータや情報を、集計レベルで記述します。このモデルにより、各機関は連邦政府と国民の間で行われる相互作用や情報交換の種類を記述することができます。[ 1 ] DRMは、政府情報をより詳細なレベルに分類します。また、連邦データの分類を確立し、重複するデータリソースを特定します。共通のデータモデルは、連邦政府内および政府と外部の利害関係者間の情報交換プロセスを効率化します。
DRMの第1巻では、構造、使用方法、およびデータ識別構成要素の概要を概説します。この文書は、
DRMは、データアーキテクトがモデリング標準と概念を開発する際の出発点となるものです。DRMの複数のボリュームを組み合わせることで、データ分類をサポートし、水平方向および垂直方向の情報共有が可能になります。
TRMは、サービスコンポーネントと機能の提供をサポートおよび可能にするための標準とテクノロジーを分類する、コンポーネント主導型の技術フレームワークです。また、政府全体の視点からテクノロジーとサービスコンポーネントの再利用と標準化を推進するための基盤を提供することで、既存の機関のTRMと電子政府ガイダンスを統合します。[ 1 ]
TRMは以下で構成されます。
右側の図は、TRMの概要を示したものである。
TRM に機関の設備投資を合わせることで、共通の標準化された語彙が活用され、機関間の発見、コラボレーション、相互運用性が可能になります。機関と連邦政府は、業務機能、ミッション、ターゲットアーキテクチャをサポートする最適なソリューションとテクノロジーを特定して再利用することで、規模の経済の恩恵を受けることができます。階層構造で整理された TRM は、コンポーネントベースまたはサービス指向アーキテクチャで使用および活用できるビジネスおよびアプリケーションサービスコンポーネントの安全な配信、交換、構築を包括的にサポートする標準とテクノロジーを分類します。[ 1 ]
FEAでは、エンタープライズアーキテクチャ、セグメントアーキテクチャ、ソリューションアーキテクチャは、詳細レベルを変え、関連するが異なる懸念事項に対処することで、異なるビジネス視点を提供します。企業自体が階層的に組織されているのと同様に、各タイプのアーキテクチャによって提供されるさまざまなビューも階層的に組織されています。連邦エンタープライズアーキテクチャ実践ガイダンス（2006）では、3種類のアーキテクチャが定義されています。[ 2 ]
定義上、エンタープライズアーキテクチャ（EA）は、戦略、ビジネスプロセス、投資、データ、システム、テクノロジーなど、共通または共有の資産を特定することに根本的に関心があります。EAは戦略によって推進され、組織のリソースが組織の使命と戦略目標に適切に整合しているかどうかを特定するのに役立ちます。投資の観点から、EAはIT投資ポートフォリオ全体に関する意思決定を推進するために使用されます。したがって、EAの主要な利害関係者は、組織が可能な限り効果的かつ効率的に使命を果たすことを保証する責任を負う上級管理者と幹部です。[ 2 ]
対照的に、「セグメントアーキテクチャ」は、中核となるミッション領域、ビジネスサービス、またはエンタープライズサービスのためのシンプルなロードマップを定義します。セグメントアーキテクチャはビジネス管理によって推進され、市民や機関職員へのサービス提供を改善する製品を提供します。投資の観点から見ると、セグメントアーキテクチャは、中核となるミッション領域または共通サービスもしくは共有サービスをサポートするビジネスケースまたはビジネスケース群に関する意思決定を推進します。セグメントアーキテクチャの主な利害関係者は、ビジネスオーナーとマネージャーです。セグメントアーキテクチャは、次の3つの原則を通じてEAと関連しています。
「ソリューションアーキテクチャ」とは、個々の機関の業務機能を自動化および改善するために使用されるアプリケーションやコンポーネントなどの機関のIT資産を定義するものです。ソリューションアーキテクチャの範囲は通常、単一のプロジェクトに限定され、システムまたはビジネスソリューションの全部または一部を実装するために使用されます。ソリューションアーキテクチャの主な利害関係者は、システムユーザーと開発者です。ソリューションアーキテクチャは、定義と制約を通じて、セグメントアーキテクチャおよびエンタープライズアーキテクチャと関連付けられることがよくあります。たとえば、セグメントアーキテクチャは、コアミッション領域またはサービス内で使用されるデータまたはサービスインターフェイスの定義を提供し、これらは個々のソリューションによってアクセスされます。同様に、ソリューションは、エンタープライズレベルで定義された特定のテクノロジーと標準に制約される場合があります。[ 2 ]
2011年の米国議会への公式報告書では、「ほとんどの省庁は、それぞれのエンタープライズアーキテクチャプログラムから将来的にメリットを得られると予想していると報告している。これは、連邦政府におけるエンタープライズアーキテクチャの開発と利用による真の価値が、依然としてほとんど実現されていないことを示唆している」と報告されている。[ 8 ]