 |
≫ |
|
|
|
|
■SOA導入は進化の過程、スパイラルなアプローチで |
|
|
|
|
聞き手 |
次に挙げられているのはスパイラルなアプローチですが、これはどういう意味ですか。 |
|
|
西村 |
SOAの導入は、いちど取り組めば終わりというものではありません。改善を繰り返しながら、少しずつレベルアップしていく必要があります。スパイラルというのは、目的地に向かって一直線に進むのではなく、渦巻き型で進んでいく考え方です。 |
|
|
|
|
聞き手 |
システム開発の手法として“ウォーターフォール型”というやり方を習ったことがありますが、これが目的地に向かって一直線に進む手法なんですね。つまり、これとは異なるアプローチが必要だということですね。 |
|
|
西村 |
ウォーターフォール型の発想だけでSOAを導入すると、かなり困難な途を歩むことになります。なぜならSOA導入というものは、なかなか一筋縄ではいかないものだからです。SOAを実現するには、まずアプリケーションが利用できるサービスを用意しなければなりません。でもすべてのアプリケーションのニーズを満たすサービスを、最適な形で一気に作ることができると思いますか？ |
|
|
|
|
聞き手 |
それはかなり難しそうですね。 |
|
|
西村 |
難しいというよりも、現実的ではないというべきです。そもそもどのような形でとりまとめれば最適なサービス群を作れるのか、最初はおそらく試行錯誤の連続となるはずです。 |
|
|
|
|
聞き手 |
それではどうすればいいのですか？ |
|
|
西村 |
まず最初に行うべきなのは、大きな業務の単位でサービスを作っていくことです。アプリケーションを大まかな機能で分けて、これらをサービス化します。この段階で作成されたサービスは、まだ汎用性が低くて、他のアプリケーションで再利用するのは難しいかもしれません。でも最初はこの段階からスタートすべきなのです。 |
|
|
|
|
聞き手 |
この段階では開発のスピードアップという効果は、まだ見えてきませんね。だからこそ「見える化」から始めるべきなんですね。 |
|
|
西村 |
アプリケーションのサービス化がある程度進んできたら、今度はサービスの“粒度”を小さくしていきます。つまり機能をさらに細かく分けていくわけです。こうすることでサービスの汎用性が高まり、他のアプリケーションでも使えるものになっていきます。もちろん細分化されたサービスの中には、特定のアプリケーションでしか使えないものも出てくるはずです。しかしこの取り組みを継続していけば、自然にサービスが淘汰され、共通サービスとして使い勝手のいいサービス群が蓄積されていきます。 |
|
|
|
|
|
| ● |
大規模ウォーターフォールの限界
- 使われる共通サービスを当初に全て規定するのは困難
- スパイラルな取り組みでサービスの再利用が増加する
|
| ● |
サービス粒度は大から小へ
- 当初は業務の単位でサービスを規定
- 徐々に子サービス、孫サービスを整備
|
| ● |
共通サービスの顕在化
- 自然淘汰により本当に使われる共通サービスが顕在化
|
| ● |
ガバナンスとアーキテクチャから共通基盤を進化させる
- ガバナンスとアーキテクチャもスパイラルなアプローチで学びながら
深化・発展させ、共通基盤も進化・拡張させる |
|
|
|
|
|
|
聞き手 |
淘汰ですか。まるで進化論のようですね。 |
|
|
西村 |
そう、SOAの導入は進化の過程でもあるのです。SOA導入の最大の目的は変化に強いビジネス基盤を作ることにありますが、SOA導入そのものも変化の一部なのです。このようにスパイラル型で発展させ続けることで、次第に最適な形に近づいていきます。 |
|
|
|
|
第4のツボは「ITコンソリデーションとセットで考えること」です。ソフトウェアレベルでのSOAだけでは、十分な効果を発揮することはできません。 |
|
|
|
|
聞き手 |
それはなぜですか？ |
|
|
西村 |
アプリケーションから業務機能を抜き出してサービス化しても、それらがバラバラのサーバ上で動いているようでは、十分な柔軟性を発揮できないからです。
例えばサーバ1でサービスAとサービスB、サーバ2でサービスCとサービスDが動いていて、サービスAとBをアプリケーション1が、サービスCとDをアプリケーション2が使っているとしましょう。ここでアプリケーション3が追加されて、サービスAを使うことになりました。もしこのアプリケーション3の処理量が大きければ、サーバ1には大きな負荷がかかります。アプリケーション1の処理にも影響を与えてしまう危険性もあります。 |
|
|
|
|
聞き手 |
それは困りますね。 |
|
|
西村 |
先程、SOAの基本はレゴブロックだが、共通基盤も重要といったのは、まさにこのことです。共通基盤、つまり、ITコンソリデーションをセットで考えないと、このような負荷の変動に対応しにくいのです。逆にサービスの負荷が下がった場合には、今度は使われないITリソースができてしまい、ムダになってしまいます。ITコンソリデーションによってITリソースを統合し、されに仮想化して各サービスに提供するようにすれば、このような問題は根本から解決します。 |
|
|
|
|
聞き手 |
なるほど、ITコンソリデーションはSOAを支えるITリソースとなる“共通基盤”を作るために不可欠なのですね。 |
|
|
西村 |
ITリソースそのものも、その上で動くソフトウェアサービスと同じように、一種のサービスとして位置づけるべきなんです。アプリケーションはソフトウェアとしてのサービスだけではなく、ITリソースとしてのサービスも組み合わせて、目的の機能を利用するわけです。ソフトウェアとしてのサービスは“機能”を提供しますが、ITリソースとしてのサービスは、レスポンススピードやスループット、確保すべきディスク容量といった“サービスレベル”を提供します。
これをさらに一歩進めれば、使われた機能とサービスレベルによって課金する、といった考え方に発展するでしょう。このような仕組みを作り上げれば、システムのコスト効果がより明確になり、より合理的な投資が可能になります。 |
|
|
図：「ITコンソリデーションとセットで考える」 |
|
|
印刷用画面へ
