Information On Demand

“SOA（Service Oriented Architecture：サービス指向アーキテクチャー）が今後のビジネスの柔軟性をバックアップするITシステムの理想像である”と言われ始めてすでに数年が経とうとしています。しかし、いまだに完全なかたちでSOAが実装されている例はきわめて少ないのが現状です。これは、企業全体でアプリケーションをすべて一度にSOAのかたちに再編成することの難しさを示しています。 そうしたなかで、IBMはSOAを始める出発点として、「People（人）」「Process（プロセス）」「Information（情報）」「Connectivity（接続性）」「Reuse（再利用）」という5つのエントリー・ポイントをご提案していますが、中でも「情報（データ）統合」から始めることがSOA実現への有力な近道であると考えています。 ここでは、「情報（データ）統合」が“なぜSOAのエントリー・ポイントになるのか？”ということを、お客様の事例を交えながらお話しします。

SOAが完成された形で実装された例がまだまだ少ない理由として、実装技術が理想に追いつかなかったこと、そしてもう一つ、SOA自身を目標化して性急に攻略しようとする姿勢をあげることができます。
与えられた資源と時間のなかでSOAの実装を確実に成功させるのに有効なアプローチは、まずデータ統合から着手することで直接的な課題解決の効果をすぐに得ながらシステム連携の基盤を構築すること。そして、ステップ・バイ・ステップで範囲を拡大しながら、企業システム全体のSOA化を段階的に進めることです。

SOAの構造を見てみましょう。
中央にESB(Enterprise Service Bus)があり、それを介在させて＜ビジネス・アプリケーション・サービス＞と＜プロセス・サービス＞が関係づけられています。
＜ビジネス・アプリケーション・サービス＞は個々のアプリケーション・コンポーネントであり、内部にはデータと状態が収納されています。このコンポーネントは、具体的には受発注システムや在庫管理システム、請求システムなどの細分化されたサービスの集合体です。
＜プロセス・サービス＞はサービス要求を定義するワークフロー・エンジンであり、アプリケーションやサービスをコントロールして業務を処理します。

ワークフロー・エンジンがアプリケーション・コンポーネントにサービスを要求するとき、プログラミング言語や通信プロトコルを直接使用すると、サービスがシステムに制約されるだけではなく、利用者はシステムの詳細にかかわらなければなりません。
しかも、アプリケーションやコードがデータと一対一対応で結びついている状態では、アプリケーション・プログラムを再利用しようとしても、自分と結びついたデータしか参照できません。

そこで、サービスを利用する側(コンシューマー)とサービスを提供する側(プロバイダー)の双方にサービスへの対応を専門とするインターフェースを設け、それらのサービス・インターフェース間で通信することが考えられました。
そのことにより、コンシューマーはプロバイダーの実装(アプリケーション・コンポーネント)やプログラミング言語、通信方式を気にすることなく要求を出し、また、サービスのかたちで回答をもらうことができるようになりました。SOAが“サービス指向”とされるゆえんです。

図1:IBMの提唱するSOAリファレンス・アーキテクチャーと、“インフォメーション・サービス”

拡大図

ESBは、分散されたさまざまなアプリケーションやシステムを統合し、クライアントから透過的にアクセスできる通信経路で、SOAシステムの中核を成すものです。
＜ビジネス・アプリケーション・サービス＞＜プロセス・サービス＞にESBを加えた総体が、通常はSOAとされています。 しかし、IBMはそのようなフレームワークだけがSOAであるとは考えていません。

SOAとは、その他のコンポーネントやセグメントを加えた全体像であり、なかでも<インフォメーション・サービス>というセグメントは再利用性の高いサービス・コンポーネントを実装していく上で非常に重要な働きをしています。また、全体のフレームワークを実現していく上で、<インフォメーション・サービス>における情報（データ）統合から実装していくことが、最も容易な入り口（エントリーポイント）の一つだと考えています。

