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

今回は、アプリケーションアーキテクチャをどう設計するのか説明します。
アプリケーションアーキテクチャは、エンタープライズアーキテクチャの一要素で、データアーキテクチャやビジネスアーキテクチャと関係しています。
アプリケーションマネジメントの導入プロセスにおけるアプリケーションアーキテクチャの設計の位置づけは次の図のようになります。

次の図は、アプリケーションアーキテクチャを設計するプロセスを示しています。

※実践は、順番、点線は参照を示す線です。
今回は、このビジネスアーキテクチャ設計プロセスに従って、次の順で、ビジネスアーキテクチャの具体的な設計方法について説明します。

アプリケーションポートフォリオの設計
ユースケースの洗出
アプリケーション連携モデル（概念）の設計
現行アプリケーションの分析
アプリケーション戦略の策定
現行ユースケースの洗出
現行ユースケースの分析
現行ユースケースの詳細化
要件定義
将来ユースケースの設計
アーキテクチャパターンの選定
アプリケーション製品の選定
アプリケーション連携モデル（論理）の設計
ユースケースの実現性検証

アプリケーションポートフォリオの設計

ここでは、トランザクション処理アプリケーションタイプと分析アプリケーションタイプの構成をアプリケーションポートフォリオとして設計します。

トランザクション処理アプリケーションのポートフォリオ

トランザクション処理アプリケーションのアプリケーションタイプは、職務（ジョブ）に対応させます。
ジョブは、内部統制による職務分掌や、同じスキルセット、ドメイン知識を持つ機能単位として考えられているので、ジョブ単位にトランザクション処理アプリケーションを分割することで、業務機能とアプリケーションを対応させることができます。
これは、結果的に、ソフトウェア設計原則の単一責任の原則「変更する理由が同じものは集める、変更する理由が違うものは分ける」に則ることになります。
例えば、ジョブが次のように設計されたとします。

すると、それをベースにしてトランザクション処理アプリケーションのアプリケーションタイプの構成は次のように設計することができます。

ここでは、戦略目標「製品品質の維持向上」を実現するために、顧客に導入した納入機（製品個体）の状態を監視し予防保全を実現するため納入機管理システムを導入しています。
また、得意先元帳や仕入先元帳に対応するシステムを導入し債権債務を細かく管理するため会計管理システムから売上管理システムと仕入管理システムを独立させています。

アプリケーションポートフォリオを一覧化すると次のようになります。

分析アプリケーションのポートフォリオ

次に、分析アプリケーションのアプリケーションタイプの構成ですが、これは、ソフトウェア設計原則の単一責任の原則に従うよう、分析の目的別に分類します。
例えば、売上分析をしたい場合は、売上分析システムになります。
次の図のように、BSCのKPIが定義されている場合、KPIごとに分析システムを設定することができます。

ユースケースの洗出

アクションフローからフロントエンドアプリケーションのユースケースを洗い出しユースケースモデル（概要）を作成します。
フロントエンドアプリケーションは、アクションフローのレーンのジョブごとに定義します。
ビジネスプロセスマネジメントで業務改善を行う場合、アクションの改善内容をユースケースに定義します。
ユースケースに定義されたアクションの改善内容は、要件定義の機能要件になります。
※
フロントエンドアプリケーション
フロントエンドアプリケーションは、ユーザーとのインターフェース（ユーザーインターフェース、UI）を司るアプリケーションです。
マイクロサービスは、フロントエンドアプリケーションのバックエンドでサービスを提供します。

業務概念データモデルの設計で例にした「製品の受注」アクティビティのアクションフローを例にします。

このアクションフローのうち、アプリケーションを活用するアクションは、「受注の登録」と「出荷の予約」です。

そこで、販売管理者のフロントエンドアプリケーションを販売管理フロントエンドシステムとすると、次のようなユースケースモデルを定義することができます。

※
ユースケースモデル
ユースケースモデルとは、アプリケーションのユースケース（使い方）を、ユースケース図を使って表したモデルのことです。

アプリケーション連携モデル（概念）の設計

記事「データアーキテクチャの設計方法」のアプリケーション連携モデル（概念）の設計を参照してください。

現行アプリケーションの分析

まず、現在のアプリケーションカテゴリはどうなっているか分析します。
次の図は、アプリケーションポートフォリオの各アプリケーションタイプに対応して現行システム（現行のアプリケーションカテゴリ）をマッピングした例です。

