Salesforce é um sistema entre muitos

🌐 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 1 de 6 do capítulo Entendendo os dados corporativos, capítulo 4 do curso Data Architect. Cada módulo se sustenta sozinho. Próximo: Os tipos de dados corporativos

A pergunta que este módulo responde: Por que um arquiteto de dados desenha o que cerca a org antes de projetar a org?

Quando ensino candidatos a CTA, a lição de casa depois do primeiro dia é sempre a mesma. Leia o cenário. Comece o panorama de sistemas numa tela em branco. Só então arrisque o modelo de dados. Não os objetos, não as integrações em detalhe: o panorama. Quero ver o que cerca o Salesforce antes de decidirmos o que pertence a ele.

É uma mudança de perspectiva para muitos profissionais Salesforce. Se você passou a carreira como administrador ou desenvolvedor, o Salesforce é naturalmente o centro do seu mundo. Você abre o Setup, cria objetos, constrói flows, escreve Apex e integra outros sistemas ao Salesforce. Tudo parece começar pela org. Um arquiteto precisa afastar a câmera, porque numa empresa o Salesforce é um sistema entre muitos, e com bastante frequência não é ele o dono dos dados.

Desenhe o panorama primeiro

O capítulo 2 construiu o modelo lógico, e o capítulo 3 perguntou como ele vive no Salesforce. Agora vou aumentar o problema. Antes de decidir do que o Salesforce deveria ser dono, quero entender a empresa ao redor dele. Que sistemas já existem? Onde os clientes são criados, os produtos definidos, os pedidos iniciados, as faturas geradas? Onde vive a identidade? Onde acontece a análise, onde ficam os documentos, onde está o histórico? Quais sistemas precisam dos dados do Salesforce, e de quais o Salesforce depende?

Essas perguntas mudam a arquitetura. Então começo numa tela em branco, coloco o Salesforce no meio e desenho tudo ao redor dele. O módulo 4 mostra exatamente como faço o layout. Por enquanto, a lição é simplesmente: não projete a org antes de entender o mundo em que ela vai ter de viver.

Muitas vezes o Salesforce não é o sistema de registro

Pegue uma empresa muito comum: o Salesforce mais um ERP, um sistema de gestão empresarial como SAP ou Oracle, que cuida de finanças, produtos, estoque, compras e atendimento de pedidos. Agora faça uma pergunta simples: onde vive o cliente?

Pode ser o Salesforce, o ERP ou os dois, e é aí que fica interessante. Os vendedores podem trabalhar prospects como Contas no Salesforce, enquanto o ERP emite o número oficial de cliente quando eles viram clientes pagantes. Produtos e preços? Provavelmente o ERP. Estoque? Quase nunca o Salesforce. Os pedidos podem ser capturados no Salesforce e atendidos no ERP; as faturas vêm do ERP; o atendimento vive no Salesforce; a análise está dividida entre relatórios do Salesforce e um data warehouse. De repente, nosso bonito modelo de dados do Salesforce não é o modelo de dados da empresa. É uma parte dele.

A integração que vejo de novo e de novo

A integração mais comum que vejo é assim: clientes, produtos e preços entram no Salesforce vindos do ERP, e os pedidos saem. Troque por SAP, Oracle ou qualquer outro ERP; o formato é o mesmo. O ERP é dono do golden record do cliente e do produto, então esses fluxos vêm da direita, para dentro do Salesforce. Vendas fecha o negócio no Salesforce, então o pedido começa ali e volta ao ERP para ser atendido, faturado e contabilizado.

Esses fluxos não são só integrações. Eles me dizem onde a empresa acredita que a verdade vive.

Setas de mão única me deixam nervoso

Sempre que vejo uma integração com um único fluxo, começo a ficar preocupado. No nível alto, alguém desenha uma única seta: pedidos do Salesforce para o ERP. Tudo bem. Agora olhe mais a fundo. Como posso enviar um pedido ao ERP se não conheço os clientes, os produtos ou os preços dele? O pedido precisa estar vinculado a um cliente que o ERP já tem, e cada linha precisa ser um SKU que o ERP já vende. Não posso enviar um item de linha de um produto que não existe do outro lado. Então, antes que essa seta de pedidos possa funcionar, fluxos de retorno precisam existir, correndo no sentido contrário.

Essa é a pergunta que faço a toda seta: de que esse fluxo depende? A seta de nível alto que você vê normalmente precisa de fluxos de retorno que você ainda não desenhou.