＜インフォメーション・サービス＞の働きを見てみましょう。
ワークフロー・エンジンである＜プロセス・サービス＞は、要求されたアプリケーション・コードをESB経由で呼び出し、＜ビジネス・アプリケーション・サービス＞のデータを含めて処理するものだと、一般には簡単に考えられています。 しかし、IBMの考えは異なっています。
仮想化された＜インフォメーション・サービス＞は、ESB経由で問い合わせを受けると、実際のデータがレガシー・システムやほかのデータベース、さらにはSAPパッケージなど、どこにあっても、場所に関係なく利用したいデータにアクセスするという動きをします。
その際、＜ビジネス・アプリケーション・サービス＞には純粋にアプリケーションだけが存在しています。使いたいデータは＜インフォメーション・サービス＞から抽出され、多種多様なサービスが自由に利用できるようになります。

一つのアプリケーションのデータをほかの異なるアプリケーションでも利用したいというニーズは、もちろんこれまでにもありました。それに対し、従来は異なる業務システムで生成されたデータをデータウェアハウスに物理的に集積して情報処理をしていました。
しかし昨今のように、顧客などからの問い合わせにその場ですぐ対応することを求められるようになると、データをデータウェアハウスに集めている余裕はなくなり、より高いリアルタイム性を実現したいという要求が強まってきました。インフォメーション・オンデマンド(IOD)は、そのようなニーズに応えるものとして生まれてきました。

図2:必要に応じて必要なデータにアクセスできる——インフォメーション・オンデマンド

IODは、アプリケーションと密接に結びついたこれまでのデータのあり方に対し、必要なアプリケーションが必要に応じて必要なデータにアクセスできる環境を、仮想化・共有化によって実現しようとします。そのIODを支える主たる技術が、「仮想統合」「物理統合」というテクノロジーです。
たとえば受発注データや請求書データがシステム内の各所に散在する場合、データを動かすことなく、あたかも1つのデータベース上にあるように扱うことを「仮想統合」と言います。
また、履歴データなど更新されることのない膨大な情報をデータウェアハウスに集約・蓄積して管理するのが「物理統合」です。

図3:物理統合と仮想統合

これらの統合化に加え、IODにとって重要な分野として、顧客情報や商品情報などのマスター・データを扱う「マスター・データ管理」があります。
受注システムにおける受注データ、あるいは在庫管理システムにおける在庫データに見られるほどの業務依存性はなく、多くのアプリケーションにとって共用度が高く、運用するうえで最新のデータだけがあればいいというのがマスター・データの特徴です。
これまでは、マスター・データも各アプリケーションごとに保持されていました。しかし、ITが進歩し、データとアプリケーションを分離できるようになると、正確で矛盾のないデータを複数のアプリケーションで共有することが可能になりました。 マスター・データはCRM(カスタマー・リレーションシップ・マネジメント)やSCM(サプライチェーン・マネジメント)などの戦略情報として大きな意味をもつことから、近年特に注目されるようになっています。
IBMでは、高品質で信頼性の高い情報の一元化という目的を満たす機能に加え、そのデータを“戦略情報”として活用するためのデータモデルや柔軟なデータ構成管理機能がマスターデータ管理に求められる重要な技術要素と見ています。

IODの成功例はまだ多くありませんが、そのなかでも数少ない先駆けともいえる事例としてNTTコミュニケーションズ（以下、NTTコム）様における高度な情報統合をご紹介します。

NTTコム様では、さまざまな業務拡張や分社・再編成を経てきた経緯から、地域電話、長距離国際電話、携帯電話、インターネット・プロバイダーなど、数多くのレガシー・システムを抱え、企業のおかれた環境に柔軟かつ迅速に対応できないという課題を抱えていました。
提供するサービスごとにシステムが異なり、顧客データベースもバラバラになった結果、一つのお客様対応窓口で複数のサービスの手続きを横断的に処理できないといった事態に陥り、顧客満足度が低下。社内のオペレーションは煩雑化して、新しいサービス提供の設計もできないなど、深刻な市場競争力の低下を招いていました。
そこで、市場環境に柔軟かつ迅速に対応するため、抜本的なIT基盤の見直しを図るべく検討を開始し、多くの議論を重ねた結果、お客様情報のデータ統合から着手することになりました。グランドデザインのもとで業務の見直しを行うことは確かに大切ですが、それ以前に、直面している課題に対してまずはお客様情報に限定して情報管理ができる仕組みづくりを始めようということになったのです。
NTTコム様におけるIOD実装へのアプローチは、次のステップで進められました。

