【解説】
SOAのメリットを最大限に引き出す「5つの方法」

United Airlines、Comcastなど先進ユーザーに学ぶ

（2008年03月18日）

ビジネス・ニーズに迅速に対応できるITシステムを実現することは、ITマネジャーが取り組むべき主要課題の1つである。SOAは、この課題を解決することのできる戦略的なアプローチとして注目を集めている。しかし、いまだに多くの企業が導入の初期段階にとどまっており、SOAによって得られるメリットを十分に引き出せていないという企業も少なくない。そこで本パートでは、実際にSOAの導入に成功している米国企業の事例を紹介しながら、SOAのメリットを最大限に引き出す方法を探ってみたい。

Galen Gruman
InfoWorld米国版

ケース・スタディで学ぶ
SOAのメリットの引き出し方

　SOAが注目され始めたころ、その目的と言えば、「アプリケーションの機能を共有サービスとして提供する」という非常にシンプルなものだった。企業はビジネスの成長に合わせて自社のアーキテクチャを構築してきた。もちろん、それは今日も変わらない。今と昔で異なるのは、この数年間でITの戦略的価値に対する経営サイドの認識がいっそう深まったことだ。またIT部門も、会社が生き残るために厳しい競争を戦い抜かなければならないことを理解するようになった。そうしたなか、SOAはこれまで以上に、ITと経営が足並みをそろえる環境を提供するようになった。

　企業が求めているものは、新製品や新サービスをすばやく展開するために、ビジネス・プロセスの構築と組み替えができる一連のサービス群だ。またSOAの主眼も、管理可能なサービスや一貫性のあるフレームワークを提供することにある。いまだに多くのSOAプロジェクトが初期の段階にとどまっているが、SOAの導入によってビジネスの俊敏性が高まることは明白であるため、ここにきて多くの企業がSOAの展開を加速しているのである。

　以下、SOAを導入し、戦略的なビジネス改革に取り組んでいる大手企業5社の事例をケース・スタディとして紹介しよう。

CASE STUDY 1
Comcast　http://www.comcast.com/
独自のアーキテクチャを基にSOAガバナンスを構築

　「SOAの導入が決まると、多くの企業が手始めにESB（Enterprise Service Bus）やレジストリ、その他ツールの購入に向かう。だがそれではSOA本来の重要な意味を見失ってしまいかねない」──そう語るのは、ケーブル・テレビ最大手のComcastでアプリケーション・アーキテクチャ＆ITガバナンス担当シニア・マネジャーを務めるトム・アドラー（Tom Adler）氏だ。

　同氏は、18カ月前にSOA導入プロジェクトがスタートした当初を振り返り、次のように語る。「どのベンダーも結局、われわれにESBを売りたがっていただけだった。われわれはベンダーの力を借りるという誘惑を断ち切り、専門家の意見を聞きながら最初にやるべきことを探った。その結果、まずアーキテクチャの策定からスタートすれば、現在と将来の変更に柔軟に対応できる正しいフレームワークを構築できることがわかった」

　アーキテクチャの策定に含まれるのは、フレームワークの定義だけではない。ビジネス・プロセスやアプリケーションの重複している部分を特定する作業も重要だ。「それは経営陣を味方につけるカギになる」とAdler氏が語るように、共通のサービスを利用してコストを削減すれば、保守や統合化にかかる負担を減らせるだけでなく、将来的に迅速な開発が可能なことも示せるため、その後のSOAインフラや各種ツールへの投資を正当化することができる。加えて同氏は、「重複するサービスを削減することも重要」とアドバイスしている。

　Comcastでは、「共通ドメイン・モデル」と呼ばれる独自のアーキテクチャを完成させたあと、次のステップとして、サービスの開発と展開を支援するガバナンス・フレームワークの構築に取り組んだ。「開発したサービス群は、ガバナンス・ゲートを通過させるようにした」とAdler氏。

　ガバナンス・ゲートを通過しないサービスは、だれもその存在を認識できず、正しいポリシーやプロシージャをフォローすることもできない。つまり、ガバナンス・ゲートを通過したサービスだけが、サービス・レジストリに追加され、利用可能になるという仕組みだ。

　ガバナンスの課題の1つは、サービスの所有者をだれにするかという点だった。Adler氏によると、Comcastでは比較的システムの分散化が進んでいたため、社内風土的にサービスを利用開始した者がそれぞれのドメインでサービスを所有するという形になった。また、シングル・サインオンなどの共通サービスは、ITのドメインに置かれた。

　Adler氏は、アーキテクチャを定義したあとに共通データ・サービス・モデルを開発しなかったことが失敗だったと述べている。社内情報へアクセスしたり、システム間のやり取りを管理したりするための標準データ・サービスがないため、開発者たちは任意の方法でそれらのジョブをサービスに組み込んでしまった。その結果、サービス・コンポーネントを簡単に組み合わせられるというSOAのメリットが阻害されてしまったのだ。

　「結局、あとから共通モデルを組み込むために手直しを余儀なくされ、不必要なコストを払うことになった」とAdler氏は語っている。

　ただ、SOAプロジェクトでアーキテクチャにフォーカスしたことは、技術的課題を超えてSOAコンセプトの適用範囲を広げることに役立ったとAdler氏は考えている。例えば、Comcastでは当初からSOAを単なるWebサービス対応ととらえず、あらゆるプロジェクトにSOAコンセプトを適用した。その結果、頭痛の種であった社内および社外の統合化ポイント（請求書発行ベンダーとの連携など）の削減にもつながったという。

　開発者は一般に、自分の知識に見合った、あるいは作成するアプリケーションに最適なツールやプログラミング言語を利用する。特定のツールや技術的手法を強制する代わりに、プロセスやポリシーを標準化すれば、開発者がアーキテクチャの意図する方向を見失い、特定のツールや技術の制約ぎりぎりまでプロジェクトを肥大化させることはなくなるだろう。もっともComcastの場合、共通のアーキテクチャの下で技術的な異質性を許容しているのは、9万人の従業員全員を同一の手法でまとめることが事実上不可能という現実的な理由にもよる。

　「当社ほどの企業規模になると、ビジネス・ニーズの変化や技術革新への柔軟な対応が不可欠だ」とAdler氏は指摘する。また、定期的にリファレンス・アーキテクチャを見直し、規制が窮屈すぎないか、あるいはドキュメントが有名無実化していないかを確認しなければならない。それらはいずれもSOAのメリットを阻害する要因になるからだ。「変更することはあまりない」としながらAdler氏は毎月必ずアーキテクチャの再確認を行っているという。

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