Olhe ainda mais a fundo e você encontra a viagem de volta. O Salesforce envia um pedido. E depois? Foi aceito ou rejeitado? Foi enviado, enviado em parte, cancelado? Foi faturado? Alguém no Salesforce precisa saber? Talvez não precise. Mas alguém deveria ter perguntado. Se nada volta, tudo bem. Me diga por quê.

A empresa não chegou toda de uma vez

Os panoramas ficam complicados em parte porque ninguém os construiu de uma vez. Os dados vieram em ondas. Primeiro os arquivos: registros de formato fixo, depois arquivos delimitados como o CSV. Depois os bancos de dados relacionais para dados operacionais. Depois os data warehouses para juntar tudo para análise. Depois os bancos de dados NoSQL para documentos, pares chave-valor e grafos que não cabem direitinho em tabelas. Depois os data lakes para quantidades enormes de dados brutos e semiestruturados, e os lakehouses, que combinam os dois. Os fluxos de eventos (event streams), como o Kafka ou o barramento de eventos do Salesforce, movem os dados no momento em que acontecem, em vez de em lotes noturnos. E agora a federação, em que os dados não precisam ser copiados para um só lugar antes que outra plataforma possa usá-los.

A tecnologia ainda não é o ponto. O ponto é este: a onda nova raramente faz a antiga desaparecer. Entre numa grande empresa e você vai encontrar todas ao mesmo tempo: bancos de dados relacionais, o ERP, o Salesforce, um data warehouse, um data lake, depósitos via SFTP, APIs, fluxos de eventos, a planilha que alguém ainda manda por e-mail toda sexta-feira, e aquele sistema em que todo mundo tem medo de mexer porque a pessoa que o construiu se aposentou seis anos atrás. Essa é a empresa que você está arquitetando, não a do folheto do produto.

Sistemas diferentes existem por motivos diferentes

É também por isso que nunca começo com “como colocamos todos os dados no Salesforce?” Por que eu iria querer todos lá? O Salesforce pode ser o melhor lugar para o pessoal de vendas e de atendimento trabalhar com os clientes. Isso não o torna o sistema financeiro, o data warehouse da empresa, o repositório de telemetria, o arquivo de documentos, ou a casa de cada clique, leitura de GPS e transação histórica que a empresa já produziu.

O capítulo 3 perguntou onde esses dados deveriam viver? para uma org. No nível da empresa, a mesma pergunta fica maior: às vezes o Salesforce é dono dos dados, às vezes guarda uma cópia, às vezes só uma referência, e às vezes não deveria tê-los de jeito nenhum.

Núcleo, fora do núcleo e Hyperforce

Há outra fronteira a entender: nem o “Salesforce” é um só runtime e um só banco de dados. No capítulo 3, no núcleo (on core) queria dizer onde os dados ficam: na sua mesa, nos próprios objetos da org. Aqui as mesmas palavras descrevem onde um produto roda. Você vai ouvir arquitetos usando os dois sentidos.

Historicamente, o runtime Core hospedava a maior parte da plataforma. Hoje a Salesforce descreve uma plataforma de centenas de serviços independentes orientados por metadados, com o Core continuando como o único sistema de registro dos metadados das aplicações (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), em inglês). É por isso que você vai ouvir arquitetos dizendo que uma capacidade roda no núcleo ou fora do núcleo.

Isso já importava muito antes de a plataforma se dividir em serviços. Quando pergunto a uma turma por que a Salesforce comprou a SteelBrick para cotações em vez da Apttus, a resposta que procuro é simples: a SteelBrick foi construída 100% no núcleo. Flows e triggers vivem no núcleo, então um produto construído ali ganha junto os metadados, as personalizações e a automação da plataforma. Aquele produto de cotações já deu lugar ao Revenue Cloud, mas a lição continua. Depois há o próximo ao núcleo (near-core), e o Data 360 é o exemplo que uso. O Data 360 não é núcleo. O tenant dele fica fora do núcleo: os dados e os mecanismos que os processam rodam no seu próprio lakehouse, ao lado do banco de dados relacional da org, e não dentro dele (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), em inglês). Mas as telas que você usa para configurá-lo e controlá-lo são exibidas no núcleo, na org. Então o jeito mais preciso que encontro de dizer é: gerenciado no núcleo, hospedado fora do núcleo. Nenhum dado nem processamento roda de fato no Core; a interface no Core controla o tenant fora do núcleo. E depois, claro, há tudo o que fica fora do núcleo porque nem é Salesforce.

