「戦略的な意思決定」がSOA導入を成功に導く

実装技術／製品の選定は全体像を明確にした後に

（2007年02月23日）

SOAの導入は戦略的な意思決定の下で進めるべきである。実装技術や製品の選択といった戦術的な判断は、ビジネス・プロセスやコアサービスなどを定義した後でなければならない。

エリック・ノール＆ギャレン・グルマン
InfoWorld 米国版

　開発プラットフォーム、サービスのレジストリ／リポジトリ、管理スキーム、メッセージング・システム、セキュリティ技術、そしてテスト・ツールの選択といった具合に、SOAの導入作業はさまざまな要素が絡み合い、めまいがするほど複雑だ。こうなると、サポート製品を購入するほうが得策なのか、購入するとすればどのベンダーを選択するかといった戦術的判断についつい走りがちになるが、そうした決定は、ビジネス・プロセスやコアサービス、あるいは全体的なアーキテクチャを定義した後で十分に間に合う。

　「ごった煮の議論は混乱を招くだけだ」と、コンサルタント会社テックフィナンシャル・ソリューションズの社長、ビル・アディレッタ氏は言う。可能性のあるすべての技術を検討するのではなく、すでに導入済みのものを確認し、自社のニーズに合わない製品は排除すべき、というのが同氏の意見だ。

　社内で有する技術が目的のジョブに対応していなければ、そのときに初めてベンダーの製品を検討に加える。ある程度候補が絞り込まれたら、現在利用している技術基盤および社内のスキル・セットに最も緊密にフィットする製品を選択する。その場合、なるべくプロプライエタリな技術は避けたほうがよいと、同氏はアドバイスする。

　大手保険・金融会社のハートフォードは、まさにそうしたアプローチを採用している企業の1社だ。同社は、ニーズをきちんと把握してから製品選定に取りかかり、しかもリプレースが簡単な製品を選ぶように心がけている。「ベンダーに対するわれわれの哲学は、リプレースが簡単であればあるほど、そのベンダーを信頼するというものだ」と、同社のモアランド氏は語る。

　また、「採用する技術は、すでに持っているもの、あるいは今必要とするものをベースにすべき」とアドバイスするのは、コンサルタント会社ハーウィッツ＆アソシエイツの社長、ジュディス・ハーウィッツ氏だ。同氏はこう続ける。

　「もしSAPに深くコミットしているなら、『NetWeaver』が有力な選択肢になる。そうでなければ、アプリケーションをサービスとする前に、詳細に検討しなければならない。最初にコンポーネントをチェックし、次に何が必要かを判断する。サービスの全体像が明確になったら、ESBやプロセス実行エンジンなど、必要に応じてサービスの管理技術を検討する」

　例えば、世界最大の自動車メーカーであるGMは、J2EE（Java 2 Enterprise Edition）プラットフォームを利用して、14の自動車ブランドを1つにまとめたオンライン・ショッピング・サービスを2001年に開始した。同社エンジニアリング技術グループのチーフ・アーキテクト、ホン・チャン氏は、J2EEがデータ・アクセス用のレイヤを持っていることが気に入ったと話す。「ビジネス・プロセスの依存関係を意識せずに、多くのデータ・ソースをハンドリングできる」（チャン氏）というのがその理由だ。

　ただしチャン氏は、特定の技術にこだわるつもりはないと強調する。「集中すべきはサービスであり、ビジネス・プロセスをいかに実装するかだ。技術は常に変化し、進化していく」と同氏。長期的な視野に立てば、特定のプラットフォームや技術は戦術的な選択に基づくものであり、戦略的な意思決定ではないからだ。

　いずれにしても、ビジネス・プロセス、データ・フロー、データ定義、サービス・インタフェース、ポリシーなどについては抽象化を行い、特定技術への依存性を排除しなければならない。そのためには、ローカルな実装とともに、全社レベルでのプランニングが不可欠だ。

　テックフィナンシャル・ソリューションズのアディレッタ氏は、「サービス定義やネーミング・ルールなどは、強力なガバナンス・モデルの下に定義すればよい。最悪なのは、技術からスタートし、何が可能で何が可能でないかの結論を急ぐことだ」と話す。

　重要なのは、SOAへの取り組みを巧みに進めることだ。まずはアーキテクチャとビジネス・プロセスを検討し、次に実装の要求仕様や許容可能なトレードオフ、そして必要とされるパフォーマンスを決定する。こうした作業により、実際のサービスやインフラストラクチャを構築するために利用すべき技術が明確になってくる。

　「SOAの導入にあたっては、統一された目標と方向性を維持しながら自由度の高い手法で緩やかに展開できるフェデレート型モデルを採用すべきだ」と、ハーウィッツ＆アソシエイツのハーウィッツ氏。「各プロジェクトを同一の思想、同一のアプローチでまとめるには、SOAをどう構築するかというルールの設定から手をつければよい」と同氏は語る。

セキュリティ機能の一貫性

　暗号化や認証、ID（アイデンティティ）管理などのセキュリティ機能は、SOAの成熟とともに、分散サービスにとってきわめて重要になっている。例えば、顧客管理を事業としているオートマティック・データ・プロセッシング（ADP）では、各種サービスで利用するセントラル・プロセスとして標準的なセキュリティ・モデルの導入を進めている。

　また、アプリケーション・サービス・プロバイダー（ASP）のUSiでも、エンドユーザーのID管理にフェデレーテッド・サービス・モデルを導入した。同社アドバンスド・エンジニアリング担当副社長のマイク・ラルフ氏は、フェデレーテッド・モデルを採用した理由について、「サービスは、ユーザーがだれであるかを関知しない。ただしサービスは、ユーザーがサービス・パスのいずれかの地点で認証されていることを知っている。認証情報が各サービス間でやり取りされるからだ」と説明する。

　AMRリサーチの上級アナリストであるデニス・ゴーハン氏のように、サービスでのセキュリティ確保を説く向きは多い。SOAの導入にあたっては、サービスやメッセージング・インタフェースの定義、あるいはビジネスとデータ・ロジックの分離などにどうしても目を奪われがちだからだ。

｜1｜2｜3｜ > 次のページへ