SOA適用開発プロセスの体系化#2

SOA適用開発では、システムの構成要素をビジネスプロセス、サービス、コンポーネントと論理的に明示できる。いわゆるアーキテクチャの半分以上に相当する構成要素の仕様、構成要素間の関係の規定は確定しているのである。SOA適用開発の成果物セットをイメージしてみた。
※アーキテクチャの定義も参照のこと。

プロダクト構成

　+-- ■ビジネスプロセス
　+-- ■サービス
　|   +-- ■コンポジットサービス  # 自動実行可能なプロセス
　|   +-- ■サービス定義          # 公開される定義
　|       ・サービスインタフェース定義
　|       ・メッセージ定義
　|       ・サービス動的仕様
　+-- ■コンポーネント        # サービスの実現
　|   +-- 業務コンポーネント
　|   +-- 基盤コンポーネント
　|
　+-- ■基盤                  # ESBなどを含む基盤アーキテクチャ
　|   +-- ■モニタリング機能  # パフォーマンス測定の仕組み
　+-- ■プレゼンテーション    # 利用者とサービスを連携するUI

SOA関係の用語は市販本やベンダ依存で結構不統一であり、特にビジネス、プロセス、サービス、コンポーネントあたりのキーワードは組み合わせの数(4C2=6通り)だけ出現しそうな勢いだ。シンプルな論理名で総称するならビジネスプロセス、サービス、コンポーネントである。サービス、コンポーネントは基盤側／システム側のものと、ビジネス側／業務側のもので分けてもよい。

SOAの解説では、利用者と対話するプレゼンテーション／UIの部分を明示したものが少ない。WebサービスやWSPR(WS Remote Portlets)を前提にしすぎているのだろう。従来のアプリケーションではあるが、SOAではプレゼンテーション部のみとなるので「プレゼンテーション」と表現した。

また、私にはChoreographyという単語が使い慣れてなくてイメージしにくい。「サービスの動的仕様」と表現してもらった方がしっくりくる。

また、さらに重要なポイントであるが、SOA適用開発は全体最適を目指す戦略モデルに従って行われるため、目標に対する達成度を評価する仕組みが必要である。アーキテクチャ要件の一部として実現されるが、あえて「モニタリング機能」として明示しておくこととした。

ビジネスモデル構成

　+-- 構成要素
　|   +-- ■ゴールモデル    # 目標ビュー
　|   |   ・課題
　|   |   ・目標
　|   +-- ■サービス構造    # 組織ビュー／ネットワークビュー
　|   |   ・利害関係者    　# 組織・ITシステム
　|   |   ・役割
　|   |   ・業務／サービス
　|   +-- ■プロセス構造    # プロセスビュー
　|   |   ・ビジネスルール
　|   |   ・ビジネスプロセス
　|   +-- ■情報構造
　|       ・概念モデル
　|       ・メッセージ      # メッセージモデル
　|       ・帳票など
　+-- シーン
　    +-- ■AsIsモデル
　    +-- ■ToBeモデル
　    +-- ■Realizeモデル   # 改善・変革ポイントの施策反映

ビジネスモデリングではしばしば、目標、組織、プロセス、ネットワークの4つのビューが取り上げられている。要求開発では、サービス構造、プロセス構造、情報構造の視点が強調されている。またHHaさんの提唱される4+1ビューでは、What(≒情報構造)、Who-When(コンテキスト)、How(＝プロセス構造)、Where-Who(ソリューション)、Why(≒目標)がある。このようにサービス構造の体系化がはっきりしないというか、諸説ある。サービス構造は、分かりやすく代表するならば、UMLのユースケース図と配置図で表現できる情報といえそうだ。「サービス構造」と総称すると若干分かりにくいが、代替できるいい表現も浮かばない。

戦略モデル構成

　+-- 構成要素
　|   +-- ■目標               # 戦略目標
　|   |   ・課題               # ビジネス課題、問題／課題
　|   +-- ■手段               # 解決策、施策、CSF
　|   +-- ■指標               # 評価指標(KGI、KPI)
　+-- 戦略レベルごとの目標
　    +-- ■ビジネスゴール     # 企業のビジネス目標
　    +-- ■プロジェクトゴール # プロジェクトスコープ内の目標
　    +-- ■改善・変革ポイント # スコープ内での施策の具体化

目標(ゴール)や施策などは必ず、戦略モデルとして、目標、手段(施策)、評価指標のセットで考える。BSCなどに代表される経営戦略の考え方を適用し、まず命題となる目標を定め、その目標を具体的に実現するための手段を策定し、その手段が遂行されているかどうかを定量的に測定するための指標を決めるのである。目標は課題から導かれることを明示する必要がある。

特にSOA適用開発では、指標としてKPI目標値を設定して運用時の測定値と照合して評価することがほぼ暗黙の了解となっている。このため、目標達成度を評価するためのモニタリング機能をアーキテクチャ要件の一部として実現する必要もある。

戦略には何段階かのレベルが必要である。戦略レベルに対する検証と妥当性確認が必要となる。SOA適用開発での戦略レベルには、少なくとも3つある。企業のビジネスゴールレベル、SOAプロジェクトのスコープに限定されるゴールレベル、対象フェーズでの分析スコープに限定されるゴールレベル(AsIsモデルに対する改善・変革ポイントとして表現されるレベル)である。

3番目のレベルは、SOA適用開発が一般に段階的なフェーズ開発となることを前提としている。企業におけるITの成熟度の向上、SOA基盤アーキテクチャの洗練／進化、サービス適用範囲の拡大は段階的に行わなければならない。

関連情報：体系化のアプローチ