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

エンタープライズアーキテクチャ（、略称:EA) とは、組織全体の目的を達成するために、ビジネス戦略とITシステムを全体最適の視点から統合的に設計・管理するためのガイド、およびその実践手法であるGiachetti, R.E., Design of Enterprise Systems, Theory, Architecture, and Methods, CRC Press, Boca Raton, FL, 2010.MIT Center for Information Systems Research, Peter Weill, Director, as presented at the Sixth e-Business Conference, Barcelona Spain, 27 March 2007 。

EAは、組織のビジネス目標、業務プロセス、データ資産、アプリケーション、および基盤技術の現状（As-Is）を可視化し、目指すべき将来像（To-Be）を定義する。その上で、現状から将来像へ向かうための移行計画や、設計のガイドラインを提供する。これにより、組織は複雑化するビジネス環境や技術の進化に対して、一貫性を持って適応することが可能になる。

エンタープライズのスコープエンタープライズという用語は、単一の企業や法人に限定されず、共通の目標を持つ組織のまとまりを広く指す。具体的には以下の状況に適用可能である。公共機関（政府・自治体）及び民間組織企業内の事業部門又は法人全体大きな企業の (事業単位のような) 一部ジョイント・ベンチャーやパートナ企業のような、複数組織をまたぐ組織集合体アウトソーシングを含むサプライチェーン全体

また、エンタープライズは単なるシステムの集合体ではなく以下の要素が相互に作用する複合的なシステムとして捉えられる。人情報技術

EAを策定する際は、対象とするエンタープライズの境界（どこからどこまでを最適化の対象とするか）を明確に定義することが最初の重要なステップとなる。よって、エンタープライズが、組織によって違う意味を持つ場合があることに注意すべきであるhttp://enterprisearchitecture.nih.gov/About/What/。

EAの目的 EAを導入する第一の目的は、組織の有効性（ビジネス価値の創出）と効率性（コストや無駄の削減）を継続的に向上させることである。現代のデジタルトランスフォーメーション（DX）の文脈においては、単なるITの統制を超えて、以下の点が特に重視されている。

戦略とITの整合性: 経営戦略に基づいてIT投資の優先順位を決定し、部署ごとの場当たり的なシステム構築によるサイロ化を防ぐ。変化へのアジリティ: 組織構造やIT基盤を疎結合（組み替えやすい状態）に保ち、市場環境の変化や新技術の導入に迅速に対応する。段階的な移行計画の策定: TOGAFなどの代表的なフレームワークが示すように、現状から理想の将来像への道筋を、実行可能な移行アーキテクチャとして描き、安全かつ確実な変革を支援する。

EAの4大ドメインとセキュリティアーキテクチャエンタープライズアーキテクチャは、複雑な組織の構造を分かりやすく可視化し、管理可能にするために、一般的に4大ドメインに分割される。この「ビジネス、データ、アプリケーション、テクノロジー（BDAT）」という4層構造自体は古くから存在するが、現代のデジタル環境においては、各ドメインを構成する要素が変化している。

2026年4月に示されたTOGAF 10におけるEAにおける標準的な4大ドメインの定義と、その主要な構成要素は以下の通りである。

ビジネスアーキテクチャ（BA）ビジネス戦略をITや日々の業務プロセスへと翻訳するための青写真であり、すべてのアーキテクチャの起点となる最重要ドメインである。「組織が何を達成したいのか」「そのためにどのような能力が必要か」を定義するため、現代ではビジネス・ケイパビリティやバリューストリーム、カスタマージャーニーといった要素を扱う。業界標準のビジネス参照モデル（BRM）などを参考にしながら、これらを以下のようなものを作成し可視化する。

ビジネス・ケイパビリティ: 組織が何を実行できるかというビジネス上の能力を構造化したもの。特定の部門やシステムに依存しない普遍的な能力を定義する。バリューストリーム: 顧客に価値を提供するまでのエンドツーエンドの活動の流れ。カスタマージャーニー: 顧客体験（UX）の視点から、組織との接点やプロセスをモデル化したもの。組織モデルとビジネスプロセス: アジャイルな組織構造や、BPMN等で記述された柔軟な業務プロセス。

