エンタープライズアーキテクチャ（EA）とは【わかりやすく解説】

ここでは、以下の観点で、エンタープライズアーキテクチャ（EA）について解説します。

• エンタープライズアーキテクチャ（EA）とは
• エンタープライズアーキテクチャ（EA）の重要性
• エンタープライズアーキテクチャ（EA）設計の進め方
• エンタープライズアーキテクチャ（EA）に関する書籍

エンタープライズアーキテクチャ（EA）とは

エンタープライズアーキテクチャ（Enterprise Architecture）を一言でいうと、企業の業務とシステムの設計図です。
Enterprise Architectureのことを略してEAといいます。
アーキテクチャ（Architecture）とは、設計思想、および、それに基づいた基本構造を表します。
なので、EAは企業の設計思想、および、基本構造になります。
EAは、以下の４つの階層から構成されます。

• ビジネスアーキテクチャ（Business Architecture）
  ビジネスの設計思想、および、基本構造を表します。
  略してBAといいます。
• データアーキテクチャ（Data Architecture）
  データの設計思想、および、基本構造を表します。
  略してDAといいます。
• アプリケーションアーキテクチャ（Application Architecture)
  アプリケーションの設計思想、および、基本構造を表します。
  略してAAといいます。
• テクノロジーアーキテクチャ（Technology Architecture）
  IT基盤の設計思想、および、基本構造を表します。
  略してTAといいます。

このEAですが、その目的は、企業の全体最適化です。
企業の全体最適化とは、
必要な資産や活動を、戦略的に重要な領域に集中させ、企業全体のムリ、ムダ、ムラを無くし、最も経営上の効果が上がる状態にする
ことです。
経営戦略は、経営理念の具体的な姿であるビジョンを効率的に実現するための方向性を定めたものなので、EAの設計思想は、経営理念やビジョンになります。
それでは、EAは、なぜ重要なのでしょうか。

エンタープライズアーキテクチャ（EA）の重要性

変化が激しく、不透明で先行きが予測できない昨今の経営環境をVUCA（ブーカ）という言葉で表すことがあります。
VUCAとは

• Volatility（変動性）
• Uncertainty（不確実性）
• Complexity（複雑性）
• Ambiguity（不透明性）

の頭文字をとった造語です。
例えば、コロナ禍ですが、何の前触れもなく突然訪れましたよね。
このように、いつ何が起こるかわからない時代、企業が環境の変化に柔軟に適応できる、つまり、変化に強い構造になっていることが大変重要になります。
しかし、多くの企業が、

• 大規模で複雑なシステムがサイロのように独立して乱立している
• 重複して整合していないデータが散在している
• 個々の業務やシステムがわかる人はいるが（属人化）、全体を理解できる人や資料がない

という状況にあります。
これは、

• ビジネスの変化が加速している
• ビジネスとITが密接化している

ことを受けて、全体の設計図もなく、必要に応じて、ビジネスやシステムを作ってきたからです。
このような現状を打開して、企業を変化に強い構造に作り変えるにはどうすればよいでしょうか。
企業を変化に迅速に適応できる仕組にするためには、まず、企業全体のムリ、ムダ、ムラを無くしフットワークを軽くする必要があります。
そこで、EAを設計し、それに基づいて企業を変革する必要があるのです。

ここで、変化に強い構造とは、企業がどうなっていることか、具体的に定義しておきましょう。
ここでは、変化に強い構造を次のように定義します。

• 生産性が高い仕組になっていること
  ビジネスやシステムを構成する要素が再利用可能な部品になっていること。
• 保守性が高い仕組みになっていること
  ビジネスやシステムを構成する要素同士が疎結合することにより変更による影響を最小にする仕組みになっていること。

これは、DX（デジタルトランスフォーメーション）によって会社が目指すべき姿と一致しています。
実は、EAはDXを進める上での設計図でもあるのです。

• BAは、DXによって会社が目指すべき姿のビジネスプラットフォーム、および、個々のビジネスの設計図
• AAは、DXによって会社が目指すべき姿のアプリケーション基盤の設計図
• DAは、DXによって会社が目指すべき姿のデータ基盤の設計図
• TAは、DXによって会社が目指すべき姿のIT基盤の設計図

です。

生産性が高い仕組にするためには、BA、DA、AA、TAを構成する要素が再利用可能な部品になっている必要があります。
また、保守性が高い仕組にするためには、BA、DA、AA、TAを構成する要素同士が疎結合することにより変更による影響を最小にする仕組みになっている必要があります。
以上を踏まえた上で、EAの設計をどう進めるのか見ていきましょう。

