なぜ共有データ層がポイントツーポイント統合に勝るのか

すべてのレベニューチームはいずれ同じ分岐点にぶつかります。新しいツールが既存のツールからのデータを必要とします。たとえば、セールスエンゲージメントプラットフォームがCRMからアカウントティアを必要とするとしましょう。速い答えは直接同期です。二つを接続し、いくつかのフィールドをマッピングし、出荷する。速い答えはまた、スタックが保守不能になっていく道でもあります。十数個のツールを持つ頃には、「とりあえずつなげる」という反射が、誰も完全には理解しておらず、誰も触りたがらないポイントツーポイント統合の毛玉を生み出しています。

代替案は、ツール同士を直接配線する代わりに、すべてのシステムが読み書きする共有データ層です。これは現代のレベニュープラットフォームのためのリファレンスアーキテクチャにおける荷重を支える決定の一つであり、統合の数が大きくなるまでそのトレードオフは明白ではないため、それ自体として理解しておく価値があります。

算数はすぐに醜くなる

ポイントツーポイントは純粋に組み合わせ論的な理由でスケーリングが悪化します。n個のシステムがある場合、可能な直接接続の数はn(n-1)/2です。3つのツールなら最大3つの統合で済み、たいしたことはありません。10個のツールなら最大45個です。そして各統合はただの配管ではありません。それはフィールドマッピングのセット、同期スケジュール、変換、そして失敗モードです。それを45倍すれば、どんなチームもクリーンに保てない保守面積になります。

共有層はこの算数を変えます。各システムはハブと一度だけ統合するため、n個のシステムにはn個の接続が必要になります。成長は二次関数から線形になります。さらに重要なのは、セマンティクスが一箇所に存在することです。「MQL」や「アクティブな案件」が何を意味するかについての45通りのわずかに異なる見解の代わりに、あらゆるツールが継承する一つの正規の定義が存在します。

直接同期の初期構築は本当に速いものです。隠れたコストは変更コストです。CRMがフィールド名を変更すると、それに触れる3つか4つの統合が静かに壊れ、あなたはそれを取締役会資料の中の間違った数字から知ることになります。私たちはその会議に同席してきました。楽しいものではありません。

「共有データ層」が実際に意味するもの

共有データ層は、誰もがクエリできるデータベース以上のものです。3つの特性が、それを単なる共有のゴミ捨て場と区別します。

正規のエンティティ。アカウント、コンタクト、案件、レベニューイベントは解決され、重複が排除され、安定した識別子を持つ単一のレコードにまとめられます。エンティティ解決はここで、一度だけ行われ、すべてのツールでそれぞれ再実装されることはありません。これは完全にクリーンなインプットに依存しており、だからこそRevOpsのデータハイジーンは後付けではなく前提条件なのです。

明示的なスキーマ。すべての消費側システムは、文書化されバージョン管理されたスキーマに対して読み取りを行います。スキーマが変わったとき、消費側はそれを知らされます。本番環境で発見することはありません。

双方向のフロー。この層は読み取り専用ではありません。中央で計算された洞察は、規律ある書き戻し層を通じてアクションシステムに書き戻され、そのハブは両方向において信頼できる情報源となります。

これら3つがなければ、あなたが持っているのはたまたま真ん中に位置しているデータレイクにすぎず、それは余計な手順を伴ってポイントツーポイントの混乱を再現するだけです。

あるシナリオでどう見えるか

あるミッドマーケットSaaS企業は、CRM、マーケティングオートメーションプラットフォーム、プロダクト分析ツール、請求システム、ウェアハウスを運用しています。チームは、マーケティングエンゲージメント、プロダクト利用、アカウントのファーモグラフィックスをブレンドしたリードスコアリングを望んでいます。

ポイントツーポイント:マーケティングオートメーションはCRMに同期します。プロダクト分析はエンゲージメントスコアリングのためにマーケティングオートメーションに同期します。請求はCRMに更新フラグのために同期します。ウェアハウスはこれら3つすべてから別々のスケジュールで引き出します。リードスコアはマーケティングオートメーションで部分的なビューから計算され、その後CRMで計算された別のスコアによって上書きされます。二つのスコアが存在し、それらは食い違い、担当者は1か月以内に両方を信じるのをやめます。

共有層:4つのシステムすべてがハブに供給します。エンティティ解決が、プロダクトアカウント、請求アカウント、CRMアカウントを一つの正規のアカウントに縫い合わせます。スコアは完全な全体像に対して一度だけ計算され、CRMとマーケティングプラットフォームに同一に書き戻されます。一つのスコアであり、すべてのインプットが一箇所にあるため説明可能です。

二つ目のセットアップだけが、誰もがそのスコアを信頼できるものです。指標への信頼は、その背後に単一の系譜があることに依存するからです。

ポイントツーポイントで問題ない場合

例外のないアーキテクチャのアドバイスはイデオロギーです。直接統合が正しい選択となるのは、安定した2つか3つのシステムがあり、それ以上追加する計画がない場合、フローが一方向でシンプルな場合(たとえばフォーム入力をCRMに投稿するウェブフックなど)、あるいはプロトタイピング中で接続を捨てる予定がある場合です。

デフォルトでポイントツーポイントにすることが問題なのです。なぜならそれがアーキテクチャになってしまう道だからです。私たちが好む経験則があります。三つ目のシステムが、すでに他の二つが共有しているデータを必要とした瞬間、ハブは元が取れます。その点を過ぎると、各フローにどれだけの鮮度が必要かを決めること、これはリアルタイム対バッチ:レベニューデータの鮮度が重要になるときのテーマですが、それはハブが偶然にではなく意図的に行わせてくれるフローごとの選択になります。

毛玉をほどく

すでに毛玉を抱えているなら、一晩でそれを引き剥がすことはできません。うまくいく道筋は次の通りです。

1. 既存のすべての統合とそれが触れるフィールドを棚卸ししましょう。ほとんどのチームは、想定していたよりも多く、時にははるかに多くのものを見つけます。
2. 共有層を立ち上げ、最も価値の高いシステム・オブ・レコードを最初に接続しましょう。通常はCRMです。
3. 一度に一つのフローをハブ経由にリダイレクトし、ハブ版が検証された後にのみ直接リンクを廃止しましょう。
4. 方針として新しいポイントツーポイントリンクを凍結し、ほどいている間に毛玉が成長するのを止めましょう。

これはスプレッドシートからの移行を生き延びられるものにするのと同じ漸進的な規律です。水を止めずに配管を変えるのです。

重要なポイント

• 直接統合はツール数の二乗で成長します。ハブはツール数に比例して成長します。その差は10番目のツールあたりで現れます。
• 同期は構築が安価です。高くつくのは、それらのうち3つを静かに壊すあらゆるフィールド名の変更です。
• 本物の共有層はエンティティを一度だけ解決し、バージョン管理されたスキーマを公開し、書き戻します。真ん中にあるウェアハウスは同じものではありません。
• 2つか3つのシンプルで安定した接続であれば、直接同期で問題ありません。問題は直接同期がデフォルトになることです。
• 一度に一つのフローを移行し、その間新しい直接リンクを凍結しましょう。

共有データ層は、あなたと戦うスタックと、複利的に積み上がるスタックの違いであり、それはRevnewoのようなレベニューオーケストレーションプラットフォームが提供するために構築された基盤です。もしあなたの統合数が増え続けているなら、ハブが最初にどのリンクを崩壊させるかをマッピングする価値があります。