アプリケーションアーキテクチャ（AA）とは【わかりやすく解説】

ここでは、以下の観点で、アプリケーションアーキテクチャ（AA）について解説します。

アプリケーションアーキテクチャとは
DXとアプリケーションアーキテクチャ
アプリケーションアーキテクチャ設計の進め方

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

エンタープライズアーキテクチャ（EA）を構成する一要素で、アプリケーションの設計思想、および、基本構造を表します。
※ここでいうアプリケーションとはアプリケーションシステム、あるいは、アプリケーションソフトウェアを指します。
企業全体の業務とシステムを、縦軸に企業階層、横軸に５W1Hのマトリクスで整理するザックマンフレームワークで考えると、AAの領域は「活動（How）」の領域になります。

これを見ると、分析者の視点（論理構造）がアプリケーションシステム、設計者の視点（物理構造）がアプリケーションコンポーネントになっていることがわかります。
これらの違いを説明するために、MDA（Model-Driven Architecture：モデル駆動アーキテクチャ）について説明します。
MDAは、標準化団体であるOMG(Object Management Group)が「20年持続するソフトウェアアーキテクチャ」を目標として2001年に提唱した概念で、以下の３つのモデルから構成されています。

CIM（Computation Independent Model）
計算機処理に依存しないモデル。
PIM（Platform Independent Model）
IT基盤に依存しないモデル。
PSM（Platform Specific Model）
IT基盤に特化したモデル。

MDAでは、システムを構築するとき、この３つのモデルを分けて考えることで、より堅牢なシステムをつくることができるとしています。
この３つのモデルのうち、PSMはIT基盤に特化しているので、IT基盤が変更されると作り直す必要がありますが、PIMは、IT基盤に依存しないので、再利用することができます。
アプリケーションアーキテクチャでいうと、論理構造を表すプリケーションシステムがPIM、物理構造を表すアプリケーションコンポーネントがPSMという位置付けになります。
次に、AAの構成を、型（タイプ）と実例（インスタンス）×設計思想と基本構造という観点で整理すると以下のようになります。

AAの型の設計

まず、アプリケーションアーキテクチャの設計思想である「アプリケーション要求」を定義し、
それを実現するためのアプリケーション資産（稼ぐ力を持つアプリケーション）には何があるか明確にし、
そのアプリケーション資産を管理する活動を定義します。
次に、アプリケーション資産の構造を設計し、
アプリケーション資産を管理するプロセスを設計します。

AAの実例の設計

続いて、アプリケーション要求を具体的な「アプリケーション要件」として落とし込みます。
そして、アプリケーション要件を実現するためのアプリケーション戦略を策定し、
アプリケーション戦略を実行するためのアクションプランを定めます。

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

次に、DX（デジタルトランスフォーメーション）とAAの関係について説明します。
DX（デジタルトランスフォーメーション）とはという記事で、DXによって会社が目指すべき姿を、次の３階層から成る構造で説明しました。

ビジネス
ビジネスプラットフォーム
ITプラットフォーム

アプリケーションアーキテクチャは、下図のように、アプリケーション基盤の設計図になります。

アプリケーションアーキテクチャ設計の進め方

最後に、AA設計の進め方についてですが、次の８つのステップで実施します。

アプリケーション要求の設定
アプリケーション資産の明確化
アプリケーション管理活動の定義
アプリケーション資産の構造化
アプリケーション管理プロセスの設計
アプリケーション要件の定義
アプリケーション戦略の策定
アクションプランの策定

一つ一つ見ていきましょう。

アプリケーション要求の設定

まず、アプリケーション要求とは何か？考えてみましょう。
アプリケーションアーキテクチャは、エンタープライズアーキテクチャを構成する一要素です。
エンタープライズアーキテクチャの論理的な基盤はビジネスアーキテクチャなので、アプリケーションアーキテクチャもビジネスアーキテクチャによって規定されます。
※なお、エンタープライズアーキテクチャの物理的な基盤はテクノロジーアーキテクチャなので、アプリケーションアーキテクチャもテクノロジーアーキテクチャによって規定されます。

なので、アプリケーション資産を有効活用することで経営理念を実現することが、企業がアプリケーションに求める最終的な要求です。
しかし、アプリケーション資産を有効活用する前に、アプリケーション資産自体の品質を確保する必要があります。

ISO/IEC 9126では、以下のソフトウェア品質特性をあげています。

