Os sistemas ao redor do Salesforce

🌐 Também em 28 idiomas

English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagem gerada com IA

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês

Módulo 3 de 6 do capítulo Entendendo os dados corporativos, capítulo 4 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Os tipos de dados corporativos · Próximo: Desenhe o panorama de sistemas

A pergunta que este módulo responde: O que cerca o Salesforce, e que papel cada sistema desempenha?

O último módulo classificou os dados. Agora quero colocá-los em algum lugar, e é aqui que os arquitetos Salesforce se complicam. Conhecemos o Salesforce, então dados de cliente significam Conta, dados de pedido significam Pedido, documentos significam Arquivos, análise significa Relatórios. Mas a empresa não comprou o Salesforce para substituir tudo o mais que possui. Pode haver um ERP cuidando de finanças e do atendimento de pedidos, um data warehouse com anos de histórico, uma plataforma de integração, um provedor de identidade, sistemas de parceiros, uma plataforma de eventos, uma plataforma de MDM, e o Data 360 conectando vários deles. O trabalho não é decorar tecnologias. É entender qual é o trabalho de cada sistema.

Não comece pelo nome do produto

“Temos SAP” não me diz o bastante. Nem Snowflake, MuleSoft, Tableau ou Data 360. Quero saber o que aquele sistema faz nesta arquitetura: de que dados é dono, o que lê, o que altera, quem o usa, o que depende dele, o que acontece quando ele cai. Duas empresas podem ter exatamente os mesmos produtos e arquiteturas completamente diferentes.

Então rotulo os sistemas pelo papel. Quatro papéis cobrem a maior parte:

• Sistema de registro: onde a versão com autoridade de algo é mantida.
• Sistema de engajamento: onde as pessoas fazem o trabalho.
• Sistema de referência: aonde um sistema vai buscar informação de que precisa, mas da qual não é dono.
• Sistema de insights: onde os dados se juntam para medir, analisar e prever.

Uma plataforma pode desempenhar vários papéis, e os papéis variam por dado. O Salesforce pode ser o sistema de registro dos casos, o sistema de engajamento dos atendentes e um consumidor dos dados de produto de que o ERP é dono. Então, quando alguém disser “o Salesforce é o nosso sistema de registro”, termine a frase: sistema de registro de quê?

O ERP: o back office tem gravidade

O ERP é o sistema que você vai encontrar ao lado do Salesforce com mais frequência, cuidando de finanças, estoque, compras, atendimento de pedidos e faturamento. O padrão do módulo 1 (clientes e produtos entram, pedidos saem) significa que o ERP é dono dos produtos, mas os vendedores ainda precisam deles no Salesforce. Tudo bem: traga-os. Mas copiar dados não transfere a propriedade. Uma cópia não é autoridade.

Minha posição: dados de propriedade do ERP são lidos localmente e gravados sob controle. Os usuários do Salesforce recebem os dados onde trabalham, mas o Salesforce não pode alterar aquilo de que o ERP é dono. E torno isso visível no esquema: os campos do ERP levam um prefixo erp_, como erp_Product_Number__c, para que qualquer pessoa lendo o objeto saiba quem é dono de cada campo e tenha cuidado ao alterá-lo. O prefixo não impõe nada; as permissões, a validação e o padrão de integração fazem isso. Ele comunica a intenção, e é o mapa de autoridade tornado visível.

O data warehouse, o data lake e o lakehouse

Sistemas operacionais tocam o negócio; sistemas analíticos ajudam a entendê-lo. “Mostre minhas oportunidades abertas” é um relatório do Salesforce. “Mostre cinco anos de vendas, atendimento de pedidos, devoluções, casos, estoque e finanças em todos os canais” é outro problema.

Você vai encontrar três tipos de repositório analítico. Um data warehouse guarda dados estruturados preparados para análise. Um data lake guarda muito mais dados em mais formatos, muitas vezes brutos. Um lakehouse combina os dois: armazenamento no estilo do lake com análise no estilo do warehouse. Conheça-os, porque aparecem nos panoramas. Mas minha experiência é que lakehouses e data mesh ainda são nicho em projetos Salesforce. O panorama típico é CRM, ERP, um data warehouse e uma camada de integração, com outras plataformas onde o negócio realmente precisa delas. Aprenda a arquitetura; não corra atrás do vocabulário.

