ウェアハウスネイティブ対アプリネイティブのレベニューツーリング

あらゆるレベニューツーリングの意思決定には、評価の中でほとんど名指しされることのない分岐点があります。それにもかかわらず、それはその後何年にもわたってオーナーシップ、コスト、柔軟性を形づくります。そのツールは、あなたがすでに持っているデータウェアハウスの上で動き、あなたが所有し管理するデータの上で計算を行うのか。それとも、ベンダーの環境の中で動き、あなたが中を見ることのできないシステムにあなたのデータのコピーを引き込むのか。これがウェアハウスネイティブ対アプリネイティブという問いであり、現代的なレベニュープラットフォームのリファレンスアーキテクチャにおける、より重大な選択の1つです。

どちらの答えが常に正しいということはありません。しかしそのトレードオフは予測可能であり、それを理解している評価者は、デモに流された評価者よりも良い長期的な意思決定を下します。

2つのアーキテクチャ

アプリネイティブなツーリングは、独自のデータストアを持ちます。あなたはソースを接続し、ベンダーはそのコピーを自社のインフラに取り込み、すべての計算はそこで行われます。それは独自のデータベース、コンピュート、UIを持つ自己完結型のアプリケーションです。ほとんどの古いレベニューツールはこの方式で動作します。ベンダーにとって構築・運用がシンプルだからです。

ウェアハウスネイティブなツーリングは、Snowflake、BigQuery、Databricks、Redshiftなど、あなたがすでに持っているクラウドウェアハウスの上で動作します。データを外部にコピーするのではなく、ロジックを内部に押し込み、データがすでに存在する場所でモデルを実行します。これは「データアプリ」あるいは「ウェアハウスファースト」と呼ばれることもあります。このパターンが登場したのは、ますます多くの企業がすでにウェアハウスを分析上の重心として持っており、そこからデータをコピーして持ち出すことが、まさにそのウェアハウスが解決するはずだったサイロの問題を再現してしまっていたからです。

これは表面的な違いではありません。誰が生データを保持するか、誰がコンピュートの費用を払うか、そしてベンダーが出荷した以上にどこまでシステムを拡張できるかを決定づけます。

トレードオフを決める要因

主に5つのことです。

データ所有権。 ウェアハウスネイティブは、あなたの環境内に1つの正典的なコピーを保持します。アプリネイティブは、ベンダーのシステム内に第二のコピーを作り、それは同期を保たなければならず、しかもずれていきます。これは、共有データレイヤーが防ごうとしている乖離を再び持ち込むことになります。

拡張性。 ウェアハウスネイティブでは、ベンダーのアウトプットはテーブルです。それらを結合し、拡張し、SQLで独自のモデルを構築できます。アプリネイティブのアウトプットはベンダーのUIとAPIの背後にあり、あなたが得られるのは彼らが公開するものだけであり、それ以上ではありません。

コンピュートコストと制御。 ウェアハウスネイティブは、あなたが見て、計測し、調整できるあなた自身のウェアハウスコンピュートの上で動きます。コストは透明であり、それはあなたのものです。アプリネイティブはコンピュートをサブスクリプションにバンドルします。これはシンプルですが不透明です。

ガバナンス。 ウェアハウスネイティブは、あなたがすでにウェアハウスで設定したアクセス制御、行レベルのセキュリティ、監査を引き継ぎます。これは見た目以上に大きなことであり、ガバナンスとアクセス制御がその理由を掘り下げています。アプリネイティブは、設定し、最初のものと整合を保ち続けなければならない第二のガバナンス境界を意味します。

価値実現までの時間。 アプリネイティブは通常、立ち上げが速く、ウェアハウスをまったく必要としません。成熟したデータインフラを持たないチームにとって、それは本物の利点です。ウェアハウスネイティブは、あなたがすでにウェアハウスを有能に運用していることを前提としており、そうでなければ、あなたが吸収できない複雑さを単に移動させるだけになります。