機能性（functionality）
目的から求められる必要な機能の実装の度合い。
信頼性(Reliability)
機能が正常動作し続ける度合い，障害の起こりにくさの度合い。
使用性（Usability）
分かりやすさ、使いやすさの度合い。
効率性(Efficiency)
目的達成のために使用する時間や資源の度合い。
保守性(Maintainability)
保守(改訂)作業に必要な労力の度合い。
移植性（Portability）
移植のしやすさ，別の環境へ移した際そのまま動作する度合い。

アプリケーション資産の明確化

次に、企業のアプリケーション資産（稼ぐ力を持つアプリケーション）には何があるか以下の手順で整理します。

企業全体のドメイン（問題領域）分析
企業全体のコンテキスト境界分析

さて、ここでは、ドメイン駆動設計（DDD）の考え方を使ってアプリケーション資産を明確にしたいと思います。
ドメイン駆動設計（DDD）では、問題解決の対象領域を広義のドメインといい、次のように分類しています。

問題領域
解決すべき問題が潜んでいる領域。
問題を分析して解決すべき問題を課題として設定します。
解決領域
システムを使って、どのように課題を解決するか、その解決方法（ソリューション）により構成された領域。
課題をどのように解決するか設計します。

このうち、問題領域を狭義のドメイン、解決領域をコンテキスト境界と呼んでいます。
詳細は、ドメイン駆動設計入門【DDDをわかりやすく解説】を参照してください。

企業全体のドメイン（問題領域）分析

まず、ビジネスアーキテクチャ（BA）の活動領域に基づいて、アプリケーションシステムのドメイン（問題領域）を定義します。

バリューチェーンとドメインの関係は以下のように考えることができます。

バリューチェーンの主要活動の中でシステムが関係する活動がコアドメイン
バリューチェーンの事業支援活動の中でシステムが関係する活動が支援ドメイン
バリューチェーンの企業支援活動の中でシステムが関係する活動が汎用ドメイン

企業全体のコンテキスト境界分析

次に、企業全体のドメイン（問題領域）をベースに、コンテキスト境界を設定します。
この例では、青い丸で囲んだ部分が一つのコンテキスト境界を表しています。

コンテキスト境界に対応する現行システムを明確にします。

アプリケーション管理活動の定義

続いて、アプリケーション資産を管理する活動を定義します。
アプリケーション資産を管理する活動には、
アプリケーション資産のライフサイクルを管理する活動と
それをマネジメントする活動
があります。
まず、アプリケーション資産のライフサイクル管理する活動ですが、活動領域でいうと情報管理活動の中の一つになります。

また、この活動は、通常、テクノロジーアーキテクチャ（TA）のマネジメントインフラとして定義されます。

テクノロジーアーキテクチャ（TA）のマネジメントインフラですが、以下のような要素があります。

システム開発マネジメント
システムを開発してリリースするまでのマネジメント標準。
ITサービスマネジメント
システムリリース後、システムがビジネスをどう支援するかに関するマネジメント標準。

システム開発の方法の一つにアジャイル開発がありますが、アジャイル開発のシステム開発マネジメントを、アジャイル開発マネジメントといいます。
次に、アプリケーション資産のライフサイクル管理をマネジメントする活動ですが、これは、アプリケーションのライフサイクルを管理する活動が、
正しくアプリケーションの品質を確保しているか
アプリケーション資産を有効活用できているか
管理する活動です。
アプリケーションは、コンテキスト境界ごとに分類することができるので、それぞれの境界ごとにアプリケーションのライフサイクルを管理する活動が発生します。

この例では、アプリケーション資産のライフサイクル管理をマネジメントする職務と、正しくマネジメントされているか監督する職務を分離することによってアプリケーションガバナンスが働く仕組みを表しています。
前者の職務をアプリケーション管理者、後者の職務をアプリケーションスチュワードと呼びます。
アプリケーションチュワードの代表的な活動は以下のようになります。

核となるアプリケーションデータの作成と管理
上述したようにアプリケーションの品質を確保するためにはアプリケーションデータがとても重要です。
アプリケーションチュワードは、各アプリケーションのアプリケーションデータを管理する役割を担います。
ルールと標準の文書化
アプリケーションチュワードは、アプリケーション管理ポリシー（アプリケーションガバナンスとして何をやるべきはを定める）、アプリケーション管理標準（アプリケーションガバナンスをどう進めるかを定める）、アプリケーション品質ルールなどを定義し、文書化します。
アプリケーション品質の問題管理
アプリケーションチュワードは、アプリケーション関連の問題の特定と解決に携わります。
アプリケーションガバナンス運営活動の実施
データスチュワードは、アプリケーション管理ポリシーやアプリケーション管理標準が守れアプリケーションガバナンスが働くようにする責任を負います。

