공유 데이터 레이어가 점대점 통합을 이기는 이유

모든 수익 팀은 결국 같은 갈림길에 도달합니다. 새로운 도구가 기존 도구의 데이터를 필요로 합니다. 예를 들어 세일즈 인게이지먼트 플랫폼이 CRM에서 계정 등급을 필요로 한다고 해봅시다. 빠른 답은 직접 동기화입니다. 둘을 연결하고, 몇 개의 필드를 매핑하고, 출시하는 것입니다. 그 빠른 답이야말로 스택이 관리 불가능해지는 방식이기도 합니다. 열두 개의 도구를 갖게 될 즈음이면, "그냥 연결하자"는 반사적 행동이 아무도 완전히 이해하지 못하고 아무도 건드리고 싶어하지 않는 점대점 통합의 뒤엉킨 실타래를 만들어냈을 것입니다.

대안은 도구들을 서로 직접 연결하는 대신, 모든 시스템이 읽고 쓰는 공유 데이터 레이어입니다. 이는 현대 수익 플랫폼을 위한 레퍼런스 아키텍처에서 핵심을 이루는 결정 중 하나이며, 통합 개수가 커지기 전까지는 그 트레이드오프가 명확하지 않기 때문에 그 자체로 이해할 가치가 있습니다.

수학이 빠르게 추해진다

점대점은 순전히 조합론적인 이유로 형편없이 확장됩니다. n개의 시스템이 있으면 가능한 직접 연결의 개수는 n(n-1)/2입니다. 세 개의 도구는 최대 세 개의 통합만 필요하며, 이는 아무것도 아닙니다. 열 개의 도구는 최대 마흔다섯 개가 필요합니다. 그리고 각 통합은 단순한 파이프가 아닙니다. 필드 매핑, 동기화 일정, 변환, 그리고 실패 모드의 집합입니다. 이것을 마흔다섯으로 곱하면 어떤 팀도 깨끗하게 유지할 수 없는 유지보수 표면이 생깁니다.

공유 레이어는 이 수학을 바꿉니다. 각 시스템은 허브와 한 번만 통합하므로, n개의 시스템에는 n개의 연결만 필요합니다. 성장은 제곱에서 선형으로 바뀝니다. 더 중요한 것은 시맨틱스가 한 곳에 존재한다는 점입니다. "MQL"이나 "활성 기회"가 무엇을 의미하는지에 대해 마흔다섯 개의 약간씩 다른 의견 대신, 모든 도구가 물려받는 하나의 표준 정의가 존재합니다.

직접 동기화의 초기 구축은 정말로 빠릅니다. 숨겨진 비용은 변경 비용입니다. CRM이 필드 이름을 바꾸면, 그것을 건드리는 서너 개의 통합이 조용히 깨지고, 여러분은 이사회 덱의 잘못된 숫자를 통해 그 사실을 알게 됩니다. 우리는 그런 회의에 앉아본 적이 있습니다. 즐거운 경험이 아닙니다.

"공유 데이터 레이어"가 실제로 의미하는 것

공유 데이터 레이어는 누구나 쿼리할 수 있는 데이터베이스 이상의 것입니다. 세 가지 속성이 이를 공유된 쓰레기장과 구분 짓습니다.

표준 엔티티. 계정, 연락처, 기회, 수익 이벤트는 안정적인 식별자를 가진 단일 레코드로 해소되고 중복 제거됩니다. 엔티티 해소는 모든 도구에서 재구현되는 대신 여기서 한 번만 일어납니다. 이는 전적으로 깨끗한 입력값에 달려 있으며, 이것이 RevOps 데이터 위생이 사후 대책이 아니라 전제조건인 이유입니다.

명시적인 스키마. 모든 소비 시스템은 문서화되고 버전이 관리되는 스키마를 기준으로 읽습니다. 스키마가 변경되면 소비자는 통보받습니다. 프로덕션에서 발견하지 않습니다.

양방향 흐름. 레이어는 읽기 전용이 아닙니다. 중앙에서 계산된 통찰은 규율 있는 라이트백 계층을 통해 시스템 오브 액션으로 다시 기록되므로, 허브는 양쪽 방향 모두에서 진실의 원천입니다.

이 세 가지가 없다면, 여러분이 가진 것은 우연히 중앙에 자리 잡은 데이터 레이크일 뿐이며, 이는 추가 단계를 거쳐 점대점의 혼란을 재현하는 것입니다.

한 시나리오에서 이것이 어떻게 보이는가

한 중견 SaaS 기업이 CRM, 마케팅 자동화 플랫폼, 제품 분석 도구, 청구 시스템, 그리고 웨어하우스를 운영합니다. 이 팀은 마케팅 참여도, 제품 사용량, 계정 회사 정보를 혼합한 리드 스코어링을 원합니다.