エンタープライズアーキテクチャ（EA）設計の進め方

EAの設計は以下のようなアプローチで進めます。

• まず、企業全体の業務とシステムがどうなっているか整理して見える化する
• その上で、企業のアーキテクチャ（EA）を設計して全体最適化を図る

企業全体の業務とシステムの可視化

まず、企業全体の業務とシステムがどうなっているか整理して見える化します。
企業全体の業務とシステムがどうなっているか整理するためには、何らかの思考の枠組み（フレームワーク）が必要です。

企業全体の業務とシステムを整理するための代表的なフレームワークに、IBMのコンサルタントだったジョン・A・ザックマンが考えた、ザックマンフレームワークがあります。

ザックマンフレームワークは、縦軸に企業階層、横軸に５W1Hをとり、その６×６のマトリックスで会社の業務とシステムを整理するものです。
※縦軸の６階層目は製品を表し、設計と直接関係ないので上図では省略しています。
縦軸からいうと、

• 最上位が、経営者の観点で全体構造を表します。
• 上から２階層目は、管理者の観点で個別構造を表します。
• 上から３階層目は、分析者の観点で論理的構造を表します。
• 上から４階層目は、設計者の観点で物理的構造を表します。

最下層は、実装者の観点で実装構造を表します。

このうち縦軸の上２階層が業務の観点、下３階層がシステムの観点です。
システムの観点の３階層目の論理的構造と、４階層目の物理的構造の違いは、物理基盤に依存するかしないかの違いです。
物理基盤に依存しないのが論理的構造で、物理基盤に依存するのが物理的構造です。
次に横軸ですが、

• 一番右が、なぜ（Why）の視点で、目的を表します。
• その隣が、いつ（When）の視点で、計画を表します。
• その隣が、誰が（Who）の視点で、組織を表します。
• その隣が、どこで（Where）の視点で、拠点を表します。
• その隣が、どのように（How）の視点で、活動を表します。
• 一番左が、何を（What）の視点で、資産を表します。

このザックマンフレームワークですが、EA（基本構造）の論理基盤になり、

• 上２階層（業務の観点）が、ビジネスアーキテクチャ
• 「資産」の列が、データアーキテクチャ
• 「活動」の列がアプリケーションアーキテクチャ
• 「拠点」の列がテクノロジーアーキテクチャ

に対応します。
一つ一つ、具体的に見ていきましょう。

ビジネスアーキテクチャ

まず、ビジネスアーキテクチャからです。
ザックマンフレームワークのビジネスアーキテクチャを構成する各セルで表すものを書いたのが下図です。

これに従って、現行の業務を整理します。
このうち経営理念とビジョンが、ビジネスアーキテクチャの設計思想になり、それを実現するための基本構造を、事業ポートフォリオや、組織、拠点、活動、資産、戦略、計画という観点で設計します。

データアーキテクチャ

次に、データアーキテクチャです。
ザックマンフレームワークのデータアーキテクチャを構成する各セルで表すものを書いたのが下図です。

これに従って、現行のデータを整理します。
各データモデルの定義は以下のようになります。

• 概念データモデル
  ビジネスの仕組を実現するために必要なデータ（業務活動で発生する事実）の構造を明確にする。
• 論理データモデル
  システムの機能要件やデータの品質要件（一意性・一貫性・参照整合性など）を満たすデータの構造を明確にする。
• 物理データモデル
  システムの非機能要件（特に効率性）を満たし、IT基盤（データベース製品など）に適応したデータの構造を明確にする。

DDLはデータ定義言語といい、リレーショナルデータベースを扱うSQL（構造化照会言語）の一種で、テーブルなどデータの定義を行う言語です。

アプリケーションアーキテクチャ

次に、アプリケーションアーキテクチャです。
ザックマンフレームワークのアプリケーションアーキテクチャを構成する各セルで表すものを書いたのが下図です。

これに従って、現行のアプリケーションを整理します。
アクションフローとは、細かいレベルの業務フローです。
ここでは、アプリケーションの論理的構造をアプリケーションシステム、物理的構造をアプリケーションコンポーネントと呼んでいます。

テクノロジーアーキテクチャ

最後に、テクノロジーアーキテクチャです。
ザックマンフレームワークのテクノロジーアーキテクチャを構成する各セルで表すものを書いたのが下図です。