EA全体の活動の中で見ると、アプリケーションスチュワードは、アプリケーション開発者だけでなく、アプリケーションで発生するデータを管理するデータ基盤を管理するデータスチュワードや、アプリケーションを支えるIT基盤を管理するIT基盤管理者とコミュニケーションを取り、EA全体が適切に設計、構築、運用できるようにする役割も担います。

アプリケーション資産の構造化

アプリケーション資産の構造化では、企業全体のコンテキスト境界の関係をコンテキストマップとして描きます。

ビジネスアーキテクチャ（BA）で考えるバリューチェーンの主要活動がアプリケーションアーキテクチャ「（AA)のコアドメイン、事業支援活動が支援ドメイン、企業支援活動が汎用ドメインに対応していることがわかります。
コンテキスト境界の名前ですが、システム名がわかるものは、システム名をコンテキスト境界名にします。
コンテキストマップは、ザックマンフレームワークでいうとアプリケーションシステム（論理的構造）に対応します。

※コンテキストマップについての詳細は、詳細は、ドメイン駆動設計（DDD）を参照ください。
それでは、アプリケーションシステム（論理的構造）はどのように設計するのでしょうか。
アプリケーションシステムは、ビジネスアーキテクチャ（BA）の業務構造をベースに考えることができます。
活動領域の販売活動で考えてみましょう。

販売活動の業務構造が次のようになっているとします。

販売活動の流れは次のようになっています。

顧客が販売担当者に注文を出すと、販売担当者は製品を引当する。
製品が引当できる場合、販売担当者は、物流担当者に製品の出荷依頼をする。
それを受けて、物流担当者は、製品倉庫から製品を出庫して顧客に配送する。
２で、製品が引当できない場合、販売担当者は、製造担当者に製品の製造依頼をする。
それを受けて、製造担当者は、製品を製造後、それを製品倉庫に入庫し、物流担当者に製品の出荷依頼をする。
それを受けて、物流担当者は、製品倉庫から製品を出庫して顧客に配送する。

この流れをみると、販売活動には、物流活動や生産活動が含まれていることがわかります。
販売活動の業務構造のうち、本来の販売活動の部分を示すと次のようになります。

販売活動の業務構造のうち、物流活動の部分を示すと次のようになります。

もちろん、これは、物流活動のうち、販売活動に関係する部分だけで、物流活動は、これ以外にもあります。
物流活動を活動領域の中で示すと次のようになります。

次に、販売活動の業務構造のうち、生産活動の部分を示すと以下のようになります。

もちろん、これは、生産活動のうち、販売活動に関係する部分だけで、生産活動は、これ以外にもあります。
生産活動を活動領域の中で示すと次のようになります。

ここで、ビジネスアーキテクチャ（BA）の活動領域をベースに、アプリケーションアーキテクチャ（AA）のアプリケーションの単位を定義しましょう。
活動領域の各領域は業務の機能のまとまりとして定義してあるので、これを個々のアプリケーションの単位とするのは適切だと考えます。

基本的に、活動領域の各領域に一つアプリケーションを割り当てます。
上の例では、「販売活動」に「販売管理システム」を割り当てています。
ただし、資産管理活動の場合、各資産のライフサイクルを管理する単位でアプリケーションを割り当てます。
上の例では、顧客のライフサイクルを管理する「顧客管理」という単位に、「顧客管理システム」を割り当てています。
それでは、販売管理システム、物流管理システム、生産管理システムを導入して、先の販売活動の業務構造を表してみましょう。
※UMLのクラス図で表記しています。

そうすると、販売管理システム、物流管理システム、生産管理システム間の連携がわかります。
クラスで表されてた各システムのメソッドが、システムのユースケースになります。
上の業務構造から物流管理システムの部分をピックアップして、ユースケース図を描くと次のようになります。

なお、このユースケースは、後述するヘキサゴナルアーキテクチャのアプリケーション部分（下図の物流管理サービスの部分）によって実現されます。

さて、上の業務構造のシステムの部分にコンテキスト境界を当てはめると、コンテキストマップの元ができあがります。
※システムの繋がりの部分だけにすればコンテキストマップになります。