A análise vive onde os dados vivem

Esta é uma das minhas posições mais firmes: onde a análise vive segue onde os dados vivem. Se o relatório só precisa de contas, oportunidades e vendedores, está tudo no núcleo: relatórios e dashboards padrão. Aí o negócio pede para acrescentar as faturas do ERP. Depois o custo do produto. Depois cinco anos de pedidos do data warehouse. Depois a atividade no site. Em algum momento, arrastar tudo isso para o CRM operacional só para fazer relatórios deixa de fazer sentido. Quando outros repositórios de dados entram, uma plataforma de análise passa a ser necessária: o Tableau (incluindo o Tableau Next, construído sobre o Data 360), ou o CRM Analytics onde ele já é usado. Ela é essencial quando os dados do Salesforce são combinados com um data warehouse. O requisito não só ficou mais complicado; o panorama mudou o lugar onde a pergunta deve ser respondida. Então nunca começo com “qual ferramenta de análise?” Começo com onde estão os dados?

Pergunto a mesma coisa aos candidatos ao CTA: “Qual dos meus diagramas resolve isso lindamente? O panorama.” Se está tudo no núcleo, use relatórios. Se você tem dados em outros repositórios, quero ver uma plataforma de análise. O panorama responde à pergunta dos relatórios antes que alguém abra um criador de relatórios. (Os nomes dos produtos mudam; o capítulo de Data 360 cobre onde a análise da Salesforce está hoje.)

MDM: quem é este cliente, de verdade?

Agora suponha que as informações de cliente vivem no Salesforce, no ERP, no e-commerce, numa plataforma de fidelidade e num sistema de parceiro, e cada um acha que sabe quem é o cliente. É aí que entra o gerenciamento de dados mestres (MDM): estabelecer e governar a identidade com autoridade dos dados-chave entre sistemas. Mas MDM não é “um banco de dados mestre de clientes”. As perguntas difíceis são qual sistema pode criar o cliente, de quais atributos cada sistema é dono, como as duplicatas são encontradas, qual identificador sobrevive, e o que acontece quando os sistemas discordam. O capítulo 6 é todo sobre isso. Aqui, reconheça o papel: se existe uma plataforma de MDM, ela pode ser uma autoridade crítica entre o Salesforce e o resto da empresa.

A camada de integração e os eventos

Conecte cada sistema diretamente a todos os outros, e o panorama vira espaguete rapidinho. É por isso que as empresas têm uma camada de integração: um ESB (enterprise service bus) ou um iPaaS (plataforma de integração como serviço). O MuleSoft é o que você mais vai encontrar em panoramas Salesforce. Ele faz a mediação, para que cada aplicação não precise entender todas as outras.

Mas uma caixa do MuleSoft no meio não torna a integração boa. Ainda quero saber o que passa por ela e o que não passa, quem transforma os dados, quem é dono do contrato, o que acontece quando o destino está fora do ar, se é síncrona ou assíncrona, e como sabemos que uma mensagem teve sucesso. O curso Integration Architect vai fundo; aqui, reconheça-a como um papel próprio.

E nem toda integração é o sistema A chamando o sistema B. Às vezes algo acontece (um pedido é criado, uma entrega muda de status, um caminhão entra numa região), um evento é publicado, e quem estiver interessado reage. Eventos em movimento também têm infraestrutura: as capacidades de eventos do próprio Salesforce, um barramento de eventos corporativo, outras mensagerias. Desenhe os mecanismos que carregam os dados, não só os bancos de dados.

O sistema que os desenvolvedores esquecem: identidade

Há uma caixa que sempre quero no panorama e na qual os desenvolvedores raramente pensam: o provedor de identidade. Os desenvolvedores entram direto nos seus sandboxes com usuário e senha, então a identidade fica invisível durante a construção. Aí chegam o UAT ou a produção, e de repente aparece o single sign-on da empresa para os funcionários, talvez um segundo provedor para os parceiros, login social para os clientes. A identidade sempre fez parte da arquitetura. O desenvolvedor só não a tinha visto ainda.

