ここでは、以下の観点で、エンタープライズアーキテクチャ（EA）について解説します。
- エンタープライズアーキテクチャ（EA）とは
- エンタープライズアーキテクチャ（EA）の重要性
- エンタープライズアーキテクチャ（EA）の構成
- エンタープライズアーキテクチャ（EA）設計の考え方
- EAベース開発の実践的アプローチ
- エンタープライズアーキテクチャ（EA）に関する書籍
- エンタープライズアーキテクチャ（EA）資料のダウンロード
なお、EAをベースにしたビジネスマネジメントについては【実践！DX】実践的ビジネスマネジメントを参照してください。
エンタープライズアーキテクチャ（EA）とは
エンタープライズアーキテクチャ（Enterprise Architecture）を一言でいうと、企業の業務とシステムの設計図です。
Enterprise Architectureのことを略してEAといいます。
アーキテクチャ（Architecture）とは、設計思想、および、それに基づいた基本構造を表します。
なので、EAは企業の設計思想、および、基本構造になります。
EAは、以下の４つの階層から構成されます。
- ビジネスアーキテクチャ（Business Architecture）
ビジネスの設計思想、および、基本構造を表します。
略してBAといいます。 - データアーキテクチャ（Data Architecture）
データの設計思想、および、基本構造を表します。
略してDAといいます。 - アプリケーションアーキテクチャ（Application Architecture)
アプリケーションの設計思想、および、基本構造を表します。
略してAAといいます。 - テクノロジーアーキテクチャ（Technology Architecture）
IT基盤の設計思想、および、基本構造を表します。
略してTAといいます。
このEAですが、その目的は、企業の全体最適化です。
企業の全体最適化とは、
必要な資産や活動を、戦略的に重要な領域に集中させ、企業全体のムリ、ムダ、ムラを無くし、最も経営上の効果が上がる状態にする
ことです。
ちなみに、一般的に、ムリは、無駄な活動（それに関わるコスト）によって発生し、ムダは、無駄な資産（それに関わるコスト）によって発生します。
また、ムラは、例えば、ある時点や部門では在庫があるのに、別の時点や部門では在庫が不足しているなど、時点や部門の違いで資産の状態が異なることによって発生します。
それから、企業を戦略に合わせて全体最適化するためには、企業の業務とシステムが、戦略に合わせて柔軟に適応できる構造、変化に強い構造になっている必要があります。
さらに、業務とシステムがどのように変化しても、データ、アプリケーション、IT基盤の信頼性と安全性を担保する必要があります。
- 企業の業務とシステムを変化に強い構造にすること
- システムの信頼性と安全性を担保すること
はEAの重要な課題です。
EAを設計することで、システムの構成要素のうち、比較的変化しにくいデータと、変化しやすい処理を分離し、データを企業全体で一元管理することで、データの信頼性と安全性を確保するとともに、データの再利用性や保守性を上げ、企業を変化に強い構造にすることができます。
なお、企業全体のデータは、データ基盤によって管理されます。
また、EAによって、アプリケーションをコンポーネント化し、アプリケーション基盤によってアプリケーション全体を管理することで、アプリケーションの信頼性と安全性を確保するとともに、アプリケーション開発の保守性と生産性を上げ、変化に強い構造にすることができます。
さらに、企業全体のIT基盤を設計・構築することで、データとIT基盤の信頼性と安全性を確保することができます。
つまり、EAを設計し、構築するとは、企業全体のデータ基盤、アプリケーション基盤、IT基盤を構築するということです。
さて、企業の全体最適化を図るときには、資産や活動を集中すべき業務やシステムがわかっていなければなりません。
戦略的に重要な業務とシステムを明確にするための有効な方法が戦略マップです。
戦略マップとEAを組み合わせることで、企業全体の業務とシステムを最適化することができます。
エンタープライズアーキテクチャ（EA）の重要性
変化が激しく、不透明で先行きが予測できない昨今の経営環境をVUCA（ブーカ）という言葉で表すことがあります。
VUCAとは
- Volatility（変動性）
- Uncertainty（不確実性）
- Complexity（複雑性）
- Ambiguity（不透明性）
の頭文字をとった造語です。
例えば、コロナ禍ですが、何の前触れもなく突然訪れましたよね。
このように、いつ何が起こるかわからない時代、企業が環境の変化に柔軟に適応できる、つまり、変化に強い構造になっていることが大変重要になります。
しかし、多くの企業が、
- 大規模で複雑なシステムがサイロのように独立して乱立している
- 重複して整合していないデータが散在している
- 個々の業務やシステムがわかる人はいるが（属人化）、全体を理解できる人や資料がない
という状況にあります。
これは、
- ビジネスの変化が加速している
- ビジネスとITが密接化している
ことを受けて、全体の設計図もなく、必要に応じて、ビジネスやシステムを作ってきたからです。
このような現状を打開して、EAを設計し、それに基づいて企業を変革する必要があるのです。
ここで、変化に強い構造とは、企業がどうなっていることか、具体的に定義しておきましょう。
ここでは、変化に強い構造を次のように定義します。
- 生産性が高い仕組になっていること
ビジネスやシステムを構成する要素が再利用可能な部品になっていること。 - 保守性が高い仕組みになっていること
ビジネスやシステムを構成する要素同士が疎結合することにより変更による影響を最小にする仕組みになっていること。
これは、DX（デジタルトランスフォーメーション）によって会社が目指すべき姿と一致しています。
実は、EAはDXを進める上での設計図（青写真）でもあるのです。
以上を踏まえた上で、EAの設計をどう進めるのか見ていきましょう。
【DXに関する記事】
エンタープライズアーキテクチャ（EA）設計の構成
次の図は、EAの構成を表しています。
ザックマンフレームワークでも言及しますが、EAの構成要素は、概念レベル、論理レベル、物理レベルとレイヤ構造を分けて整理します。
レイヤ構造については、MDAを参照してください。
エンタープラズアーキテクチャの体系図は次のようになります。
ビジネスアーキテクチャ
- 事業構造
まず、企業の事業ドメインの構造を分析します。
事業ドメインごとに顧客と製品が違います。
次の図は、４つの事業ドメインから構成され不動産開発事業者の例です。
- 活動領域
次に、自社の活動領域はどの範囲なのか分析します。
その際、事業ドメインごとの主要活動、事業共通の事業支援活動、企業共通の企業支援活動を分析します。
主要活動、支援活動については、バリューチェンを参照ください。
次の図は、不動産開発事業者の活動領域の分析例です。
- 場所
営業場所、物流場所、生産場所など企業の場所のタイプを明確にします。 - 財務資産
設備など、事業にとって重要な財務資産があれば、それを明確にします。 - ジョブ
次の活動領域とジョブの関係を考え、現在のジョブを洗い出します。
洗い出したジョブは、次の表のようなジョブ一覧にまとめます。
- ビジネスプロセス
次の活動領域とビジネスプロセスの関係を考え、現在のビジネスプロセスを洗い出します。
洗い出したビジネスプロセスは、次の表のようなビジネスプロセス一覧にまとめます。
- 業務フロー
ジョブを活動主体にして、ビジネスプロセスごとに業務フローを作成します。
業務フローには、ビジネスプロセスの本質的な流れを示すアクティビティフローと、それを構成するアクティビティをさらに詳細化したアクションフローがありますが、まず、アクティビティフローを作成し、必要に応じて、アクションフローを作成します。
なお、業務フローは、次のようにUMLのアクティビティ図で描くこともできます。
データアーキテクチャ
データアーキテクチャのうちデータ基盤、マスターデータ、概念データモデルは必須です。
- データ基盤
まず、情報資本ポートフォリオのデータ基盤を設計します。 - マスターデータ
次に、データ基盤のマスター共有ハブで管理するマスターデータのデータモデルを設計します。
- トランザクションデータ
次に、ビジネスプロセスのアクティビティごとに、活動の事実として記録すべきトランザクションデータを洗い出します。
洗い出したトランザクションデータは、次の表のようなトランザクションデータ一覧にまとめます。
- データフロー
次に、ビジネスプロセスのアクティビティと、マスターデータおよびトランザクションデータのマトリクスを作り、マスターデータおよびトランザクションデータがどの活動で、生成、参照、更新、削除されるか明確にします。
アクティビティとデータのライフサイクル（生成、参照、更新、削除）の関係を分析することで、アクティビティとデータの網羅性を検証することができます。
次の図は、データフローのフォーマット例です。
- 概念データモデル
最後に、マスターデータと、トランザクションデータを考慮して、ビジネスプロセス別の概念データモデルを設計します。
概念データモデルは、システム開発の際、アプリケーション単位のドメインモデル、論理データモデルのインプットになります。
アプリケーションアーキテクチャ
アプリケーションアーキテクチャのうちアプリケーションとアプリケーション基盤は必須です。
- アプリケーションシステム
IT基盤（後述）の上で動作する応用ソフトウェアのことです。略してアプリケーションともいいます。
アプリケーションシステムもMDAの３階層で分けることができ、概念レベル、論理レベル、物理レベルのアプリケーションシステムを、それぞれ、アプリケーションタイプ、アプリケーションカテゴリー、アプリケーションコンポーネントと呼びます。
アプリケーションシステムは、次のように分類することができます。- SoR（System of Records）
従来型のトランザクション処理を中心にしたミッションクリティカルな基幹システム群。 - SoE（System of Engagement）
顧客との関係強化を目的に最新のインターネット技術を駆使したシステム群。
米国のマーケティングコンサルタント、ジェフリー・ムーアが2011年に提唱した概念。 - SoI（System of Insight）
AIや機械学習の技術を利用して、SoEから得たデータを分析して顧客の欲求や行動心理を洞察するためのシステム群。
まず、情報資本ポートフォリオのアプリケーションの部分を参考にして、企業全体のアプリケーションタイプ（概念レベルのアプリケーション）の構成を設計します。
また、アプリケーションタイプに対応するアプリケーションカテゴリー（論理レベルのアプリケーション）、アプリケーションカテゴリーに対応するアプリケーションコンポーネント（物理レベルのアプリケーション）を明確にします。
洗い出したアプリケーションは、次の表のようなアプリケーションタイプ一覧にまとめます。
なお、書籍「戦略マップ」では、アプリケーションを、トランザクション処理アプリケーション、分析アプリケーション、変革アプリケーションに分類しています。
詳細は、戦略マップのアプリケーション分類を参照してください。 - SoR（System of Records）
- アプリケーション基盤
次に、アプリケーションタイプ間の連携方式である、情報資本ポートフォリオのアプリケーション基盤を設計します。 - コミュニケーション基盤
最後に、情報資本ポートフォリオのコミュニケーション基盤を設計します。
テクノロジーアーキテクチャ
- IT基盤
まず、情報資本ポートフォリオのコミュニケーション基盤を設計します。
次のように具体的なIT基盤をIT基盤一覧としてまとめます。
クラウドコンピューティングを活用している場合、具体的なサービスの情報を明確にします。
- アプリケーション・IT基盤マトリクス
次に、アプリケーションタイプとIT基盤のマトリクスを作成し、どのアプリケーションは、何のIT基盤を使用しているか明確にします。
アプリケーション・IT基盤マトリクスは、ビジネスインパクト分析で活用します。
次の図は、アプリケーション・IT基盤マトリクスのフォーマット例です。
エンタープライズアーキテクチャ（EA）設計の進め方（理論）
EAの設計は以下のようなアプローチで進めます。
- まず、企業全体の業務とシステムがどうなっているか整理して見える化する
- その上で、企業のアーキテクチャ（EA）を設計して全体最適化を図る
企業全体の業務とシステムの可視化
まず、企業全体の業務とシステムがどうなっているか整理して見える化します。
企業全体の業務とシステムがどうなっているか整理するためには、何らかの思考の枠組み（フレームワーク）が必要です。
企業全体の業務とシステムを整理するための代表的なフレームワークに、IBMのコンサルタントだったジョン・A・ザックマンが考えた、ザックマンフレームワークがあります。
ザックマンフレームワークは、縦軸に企業階層、横軸に５W1Hをとり、その６×６のマトリックスで会社の業務とシステムを整理するものです。
※縦軸の６階層目は製品を表し、設計と直接関係ないので上図では省略しています。
縦軸からいうと、
- 最上位が、経営者の観点で全体構造を表します。
- 上から２階層目は、管理者の観点で個別構造を表します。
- 上から３階層目は、分析者の観点で論理的構造を表します。
- 上から４階層目は、設計者の観点で物理的構造を表します。
最下層は、実装者の観点で実装構造を表します。
このうち縦軸の上２階層が業務の観点、下３階層がシステムの観点です。
システムの観点の３階層目の論理的構造と、４階層目の物理的構造の違いは、物理基盤に依存するかしないかの違いです。
物理基盤に依存しないのが論理的構造で、物理基盤に依存するのが物理的構造です。
レイヤ構造については、MDAの考え方を参照ください。
次に横軸ですが、
- 一番右が、なぜ（Why）の視点で、目的を表します。
- その隣が、いつ（When）の視点で、計画を表します。
- その隣が、誰が（Who）の視点で、組織を表します。
- その隣が、どこで（Where）の視点で、拠点を表します。
- その隣が、どのように（How）の視点で、活動を表します。
- 一番左が、何を（What）の視点で、資産を表します。
このザックマンフレームワークですが、EA（基本構造）の論理基盤になり、
- 上２階層（業務の観点）が、ビジネスアーキテクチャ
- 「資産」の列が、データアーキテクチャ
- 「活動」の列がアプリケーションアーキテクチャ
- 「拠点」の列がテクノロジーアーキテクチャ
に対応します。
「強いビジネスを創る」という記事で提示したビジネスストラクチャマトリクスの縦軸、ビジネスの構成要素が5W1Hに対応し、横軸、レイヤ構造が企業階層に対応しますが、ビジネスストラクチャマトリクスでは、ビジネスの構成要素の資産に情報資産として、データ、アプリケーション、ITを含めています。
なので、ビジネスストラクチャマトリクスでいうと、データの部分がデータアーキテクチャ、アプリケーションの部分がアプリケーションアーキテクチャ、ITの部分がテクノロジーアーキテクチャ、それ以外がビジネスアーキテクチャということになります。
一つ一つ、具体的に見ていきましょう。
ビジネスアーキテクチャ
まず、ビジネスアーキテクチャからです。
ここでは、経済産業省がガイドラインで示したビジネスアーキテクチャの定義について説明します。
ザックマンフレームワークのビジネスアーキテクチャを構成する各セルで表すものを書いたのが下図です。
これに従って、現行の業務を整理します。
このうち経営理念とビジョンが、ビジネスアーキテクチャの設計思想になり、それを実現するための基本構造を、事業ポートフォリオや、組織、拠点、活動、資産、戦略、計画という観点で設計します。
データアーキテクチャ
次に、データアーキテクチャです。
ここでは、経済産業省がガイドラインで示したデータアーキテクチャの定義について説明します。
ザックマンフレームワークのデータアーキテクチャを構成する各セルで表すものを書いたのが下図です。
これに従って、現行のデータを整理します。
各データモデルの定義は以下のようになります。
- 概念データモデル
ビジネスの仕組を実現するために必要なデータ（業務活動で発生する事実）の構造を明確にする。 - 論理データモデル
システムの機能要件やデータの品質要件（一意性・一貫性・参照整合性など）を満たすデータの構造を明確にする。 - 物理データモデル
システムの非機能要件（特に効率性）を満たし、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ベース開発の実践的アプローチのコンセプトは、
トップダウンであるべき姿を広く浅く積み上げていく
です。
まず、「トップダウンで」とは、MDAの３階層アーキテクチャでいうと、概念レベル→論理レベル→物理レベルという順でEAを設計し、構築するということです。
EAのBA、DA、AA、TAは、それぞれ３階層（概念レベル、論理レベル、物理レベル）から構成されます。
抽象度に従って、粒度も概念レベル、論理レベル、物理レベルの順で細かくなります。
なので、概念レベルから考えるということは、細かく具体的に考えるのではなく、抽象的に粗く考えるというアプローチになります。
次に、「あるべき姿を」とは、To-Beから考えるというアプローチです。
よくあるのは、現状（As-Is）の物理レベルの実装から、As-Isの論理レベルのモデルをリバースし、それを抽象化することであるべき（To-Be）概念レベルのモデルを導き出し、そこからあるべき論理レベルのモデル、物理レベルの実装を展開するというアプローチです。
これは、これは、現状（As-Is）の物理レベルを起点としたボトムアップアプローチです。
この方法のように、現状ある物理レベルを分析するほうが具体的なので、とっかかりやすいと思いますが、実際にボトムアップ・プローチで進めると、物理レベルの分析で疲弊してしまい断念してしまいます。
大切なのは、あるべき姿を実装することです。
なので、As-Isの物理レベルは極論必要ありません。
なので、ここでは、次の図のように、あるべき概念レベルのモデルを考え、As-Isの論理レベルのモデルを参照しながら、概念レベルのモデルをTo-Beの論理レベルのモデルに展開し、実装するというアプローチを適用します。
ここで、重要なのが物理レベルの実装は、「広く浅く積み上げていく」ということです。
EAベース開発の実践的アプローチでは、まず、IT基盤、データ基盤、アプリケーション基盤の土台だけ構築しておき、個別システムを開発する都度、土台に個別の実装を積み上げていきます。
具体的に見ていきましょう。
EAの設計
EAは次のような手順で設計します。
- 概念レベルの設計
概念レベルの設計は、マネジメントサイクルの戦略期間の設計フェーズで行います。 - 論理レベルの設計
論理レベルの設計は、マネジメントサイクルの戦略期間の戦略フェーズで行います。
事業領域・活動領域の確認
最初に、あるべき事業領域・活動領域を設計します。
次の図は、不動産開発事業者の事業領域・活動領域を設計した例です。
新しい事業領域を創出しない限り、事業領域・活動領域は変わりません。
重要なのは、事業固有の主要活動と、事業共通の支援活動を明確にすることです。
なお、次の図のように、実際に価値を創出し提供する主要活動を、文化を創る活動、価値を創る活動、価値を伝える活動、価値を届ける活動のバリューチェンとして表します。
ジョブの洗い出し
次に活動領域ごとに企業全体のジョブを洗い出します。
洗い出したジョブは、次の表のようなジョブ一覧にまとめます。
ビジネスプロセスの洗い出し
次に、活動領域ごとのビジネスプロセスを洗い出します。
洗い出したビジネスプロセスは、次の表のようなビジネスプロセス一覧にまとめます。
アプリケーションタイプ（概念レベルのアプリケーション）の洗い出し
次に、ジョブに対応したトランザクション処理アプリケーションのアプリケーションタイプを洗い出します。
洗い出したアプリケーションタイプは、次の表のようなアプリケーション一覧にまとめます。
なお、アプリケーションタイプ（アプリケーションの型）については、ビジネスストラクチャマトリクスを参照してください。
アプリケーション基盤（概念レベル）の設計
あるべきアプリケーション基盤を概念レベルで設計します。
ここでは、アプリケーションの統合方式を決めます。
データ基盤の設計（概念レベル）
次に、企業全体で一元管理するデータのデータ基盤を設計します。
概念レベルでデータ基盤の構成を図式化します。
概念マスターデータモデルの設計
次に、データ基盤のマスター共有ハブで管理するマスターデータのデータモデルを設計します。
概念マスターデータモデルについては、データアーキテクチャを参照してください。
事業概念データモデルの設計
上記バリューチェーンを構成する活動からトランザクションデータを洗い出し、マスターデータモデルのマスターデータと組み合わせて事業ごとの概念データモデルを設計します。
事業概念データモデルについては、データアーキテクチャを参照してください。
IT基盤の設計（概念レベル）
事業成長モデルの設計
ここで、特定の事業領域の事業戦略の本質を明らかにし、どこに資産や活動を集中させるべきか明確にします。
そのために、まず、事業成長モデルを設計し、事業の成長ドライバーとなる資産、価値の源泉を明確にします。
その際、ビジネスプロセス一覧から、価値を創るビジネスプロセス、価値を届けるビジネスプロセス、価値を伝えるビジネスプロセス、文化を創るビジネスプロセスを選定します。
戦略の策定
事業成長モデルによって明らかになった顧客価値、製品価値、価値を創るビジネスプロセス、価値を届けるビジネスプロセス、価値を伝えるビジネスプロセス、文化を創るビジネスプロセスを参考にして、戦略マップを策定します。
戦略マップを策定することで、IT戦略を事業戦略に方向づけることができ、
- 顧客に価値を提供し収益上げるためのビジネスプロセスと、その業務課題は何で、それを実現するためにどのようなシステムの機能や品質が求められるか、どのようなデータが必要か、
- 業務の生産性を上げるためのビジネスプロセスと、その業務課題は何で、それを実現するためにどのようなシステムの機能や品質が求められるか、どのようなデータが必要か
明確にすることができます。
また、戦略マップによって、資産と活動を集中すべき、重要なビジネスプロセス、アプリケーション、データが明確になります。
重要なビジネスプロセスは、上記で洗い出されたビジネスプロセスから、重要なアプリケーションは、上記で洗い出されたアプリケーションタイプから、重要なデータは上記事業概念データモデルから、それぞれ選択します。
アクティビティフローの設計
次に、戦略マップで明確になった、戦略的に重要なビジネスプロセスの活動の流れを、アクティビティフロー（概要業務フロー）として明確にします。
業務概念データモデルの設計
最後に、マスターデータモデルのマスターデータと、事業概念データモデルのトランザクションデータ、および、アクティビティフローのアクティビティを考慮して、ビジネスプロセス別の業務概念データモデルを設計します。
業務概念データモデルは、データアーキテクチャの活動領域単位の概念データモデルになります。
業務概念データモデルは、システム開発の際、アプリケーション単位のドメインモデル、論理データモデルのインプットになります。
業務概念データモデルについては、データアーキテクチャを参照してください。
アプリケーションカテゴリ（論理レベルのアプリケーション）の洗い出し
次に、上記アプリケーション（概念レベル）に対する現行のアプリケーション（論理レベル）を対応付けし、アプリケーション一覧にまとめます。
アプリケーション（論理レベル）は、☓☓システムのように、各会社で固有名詞で呼ばれているアプリケーションシステムの単位です。
アプリケーションシステム、および、そこで管理されているデータが重複している場合、アプリケーション（概念レベル）に対する論理レベルのアプリケーションが複数になります。
論理マスターデータモデルの設計
論理マスターデータモデルを設計します。
論理マスターデータモデルについては、データアーキテクチャを参照してください。
事業論理データモデルの設計
事業論理データモデルを設計します。
事業論理データモデルについては、データアーキテクチャを参照してください。
業務論理データモデルの設計
業務論理データモデルを設計します。
業務論理データモデルについては、データアーキテクチャを参照してください。
アプリケーションカテゴリの設計
次に、アプリケーション（論理レベル）の重複や不足を調整した、あるべきアプリケーション（論理レベル）を設計し、アプリケーション一覧にまとめます。
その際、戦略マップを参照して、アプリケーションに対する非機能要件を定義します。
アプリケーション基盤（論理レベル）設計
次に、あるべきアプリケーション基盤を論理レベルで設計します。
データ基盤（論理レベル）の設計
データフローの設計
どのタイミングで、どのシステムの何のデータがどのように移動するのか、データフローを設計します。
IT基盤（論理レベル）の設計
次に、アプリケーション（論理レベル）の非機能要件に従って、あるべきIT基盤（論理レベル）を設計します。
IT基盤（論理レベル）の設計するときは、アプリケーションタイプとIT基盤のマトリクスを作成し、どのアプリケーションは、何のIT基盤を使用しているか明確にします。
アプリケーション・IT基盤マトリクスは、ビジネスインパクト分析で活用します。
ビジネスインパクト分析では、どのIT基盤に障害が発生すると、どのアプリケーション、どのビジネスプロセスに影響が出るか分析します。
次の図は、アプリケーション・IT基盤マトリクスのフォーマット例です。
アプリケーション・IT基盤マトリクスの設計
次に、アプリケーション（論理レベル）の非機能要件に従って、アプリケーションタイプとIT基盤のマトリクスを作成し、どのアプリケーションは、何のIT基盤を使用しているか明確にします。
アプリケーション・IT基盤マトリクスは、ビジネスインパクト分析で活用します。
次の図は、アプリケーション・IT基盤マトリクスのフォーマット例です。
アクションフローの設計
次に、重要なアクティビティに対するアクションフロー（詳細業務フロー）を作成します。
その際、どのアクションを、どのアプリケーション（論理レベル）で実現するか明確にします。
EAの構築
EAの構築は、事業ライフサイクルの戦略期間の構築フェーズで行います。
EAは次のような手順で構築します。
IT基盤の構築
企業全体のIT基盤（物理レベル）を構築します。
データ基盤の構築
データの統合
次の図のように散在しているデータをETLによって統合します。
アプリケーション基盤の構築
EAの展開
次の手順で、EAを個別システムに展開します。
ユースケースモデルの設計
まず、アプリケーション（論理レベル）で実現する、アクションフローのアクションを、アプリケーション（論理レベル）のユースケースとして抽出し、ユースケースモデルを設計します。
次に、現行アプリケーション（論理レベル）のユースケースを洗い出し、上記あるべきユースケースモデルとのギャップを確認し、それにどう対応するか決定します。
アプリケーション開発の機能要件になります。
ドメインモデルの設計
業務概念データモデルから、アプリケーション（論理レベル）に関係する範囲を選択し、それをインプットとしてドメインモデルを設計します。
その際、ビジネスメタデータを参照して、データ要件を明確にします。
論理データモデルの設計
まず、ドメインモデルをインプットとしてあるべき論理データモデルを設計します。
その際、テクニカルメタデータを参照して、データ要件を明確にします。
次に、現行アプリケーション（論理レベル）の論理データモデルを作成し、上記あるべき論理データモデルとのギャップを確認し、それにどう対応するか決定します。
IT基盤の検証
IT基盤がアプリケーションの品質要件を満たすか検証します。
アプリケーション基盤の検証
アプリケーションが外部のアプリケーションと連携する場合、外部設計のとき、アプリケーション基盤を適用できるか検証します。
アプリケーションの開発
アプリケーションを開発します。
アプリケーション開発については、「UPで学ぶシステム開発」
を参照ください。
EAの検証
次の手順でEAを検証します。
アクティビティフローの検証
構築されたEAによってアクティビティフローが問題なく実行できるかビジネスプロセスのKPIに基づいて検証します。
戦略の検証
構築されたEAによって戦略が実行できるかBSCに基づいて検証します。
エンタープライズアーキテクチャ（EA）に関する書籍
エンタープライズアーキテクチャ（EA）について初めて触れる人にお勧めなのが「かんたんEA」です。
図が多く、わかりやすく、EA全体を網羅することができます。
かんたん!エンタープライズ・アーキテクチャ―UMLによる「業務と情報システムの最適化計画」の立案 (ビジネス図解シリーズ)
エンタープライズアーキテクチャ（EA）資料のダウンロード
EAに関する概念を整理した用語集を以下よりダウンロードすることができます。
EA用語集
以上、今回は、エンタープライズアーキテクチャ（EA）について解説しました。
[…] エンタープライズアーキテクチャ（EA）とはという記事で、テクノロジーアーキテクチャ（Technology Architecture）とは、IT基盤の設計思想、および、基本構造を表すと書きました。 エンタ […]
[…] 企業全体の業務とシステムの設計図をエンタープライズアーキテクチャ（EA）といいます。 EAは４階層で構成されており、その中の一つにテクノロジーアーキテクチャ（TA）があります。 […]
[…] エンタープライズアーキテクチャ（EA）を構成する一要素で、ビジネスの設計思想、および、基本構造を表します。 ビジネスアーキテクチャ（以下、BA）を設計する目的は、ビジネスの […]
[…] エンタープライズアーキテクチャ（EA）を構成する一要素で、データの設計思想、および、基本構造を表します。 データマネジメント知識体系（DMBOK）によると、データアーキテクチャ […]
[…] エンタープライズアーキテクチャの設計。 DXによって会社がどこへ向かうのか、企業の戦略とアーキテクチャ（基本構造）を設計します。 エンタープライズアーキテクチャ（以下、EA） […]
[…] エンタープライズアーキテクチャの設計については、エンタープライズアーキテクチャとはを参照ください。 […]
[…] エンタープライズアーキテクチャ（EA）を構成する一要素で、企業のデータの基本的な構造や振舞を表すものです。 データマネジメント知識体系（DMBOK）には、データアーキテクチャの […]
[…] ビジネスアーキテクチャは、エンタープライズアーキテクチャの一要素になります。 ビジネスアーキテクチャは、データアーキテクチャとアプリケーションアーキテクチャの設計思想 […]
[…] ここでは、企業全体、エンタープライズアーキテクチャ（EA）の観点でドメインモデルの位置付けを考えます。 ドメイン駆動設計（DDD）の「戦略的設計」で重要な概念は次の３つです。 […]
[…] 。 企業基盤には、論理基盤と物理基盤がありますが、 まず、論理基盤であるエンタープライズアーキテクチャを設計し、 それに基づいて物理基盤である、IT基盤、アプリケーション基盤 […]
[…] 事業概念データモデルモデルの設計 […]
[…] ネジメントは、エンタープライズアーキテクチャ（EA）のテクノロジー […]