現行システム（現行のアプリケーションカテゴリ）でどのようなエンティティ（データ）を管理しているかもわかります。

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

次に、あるべきアプリケーションカテゴリの構成についての戦略を策定します。
次の図は、企業のアプリケーションを、業務活動の特殊性と規模で分類したものです。

これを見ると、業務活動の規模が大きくて特殊なアプリケーションはスクラッチ開発がよく、業務活動の規模が大きくて汎用的なアプリケーションは業務パッケージを適用したほうがよいとなっています。
なぜならば、業務活動の規模が大きくて特殊なアプリケーションは、ビジネスのノウハウが機能として蓄積されていく部分なので変更可能性が高く、自分たちが自由に変更しづらい汎用的な業務パッケージが足かせになる可能性が高いからです。
マイケル・ポーターのバリューチェーンは主要活動と支援活動から構成されていますが、価値を創り、伝え、届ける主要活動の部分は、ビジネスの根幹となる部分であり特殊性が高く、支援活動は汎用性が高いと考えることができます。
特に、会計や給与計算などは、会社によって機能が変わるわけではなく法改正による機能変更をいちいち自社で行う必要はないので、それこそ既成の業務パッケージを適用するほうがよいと考えます。
そして、この業務活動の規模が大きくて特殊性が高いアプリケーションこそマイクロサービスを適用すべきだと考えます。
なぜならば、ビジネスの根幹となる業務を支援するアプリケーションは高い保守性や可用性が求められるからです。
マイクロサービスを適用することで、システムがモジュール化され、比較的柔軟に機能を追加、変更することができます。
また、マイクロサービスは、分散システムを形成するので障害耐性が強く可用性を高くします。
次の図は、アプリケーションポートフォリオで業務パッケージを適用する部分とマイクロサービスを適用する部分を分けた図です。

これを見ると、会計や人事など規模が大きく汎用的なアプリケーションには業務パッケージを適用し、大規模で特殊性の高いSCMやCRM、PLMにはマイクロサービスを適用していることがわかります。
DXを進めるときは、アプリケーション戦略に基づいて、現行の基幹システムの構成をあるべき基幹システムの構成にトランスフォームするようにします。
※
SCM
サプライチェーン管理（SCM：Supply Chain Management、以下、SCM）とは、製品やサービスを提供するために必要な資材や部品などを供給するネットワーク全体を統合的に管理するソリューションです。
CRM
顧客関係管理（CRM：Customer Relationship Management、CRM）とは、顧客との関係を強化し、顧客とのコミュニケーションや相互作用を最適化するための戦略的なアプローチや技術の総称です。
PLM
製品ライフサイクル管理（PLM：Product Lifecycle Management、以下、PLM）とは、製品開発力や企業競争力を強化するために、製品ライフサイクル全体（製品企画・設計、調達、製造、販売、物流、保守サービス）に渡って発生する様々な技術情報を集約してエンジニアリングチェーンを繋いで管理するソリューションです。
ERP
エンタープライズ・リソース・プランニング（ERP: Enterprise Resource Planning）とは、企業全体を経営資源（人、物、金、情報）の有効活用の観点から統合的に管理し、経営の効率化を図るための手法です。

それから、アプリケーション戦略では、シングルサインオンを導入するかどうかなど、アプリケーションカテゴリ全体に関係する方針も決めます。
マイクロサービスの構成を考えるときは、ビジネスの活動領域を担うサービスだけでなく、ロギングサービスや認証サービスなど業務機能に共通の機能をマイクロサービス化することも考えます。
例えば、シングルサインオンを導入する場合、それを実現する認証サーバーをマイクロサービス（認証サービス）として実現することができます。

現行ユースケースの洗出

現行システムからアプリケーションのユースケースを洗い出しユースケースモデル（概要）を作成します。
例えば、現行のSCMシステムを利用して「受注の登録」と「出荷の予約」ができる場合、次のようなユースケースモデルになります。

現行ユースケースの分析

ユースケースをさらにケース分けしユースケースモデル（詳細）を作成します。
次の図は、上記SCMシステムのユースケースモデルを分析した例です。

