 |
|||||||
|
|
|
||||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
|
Oracleの次世代IT基盤「Fusion Middleware」を探る【第二回】 |
||||||||||||||||
|
||||||||||||||||
|
Oracle Data Hubsによるデータ統合の重要性
|
||||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
|
第2回は、システムにあるすべての情報を企業全体で一元的に管理する「Oracle Data Hubs（以下、Data Hubs）」についてである。Data Hubsは標準化された技術で開発されているため、Oracleの製品だけでなく、ほかのベンダの製品とも統合が可能である。既存の環境に影響を与えることなく、企業内に分散している情報を同期させ、情報の品質を管理することができるData Hubsは、同社のナレッジ戦略のベースとなる機能である。 同社の提供するData Hub製品には、顧客情報を管理する「Customer Data Hub」、製品情報を管理する「Product Information Management Data Hub」、財務情報を管理する「Financial Consolidation Hub」などがある。今回は、日本オラクルのアプリケーションソリューション本部 本部長 石川正明氏、ならびに同社アプリケーションソリューション本部 データハブソリューション部 シニアソリューションコンサルタント 小坂大祐氏より、Customer Data Hubを中心に、同社のData Hubsについて話を聞いた。 ■ シングルデータモデルを実現するための武器
「Customer Data Hubは企業全体で顧客データを一元的に管理するしくみです。これまで企業レベルでマスターデータを活用したいと思っても、名前やコード体系が違ったりすると、活用することが困難でした。Customer Data Hubでは、これらのデータをインテグレートし、それぞれのシステムとマッピングします。さらに当社製品では、マスターデータだけでなく、製品情報や商談のステータスといった関連するトランザクションの情報も活用しようという目的を持っているため、これらのトランザクションデータもあわせて管理することができます」（小坂氏）。 データを統合したいという要望には、マスターデータを物理的に一元化したい、データ入力を一元化したい、複数のサーバーにあるデータの同期をとりたい、などがある。もちろん、このような情報システム的な要望は、そのまま経営的なバリューを出すための要望と直結している。 「個人情報保護法の施行によって、各事業部がもっているデータを統合的に管理したいというお客様は増えています。しかし、部署ごとに営業形態が異なるため、SFA（Sales Force Automation）自身を統合するのは無理だという声も多く聞かれます。こういったお客様こそ、Customer Data Hubのスイートスポットです」（小坂氏）。 個人情報の一元的な管理だけではなく、マスターを統合することで正確な情報をリアルタイムで活用したい、トランザクションを一個所に集めて商談のステータスやクレームといったビジネス情報を現場でリアルタイムに確認したい、といった要望に、OracleのData Hubsは的確に応えることができるのだ。 ■ Data Hubsによるデータ統合のステップ
Step1.データの状況をモデリングする それぞれのシステムにおいて、顧客データがどのように使われているか、マスターとトランザクションに関してモデリングする。 Step2.どのデータを統合するのか決める すべてのデータを統合するのか、それとも活用したい一部のデータだけをピックアップするのかを決定する。理想は全データの統合であるが、現実的には必要なデータだけを収集して管理することが多い。 Step3.顧客のデータモデルにマッピングする Oracleが持っている顧客データモデルに、収集したデータをマッピングする。同社の顧客データモデルは、ERPパッケージの顧客データそのものであり、CRMでも使われている汎用性の高いものである。 ここで気になるのは、Step3のデータマッピングである。汎用的なデータモデルに、自分たちのデータがマッピングできるのか心配する企業も多いのではないだろうか。 「自分たちのデータは統合できないと考えておられるお客様はとても多いようです。しかし、いくつかのお客様のデータをモデリングしましたが、それほど大差はありませんでした。住所などのデータを複数もてるかどうかといったことを気にされるお客様は多いのですが、当社の顧客データモデルであれば問題ありません」。 「また、業界特化型のデータなどは、丸ごとテーブルを取り込んで拡張モデルを作って吸収することができます。たとえば販売店の場合、売り場面積や店員の人数といったデータも含まれてきますが、このような情報は拡張モデルで対応します。また、このデータモデルの拡張機能によって、当社ではインダストリに特化した機能を順次追加していく予定です」（以上、小坂氏）。 企業のシステム全体でデータを統合したいという要望はあるが、現状のままでは統合できないと思い込み、新しくシステムを構築しなければならないと考える企業は多い。しかし、Data Hubsは既存のシステムに与えるインパクトを最小限に抑えながら、データを統合することができる仕組みである。 ■ 共通基盤としてのデータ
「ミドルウェアというのは、アプリケーションの共通基盤です。アプリケーションとはプログラムとデータから構成されているのですから、データそのものも基盤になると当社は考えています」（石川氏）。 企業のシステム全体がミドルウェアという共通の基盤の上で統合されるのであれば、それぞれのアプリケーションが利用するデータも同じ基盤の上で一元的に管理されていなければならないというOracleの考え方は、非常に理にかなっている。現実に企業のシステムを統合する上で、マスターデータをどのように統合するか、付随するトランザクションをどのように共有するかといった問題に直面している担当者であれば納得していただけるのではないだろうか。 ■ データの責任を誰がもつのか Oracleがこうしたデータドリブンなしくみを提案できるのは、同社がデータベースのベンダであることが大きい。市場に受け入れられたデータベース製品を自分たちで開発し、それがミドルウェアと統合されているというのは大きなアドバンテージである。事実、同社では、データ管理基盤を内包しているミドルウェア製品はFusion Middlewareだけであると自信をもって言い切る。「現在、Data Hubsは競合製品として意識するものがありません。ほかのベンダでも論理的なデータ統合をうたった製品はありますが、当社のように物理的にデータを統合するのと、論理的にデータを統合するのとでは根本的な考え方に違いがあります。ユーザーにとってデータを一元的に管理するといえば一個所にまとまっていると思うのが普通で、分散したデータを同期させることではないでしょう。ですからデータをシングルで持っていない仕組みをData Hubsと同じレベルで比較はできません」（石川氏）。 確かにデータの物理的な統合と論理的な統合には大きな隔たりがある。データが論理的に統合されただけの環境でトランザクションが増えた場合、パフォーマンスを誰が保証できるのだろうか。また、データのセキュリティは誰が保証してくれるのだろうか。同社のように物理統合であれば、パフォーマンスもセキュリティもOracle Databaseが一貫して責任を持つことになる。 「データが分散していても一個所で管理できるというのは、データベースがもともともっている概念です。データベースのレイヤ、つまりDBMSの仕組みで一元管理されている状況で、パーティションが切られていたり、ディスクが分かれていたりするのは構いません。しかし、上位レイヤであるミドルウェアから見た場合、あくまでもデータは一個所で集中的に管理されていなければならないと当社では考えます」（石川氏）。 ■ 一貫したデータ管理基盤を提供するFusion Middleware Fusion Middlewareのシングルデータモデルは、Oracle Databaseとの統合によって現実味を帯びた機能となった。Oracleはデータベース、ミドルウェア、アプリケーションといったすべてのレイヤで一貫したデータ管理基盤を提供することによって、データ品質、データアクセスのパフォーマンス、そしてデータのセキュリティに責任を持てる数少ないベンダなのである。データ統合の問題には、かならずセキュリティの問題がついてまわる。特に個人情報保護法や、今後施行されることになるであろう日本版SOX法といった法律に関するコンプライアンス問題への対応として、今後日本でもデータの一元管理は注目されるしくみとなるだろう。 次回は、OracleがどうやってSOAを実現しようとしているかを、「Oracle BPEL Process Manager」を中心に見てみよう。 ■ ＵＲＬ 日本オラクル株式会社 http://www.oracle.co.jp/ Oracle Fusion Middleware http://www.oracle.co.jp/products/middleware/
（ 北原 静香 ）
|
