数年後企業はいくつのSaaS とデータ連携をしているか？～SaaS データ連携はロングテール（Long Tail）を前提なアーキテクチャを～

CData は、SaaS やNoSQL のデータのインターフェースを統一して、標準SQL でアクセスできるドライバーを提供しています。エンジニアとのディスカッションの中でよくいただくコメントがあります。

「CData の統一インターフェースはたしかに便利ではある。でもWeb API でプログラミングすることもそんなに難しくないよ」

たしかに、多くのサービスにはWeb API があり、おおよそRESTful と言われるスタイルに則っており、少し学習すれば、API プログアミングによりデータ連携を行うことができるでしょう。では、CData Drivers のようにインターフェースを統一する製品を使う必要はあるのでしょうか？

考えるべき状況は今ではなく、近い将来にデータ連携するSaaS の数が20を超えてきたときです。ひとつのAPI をプログラミングで連携実装できても、連携対象サービスが20となった場合に個々のSaaS と異なった連携を構築し維持することはむずかしく、CData のような統一インターフェースを提供する製品・サービスの必要となります。

本記事はCData Software Advent Calendar の11日目の記事です。

qiita.com

データ連携先はSaaS の増加によりロングテールに増加

RDB のみの時代

10数年前にデータ連携が必要な先といえば、MySQL、SQL Server、Oracle、PostgreSQL といったRDB でした。多くのプログラミング言語があれどRDB の数は10指にあまる程度でした。

RDB はSQL でクエリできます。SQL はDB 毎の方言の違いなどはあれ、40年以上にわたり標準クエリ言語として使われています。アプリケーションとのインターフェースもJDBC やODBC など確立した標準があり、連携は比較的容易でした。

ところが、クラウドシフトと共にSaaS やRDB ではないストレージ（NoSQL）が使われるようになってきました。

ユニバーサルなSaaS

始めは、既存のカスタム・パッケージERP の業務の一部を置き換える形でSalesforce、Dynamics、G Suite などがサービスを提供しはじめました。CRM で行う営業管理、グループウェアで行うメール・スケジュール・タスクの管理などは多くの企業に共通して使われている機能のSaaS 化であり、これらのサービスはユニバーサルに企業に使われるようになりました。

データ連携については、API やSDK が洗練されユーザーにナレッジも蓄積され、ある程度簡単にAPI 連携を行うことができました。また、多くの場合、CRM 1種、会計1種、グループウェア1種という利用となり、多くても1社で2－3のサービスと連携すればよい状況でした。

バーティカルな（業務特化型）サービス

次第にSaaS では、Marketo、HubSpot などのマーケティングオートメーション、ログ管理のSplunk などのデジタルの強みを活かした特定の業務分野に特化したサービスが普及しはじめました。ただし、マーケティングオートメーションは一定数の顧客がいる企業向けであったり、どの企業も使うという訳ではありません。また、同じ業務向けの製品にもそれぞれ得意な分野があり、市場を圧倒的に占有することもできていません。

バーティカルな業務特化サービスのデータ連携はより困難になりました。デジタルの強みを活かしたサービスはデータの量・種類が膨大です。エンティティの数だけでなく、レコード数も従来のオンプレ業務システムを置き換えたのSaaS と比べ、桁違いに大きくなりました。データを上手に活用することは複雑なデータ連携を必要とするようになりました。また、同一業務向けでも選択肢となるサービスの数が増多く、エンジニア市場でもそれぞれのサービスのデータ連携のプロフェッショナルの数が少ないという状況です。

機能特化型サービス

そして現在は、ひとつの機能だけに特化したSaaS がどんどん増えてきています。電話やSMS 機能だけを行うTwilio、メールだけを行うSendGrid、MailChimp、電子サインのDocuSign やCloudSign、決済だけを行うstripe などです。市場にはどんどん機能特化型の便利なサービスがでてきて、API で連携しながらそれらを使いこなすことで、ユーザー企業は短時間で高機能なサービスを構築可能です。欧米のみならず日本でも年に数百、数千といった数で機能特化型のSaaS が生まれています。

データ連携となるとすでにカオスです。API が洗練されているものから、非常に限定された機能しかないものまであります。機能特化型であるため、複数のサービスを企業内で使用するようになり、データ連携も複雑さを増しています。

アメリカでは、一つの企業で平均20 程度のSaaS を使う時代に

あるリサーチでは, 2015 年に企業内で使用するSaaS の数は8程度であったものが、2017年には平均16のSaaS を使うようになったとのことです。

弊社のUS チームでユーザーから聞くところでは、平均20程度のSaaS に接続する必要があるとのことです。いくつかのユニバーサルなSaaS、その他特化型のSaaS が多数、そしてもちろん既存のオンプレミスのカスタムアプリケーションも同数以上との接続が必要です。

エンドユーザー企業であっても20という連携先の数は膨大です。これがBI、ETL、iPaaS、DWH や開発ツールなどを提供するIT ベンダーであれば、優に100を超えるSaaS との連携に備える必要があります。そして特化型SaaS はロングテール、つまり数が非常に多く、どのユーザーがどのサービスを使うかが絞れない状況です。

日本でもSaaS の活用はトレンドであり、数年後には現在のアメリカのようにひとつの企業が20以上のSaaS を利用し、それらのデータを連携する状況に至るでしょう。

Web API は連携方法がどれも独特

もし、Web API がプロトコルのように同じ仕様でアクセスできるようなら問題はシンプルです。しかし、Web API はいろいろな点で大きく異なる独自仕様になっています：

• プロトコル

• データモデル

• メタデータ

• 認証

• クエリ機能

細かくはCTO のブログ記事で解説しています：クラウドデータ連携はココがポイント！

多様なデータソースとの連携が可能なアーキテクチャを

これらのアプリケーション間を一つ一つ異なる実装で連携できるでしょうか？一つのETL やBI ツールからデータを使うことができるでしょうか？できたとしても頻繁に仕様が変更になるSaaS のAPI に追従できるでしょうか？これでは連携ができないか膨大なコストを支払い続けることになります。

連携が必要なデータソースが2-3 個のうちから、近い将来に接続先が20を超えてくることを予期し、マネージ可能なアーキテクチャでアプリケーションを組む必要があります。

CData による統一インターフェースの提供

そこで、CData では、150 種類以上のSaaS やNoSQL に対して、統一インターフェースであるSQL でのアクセスを可能にするODBC Drivers、JDBC Drivers、ADO.NET Providers を提供しています。カスタムアプリから、もしくはETL やBI ツールからシンプルに複数のデータに連携することができるようになります。

アーキテクチャとしては、アプリケーションから複数のデータにアクセスする仮想レイヤーとしてCData Drivers を使う形です。

エンドユーザー企業だけでなく、世界中のBI、ETL、AI、iPaaS、DWH などのベンダーにもCData Drivers はOEM されています（https://www.cdata.com/jp/company/partners.aspx）。

関連コンテンツ