▼ステップ1 ： メッセージ連携基盤の構築により、サービスごとの基幹システムを意識することなく活用可能に
まず、ESBにメッセージ基盤を構築してそこにお客様情報のリポジトリーをもたせ、お客様情報の仮想統合を行いました。その結果、たとえばコールセンターに住所変更依頼が来た際に、お客様の電話番号情報をメッセージ基盤に投げると、それをトリガーに各システムのDBを参照し、利用しているサービスの一覧が表示されるようになりました。
そして、各々にメッセージを飛ばすと、お客様情報が戻ってきてメッセージ連携基盤で統合されます。
2つのお客様情報が所在する場所は別々ですが、電話番号をトリガーにして統合ができるメッセージ基盤を、既存のオペレーティング・システムのもとでWebSphere Message Brokerを導入して構築しました。

▼ステップ2 ： データ集約基盤構築により顧客情報（契約/請求/属性）を一元的に管理参照が可能に （バッチ・データ連携基盤によるデータ集約基盤の構築）
ステップ1の方法では、現行業務で稼働中のデータをそのまま取ってくるので、現時点でのお客様情報しか見ることができません。しかし、営業活動には過去の履歴系データも必要となるため、ステップ2では物理統合したデータウェアハウスを構築し、バッチ・データ連携基盤を整えました。

弊社でお手伝いをさせていただいたのはここまでですが、NTTコム様ではその後、ワークフロー・エンジンを導入し、SOAの思想に最も近い理想的な実装段階に進まれています。

図4:IOD実装アプローチ事例

このように、NTTコム様は、まず現在のお客様情報だけを仮想統合し、その後、物理統合によって扱える情報を履歴系に広げ、さらにアプリケーション・プロセスの連携へとステップ・バイ・ステップでデータ統合のレベルを上げてこられました。 この事例は、IODの先駆け的な事例であるばかりでなく、データ統合から始めると、いかに自然な流れでSOAを実現できるかということを実証している事例だと言えます。

ESBは、フォーマッティングやマッピングなどをメッセージ・レベルである程度、加工・編集できる能力を備えています。そのためステップ1で行われたお客様情報の仮想統合のような実装は、比較的容易に実現することができます。
お客様データの統合だけでなく、たとえば受発注システムのオーダー情報や商品管理システムのマスター情報などを仮想化することが必要となり、ESBという道具だけでは難しくなったとき、その段階でフェデレーションなどの技術を導入すればいいのです。
なお、フェデレーションは、ESBによるメッセージ・ベースのデータ連携と違い、SQLベースでの連携であるため、連携対象システムごとのアプリケーション開発と保守が不要であることから、連携基盤側の責任でプロジェクトを推進できます。このためシステム連携にありがちなプロジェクト間の調整の負荷が比較的低く円滑なシステム連携を実現することができるため、ESB導入に先んじて実装されるケースもあります。

ステップ1においては、ある程度のデータ連携をESBでスタートさせ企業にESBのハブを導入する契機とする、次に単なるデータ連携ではない仮想化へのニーズが高まったとき、それに合わせて追加的にソリューションを導入してIODのレベルアップを図っていく。そしてIODによるシステム間連携を基盤として、アプリケーション／プロセス連携にステップアップしていくことにより、ごく自然に理想のSOAへと歩みを進めていくことが可能となります。

“情報統合はSOAのエントリー・ポイント”。いまIODの一歩を踏み出せば、その先は理想のSOAの世界へと続いています。

• IODトップへ戻る

IBM, IBM(logo), DB2, developerWorks, IMS, PartnerWorld, WebSphereはInternational Business Machines Corporationの米国およびその他の国における商標です。
他の会社名、製品名およびサービス名等はそれぞれ各社の商標。