これに従って、現行のIT基盤を整理します。
情報システム拠点とは、データセンターの場所など情報システムを管理する拠点を表します。
ここでは、IT基盤の論理的構造を情報システム構造、物理的構造をネットワーク構造と呼んでいます。

エンタープライズアーキテクチャ（EA）の設計

企業全体の業務とシステムが可視化されたら、BAの経営戦略に従って、あるべきEAを設計します。

ビジネスアーキテクチャは、DX（デジタルトランスフォーメーション）によって会社が目指すべき姿のビジネスプラットフォームにも対応しています。

ビジネスプラットフォームの経営理念とビジョンが、ビジネスアーキテクチャの設計思想に対応し、それを実現するための基本構造として事業ドメインと事業ポートフォリオ、バリューチェーンとコアコンピタンス、人事システムと組織文化を設計します。
事業ポートフォリオによって、戦略的に重要な事業が明確になります。
事業ドメインのバリューチェーンによって、戦略的に重要な活動が明確になります。
コアコンピタンスを担うキーリソースによって、戦略的に重要な資産が明確になります。
そして、資産や活動を、戦略的に重要な領域に集中させ、企業全体のムリ、ムダ、ムラを無くし、最も経営上の効果が上がる業務とシステムの構造を設計するのです。
なお、ビジネスプラットフォームですが、ここでは、人事、会計、債権債務管理、購買、物流など全社で共通の業務が共通サービスとして部品化されており、それを利用して新しいビジネスが迅速に実現できるように設計されています。
それでは、各アーキテクチャを設計するときのポイントについて見ていきましょう。
なお、EAを設計する際、IT基盤、データ基盤、アプリケーション基盤、ビジネスプラットフォームが構築された状態を測るKGI（Key Goal Indicator：重要目標達成指標）と、その目標値を決めます。

ビジネスアーキテクチャ（BA）

まず、ビジネスプラットフォームのベースになる以下を明確にします。

• 経営理念
• 組織文化
• 人事システム
• 事業ドメイン
• コアコンピタンス
• ビジョン
• 事業ポートフォリオ

それから、企業の組織および役割と、戦略的に重要な領域のビジネスプロセスを設計します。
ビジネスプロセスには、購買や販売などの定型的なプロセスと、ビジネス課題を解決するための非定型的な仮説検証プロセスがあります。
仮説検証プロセスの一つとして、データを有効活用する
データサイエンス
があります。
次に、ビジネスプラットフォームの上で実行する各事業をビジネスモデルとして設計します。
ビジネスモデルは以下の観点で設計します。

• 順序関係
  バリュチェーン、および、バリューチェーンを実現するためのコアコンピタンスを定義にする。
  ※コアコンピタンスとは、他社が真似できない会社の中核的能力のことです。
• 相互関係
  コアコンピタンスを担う会社のキーリソース（人的資産、知的資産、財務資産、情報資産）と、それらの相互関係を設計する。
• 因果関係
  財務、顧客、活動（バリューチェーンを構成する活動）、資産（キーリソース）の観点で、経済合理性（なぜ儲かるのか）、競争優位性（なぜ勝てるのか）、持続可能性（なぜ続くのか）を因果関係として表す。

なお、ビジネスアーキテクチャのKGIですが、ビジネスプラットフォームの実現度合いを測る指標として設計されます。

• 社員の行動の動機となる価値観である経営理念があり、それが組織文化になっていること
• どの領域でビジネスを行うか、どの機能で差別化するかが事業ドメインやコアコンピタンスとして定義され共有されてること
• 会社が向かうべき先がビジョンや事業ポートフォリオとして全員に共有されていること
• ビジネスモデルの発見や検証の生産性を上げる思考法や表記法が社員に浸透していること
• 仮説検証サイクルを繰り返し新しいビジネスモデルを創出する仕組みになっていること
• 人事、会計、債権債務管理、購買、物流など全社で共通の業務が共通サービスとして部品化されており、それを利用して新しいビジネスが迅速に実現できるようになっていること

データアーキテクチャ（DA）

ビジネスモデルの相互関係を業務構造として表します。
業務構造から、会社として重要なデータを論理的なエンティティ（実体）として洗い出します。
エンティティの種類には

• リソース系エンティティ（マスターデータ）
• イベント系エンティティ（トランザクションデータ）

があります。
これらエンティティを構造化して、概念データモデル、論理データモデル、物理データモデルとして表します。
データアーキテクチャの設計思想は、データ品質の向上です。
なので、データアーキテクチャのKGIは、データ品質が高い状態の実現度合いを測る指標として設計されます。
データ品質の評価軸には以下のようなものがあります。