データアーキテクチャ（DA）組織の最重要資産である「データ」をどのように収集、統合、保護、および活用するかを定義する。かつてのデータベース設計やマスターデータ管理（MDM）に加え、現代ではデータプラットフォーム（データレイク/メッシュ）やAI・機械学習のためのデータパイプラインが中心となる。データの標準的な分類体系（DRM：データ参照モデル）に基づいて、以下のような成果物を作成し可視化する。

データ・カタログ: データ定義表。組織内の全データの所在、意味、所有者を定義した網羅的なリスト。概念・論理データモデル:ER図/UML等、データ間の関連性や構造を示す図。データ・リネージ: システム間をデータがどのように流れていくかを示す最新のフロー図。

アプリケーションアーキテクチャ（AA）ビジネス・ケイパビリティを実現し、データを処理するためのソフトウェア群の構造と連携手法を定義する。モノリシックアーキテクチャから、分散型アーキテクチャやAPIを通じたSaaSの統合へとシフトしているのが現代の主流である。共通化できるサービスや機能コンポーネントのひな型（SRM：サービスコンポーネント参照モデル）を活用し、以下のような成果物を作成し可視化する。

アプリケーション・ポートフォリオ: 組織が保有する全システムのリストと、それぞれの投資対効果などの評価状況。 APIエコノミーの連携図: 内部システムや外部のSaaS、パートナー企業との間を標準化されたAPI（REST、GraphQL等）で疎結合に連携する仕組み。情報システム関連図ともいう。アプリケーション・サービス・マップ: どのシステムがどの業務を支援しているかを示す対応表。

テクノロジーアーキテクチャ（TA）アプリケーションとデータを稼働させるための、論理的および物理的なITインフラストラクチャを定義する。かつての自社データセンターやハードウェアを中心とした概念から、パブリッククラウド（IaaS/PaaS）やコンテナ、コードによるインフラ管理（IaC）へと完全にシフトしている。組織内で標準として採用すべき技術要素の分類表（TRM：テクノロジー参照モデル）を基準に、以下のような成果物を作成し可視化する。

クラウドプラットフォーム: パブリッククラウド（AWS、Azure、Google Cloud等）を活用したIaaS/PaaS基盤、ハイブリッド/マルチクラウド構成、およびそれらを構成するネットワーク。ハードウェア構成図ともいう。コンテナとオーケストレーション: アプリケーションの実行環境をポータブルにするDockerや、それを自動管理するKubernetesなどの基盤技術。 Infrastructure as Code (IaC): インフラの構築・設定をコード化し、自動化とバージョン管理を可能にする手法。

その他（セキュリティアーキテクチャ）現代のEAにおいて、セキュリティはテクノロジーアーキテクチャの単なる一部ではなく、すべてのドメインを横断して組み込まれるべき必須の要素とされている。セキュリティ・バイ・デザインが推奨されている。

ゼロトラスト・アーキテクチャ: 「社内ネットワークは安全である」という境界型防御を捨て、すべてのアクセスを検証する現代のセキュリティモデル。アイデンティティとIAMアクセス管理: 認証・権限管理の基盤。

経緯 1987年、ジョン・ザックマンは、『情報システム・アーキテクチャのフレームワーク』を発表。EAの概念の基礎を築いた。体系的なオントロジーに基づき、EAを「What」「How」などの6つの疑問詞と、「経営者」「開発者」などの役割（視点）を掛け合わせたマトリクスで定義した。具体的な開発手順を示すものではないが、アーキテクチャの記述に漏れがないかを確認するための網羅的なチェックリストとして現在も機能している。

1992年にスティーブン・スペワックは、EAPの概念を初めて提唱した。アーキテクチャを階層化し、下層の「ビジネス・モデリング」を基盤として、その上にデータ、アプリケーション、テクノロジーを積み上げるウェディングケーキ・モデルを定義した。「データこそが最も安定した資産である」という思想のもと、数年単位で将来の計画を描くウォーターフォール・モデルのアプローチが特徴であったSpewak, Steven H. and Hill, Steven C. , Enterprise Architecture Planning - Developing a Blueprint for Data Applications and Technology,(1992), John Wiley。

その後、インターネットが普及し、巨大組織におけるシステムの肥大化が問題になると、IT投資の最適化や標準化を目的としたフレームワークが台頭した。

