前回までで,SOAにまとわりつく誤認識や,SOAが出てきた背景,そしてメリットについて,現状を交えながら解説してきた。これだけSOAについての記事や議論がIT業界内で飛び交うなか,敢えて「あらためて」の視点でこれらの話題を取り上げてきた理由は,SOAが極めてテクノロジーによって曲げられがちな考え方であるからだ。
もちろんSOAは各種テクノロジーの力がなければ実現できない。とはいえ,その企業システムの全体構成・設計をどうするか,というアーキテクチャの視点や,そのアーキテクチャを中長期的に支えるポリシー---言い換えると原理原則---が,SOAをSOAたらしめる基本である。それは,ガイドラインといった温(ぬる)いものではない。死守するべきものである。この点は,いくら強調しても,し過ぎるということはない。
テクノロジーに引っ張られがちなSOA
しばしばユーザー企業で見られるのが,「設計は設計,実装は実装」として,全体のアーキテクチャやポリシーを構築の現場で曲げてしまうケースである。
SOAのサービスを呼び出す側(クライアント側)の作り方によっては,サービスを提供する側(サーバー・サイド側)のモジュール性を失ってしまうことがある。高い処理性能を実現しなければならないというテクノロジーの要件や,便利なパッケージ・ソフトが市場にあり安価に構築できる,という手軽なテクノロジーの存在に負けて,モジュール性を低めてしまうわけだ。これではクライアント側とサーバー側の相互依存性を高めてしまい,サービスの汎用性が失われ,SOAの意義が消失してしまう。
日々システムを構築・運用している立場のシステム担当者からすると,アーキテクチャが大事とはいえ,目の前にあるシステムを実装できなければ意味がない,ということはよく理解できる。しかしSOAがそもそもアーキテクチャと銘打っている理由は,アーキテクチャやポリシーが,SOAがSOAたるメリットを引き出すからである。
例えばパッケージ・ソフトについてはその考え方を徐々に変えていく必要があるだろう。その製品を実装することにとらわれてはいけない。あくまでパッケージはサービスを実現する一手段としてとらえ,それが自社のアーキテクチャに沿うかどうかを一歩引いた立場で判断することが大切だ。
決して,テクノロジーや実装の都合で,アーキテクチャやポリシーを曲げてはならない。やむなく曲げるとしても,“わかって曲げる”自覚,そしてそれによる影響を把握したり,曲げた事実を管理する施策---本来あるべき姿にするタイミングや条件などを決めておくなど---が不可欠である。
SOAはアーキテクチャでありポリシーであるため,極端な話メインフレームやCOBOLなど使用するテクノロジーがまったく古いままでも,“SOA的なアーキテクチャ”は実現しうる。次回はアーキテクチャの本質を知るユーザー企業のエピソードを交えつつ,アーキテクチャの重要性についてより詳しく解説する。
飯島 公彦(いいじま きみひこ)/ガートナー ジャパン リサーチ ソフトウェアグループ アプリケーション統合&Webサービス担当 リサーチディレクターガートナー ジャパン入社以前は,大手SIベンダーにてメインフレームを含む分散環境におけるシステム構築・管理に関する企画,設計,運用業務に従事。特にアーキテクチャやミドルウエアを利用したインフラストラクチャに関する経験を生かし,アプリケーション・サーバー,ESB(エンタープライズ・サービス・バス),ビジネス・プロセス管理,ポータル,Webサービスといったアプリケーション統合技術に関する調査・分析を実施している。7月19日~20日に開催される「ガートナー SOAサミット 2006」では,コンファレンスのチェアパーソンを務める。ガートナーは世界75カ所で情報技術(IT)に関するリサーチおよび戦略的分析・コンサルティングを実施している。 |