SOA適用開発プロセスの体系化#3
SOA適用開発の一般的な基本フローとして、以下のように定義してみた。フェーズ開発を前提としている。
SOA適用開発の基本フロー
+-- ■1 プレ分析と開発計画 +-- フェーズごと +-- ■2 ビジネスモデリング +-- 並列 | +-- ■3 基盤アーキテクチャ構築 | +-- □サービス分析／開発 | +-- ■4 サービス抽出 | +-- ■5 サービス分析 | +-- 並列 | +-- □コンポーネント分析／開発 | | +-- ■6 コンポーネント分析 | | +-- ■7 コンポーネント開発 | +-- ■8 プレゼンテーション開発 | +-- ■9 コンポジットサービス開発 +-- ■10 総合テストと移行 +-- ■11 運用 +-- ■12 プロセス改善
SOA適用開発は、全体最適を目指すのでいくつかのフェーズで段階的にサービス適用範囲を拡大し、段階的に基盤アーキテクチャを洗練／進化させる必要がある。また部門から全社、全社から協力会社へとIT成熟度に合わせて最適化の範囲を拡大させることになる。
ビジネスモデリングはEAベースで各フェーズ内の活動として配置している。原則、フェーズごとにAsIs、ToBe、Realizeを見直すことになる。
基盤構築とサービス開発の活動は並行である。
サービス分析の中でサービスが定義され、それに応じて、コンポーネントによる実現、コンポジットサービスによる実現、またプレゼンテーション開発が並行の活動となる。
フェーズ開発
SOA適用開発ではいくつかのフェーズで段階的に成熟度を上げていく。一般に、3段階のフェーズが多く提唱されている。フェーズを具体的にどのように定義するかは、組織やプロジェクトの特性に依存するので提示はしない方が無難である。フェーズ定義の要件としては、企業のIT成熟度、基盤アーキテクチャの洗練／進化、サービスの適用範囲の拡大の3点がある。
(1) 企業のIT成熟度とは、部分最適から全体最適を目指すことで、部門内の最適化、全社での最適化、パートナー会社を巻き込んだ最適化と段階的に進めることだ。
(2) 基盤アーキテクチャの洗練／進化とは、例えば、個別サービスの連携、ESBなどの導入、さらにESB・UDDI・BPELなどの連携へと段階的に進めることだ。SOA関連の標準化の動向を考慮する必要がある。
(3) サービスの適用範囲の拡大とは、既存資産のサービス部品化、部品の組み合わせ(コンポジットサービス定義)、新たなサービスの開発やBPELなどのによる自動プロセス化、といったように段階的に進めることだ。
一般にSOA適用開発は最初のハードルが高いので、第１フェーズを最小構成とするようなスモールスタートが推奨されている。
サービス特定の流れ
サービスは、抽出と分析の活動を経て仕様化される。抽出では、トップダウンとボトムアップのアプローチから候補を識別し、適宜融合を図る。分析では、候補のクラス分け、レイヤへの配置やモニタリング可能性といったアーキテクチャへの割付を行って、サービスとして確定していく。
+-- サービス抽出 | +-- 並列 | | +-- トップダウン | | | +-- プロセス分割 | | | | +-- ■プロセス分割 | | | | +-- ■共通性・可変性分析 | | | +-- ■ゴール分析 | | +-- ボトムアップ | | +-- ■既存システム分析 | +-- ミドルアウト | +-- ■候補の融合 # クロスセクション分析など +-- サービス分析 +-- 並列 +-- ■クラス分け +-- ■レイヤ配置 +-- ■モニタリング可能性の調整
(1) トップダウンでは、定義したビジネスプロセスからプロセスを分割し、サービス候補(ビジネスプロセス図ではアクティビティに相当)を抽出する。ビジネスルールと、プロセスやサービス候補に対する非機能要件も合わせて抽出しておく。フィーチャモデルとして機能と非機能特性を包含したフィーチャを抽出し、さらに将来変更が予測される部分と変更はないと予測される部分を明示しておくことも重要となる。
プロセス分割では、資産として業種別テンプレートがあればそれを適用することで効率的に候補が抽出できる。対象ドメインで蓄積され集約されたプロセス構造や情報構造のテンプレート、あるいはさらに共通性・可変性が分析されたテンプレートでもよい。
(2) またトップダウンでは、ビジネスゴールを階層化したサブゴールに対して具体的な施策の検討を繰り返す。その実現手段としてサービス候補が抽出される場合もある。
(3) ボトムアップでは、現在稼働している既存システムをプロセスフロー、ビジネスルール、再利用可能なサービス候補に分割する。
(4) それぞれのアプローチで抽出されたサービス候補やビジネスルールは、Realizeモデルのビジネスプロセスに反映し、再構成してみる。サービス候補がアクティビティとして配置され、ビジネスルールが適切なアクティビティに割付られていること。その際、必要に応じてサービスの統合や更なる分割を行う。重複があったり、粒度が小さすぎる場合はサービス候補を統合する。ここまでが抽出の範囲である。
(5) さらに分析の段階に進む。サービス候補を様々な視点でクラス分けし、必要に応じてさらにサービスの統合や分割を行う。クラス分けの視点には、業務カテゴリ、利用者分類、ソーシング種別(人系、既存利用、新規開発)、部門・自社・外部の区分、優先度、類似性・重複や拡張性・変更性・安定性などがある。分析段階のクラス分けでは実現のための手段が考慮される。
(6) サービス候補は、SOAの基盤アーキテクチャとして構成される各レイヤに配置してみる。ビジネスサービス(人系)、ITで実現する業務サービスと基盤サービスなどの区別、またサブシステムへの割付を検討する。さらにモニタリング機能はアーキテクチャ要件の一部として実現するので、モニタリングが行えるか／行いやすいかという視点でサービスの粒度や配置を調整する。
