
FDICエンタープライズアーキテクチャフレームワーク(FDIC EAF)は、連邦預金保険公社(FDIC)が業務プロセスと情報技術システムを整合させるために開発したエンタープライズアーキテクチャフレームワークです。2002年に導入され、2005年頃に正式に採用されたこのフレームワークは、ザックマンフレームワークと連邦エンタープライズアーキテクチャフレームワーク(FEAF)に基づいており、金融データとシステムを保護するためのセキュリティに重点を置いています。
2011年までに、このフレームワークは時代遅れとみなされ、連邦政府が標準化されたエンタープライズアーキテクチャの実践へと移行する一環として廃止された可能性が高い。例えば、2012年に導入された「連邦政府エンタープライズアーキテクチャへの共通アプローチ」は、相互運用性を強化し、機関固有のフレームワークを削減することを目的としていた。[ 2 ]
FDIC のエンタープライズ アーキテクチャを実装するためのフレームワークは、最高情報責任者 (CIO) 協議会の連邦エンタープライズ アーキテクチャ フレームワーク(FEAF) やZachman のエンタープライズ アーキテクチャ フレームワークなど、連邦政府および業界のベスト プラクティスに基づいています。FDIC のフレームワークはセキュリティを重視するように調整されています。従来の FDIC EA フレームワークは FEAF に準拠しており、アーキテクチャの他のすべてのコンポーネントに対するセキュリティの重要性を強調しています。[ 3 ]
FDIC EA フレームワークは 5 つのコンポーネントで構成されていました。最初のコンポーネントであるビジネス アーキテクチャは、FDIC のビジネス ニーズに焦点を当てていました。次の 3 つのコンポーネントであるデータ アーキテクチャ、アプリケーション アーキテクチャ、およびテクニカル インフラストラクチャ アーキテクチャは、ビジネスおよび情報ニーズをサポートする技術的機能に焦点を当てていました。最後のコンポーネントであるセキュリティ アーキテクチャは、企業全体に及ぶ、FDIC にとって関心のある特定の側面に焦点を当てており、他のすべてのアーキテクチャの不可欠な部分である必要があります。[ 3 ]
歴史的に、連邦政府機関はIT投資を独自に管理していました。新千年紀までは、各機関が連携してIT投資を効果的に再利用したり、IT知識を共有したり、共同ソリューションを模索したりするインセンティブはほとんどありませんでした。1990年後半から、連邦CIO協議会の支援を受け、連邦エンタープライズアーキテクチャ(FEA)を活用した政府全体の共同の取り組みが開始され、IT投資の管理と再利用を大幅に改善するとともに、市民へのサービスを向上させ、内部および外部のビジネス関係を促進することを目指しました。[ 4 ]
連邦預金保険公社(FDIC)がエンタープライズアーキテクチャの価値を初めて認識したのは1997年のことで、当時2人の経営幹部が銀行業界向けの重要な報告書のために、異なるシステムから得られたデータを照合する必要があった。FDICの最初のEAブループリントは2002年12月に公開された。[ 5 ]
2004年、FDICは、企業データを共同で管理する取り組みに対して、ザックマン・フレームワーク推進研究所(ZIFA)から2004年エンタープライズ・アーキテクチャ優秀賞を受賞しました。 [ 6 ]
2005年のFDIC EAフレームワークは5つの構成要素から成っていた。

2008年の銀行ビジネスモデルはより複雑化し、リスク管理のために担保付債務証券(CDO)やストラクチャード投資ビークル(SIV)などの金融商品が登場した。これらの商品は、国内金融市場と国際金融市場間の依存関係を強めた。そのため、当時の金融機関は、規制、法律、銀行家の懸念事項の間でバランスを取りながら、リスクを適切に管理する必要があった。[ 7 ]
概念的には、簡素化されたIT環境とより効率的なプロセスによってコスト削減が実現されるにつれて、その削減分はIT改善のために再投資されるか、企業に蓄積される。この自己資金調達モデルは右図に示されている。[ 7 ]
テクノロジーロードマップでは、IT環境の標準化とITの効率性および有効性の向上に向けた5年間の主要な取り組みが概説されました。これらの取り組みは、ビジネス側のITロードマップ、経営幹部の計画会議、クライアントの計画セッション、クライアントの年末レビューなど、さまざまな情報源に基づいて決定されました。特定された3つの主要な取り組みは、エンタープライズアーキテクチャ、セキュリティおよびプライバシープログラム、および財務規律でした。[ 7 ]

エンタープライズアーキテクチャの取り組みは、ミッションクリティカルなアプリケーションの安定した経済的なパフォーマンスを確保するために環境を簡素化することに重点を置いていました。コスト削減のための環境の簡素化には、アプリケーションシステムの数を減らし、アプリケーションをメインフレームから移行するなどの活動が含まれていました。また、大規模なデータセットを操作する機能や、従来の紙ベースのファイルを電子的に保存する機能を拡張することによっても効率化が図られることが期待されていました。SOAサービスセンターは、すべての開発チームが発見して使用できるコード(またはサービス)を管理することを目的としており、アプリケーションの開発、テスト、および展開における時間とコストの削減が期待されていました。[ 7 ]
組織は、機密データに対する管理を強化することで、新たなリスクや変化するリスクに対処するため、ITセキュリティとプライバシープログラムを継続的に強化する計画を立てた。場合によっては、送信メールをスキャンして機密情報を検出したり、リムーバブルストレージデバイスを暗号化したりするなどの技術によって、潜在的なリスクを軽減できる。リスク軽減のもう1つの要は、従業員に新たなセキュリティとプライバシーの問題について教育することだった。[ 7 ]
最後に、健全な財政規律と責任を維持するために、組織はITのベースラインと指標を確立し、定常状態のコストを調査し、サービスレベル契約を管理し、新しい開発プロジェクトをより慎重に選択することを計画しました。これら3つの領域(エンタープライズアーキテクチャ、セキュリティとプライバシープログラム、財政規律)は、推定時間枠とともに以下に示されています。[ 7 ]