Me importa menos decorar qual produto roda onde neste ano, porque isso muda, do que o hábito: uma fronteira pode afetar a movimentação de dados, a latência, a identidade, a integração e a residência. Então não presuma que, porque um produto diz Salesforce, seus dados ficam bem ao lado dos seus registros de Conta. Olhe para a arquitetura real.

Depois há o Hyperforce: a infraestrutura da Salesforce construída para a nuvem pública e definida como código, em vez dos seus data centers próprios tradicionais, dando aos clientes mais escolha sobre onde seus dados residem (Salesforce Hyperforce: General Information and FAQ (opens in a new tab), em inglês). Isso importa, e o módulo 5 volta a isso. Mas arquitetura de infraestrutura não é arquitetura de dados corporativos. Mover uma org para a nuvem pública não lhe diz quem é dono do cliente, onde vive o estoque, onde a análise roda, ou quais dados podem cruzar uma fronteira. O Hyperforce pode moldar algumas dessas decisões, especialmente a residência. Ele não substitui conhecer o panorama.

O panorama vem antes da caixa

Então eis o hábito. Alguém lhe entrega um cenário. Não comece a construir a solução Salesforce. Primeiro encontre os sistemas: o ERP, o provedor de identidade, o data warehouse, a plataforma de integração, os sistemas dos parceiros, os canais do cliente, os repositórios de documentos. Depois encontre os dados que se movem entre eles: clientes, produtos, pedidos, faturas, documentos, eventos, identidades. Depois pergunte quem é dono de cada um. Só então decida o que pertence ao Salesforce. Senão você está projetando uma caixa sem saber a que ela se conecta.

Click to enlarge

Passo 1 de 3: a org que projetamos, sozinha. Daqui, ela parece o mundo inteiro.

Click to enlarge

Passo 2 de 3: afaste o zoom. O Salesforce é um sistema entre muitos (o módulo 4 ensina este layout).

Click to enlarge

Passo 3 de 3: as primeiras setas. Clientes, produtos e preços entram vindos do ERP, pedidos saem: elas dizem onde a empresa acredita que a verdade mora.

O panorama muda o modelo de dados

É por isso que isso importa para um arquiteto de dados. O capítulo 2 diz que o cliente é uma entidade importante. Certo. Aí o panorama diz que o ERP tem autoridade sobre o cliente. Isso muda o modelo físico. O Salesforce ainda pode manter uma Conta local, porque as pessoas a usam todo dia, mas agora precisamos do identificador do ERP como ID externo; precisamos saber quais campos o Salesforce pode alterar (marco os campos do ERP com um prefixo erp_, como vamos ver no módulo 3); com que rapidez as mudanças do ERP chegam; se o Salesforce pode criar um cliente antes de o ERP saber dele; e o que acontece quando os dois discordam. Essas não são perguntas de integração para depois. São perguntas de arquitetura de dados, e o panorama as expôs.

Veja como um deles morde. Um vendedor converte um lead de uma grande empresa de bebidas, cria a Conta, ganha o negócio, e o cliente vai para o ERP. Mas a empresa faz negócios com essa empresa de bebidas há anos, e o ERP já a tem. Agora são duas. O vendedor deveria ter conseguido criar essa Conta? Os capítulos 5 e 6 voltam a isso; o panorama é onde você vê o problema chegando.

O que um arquiteto decide aqui

• Quais sistemas cercam o Salesforce, e que papel cada um desempenha.
• Qual sistema é dono de cada tipo importante de dado, antes de decidir quanto disso o Salesforce guarda.
• O que entra no Salesforce, o que sai, e o que volta.
• Quais dados o Salesforce deve possuir, copiar, referenciar, federar, arquivar ou deixar em paz.
• Quais fronteiras de plataforma e de infraestrutura importam, em vez de presumir que tudo com a marca Salesforce vive num só lugar.

A passagem de desenvolvedor a arquiteto muitas vezes não é aprender mais um recurso. É aprender quando parar de olhar para o Salesforce: afastar a câmera, seguir os dados, encontrar quem é dono da verdade, e então voltar e decidir qual deve ser o trabalho do Salesforce.

Para saber mais

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (em inglês), consultado em 2026-10-14.
• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (em inglês), consultado em 2026-10-14.