現代のレベニュープラットフォームのためのリファレンスアーキテクチャ

ほとんどのレベニュースタックは、設計されたものではありません。積み重なってきたものです。まずCRMが導入され、次にマーケティングオートメーション、セールスエンゲージメントツール、CPQシステム、ウェアハウス、3社のエンリッチメントベンダー、そして最後にBI層がボルト留めされます。それぞれが顧客に関する独自のコピーを保持し、「アカウント」とは何かについて独自の考えを持ち、案件がいつ本物になるかについて独自の見解を持っています。スタックは技術的には機能します。しかしアーキテクチャとしては混乱状態です。新しい統合が加わるたびに、真実がずれる場所がもう一つ増えるからです。

現代のレベニュープラットフォームは、重心を逆転させます。CRMはハブであることをやめます。データがハブになり、アプリケーションはそこに接続され、必要に応じて入れ替え可能な参加者になります。以下は、そのモデルのためのリファレンスアーキテクチャです。各層、層間の契約、そしてそれが価値を複利的に積み上げるか、統合負債の下で崩壊するかを決める一握りの決定について説明します。リンク先の記事では、それぞれの層をさらに深く掘り下げています。

5つの層

耐久性のあるレベニューアーキテクチャは、関心事を5つの層に分離します。それぞれが狭い役割と、隣接する層との明確なインターフェースを持ちます。

取り込みと接続性。システム・オブ・レコード(CRM、マーケティングオートメーション、プロダクト分析、請求、サポート、パートナーシステム)からデータを引き出し、押し込むコネクタです。設計上の目標は冪等性とリプレイ可能性です。すべてのソースは重複を生むことなく再取り込みできるべきであり、すべての同期失敗は、誰かが土曜日に手作業でクリーンアップすることなく回復可能であるべきです。

統合データ層。アカウント、コンタクト、案件、活動、レベニューイベントの、バージョン管理された唯一の表現です。エンティティ解決はここで行われます。正規の定義もここに存在します。この層が欠けていると、各チームがそれを下流のツールの中でそれぞれ、しかも不完全な形で再構築し、それぞれの再構築が互いに食い違うことになります。

モデリングとインテリジェンス。アトリビューション、スコアリング、ヘルス指標、フォーキャスト、次善のアクションロジックはすべて、統合データの上で計算されます。ここでイベントが意思決定に変わります。

書き戻しとアクティベーション。洞察を、人々や自動化が実際に働く場所、すなわちCRM内のタスク、広告プラットフォーム内のオーディエンス、Slack内のアラートへと戻す経路です。

ガバナンスと可観測性。アクセス制御、リネージ、データ品質モニタリング、監査です。これは他の4つの層の横に並ぶのではなく、それらを横断します。

規律は境界線にあります。モデリングロジックが取り込み層に漏れ出したり、ガバナンスがアクティベーションの出荷後に後付けされたりすると、各層は独立して置き換え可能ではなくなります。アーキテクチャはコンクリートのように固まり、あなたは元の積み重ね状態に逆戻りします。

データ層がすべてを決める

最も重大な決定は、本物の共有データ層を持つか、それともポイントツーポイント同期の網を持つかです。ポイントツーポイントは初期段階では速く感じられます。ツールAとツールBを接続して出荷すればよいのです。しかし接続数は二次関数的に増加します。n個のシステムには最大でn(n-1)/2個の統合が必要になり得て、それぞれが独自のフィールドマッピング、同期ケイデンス、失敗モードを持ちます。10個のシステムがあれば、それは最大45本の脆弱なリンクと、それらすべての仕組みを知っている運用担当者一人ということになりかねません。

共有データ層は、それをn個の接続に圧縮します。各システムはハブと一度だけ統合し、エンティティ解決と正規の定義はまさに一箇所にのみ存在します。このトレードオフについてはなぜ共有データ層がポイントツーポイント統合に勝るのかで詳しく解説していますが、アーキテクチャ上の含意はシンプルです。データ層は荷重壁です。それ以外はすべてリノベーションにすぎません。

そしてその壁は、そこに流れ込むものと同じだけの健全性しか持ちません。ソースデータに一貫性がなければエンティティ解決は崩壊します。だからこそRevOpsのデータハイジーンは、雑用として片付けられるのではなく、アーキテクチャの議論に含まれるべきなのです。

層間の契約