점대점 방식: 마케팅 자동화가 CRM에 동기화됩니다. 제품 분석이 참여도 스코어링을 위해 마케팅 자동화에 동기화됩니다. 청구가 갱신 플래그를 위해 CRM에 동기화됩니다. 웨어하우스는 이 세 가지에서 별도의 일정으로 데이터를 가져옵니다. 리드 스코어는 부분적인 뷰로부터 마케팅 자동화에서 계산되고, 그다음 CRM에서 계산된 다른 스코어로 덮어씌워집니다. 두 개의 스코어가 존재하고, 서로 일치하지 않으며, 담당자들은 한 달 안에 둘 다 신뢰하지 않게 됩니다.

공유 레이어 방식: 네 개의 시스템 모두 허브에 데이터를 공급합니다. 엔티티 해소는 제품 계정, 청구 계정, CRM 계정을 하나의 표준 계정으로 이어붙입니다. 스코어는 완전한 그림 위에서 한 번만 계산되고, CRM과 마케팅 플랫폼에 동일하게 다시 기록됩니다. 하나의 스코어가 있고, 모든 입력값이 한 곳에 있기 때문에 설명 가능합니다.

두 번째 설정만이 누구든 그 스코어를 신뢰할 수 있는 유일한 방식입니다. 지표에 대한 신뢰는 그 뒤에 단일한 계보가 있는가에 달려 있기 때문입니다.

점대점이 괜찮은 경우

예외가 없는 아키텍처 조언은 이데올로기입니다. 직접 통합이 올바른 선택인 경우는 두세 개의 안정적인 시스템만 있고 더 추가할 계획이 없을 때, 흐름이 단방향이고 단순할 때(예를 들어 폼 제출을 CRM에 게시하는 웹훅), 또는 프로토타이핑 중이며 그 연결을 버릴 것으로 예상할 때입니다.

기본값으로서의 점대점이 문제입니다. 그것이 바로 아키텍처가 되어버리는 방식이기 때문입니다. 우리가 좋아하는 경험칙이 있습니다. 세 번째 시스템이 이미 다른 두 시스템이 공유하는 데이터를 필요로 하는 순간, 허브는 그 값어치를 합니다. 그 지점을 넘어서면, 각 흐름이 얼마나 신선해야 하는지 결정하는 것, 즉 실시간 대 배치: 수익 데이터 신선도가 중요한 순간의 주제는 허브가 여러분에게 우연이 아니라 의도적으로 내릴 수 있게 해주는 흐름별 선택이 됩니다.

뒤엉킨 실타래 풀기

이미 뒤엉킨 실타래를 가지고 있다면, 하룻밤 사이에 뜯어낼 수는 없습니다. 효과가 있는 경로는 다음과 같습니다.

1. 기존의 모든 통합과 그것이 건드리는 필드를 목록화하십시오. 대부분의 팀은 예상보다 많이, 때로는 훨씬 많이 발견합니다.
2. 공유 레이어를 구축하고 가장 가치가 높은 시스템 오브 레코드부터 연결하십시오. 보통 CRM입니다.
3. 한 번에 하나의 흐름을 허브를 통해 리다이렉트하고, 허브 버전이 검증된 후에야 직접 연결을 폐기하십시오.
4. 새로운 점대점 연결을 정책적으로 동결해서, 이를 풀어가는 동안 실타래가 더 이상 커지지 않게 하십시오.

이는 스프레드시트에서 벗어나는 마이그레이션을 견딜 만하게 만드는 것과 동일한 점진적 규율입니다. 물을 끄지 않고 배관을 바꾸는 것입니다.

핵심 요약

• 직접 통합은 도구 개수의 제곱에 비례해 성장합니다. 허브는 도구 개수에 비례해 성장합니다. 그 차이는 열 번째 도구 즈음부터 나타납니다.
• 동기화는 구축하기 저렴합니다. 비용이 많이 드는 부분은 필드 이름이 바뀔 때마다 그중 세 개가 조용히 깨진다는 것입니다.
• 진짜 공유 레이어는 엔티티를 한 번만 해소하고, 버전이 관리되는 스키마를 발행하며, 다시 기록합니다. 중간에 있는 웨어하우스는 같은 것이 아닙니다.
• 두세 개의 단순하고 안정적인 연결은 직접 동기화로도 괜찮습니다. 문제는 직접 동기화가 기본값이 될 때입니다.
• 한 번에 하나의 흐름을 마이그레이션하고, 그 작업을 하는 동안 새로운 직접 연결을 동결하십시오.

공유 데이터 레이어는 여러분과 싸우는 스택과 복리로 쌓이는 스택 사이의 차이이며, Revnewo와 같은 수익 오케스트레이션 플랫폼이 제공하도록 구축된 토대입니다. 여러분의 통합 개수가 계속 늘어나고 있다면, 허브가 가장 먼저 무너뜨릴 연결이 무엇인지 매핑해볼 가치가 있습니다.