「受注の登録」と「出荷の予約」のユースケースに対して、受注の登録変更するケースと出荷の予約変更するケースが派生していることがわかります。
また、受注の登録内容を変更する場合は、まず、受注の内容を確認する必要があること、受注明細の登録内容を変更、削除する場合は、まず、受注明細の内容を確認する必要があることがわかります。
それから、出荷の登録内容を変更する場合は、まず、出荷の内容を確認する必要があること、出荷明細の登録内容を変更、削除する場合は、まず、出荷明細の内容を確認する必要があることがわかります。

現行ユースケースの詳細化

アプリケーション戦略で、スクラッチ開発するアプリケーションカテゴリが明確になっているので、スクラッチ開発するアプリケーションカテゴリのユースケースを詳細化します。
ユースケースの詳細化とは、アクターとシステムの相互作用をイベントフローや画面遷移図、画面定義、画面イメージとして記述することです。
※
イベントフロー
ユースケース単位にアクターとシステムの相互作用を記述したもの。
アクターとは、システムに関連する外部要素（ユーザーや他のシステム）。

画面定義には、画面項目が入力か選択か、選択の場合の内容は何か、入力の場合、必須か任意かなど画面を構成する項目の仕様を定義します。
次の図は、上記SCMシステムの「受注の登録」ユースケースのイベントフローの例です。

また、次の図は、上記SCMシステムの「出荷の予約」ユースケースのイベントフローの例です。

イベントフローを作成するときは、イベントフローに記述された画面のイメージと画面遷移も合わせて作成します。

要件定義

要件定義は、機能要件の定義と非機能要件の定義から成ります。

機能要件定義

アプリケーションアーキテクチャ（概念レベル）で設計したユースケースモデルを、アプリケーションカテゴリの、あるべき機能要件として定義します。

ユースケースには、ビジネスプロセスマネジメントのアクションの改善内容が定義されています。

非機能要件定義

データ要件定義
データアーキテクチャの一環として定義されたビジネスメタデータをデータ要件とします。
品質要件定義
アプリケーションの品質要件を定義します。
ITILの可用性要件の定義とキャパシティ要件の定義も合わせて参照してください。
セキュリティ要件定義
ソフトウェア品質の一要素として情報セキュリティの要件を定義します。
セキュリティ要件を定義するときは、ビジネスメタデータに定義されている機密性レベルや規制対象カテゴリも参照しています。
制約条件
ソフトウェアを実行するIT基盤や、導入のための考慮事項などの制約条件があれば定義します。

将来ユースケースの設計

現行ユースケースモデルの詳細を、要件定義で定義されたユースケースモデルに適用します。
その上で、機能要件を満たすようにあるべきイベントフローや画面を見直します。
ビジネスプロセスマネジメントで業務改善を行う場合、アクションの改善内容をユースケースに定義します。
ユースケースに定義されたアクションの改善内容がある場合、それをイベントフローに落とし込みます。

アーキテクチャパターンの選定

アプリケーションのアーキテクチャパターンを選定する基準を非機能要件の観点で定義します。
アーキテクチャパターン選定基準に従って、アーキテクチャパターンを選定します。
アプリケーションマネジメントでは、マイクロサービスアーキテクチャと、マイクロサービスの仕組としてのヘキサゴナルアーキテクチャを推奨します。

アプリケーション製品の選定

アプリケーションを実現する製品を選定するための判断基準を定義します。
判断基準は、製品に求められるビジネス特性、機能要件、非機能要件、開発ベンダーの特性、価格などの観点で定義します。
アプリケーション製品選定基準に従って、アプリケーションを実現する製品を選定します。

業務パッケージの場合

業務パッケージを導入するときは、次の観点でFit&Gap分析をします。

業務パッケージのユースケースモデル（詳細）を洗出し、上述したあるべきユースケースモデル（詳細）と比較してギャップを洗い出す。
業務パッケージがデータ要件を満たしているか分析する。
業務パッケージが品質要件やセキュリティ要件を満たすことができるか分析する。

スクラッチ開発の場合

ITマネジメントで設計するIT基盤の製品を選定します。
マイクロサービスアーキテクチャを適用する場合、フロントエンドアプリケーション、BFF、マイクロサービスに関する製品を選定します。

アプリケーション連携モデル（論理）の設計

記事「データアーキテクチャの設計方法」のアプリケーション連携モデル（論理）の設計を参照してください。

ユースケースの実現性検証

ここでは、スクラッチ開発のアプリケーションアーキテクチャ（論理レベル）で、データ要件も含めてユースケースが実現できるかシーケンス図を描いて検証します。