このように、ビジネスアーキテクチャ（BA）の業務構造をベースにコンテキストマップを考えることができます。
同様にして、企業の全業務構造をベースに、企業全体のコンテキストマップ、つまり、アプリケーションシステム（論理構造）を設計することができます。

アプリケーション管理プロセスの設計

続いて、先ほど定義したアプリケーション管理活動の詳細を業務フローとして設計します。
業務フローについての詳細は、ビジネスアーキテクチャを参照してください。

ここまでが、AAの骨格になります。
ここから、その骨格を具体化していきます。

アプリケーション要件の定義

まず、アプリケーション要件を定義します。
アプリケーション要件とは、アプリケーション要求を具体的な要件として落とし込んだものです。
例えば、以下のような例が考えられます。

企業全体のアプリケーション資産の品質が統制されている
企業のアプリケーション資産が経済価値を生み企業のビジョン実現に貢献している

アプリケーション戦略の策定

ここでは、アプリケーション戦略を次の２つに分けて考えます。

全社アプリケーション戦略
事業アプリケーション戦略

全社アプリケーション戦略

全社アプリケーションは次の２つに分けることができます。

全社アプリケーション活用戦略
アプリケーション管理活動を集中させるべく戦略的に重要なアプリケーション資産は何か？全社レベルで明確にします。
全社アプリケーションマネジメント戦略
アプリケーション資産の品質を向上するための方向性を明確にします。

全社アプリケーション活用戦略

複数の事業を持っている企業の場合、各事業ごとにコアドメインのアプリケーションがあると思います。
そのような場合、ビジネスアーキテクチャ（BA）の事業ポートフォリオを参考に、アプリケーション資産に対する投資戦略を考えます。

事業ポートフォリオでは、占有率（シェア）×成長率で事業単位を以下の４つに分類します。

負け犬
占有率も成長率も低い事業単位。
問題児
占有率は低いが成長率は高い事業単位。
花形
占有率も成長率も高い事業単位。
金のなる木
占有率は高いが成長率は低い事業単位。

例えば、金のなる木から得られるキャッシュフローを問題児に投下して次の花形を作るという戦略が取られている場合、問題児の事業のアプリケーションに対する投資の優先順位を高くします。
事業のコアドメインのアプリケーションに対する投資の優先順位が決まれば、それに従って、支援ドメインや汎用ドメインのアプリケーションに対する投資の方向性を考えることができます。
例えば、特殊性×規模のマトリックスでアプリケーション資産のポートフォリオをつくり、それぞれどのように構築するか考えることができます。

コアドメインのアプリケーションは、その会社の事業戦略を写し取るものなので、スクラッチ開発で構築すると思います。
支援ドメインや汎用ドメインのアプリケーションをどのように構築するか、特殊性×規模のマトリックスを参考に考えることができます。
日本では、コアドメインのアプリケーションも業務パッケージをカスタマイズして構築する企業が多々あるようです。
これは、ITはビジネスモデルの重要な１要素であることを未だ認識できておらず、システムは金食い虫で、業務パッケージを導入すれば安くつくれるだろうという思考停止状態になっている現れだと思います。
このようなメンタルモデルが企業がDXできない根本的な問題なのではないでしょうか。

全社アプリケーションマネジメント戦略

ここでは、アプリケーション資産の品質、機能性、信頼性、使用性、効率性、保守性、移植性を上げるためのソフトウェアアーキテクチャやアプリケーション間連携について以下のような手順で考えます。

企業全体のソフトウェアアーキテクチャの設計
コンテキストマップに対するソフトウェアアーキテクチャの適用
アプリケーションアーキテクチャ（AA）とデータアーキテクチャ（DA)の連携
コンテキスト境界間の連携

最後のコンテキスト境界間の連携は、アプリケーションの統合戦略になります。
【企業全体のソフトウェアアーキテクチャの設計】
まず、各コンテキスト境界に適用するデフォルトのソフトウェアアーキテクチャを決めます。
ここでは、アプリケーション資産の品質を高めることを考えて、企業全体のソフトウェアアーキテクチャとして以下のアーキテクチャを適用します。

サービス指向アーキテクチャ（SOA）
ヘキサゴナルアーキテクチャ
コマンド・クエリ責務分離（CQRS）アーキテクチャ

サービス指向アーキテクチャ（SOA）
業務上の一処理に相当するソフトウェアの機能をサービスと見立て、そのサービスをネットワーク上で連携させてシステムの全体を構築していくアーキテクチャのことです。
ここでいうサービスとは、「決済する」「在庫状況を照会する」など一つ一つの業務処理を指します。
また、ビジネス機能に沿った複数の小さいサービスの疎に結合された集合体を、マイクロサービス（microservices）といいます。