各層は明示的な契約、すなわち黙って変わることのないスキーマとセマンティクスを通じて対話します。組織再編やベンダーの入れ替えを生き延びるプラットフォームは、これらを一級市民として扱います。

スキーマ契約は、アカウントや案件の形状を定義します。上流のフィールドが消えたとき、下流のモデルは大きな音を立てて壊れるべきです。その代わりに起きるのは、静かに間違った数字が取締役会資料に紛れ込むことです。

セマンティック契約は意味を定義します。「作成されたパイプライン」は、それがCRMから来たものであれ、プロダクトシグナルから推測されたものであれ、同じ意味を持たなければなりません。アトリビューションスパインは、大部分がタッチポイント全体にわたってセマンティック契約を強制するための取り組みです。

鮮度契約はタイムリネスを定義します。すべての指標がリアルタイムである必要はなく、それを強制することはコストが高く、しばしば逆効果です。その判断方法についてはリアルタイム対バッチ:レベニューデータの鮮度が重要になるときで扱っています。

契約こそが、プラットフォームを書き直すことなくベンダーを置き換えることを可能にするものです。アプリケーションは契約を満たす何かになり、より良いものが登場すればそれから離れることができます。

2つのトポロジーの決定

ウェアハウスネイティブかアプリネイティブか。インテリジェンスは既存のウェアハウスの上で動くのか、それともベンダーのブラックボックスの中で動くのか。これはコンピュート、生データ、拡張性を誰が所有するかを決め、後から覆すのは困難です。このトレードオフについてはウェアハウスネイティブ対アプリネイティブのレベニューツールで解説しています。

エッジがどれだけ開かれているか。APIファーストなプラットフォームは、すべての機能をプログラム的に公開します。つまり、書き戻し層やカスタムのアクティベーション経路は自分たちで拡張できるということです。データをクリーンに読み込むことは半分にすぎません。それを安全に書き戻すことがもう半分であり、書き戻し層はそれ自体の規律に値します。ループを生み出したり、担当者が1時間前に行った編集を上書きしたりすることなく、洞察をアクションシステムにルーティングすることです。

これらすべての下で、ガバナンスとアクセス制御が、統合されたシステムが資産になるのか負債になるのかを決めます。レベニューデータを統合することは、あらゆる権限の決定の重みを増します。なぜなら、間違いが起きたときの被害範囲は今やスタック全体だからです。

全体を通してどう読み解くか

ソースは統合層に流れ込みます。インテリジェンスは一度だけ計算されます。洞察は人々が働くシステムに書き戻されます。ガバナンスは経路全体を監視します。各層は置き換え可能であり、各契約は明示的です。そのため、システムを追加するほどスタックはより価値を増します。なぜなら、新しいソースはすべて、別のサイロを生むのではなく、同じ正規のモデルを豊かにするからです。

これがオーケストレーションと統合演劇との違いです。オーケストレーションとは、プラットフォームがバイヤージャーニー全体にわたって協調した意思決定を行うことを意味します。統合演劇とは、データがツール間を移動する一方で、人間がスプレッドシートの中で意味をつなぎ合わせ続けることを意味します。Revnewoのようなプラットフォームがこの層状の、データ中心のモデルを軸に構築されているのは、私たちの経験では、それが衰退するのではなく複利的に積み上がる唯一のパターンだからです。

重要なポイント

• データを中心に据えましょう。CRMは統合層を取り巻く複数の参加者の一つになり、そのどれもが入れ替え可能です。
• 狭い役割を持つ5つの層:取り込み、統合データ、モデリング、書き戻し、ガバナンス。境界線をクリーンに保たなければ、各層は置き換え可能ではなくなります。
• 共有データ層は二次関数的な統合負債を線形の接続性に変え、正規の定義を一箇所にまとめます。
• 明示的なスキーマ契約、セマンティック契約、鮮度契約こそが、ベンダーを置き換え可能にするものです。
• ウェアハウスネイティブかアプリネイティブか、そしてAPIがどれだけ開かれているかは、所有権と拡張性を何年にもわたって形作ります。意図的に決めましょう。

もしあなたのスタックが設計されたのではなく積み重なってきたものなら、これら5つの層に照らしてマッピングすることは安価な第一歩です。それはまた、Revnewoのようなレベニューオーケストレーションのアプローチが、あなたが本当に望むアーキテクチャに適合するかどうかを判断する有用なレンズでもあります。