Um provedor de identidade (IdP) é o sistema que autentica um usuário e estabelece a identidade em que o Salesforce confia. Ele pertence ao panorama desde o primeiro dia, mesmo que seja configurado mais tarde no pipeline de releases, porque quem consegue entrar decide quem consegue chegar aos dados.

Há também um detalhe prático: a configuração de identidade é implantável, mas não por completo. A configuração de single sign-on SAML e os provedores de autenticação são tipos da Metadata API, então viajam pelo pipeline (SamlSsoConfig (opens in a new tab), em inglês). Mas os segredos de consumidor dos provedores de autenticação não são mais devolvidos nas respostas da Metadata API (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab), em inglês), e os certificados normalmente diferem por ambiente. Planeje para as partes que viajam e para as que não viajam.

Click to enlarge

Leia o panorama como papéis, não como logotipos: o que cada sistema possui, lê ou decide.

Onde fica o Data 360?

O Data 360 levanta uma boa pergunta de desenho. Eu o coloco à direita, abaixo do ESB ou do MuleSoft. O motivo são as conexões dele: os usuários nunca se conectam a ele diretamente, enquanto ele se conecta diretamente a muitos sistemas de back-end. Então ele pertence ao encanamento de dados, onde essas linhas ficam curtas, não lá fora com os usuários. Desenhe-o como mais uma tela em que as pessoas entram, e você está contando a história errada.

Administradores e equipes de dados abrem, sim, as telas do Data 360, mas essas telas ficam na org, no núcleo. O tenant que faz o trabalho, com seus dados e seu processamento, roda fora do núcleo. É por isso que digo que ele é próximo ao núcleo (near-core): gerenciado no núcleo, hospedado fora do núcleo (o módulo 1 explica os termos). O desenho segue o tenant: ele fica com o encanamento, com uma linha de volta para a org que o gerencia.

O que ele faz, nas palavras da Salesforce, inclui o zero copy: uma tecnologia de federação de dados que permite a uma empresa acessar e consultar dados sem copiá-los (Zero Copy (opens in a new tab), em inglês). As capacidades e os conectores mudam rápido, então o capítulo de Data 360 os cobre direito em vez de transformar este módulo num tour de produto.

Leia o panorama como responsabilidades

Quando olhar para um panorama, não leia os logotipos; leia as responsabilidades. O ERP: do que é dono? O data warehouse: a que perguntas responde? A plataforma de integração: o que move? O IdP: quem autentica? O MDM: que identidade governa? O Data 360: o que conecta, e para quê? O Salesforce: pelo que ele é realmente responsável? Quando você consegue responder a isso, as caixas passam a significar algo, e as setas entre elas ficam muito mais interessantes. A seguir, vamos desenhá-las de forma deliberada.

O que um arquiteto decide aqui

• Que papel cada sistema desempenha, além do nome do produto.
• Qual sistema tem autoridade sobre cada conjunto de dados importante, e onde o Salesforce guarda só uma cópia local.
• Se os dados de propriedade do ERP estão disponíveis no Salesforce com as gravações controladas, e como essa propriedade aparece no esquema.
• Onde a análise pertence, com base em onde os dados vivem.
• Onde ficam no panorama a identidade, a integração, os eventos e a autoridade sobre os dados mestres.

Um panorama com dez retângulos não é arquitetura; é inventário. A arquitetura começa quando você consegue apontar para cada retângulo e dizer por que ele está ali, do que é dono, quem o usa, do que o Salesforce precisa dele, e o que quebra se você entender mal o papel dele.

Para saber mais

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (em inglês), consultado em 2026-10-14.
• Salesforce Help, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (em inglês), consultado em 2026-10-14.
• Salesforce, Zero Copy (opens in a new tab) (página de produto, em inglês), consultado em 2026-10-14.
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab), martinfowler.com (em inglês), 2019.