O mito do conector CDP

Em uma demonstração recente do CDP da qual participei, um cliente nervoso perguntou ao fornecedor se ele tinha um conector para o Salesforce Sales Cloud. O vendedor respondeu afirmativamente, e o cliente deu um suspiro de alívio. Mas a verdade é que a maioria dos fornecedores de plataforma de dados do cliente (CDP) tem conectores empacotados decepcionantes. Leia sobre por que isso acontece e o que você pode fazer sobre isso.

Um pouco de história: A corrida dos 'portlets' corporativos

Esse encontro me lembrou a era do “portal empresarial”. Por favor, permita-me enquanto olho para o final dos anos 2000 e início de 2010 - uma época que a maioria dos clientes e fornecedores gostaria de esquecer, mas que ainda traz lições hoje.

Os portais corporativos deveriam fornecer uma interface única e conveniente para uma variedade potencialmente ampla de aplicativos corporativos, exibidos como blocos separados em uma tela em um motivo de painel. A tecnologia subjacente a esses blocos individuais tinha muitos nomes, mas, por enquanto, vamos chamá-los de “portlets”.

Rapidamente ficou claro que os programas de portal eram fundamentalmente projetos de integração altamente complexos, então as empresas buscaram naturalmente alavancar o código do conector pré-fabricado. Os fornecedores responderam com catálogos de portlets, e uma corrida armamentista começou. “Temos 250 portlets”, gabava-se um fornecedor.

Esses portlets variam drasticamente em proveniência, suporte, usabilidade, desempenho, segurança e (crucialmente) fundamentos técnicos. Um “portlet” era tipicamente uma instância de referência de algum código Java ou C# que alguém escreveu para uma única implementação de cliente. Na maioria das vezes, o código precisava ser revisado, às vezes do zero.

Os fornecedores responderam - não injustamente - que os problemas geralmente se originavam em como os sistemas remotos eram configurados, e não na própria plataforma do portal. Talvez sim, mas as empresas acabaram se cansando dos portlets. Em meio a outras mudanças de tecnologia e negócios no mundo digital, a tecnologia de plataforma de portal gradualmente saiu de moda.

A nova corrida de conectores CDP

Avançando para hoje, o mundo está começando a entender os CDPs como ambientes de integração (entre outras coisas). Todas as equipes de seleção de CDP com as quais trabalhamos se esforçam para encontrar fornecedores com conectores pré-construídos para corresponder às suas plataformas incumbentes. No entanto, quase todas as implementações de CDP encontram desenvolvedores caros modificando ou reescrevendo significativamente esses conectores.

Os fornecedores de CDP aparentemente estão sucumbindo às pressões que seus irmãos de portais sofreram. Se os clientes valorizam um catálogo diversificado de conectores, então, como fornecedor de CDP, você deve exibir muitos deles, prontos ou não. Nas demos do CDP, os conectores aparecem na tela como blocos organizados (com o logotipo da plataforma conectada aparecendo de forma proeminente) que você pode arrastar — quase como portlets!

Bem, não tão rápido. Assim como os portlets, os conectores do fornecedor CDP podem resultar simplesmente da saída de uma única implementação. Mais importante, em alguns casos, um único conector não pode abordar a complexidade da plataforma martech na outra extremidade.

Considere o Salesforce Sales Cloud, mencionado acima. A plataforma sofre de um modelo de objeto problemático que a maioria dos licenciados distorce ou estende fortemente. Pode ser como conectar-se a um polvo muito zangado. E o Salesforce não está sozinho aqui. Em tais situações, o conector de um fornecedor de CDP pode fornecer apenas a estrutura básica e deixar o restante para o desenvolvedor.

O inimigo somos nós?

Os portais desapareceram por outro motivo. Se os olhos são as janelas da alma, os portais eram as janelas das entranhas da empresa. Um portal era tão útil quanto os aplicativos subjacentes. Freqüentemente, esses aplicativos eram confusos, careciam de modelos comuns de conteúdo e metadados, empregavam diversos regimes de controle de acesso, exibiam diferentes modelos de UX e, às vezes, expunham dados de baixa qualidade.

Na minha empresa, vemos um fenômeno semelhante com os CDPs. Dependendo de como você define o escopo de um esforço de CDP (e diferentes padrões estão surgindo aqui), o CDP pode expor a imaturidade de seu regime mais amplo de gerenciamento de dados do cliente - mais uma razão para combinar qualquer CDP potencial com sua arquitetura de dados mais ampla.

Vá mais fundo: como identificar e organizar dados com um novo CDP

Fique atento aos fornecedores de CDP que afirmam ter diversos catálogos de conectores

Como sempre, prevenido vale por dois. Primeiro, reconsidere o excesso de peso de um fornecedor que afirma ter catálogos de conectores que correspondem bem à sua pilha. Entre outras razões, simplesmente mover arquivos CSV pode resolver muitos casos de uso (não em tempo real). Quando você precisa de conectores integrados, a experiência de integração específica torna-se útil, mas não protege inerentemente contra um desenvolvimento substancial no futuro. A chave é descobrir o quanto desenvolvimento.

Esperançosamente, você está seguindo um processo ágil de seleção de CDP que termina com um concurso competitivo e uma prova de conceito (PoC) mais técnica com um ou dois finalistas. Um PoC é um ótimo ambiente para testar alguns conectores essenciais. Você então entenderá o nível de esforço para revisar quando necessário - e isso pode ser frequente.

Assim como seus predecessores de fornecedores de portais, os fornecedores de CDP prometem pacotes de “início rápido” para acelerar uma implementação inicial. Não acredite. Mais uma vez, alguns atrasos podem resultar do tempo que você precisará para colocar seus próprios dados em ordem, mas também posso garantir que alguém fará o desenvolvimento do conector, e esse trabalho é medido em trimestres, não em meses. Orçamento seus recursos em conformidade.