• 正確性
  データが現実の実体を正しく表している程度を表す。
• 完全性
  必要なデータが全て存在しているかどうか、その程度を表す。
• 一貫性
  データが、特定のデータベースなどデータセット内で一貫して（正しいルールに貫かれて）表現されているか、あるいは、データセット間で一貫して関連付けられ、一貫して表現されているか、その程度を表す。
  一貫性は、１レコード内にある属性値と別の属性値との間（レコードレベルの一貫性）、あるレコードの属性値と別のレコードの属性値の間（クロスレコードの一貫性）、あるレコードの属性値と異なる時点における同じレコードの属性値との間（経時的一貫性）において定義される。
• 一意性
  同じ実体を表すデータが同じデータセット内に複数存在していないか、その程度を表す。
  同じ実体を表すデータは一箇所で管理されることをOne Fact in One Place（一つの事実は一つの場所に）と言います。
• 適時性
  データが適切な時点のものであるか、その程度を表す。

データは、参照データ、マスターデータ、トランザクションデータに分類することができます。
これらデータ間や、AAで設計されるマイクロサービスとの間を、DAO（データアクセスオブジェクト）のようなAPI（アプリケーションプログラミングインターフェース）によって疎結合することによって、保守性を高めることができます。
また、DAOを再利用可能なデータ部品とすることで生産性を高めることができます。

データの分類の詳細についてはデータマネジメント知識体系（DMBOK）を参照してください。

アプリケーションアーキテクチャ（AA）

ビジネスプロセスを構成する活動をベースに、論理的な機能単位としてマイクロサービスを設計します。
また、Web会議システム、チャット、スケジューラー、ワークフロー、メールなど全社の共通アプリケーションの製品を定めます。
アプリケーションアーキテクチャの設計思想は、フロントエンドアプリケーション開発の生産性、保守性を向上させることです。
なので、アプリケーションアーキテクチャのKGIは、マイクロサービスがフロントエンドアプリケーション開発の生産性、保守性に寄与する度合いを測る指標として設計されます。
マイクロサービスとは、ビジネス機能を一つのサービスとして提供したソフトウェア部品のことです。
マイクロサービスはビジネスロジックやデータアクセスを実装し、UI（ユーザーインターフェス）まわりを扱うフロントエンドアプリケーションからAPIを介して使用されます。
なので、マイクロサービスの内部状態が変わっても、フロントエンドアプリケーションは影響を受けないという保守性の高い仕組にすることができます。
また、新規にアプリケーションを開発するときは、アプリケーション基盤にある既存のマイクロサービスを再利用することができるという生産性の高い仕組にすることができます。
マイクロサービスは、共通部品なので、同じ機能は一箇所に実装されている必要があります。
これをOne Act in One Place（一つの動作は一つの場所に）と言います。

テクノロジーアーキテクチャ（TA）

全社の共通IT基盤として、ハードウェア、ネットワーク、OS、ミドルウェア（アプリケーションサーバーやデータベースシステムなど）をテクノロジースタックとして設計します。
また、システムのマネジメントに関する技術や方法を標準化するために必要な資料（ガイドラインなど）も整備します。
テクノロジーアーキテクチャの設計思想は、それが支えるデータやアプリケーションのソフトウェア品質（信頼性や拡張性など）、および、マネジメント品質を担保することです。
なので、テクノロジーアーキテクチャのKGIは、IT基盤が、データやアプリケーションのソフトウェア品質（信頼性や拡張性など）やマネジメント品質に寄与する度合いを測る指標として設計されます。
また、DAOなどのアプリケーションからアクセスされるIT基盤、例えば、データベースマネジメントシステム（DBMS）などは、APIを介してアクセスされるため、アプリケーション開発の生産性や保守性を上げることができます。
なお、テクノロジーアーキテクチャの詳細について知りたい方は
テクノロジーアーキテクチャ（TA）とは
をご覧ください。

エンタープライズアーキテクチャ（EA）に関する書籍

エンタープライズアーキテクチャ（EA）について初めて触れる人にお勧めなのが「かんたんEA」です。
図が多く、わかりやすく、EA全体を網羅することができます。
かんたん!エンタープライズ・アーキテクチャ―UMLによる「業務と情報システムの最適化計画」の立案 (ビジネス図解シリーズ)

以上、今回は、エンタープライズアーキテクチャ（EA）について解説しました。