「受注の登録」ユースケースのイベントフローの検証

まず、販売管理フロントエンドシステムの「受注の登録」ユースケースの次のイベントフローが上図のアプリケーション連携モデル（論理レベル）で実現可能かUMLのシーケンス図を作成して検証してみましょう。

次の図は、上のイベントフローを上述したアプリケーション連携モデル（論理レベル）の構成要素がどのように相互作用して実現しているかを表したものです。
1.受注登録画面が表示されるまでの流れ

2.受注が登録されるまでの流れ

これを見ると、上図のアプリケーション連携モデル（論理レベル）を構成するUI、BFF、マイクロサービスが相互作用しながらイベントフローを実現していることがわかります。
マイクロサービスでは、コンシューマ駆動契約（Consumer-Driven Contracts：CDC）を適用してAPI仕様を定義しますが、例えば、上記シーケンス図の「顧客の取得」シーケンスのように、マイクロサービスに対する操作の呼び出しがCDCのAPIとして定義されます。
「受注が登録されるまでの流れ」を見ると、受注登録できなかった場合のシーケンスが記述されています。
このうち、システムの障害によって「在庫の引当はできたが受注の登録ができなかった場合」のシーケンスがあります。
これを見ると、販売管理サービスが在庫管理サービスに対して、イベント駆動（非同期）で在庫引当の取消（キャンセル）操作をしていることがわかります。
マイクロサービスアーキテクチャのように分散ネットワークを形成することでトランザクションが分断さる場合、結果整合性を担保するための方法として補償トランザクションを発行することでロールバックを実現します。

「出荷の予約」ユースケースのイベントフローの検証

次に、販売管理フロントエンドシステムの「出荷の予約」ユースケースの次のイベントフローが上図のアプリケーション連携モデル（論理レベル）で実現可能かUMLのシーケンス図を作成して検証してみましょう。

次の図は、上のイベントフローを上述したアプリケーション連携モデル（論理レベル）の構成要素がどのように相互作用して実現しているかを表したものです。
1.出荷の登録画面が表示されるまでの流れ

2.出荷が予約されるまでの流れ

これを見ると、上図のアプリケーション連携モデル（論理レベル）を構成するUI、BFF、マイクロサービスが相互作用しながらイベントフローを実現していることがわかります。
例えば、出荷管理システムに対して「出荷の登録」操作が行わる場合のように、データの操作に対するデータ品質要件やビジネス上のデータ要件がある場合、それをコメントとして注記するようようにします。
この例の場合、出荷を登録するときには、ビジネスメタデータに定義されたデータの品質要件を実現しなければならないことがわかります。

出荷インスタンスは関連する出荷明細インスタンスがないと生成されない。
出荷明細インスタンスは関連する出荷インスタンスがないと生成されない。

という出荷エンティティ間の一貫性を保持しなければならないということがわかります。
また、データのトレーサビリティを確保するために次のデータ要件を実現しなければならないこともわかります。

出荷の元となる受注データがトレースできなければならない。
出荷明細の元となる受注明細データがトレースできなければならない。

「出荷内容の変更」ユースケースのイベントフローの検証

次の図は、「現行ユースケースの分析」でユースケースをさらにケース分けしたユースケースモデル（詳細）の例です。

この中の「出荷内容の変更」ユースケースのイベントフローをつぎのように記述します。

このイベントフローを上図のアプリケーション連携モデル（論理レベル）で実現すると次のようになります。

この例の「出荷内容編集可能性のチェック」シーケンスや「出荷の内容変更」シーケンスように、データ操作に対して、ビジネスメタデータとして定義されたビジネス上のデータ要件がある場合、それをコメントとして注記するようようにします。
この例の場合、

「製品の出荷登録」アクションのタイミング（製品が出荷されたタイミング）で、出荷の出荷日が設定され、出荷ステータスが完了にならなければならない、
出荷ステータスが完了になると、出荷内容の変更や出荷明細の追加ができないようにならなければならない、
出荷のステータスが完了している場合、出荷内容の変更ができないようにしなければならない

というビジネス上のデータ要件を守るために、「出荷内容編集可能性のチェック」操作で出荷内容が編集できるか確認していることがわかります。
また、「出荷の内容変更」するときも、念の為、ビジネス上のデータ要件が満たされているかどうか検証していることがわかります。