1999年9月、連邦CIO協議会は、連邦エンタープライズアーキテクチャフレームワーク（FEAF）を発表FEA Practice Guidance Federal Enterprise Architecture Program Management Office OMB, (2007), http://www.whitehouse.gov/omb/assets/fea_docs/FEA_Practice_Guidance_Nov_2007.pdf。米国連邦政府における情報技術取得のための共通の方法論を提供するため、行政管理予算局(OMB)で始められた。大規模な組織統合やITポートフォリオ管理のベストプラクティスとして、民間企業にも大きな影響を与えた。

2002年、The Open Group Architecture Framework (TOGAF)8が発表されたThe Open Group Architectural Framework (TOGAF) 8.1.1, (2009), https://web.archive.org/web/20080801041426/http://www.opengroup.org/architecture/togaf8-doc/arch/toc.html。ビジネスとITを統合的に設計する設計に進化している。アーキテクチャ開発手順（ADM）を提供し、準備段階から実装、変更管理までを段階的（フェーズA～H）にガイドする。と呼ばれる段階的なプロセスモデルを確立した。現状分析のプロセス（As-Is）を経て、目標像（To-Be）への移行プロセスを描き、中間ステップとして移行アーキテクチャ」を定義した。

2009年2月、TOGAF9が発表された。エンタープライズ・コンティニュアムやアーキテクチャ・ガバナンスなどが導入された。

2022年4月、TOGAF10が発表（日本語版は2026年4月に発表）。新たに、マイクロサービスアーキテクチャの採用、アジャイル開発、デジタルトランスフォーメーション（DX）、セキュリティ・バイ・デザインなどのテーマが導入された。

関連する専門領域とアーキテクチャの階層構造エンタープライズアーキテクチャ（EA）は単独で機能するものではなく、組織内のさまざまな専門領域や管理手法と密接に連携して効果を発揮する。EAは「IT部門だけのもの」と誤解されがちだが、実際にはITガバナンスの枠を超え、ビジネス最適化というより幅広い文脈で捉えるべきであるDubai Customs declares greater business agility with enterprise architecture, (2009), http://www-01.ibm.com/software/success/cssdb.nsf/CS/CCLE-7R5UE8?OpenDocument&Site=default&cty=en_usCase Study enterprise architecture fuels growth at AGL Energy, (2009),http://www-01.ibm.com/software/success/cssdb.nsf/CS/CCLE-7RM2CK?OpenDocument&Site=default&cty=en_us。組織によっては、EAチームがITポートフォリオ管理やデータガバナンス、パフォーマンス管理の責任を担うこともある。

近年では、GartnerやForresterなどの主要なITリサーチ企業も、EAと「デザイン思考（Design Thinking）」や「UX（ユーザーエクスペリエンス）デザイン」といった顧客志向の実践手法との統合の重要性を強く提唱しているGartner Advocates Hybrid Thinking for Enterprise Architecture, (2010),http://cio.tekrati.com/research/10999/Leslie Owens, Forrester Blogs - Who Owns Information Architecture? All Of Us., (2010),http://blogs.forrester.com/information_management/2010/02/who-owns-information-architecture-all-of-us.html/。

EAを実際の組織変革やシステム開発に適用する際、すべてを同じ粒度で語ることはできない。上述の米国連邦政府のFEA（連邦エンタープライズアーキテクチャ）実践ガイダンスなどでも示されている通り、アーキテクチャは対象とするスコープと詳細度に応じて、次の3つの階層に分割して管理されるのが一般的である。

エンタープライズアーキテクチャ - スコープは組織・企業全体。組織の戦略的な成果の達成を目標とする。組織全体の方向性を定め、共通のビジネス目標や全社的なIT投資の最適化に焦点を当てる。セグメントアーキテクチャ - スコープは特定の事業部門。ビジネス上の成果の達成を目標とする。「人事」「財務」あるいは「特定の製品事業部」といった、特定のビジネスセグメントの業務プロセスやシステム構造を定義する。ソリューションアーキテクチャ - スコープは個別の業務やプロセス。特定の問題を解決するための具体的なシステム設計を指し、運用の成果（効率化など）の達成を目標とする。一般的に語られるソフトウェアアーキテクチャ、ネットワークアーキテクチャ、データベースアーキテクチャといった専門的な技術領域（規律）は、すべてこの「ソリューションアーキテクチャ」を構成する部分的な要素として位置づけられる。

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

Źródło i licencja