つまりウェアハウスネイティブは、利便性を制御と拡張性と引き換えにします。アプリネイティブは、制御をシンプルさとスピードと引き換えにします。

それぞれが正しい選択となる場合

アプリネイティブが適合するのは、成熟したウェアハウスやそれを運用するチームがない場合、速い価値実現を求めており、このユースケースについてベンダーがデータプレーンを所有することに抵抗がない場合、あるいはそのユースケースが自己完結型で、そのツールのアウトプットの上に何かを構築するつもりがない場合です。

ウェアハウスネイティブが適合するのは、ウェアハウスがすでにあなたの信頼できる情報源であり、レベニューツーリングにそれを分断させるのではなく強化させたい場合です。アウトプットを他のデータと結合したり、自社のモデルに供給したりしたいため、拡張性が重要な場合にも適合します。データレジデンシー、ガバナンス、セキュリティの観点から、ベンダーのクラウドにデータをコピーすることが高くつく、あるいは許されない場合にも適合します。そして、長期的な視点を持ち、データレイヤーでのロックインを避けたい場合にも適合します。

私たちが使う経験則はこうです。ウェアハウスがすでに会社の運営にとって中心的であればあるほど、ウェアハウスネイティブの根拠は強くなります。あなたが投資してきたウェアハウスからデータをコピーして持ち出すことは、そのツールのデモがどれほど見栄えが良くても、後退です。

実際のほとんどのアーキテクチャはハイブリッドである

現場ではその境界線はぼやけており、最良のセットアップはしばしば両方を使います。あるプラットフォームは、重いモデリングをウェアハウスネイティブで行い、データが存在する場所でアトリビューションとスコアリングを計算し、ワークフロー、アクティベーション、そして結果を人々が作業しているシステムへとルーティングするライトバック層のためのアプリケーションレイヤーを提供するかもしれません。データの重い部分についてはウェアハウスネイティブの所有権と拡張性を得て、ワークフローの部分についてはアプリのような使いやすさを得るのです。

ベンダーのマーケティングが何と言っていようと、3つのことを尋ねてください。私の生データは物理的にどこに存在し、どこで計算されているのか。もし正直な答えが「当社のクラウドにあるコピー」であれば、パンフレットが何と言おうとあなたはアプリネイティブを使っていることになります。あなたのアウトプットを、私が管理するデータとして得られるのか、それともあなたのUIとAPIを通じてしか得られないのか。そして、そのアクセスを誰のガバナンス境界が強制するのか。

率直な答えは、実際のアーキテクチャを明らかにします。そこから先の選択は、あなたのデータ成熟度、システムをどれだけ拡張する必要があるか、そしてデータプレーンを所有することにどれだけ価値を置くかにかかっています。同じ答えが、APIファーストなプラットフォームが、あなたの購入したものを意味のある形で拡張できるかどうかも決定づけます。

主なポイント

• アプリネイティブはあなたのデータをベンダーの環境にコピーし、そこで計算する。ウェアハウスネイティブはあなたがすでに所有するウェアハウスの上で計算する。
• トレードオフは、片方が制御と拡張性、もう片方がシンプルさとスピードである。
• 成熟したウェアハウスがない、あるいは自己完結型のユースケースならアプリネイティブ。ウェアハウスが信頼できる情報源である、あるいはガバナンスが重要ならウェアハウスネイティブ。
• 最も強力なセットアップは通常ハイブリッドである。ワークフローとライトバックのためのアプリケーションレイヤーを備えたウェアハウスネイティブなモデリング。
• マーケティングを見抜く3つの質問。データはどこに存在するのか、アウトプットをデータとして得られるか、誰のガバナンスが適用されるのか。

この分岐点を知っていれば、デモの磨き上げではなくアーキテクチャでレベニューツーリングを判断できます。そしてRevnewoのようなプラットフォームも、同じ3つの質問で評価されるべきです。あなたのウェアハウスがすでに物事の中心にあるなら、新しいツールがその投資を尊重するのか、それとも分断するのかを見極めてください。