目次
- 1 はじめに
- 2 1. Oracle Data Integratorでビッグデータ、NoSQL、ウェブサービス、APIを管理するには
- 3 1.1 Oracle Data Integrator: ビッグデータとNoSQLプロジェクトの制約
- 4 1.2 Oracle Data Integrator: アーキテクチャと実装の複雑化
- 5 1.3 顧客サポートの課題と所有コストの急増
- 6 1.4 Oracle Data Integrator 12への移行とその課題
- 7 2. Stambia ETLでアジャイルにデータを準備
- 8 2.1 Oracle Data IntegratorからStambiaへの簡単かつシームレスなマイグレーション
- 9 2.2 Stambiaでデジタル トランスフォーメーションを加速
- 10 2.3 データ統合: Stambiaで得られる生産性とパフォーマンス
- 11 2.4 Stambiaのアジャイル顧客サポート
- 12 3. Oracle Data IntegratorからStambiaへ: 成功の証
- 13 3.1 Stambiaへのマイグレーション、その信頼性と確実性
- 14 3.2 Stambia、広がる顧客ベース
- 15 3.3 即効性の高いROIが計算できるStambia
はじめに
当文書は、Oracle Data Integrator(ODI)の新バージョンODI 12におけるマイグレーションの問題を概説し、その対策につながるアイデアを提供します。そこから見えてくるのは、デジタル トランスフォーメーション プロジェクトを従来の技術で管理することの問題点です。ここでは、プロジェクトにアジリティ(敏捷性)と効率性をもたらすビジョンも提案していきます。これらをさらに詳しく掘り下げたい場合は、巻末の参考資料リストを参照してください。
1. Oracle Data Integratorでビッグデータ、NoSQL、ウェブサービス、APIを管理するには
1.1 Oracle Data Integrator: ビッグデータとNoSQLプロジェクトの制約
米調査会社ガートナーによれば、90%の企業は2018年の段階でアプリケーション インテグレーションの革新的な戦略を欠いており、市場に出回るデータ統合サービスと現状のニーズとの間には大きな隔たりがあると言います。
技術革新の面で悩みを抱える企業が増え続けています。これは主に、従来型のソリューションが、今日の現場で起きているデジタル トランスフォーメーションを予見できなかった時代の産物であることに起因します。当時はまだ非構造化データ(NoSQL)や階層データ(XML、JSON、ウェブサービスなど)のサポートが現実的ではなく、さほど発達していませんでした。
伝統的なリレーショナル データベース(Oracle、MySQLなど)の使用は2010年の初め以来、停滞、あるいはむしろ後退する中、MongoDBやElasticsearchなどの代替技術は年間40%の成長率を見せ、ITを取り巻く環境が急速に進化しています。その一方で、Oracle Data Integrator(ODI)のような従来型の技術に依存するユーザーは、企業戦略上、重要なプロジェクトの進行が思うように進まず、アジリティを著しく欠く状態に陥っています。
ODIのような従来の技術を用いてNoSQL環境の開発を進めるには、複雑な技術の連鎖が必要になり、大変な困難がともないます。ソリューションと、その基盤となる哲学が、新しいフォーマットに対応するようには考えられていないからです。
1.2 Oracle Data Integrator: アーキテクチャと実装の複雑化
時代の流れは急速で、その分、従来型のソリューションはそのアーキテクチャが複雑化こそすれ、単純化することはありません。Oracle Data Integrator(ODI)も例外ではなく、導入設定上の制約は増すばかりで、プロジェクトは自ずと柔軟性を欠き、当初の導入目的を果たせなくなってきました。ELT(つまり抽出(extract)格納(load)変換(transform)のデータ統合プロセス)とETL(抽出、変換、格納)― 従来のSunopsisとOWB(Oracle Warehouse Builder)のしくみ ― の融合が、コンポーネント ベースのロジックの登場によって開発を複雑化しています。さらには、WebLogicサーバーの業務環境への導入がほぼ必須化された状況において、ODIツールの取り扱いがさらに難しく、コストのかかるものに変わってきています。
これに加え、データ統合の全領域を網羅するためにさまざまなソリューションの組み合わせが必要になっています。たとえば、ETL、ESB(エンタープライズ サービス バス)、CDC(変更データ キャプチャ)、WebLogic、Oracle Fusion Middlewareなど、由来の異なる(企業の合併吸収、履歴ソリューション、異なる社内開発チームなど)さまざまなソリューション群の併用が不可欠になっています。これらの共存は決して容易ではありません。それが、IT予算に大きく響く危険性すらあります。
また、Oracleユーザーの多くは数年前から、いわゆる「コンプライアンス」の費用がデータ統合ソフトウェア ソリューションの年間所有コストを大幅に嵩上げする現状に頭を悩ませています。これは主にCPUのインデックス化にともなうコストです。
これらすべての要素がITプロジェクトの足枷となり、ODIを新しビジネスの周辺環境で活用することを難しくさせています。
1.3 顧客サポートの課題と所有コストの急増
アジリティ(敏捷性)の概念はリアクティビティ(反応性)の概念と切っても切り離せない関係にあります。スポーツにおいては、アジリティは相手または移動する目標物に対する反応時間を表します。経済やコンピュータの世界において、すべてが高速で移動する状況を思い浮かべてみてください。
ITおよびデジタル トランスフォーメーションのプロジェクトが成功するためには、技術的なソリューションとアジャイルなチームもさることながら、ソフトウェアとサービスのプロバイダからのすばやい反応が欠かせません。
フランスの業界団体CIGREFによれば、Oracleとその顧客や他のベンダーとの関係はかなり消耗してきているようです。顧客へのサービスとサポートに奥行きと広がりがないことが一因とされています。Oracleの請求書は非常に複雑なうえ、ITチームのコストにおいて最大の懸案事項になっている、との指摘もあります(某フランス企業グループのITマネージャー)。それを伝える記事[1]によれば、PostgreSQLをはじめてとするオープンソースのデータベースに移行する傾向が現実的な広がりを見せています。
顧客第一のビジネスが主流となる時代においては、デジタル プロバイダに対するユーザー企業の期待もそのぶん大きくなっています。この観点から、またCIGREFとEuroCIO(欧州の大規模ユーザー100社を対象とした2016年末の調査)によると、大規模ユーザー企業の半数はOracleとの契約を終わらせるか、徐々に終了する戦略を検討しているというデータもあります[2]。
このような流れの中で、Oracle Data Integrator(ODI)に代わるソリューションを求める企業は少なくありません。ODIからの移行を成功に導く戦略が求められています。前述のようなすべての問題に対する解決策として、他のソリューションへの移行が有効なオプションとなるのか、オープンソースの採用がよりシンプルで有効な選択となるのか、各企業が判断を迫られています。
1.4 Oracle Data Integrator 12への移行とその課題
これまで述べてきたさまざまな課題に直面すると、当然ながらOracle Data Integratorの新バージョンODI 12に活路を見出したいところです。
しかし、ODI 10または11からODI 12への移行を経験した多くのユーザーは、その困難さを強調します。バージョン12gにはソリューションの哲学に根本的な変更が見られるため、マイグレーションは自動的ではなく、広範な技術的および機能的テストを必要とします。これは、バージョン12マイグレーション技術サポートの市場導入時における実地調査で判明した事実です。また、バージョン10のユーザーは、バージョン12への移行前にバージョン11を必ず通過しなければならないことも負担になっています。
このため、代替ソリューションを求める決断をしたユーザーも少なくありません。オープンソースあるいは他の従来型のソリューションへの移行を推し進める動きが広がりつつあります。
ただし、この場合、ワークフローを一から構築しなおさなければならず、問題を他の場所に移すだけの結果につながる危険性も否めません。新しいソリューションが生産性や革新性に富んでいなければ、何のための変更なのかわからなくなってしまいます。
2. Stambia ETLでアジャイルにデータを準備
Stambiaへのマイグレーションは、新しいデジタル トランスフォーメーションの主導へ向けた非常に興味深い代替オプションとなり得ます。Stambiaでは、データを準備するうえで、計算外の不合理な作業が発生することはありません。
2.1 Oracle Data IntegratorからStambiaへの簡単かつシームレスなマイグレーション
まず注目すべきは、StambiaのソリューションがODI(旧Sunopsis)の古いバージョンに近い開発哲学を維持している点です。すなわち、ELTモード(つまり、データ変換プロセスの従来の配置)にもとづくデータフロー設計とデータのマッピングを定義する非常に単純なしくみを維持している点が、ユーザーにとって大きな利点となります。
したがって、マイグレーション後にユーザーはごく自然にいつも通りの業務パターンと使い慣れたグラフィック ユーザー インターフェースに戻ることができます。開発者にとっても、ODIとStambiaの間には論理的な継続性があり、既存の知識が再利用でき、新しい技術も直ちに習得可能です。つまり、Stambiaへのマイグレーションなら、継続性を保ちながら、よりシンプルなGUI、そしてプロジェクトに対応する新しい機能を利用することができます。
しかし、いちばん重要なポイントは、既存の開発の進行を維持しながらマイグレーションが可能になる点です。ODIマイグレーション ツール(ODIのいずれのバージョンでも可)が、既存の開発環境をそのまま維持し、開発とメンテナンスの連鎖を崩すことなく進化させ続けることを可能にしてくれます。マイグレーションがインフラストラクチャに激震を起こすようなことはなく、完全に制御された経済的かつ発展的なしくみで実行されます。
2.2 Stambiaでデジタル トランスフォーメーションを加速
Stambiaへの一歩を踏み出したら、ユーザーには新しい地平線が開けています。
Stambiaのソリューションなら、デジタル トランスフォーメーションの課題に安心して取り組むことができます。
実際のところ、ビジネスの新しいイニシアティブはほとんど非リレーショナルのデータ(XML、MongoDB、Elasticsearch、JSON、Hbase …. ウェブサービス)に依存しており、それはStambiaが特に得意とする分野です。
シンプルなGUIが開発のスピードを上げるので、アジャイル方式のプロジェクト(DevOps、スクラムなど)にはまさにうってつけです。開発プロセスのイテレーションが早まり(1週間以内)、プロジェクトが数週間で業務環境に実用化可能です。
2.3 データ統合: Stambiaで得られる生産性とパフォーマンス
Stambiaへのマイグレーションを行ったユーザーは即座にパフォーマンスと生産性の向上を実感しています。Stambia独自の哲学にもとづき、階層データのロードまたはアンロードが単純な方法で実現されるので、生産性が自ずと高まります。このアプローチは、開発時間を最低でも10分の1に細分化します。パフォーマンスの例を挙げると、たとえば、フランスの自動車用品ブランドNorauto(ノルオート)のような大企業では、XMLファイルまたはCassandraとElasticsearchフィードを、同じデータ統合ソリューションと同じ開発ロジックに対して同時に処理することを可能にしています。
より従来式のデータフローでは、ODIソリューションと比較して20%増の効率化も確認されています[3]。
2.4 Stambiaのアジャイル顧客サポート
プロジェクトにおいて即応性を確保するには、デジタル ソリューションのプロバイダとアジャイルかつプロアクティブな関係を築くことが何より大切です。
この点に関して、Stambiaの顧客は次のように述べています。
「とにかく対応が早いです。午前中にリクエストを送れば、午後にはほぼ必ず回答をもらえると確信できるレベルです。」
そのようにコメントしたユーザーは、フランスの建設業界団体ProBTPにおける日次ソリューションを利用する15社に含まれます。
また、ファイナンシャル サービス大手の某企業は「Stambiaを利用してはじめて“サポート”の本当の意味がわかりました」とも述べています。
3. Oracle Data IntegratorからStambiaへ: 成功の証
3.1 Stambiaへのマイグレーション、その信頼性と確実性
Oracle Data Integrator(ODI)からのマイグレーションを目指すユーザーにとって、代替ソリューションを見つけるのが最大のネックになっています。しかし、Stambiaでは、マイグレーションがツール化され、信頼性かつ計画性に富み、きちんと組織化された方式が提示されます。
そして、このマイグレーションは顧客とStambiaチームおよびパートナーとの連携のもとで進められます。
それにより、段階的なマイグレーション(プロジェクトごと、あるいはインターフェースごと)が可能になり、マイグレーション後の環境には既存のデータフローがすべて復元されます。大々的な変革が強いられることはなく、プロジェクトの進行を遅らせるようなこともありません。それどころか、ODI環境ですでに使い慣れたオブジェクトを、StambiaのGUIで引き続き使用することができます。
個々のオブジェクト(インターフェース、パッケージ、プロセス、変数、ユーザーファンクション、トポロジーなど)に相当するものが、Stambiaのツール上でもそのまま使えるしくみになっています。
3.2 Stambia、広がる顧客ベース
数多くのユーザーがOracle Data IntegratorからStambiaへのマイグレーションを選択しています。
これらの顧客はすべてマイグレーションあるいは単に日常的なStambiaソリューションの利用によってさまざまなメリットを享受しています。
たとえば、フランス大手建材メーカーSaint Gobain(サンゴバン)グループのMaxime Horryはこう述べています。
「我々はソフトウェア プロバイダが積極的に関わって、即時に対応してくれるアジャイル ソリューションを求めていました。Stambiaはいつでもそれに応えてくれます。」
3.3 即効性の高いROIが計算できるStambia
マイグレーションが完了したら、ただちにプロジェクトの高い投資収益率(ROI)が見込めます。
Stambiaなら数日でプロジェクトを完了することができ、他の従来型のソリューションやオープンソースのソリューションで数か月かかるのに比べたら、それだけでも大きな利潤につながります。
個人保険の某大手企業では、オープンソースの代替アプローチと比較し、開発時間の25%の向上に成功したという実績が得られています。また、食品業界の某大手企業では、Stambiaにより、オープンソースのソリューションに比べて3倍の速さでマイグレーションが完了したと報告しています。
Oracle Data Integrator(ODI)との比較では、さらに優れた実績が示されています。
たとえば、XMLの階層データを1件フィードするために10以上のインターフェースやパッケージが必要であったところを、Stambiaでは単一マッピングで十分対処可能になっています。
ODIでは、しばしばJythonスクリプトや複雑な変数ベースの設定が必要になりますが、Stambiaでは標準化された単純で機能性の高いオブジェクトが使用でき、複雑なメンテナンスやユーザーへの技術的な負担もありません。
ホームセンター/リビング用品大手Leroy Merlin(ADEOグループ)のジャン=ブノワ・メハー氏による以下のコメントがすべてを物語っています。
「Stambiaソリューションの構造的な技術上の利点はもちろんのこと、仕様設計やメンテナンス、進捗状況の確認など我々管理部門が直面する課題に対しても有効性が保証され、Stambiaのシステムにそれらの指標がきちんと考慮されている点が非常にありがたいです。そして、財務的な効果は本当に嬉しい驚きでした。ツールの選択段階ではOracle ODIをはじめとする他のソリューションも検討したのですが、もしそれらを選択していたら3倍から5倍の費用がかかっていたことでしょう。Stambiaを選んだおかげで最大限の投資効果が得られました。」
関連資料リンク:
[1] 2017年6月12日付のフランスの記事、http://www.journaldunet.com/solutions/dsi/1205799-open-source-oracle/
[2] 2017年3月7日付のフランスの記事、http://www.solutions-numeriques.com/levee-de-bouclier-des-dsi-contre-oracle-50-desgrands-clients-seraient-prets-a-rompre-le-contrat-avec-lediteur/
[3] Stambiaへのマイグレーションを行った顧客グループの調査にもとづく
関連したトピックス
- ドキュメント・データベースは何か?
- Stambia Component for SAPの機能紹介
- ETLからELTへ:データウェアハウスの能力を活用し、データサイエンスで本当に価値のあるBIを実現 : Stambia
- 豊富なテンプレートでデータ統合に最適な処理を手間なく簡単開発 [Stambia]
- StambiaのSalesforceとの接続ツール: Open Connector for Salesforce
- Salesforceとのデータ統合:6つの利点 [Stambia]
- GlueSyncでNoSQL活用を加速:データモデリング編
- Stambia ユーザー導入事例:仏ランジェリー ブランド Chantelle(シャンテル)
- GUIでWEB APIも簡単に構築 [Stambia]
- スケールアップ とスケールアウト [データベース]