ヘキサゴナルアーキテクチャ
ヘキサゴナルアーキテクチャは、ドメインモデルを中心に、どのようなクライアントがきてもアダプタを追加するだけで接続できるようにするというソフトウェアアーキテクチャです。
各マイクロサービスをヘキサゴナルアーキテクチャで構築することを考えます。

ヘキサゴナルアーキテクチャの詳細は、ドメイン駆動設計（DDD）を参照ください。
コマンド・クエリ責務分離（CQRS）アーキテクチャ
データストアに対する更新操作を集めたコマンド処理と、読み取り操作（クエリ）を集めたクエリ処理を完全に分離するアーキテクチャパターンです。

詳細は、コマンド・クエリ分離の原則（CQS）を参照ください。
【コンテキストマップに対するソフトウェアアーキテクチャの適用】
サービス指向アーキテクチャ（SOA）、および、ヘキサゴナルアーキテクチャをコンテキストマップに適用すると次のようなイメージになります。

一つ一つのコンテキスト境界が、ヘキサゴナルアーキテクチャに基づいたマイクロサービスで実現されていることがわかります。
各マイクロサービスは、JavaのJarファイルなど物理的な単位に割り当てることができます。
先ほど、活動領域に基づいてアプリケーションシステムを定義しました。

同じ考え方で、活動領域の各領域に一つマイクロサービスを割り当てることができます。

さて、このコンテキストマップですが、これは、ザックマンフレームワークでいうとアプリケーションコンポーネント（物理構造）になります。

【アプリケーションアーキテクチャ（AA）とデータアーキテクチャ（DA)の連携】
アプリケーションコンポーネント（物理構造）を設計するときは、データアーキテクチャ（DA)で設計した各種データを、各マイクロサービスでどのように管理するのか決める必要があります。

そこで、各マイクロサービス単位に、データアーキテクチャ（DA)で設計したデータを割り当てます。

【コンテキスト境界間の連携】

コンテキスト境界間の連携

次に、各コンテキスト境界間をどのように連携するか設計する必要があります。
実践ドメイン駆動設計 (Object Oriented SELECTION)では、代表的な各コンテキスト境界間の連携方式を次の３つあげています。

同期通信
連携相手と同期して通信する方式です。
連携相手との関係が強い場合、通常、同期通信で連携します。
- RPC方式
  コンテキスト境界AにてAPIを公開し、コンテキスト境界Bから呼び出す。
- RESTful方式
  コンテキスト境界AにてWebリソースを公開し、コンテキスト境界Bから呼び出す。
非同期通信
連携相手と同期せずに通信する方式です。
連携相手との関係が強くない場合、通常、非同期通信で連携します。
- メッセージング方式
  コンテキスト境界Aからメッセージを配信し、コンテキスト境界Bにて取得する。

なお、同期通信と非同期通信のメリット、デメリットは以下のようになります。

同期通信
- メリット
  通信の送受信した順番がずれない。
  技術コストが低い。
- デメリット
  処理が終了するまで先へ進めないため処理のパフォーマンスが比較的悪い。
非同期通信
- メリット
  送受信が完了していなくとも別の処理を実行することができるので処理のパフォーマンスが比較的良い。
- デメリット
  通信の送受信の順番がずれることがある。
  技術コストが高い。

コンテキスト境界が連携するときの公表された言語（PL）ですが、最近ではJSONとXMLがよく使用されています。

事業アプリケーション戦略

事業アプリケーション戦略では、事業ごとの事業戦略に従って、

経済合理性
競争優位性
持続可能性

を上げるために、コアドメインのアプリケーションにどのような機能を持たせるか明確にします。

事業戦略の因果ループで考えると、アプリケーション資産は、事業のコアコンピタンスを持つ事業資産の一つという位置付けになります。
なお、事業戦略についての詳細は、ビジネスアーキテクチャを参照してください。

アクションプランの策定

最後に、アプリケーション戦略を実現すべくアクションプランを、
企業にとって戦略的に重要なアプリケーション資産を、どのように取得し、どのように統合し、どのように管理することで、アプリケーション資産の品質を確保し、有効活用できるようにするか
という観点で策定します。
アクションプランについての詳細は、ビジネスアーキテクチャを参照してください。

以上、今回は、データアーキテクチャについて解説しました。
動画視聴もできます！