Salesforce é um sistema entre muitos

🌐 Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 com IA. Ainda não revisto pela comunidade. Ler em inglês

Módulo 1 de 6 do capítulo Entender os dados empresariais, capítulo 4 do curso Data Architect. Cada módulo sustenta-se sozinho. Próximo: Os tipos de dados empresariais

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

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

É uma mudança de perspetiva para muitos profissionais Salesforce. Se passou a carreira como administrador ou programador, o Salesforce é naturalmente o centro do seu mundo. Abre o Setup, cria objetos, constrói flows, escreve Apex e integra outros sistemas com o Salesforce. Tudo parece começar pela org. Um arquiteto precisa de afastar a câmara, 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 alargar o problema. Antes de decidir de que deveria o Salesforce ser dono, quero entender a empresa à sua volta. Que sistemas já existem? Onde são criados os clientes, definidos os produtos, iniciadas as encomendas, geradas as faturas? Onde vive a identidade? Onde acontece a análise, onde ficam os documentos, onde está o histórico? Que sistemas precisam dos dados do Salesforce, e de quais depende o Salesforce?

Estas perguntas mudam a arquitetura. Por isso começo numa folha em branco, ponho o Salesforce no meio e desenho tudo à sua volta. O módulo 4 mostra exatamente como faço o layout. Por agora, 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 registo

Pegue numa empresa muito comum: o Salesforce mais um ERP, um sistema de gestão empresarial como SAP ou Oracle, que trata de finanças, produtos, inventário, compras e processamento de encomendas. 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 comerciais podem trabalhar prospects como Contas no Salesforce, enquanto o ERP emite o número oficial de cliente quando passam a ser clientes pagantes. Produtos e preços? Provavelmente o ERP. Inventário? Quase nunca o Salesforce. As encomendas podem ser registadas no Salesforce e processadas 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, o nosso bonito modelo de dados do Salesforce não é o modelo de dados da empresa. É uma parte dele.

A integração que vejo uma e outra vez

A integração mais comum que vejo é assim: clientes, produtos e preços entram no Salesforce vindos do ERP, e as encomendas saem. Troque por SAP, Oracle ou qualquer outro ERP; a forma é a mesma. O ERP é dono do golden record do cliente e do produto, por isso esses fluxos vêm da direita, para dentro do Salesforce. Vendas fecha o negócio no Salesforce, por isso a encomenda começa ali e volta ao ERP para ser processada, faturada e contabilizada.

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

As setas num só sentido deixam-me nervoso

Sempre que vejo uma integração com um único fluxo, começo a ficar preocupado. Ao nível alto, alguém desenha uma única seta: encomendas do Salesforce para o ERP. Muito bem. Agora olhe mais a fundo. Como posso enviar uma encomenda ao ERP se não conheço os seus clientes, os seus produtos ou os seus preços? A encomenda tem de estar ligada a um cliente que o ERP já tem, e cada linha tem de 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. Por isso, antes de essa seta de encomendas poder funcionar, têm de existir fluxos de retorno, a correr no sentido contrário.

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

Olhe ainda mais a fundo e encontra a viagem de volta. O Salesforce envia uma encomenda. E depois? Foi aceite ou rejeitada? Foi enviada, enviada em parte, cancelada? Foi faturada? Alguém no Salesforce precisa de saber? Talvez não precise. Mas alguém deveria ter perguntado. Se nada volta, tudo bem. Diga-me porquê.

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 vagas. Primeiro os ficheiros: registos de formato fixo, depois ficheiros delimitados como o CSV. Depois as bases de dados relacionais para dados operacionais. Depois os data warehouses para juntar tudo para análise. Depois as bases de dados NoSQL para documentos, pares chave-valor e grafos que não cabem bem 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 de ser copiados para um só lugar antes de outra plataforma os poder usar.

A tecnologia ainda não é o ponto. O ponto é este: a vaga nova raramente faz desaparecer a antiga. Entre numa grande empresa e vai encontrá-las todas ao mesmo tempo: bases de dados relacionais, o ERP, o Salesforce, um data warehouse, um data lake, ficheiros deixados por SFTP, APIs, fluxos de eventos, a folha de cálculo que alguém ainda envia por e-mail todas as sextas-feiras, e aquele sistema em que toda a gente tem medo de mexer porque a pessoa que o construiu se reformou há seis anos. Essa é a empresa que está a arquitetar, não a do folheto do produto.

Sistemas diferentes existem por motivos diferentes

É também por isso que nunca começo com «como pomos todos os dados no Salesforce?» Porque haveria eu de os 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 alguma vez produziu.

O capítulo 3 perguntou onde deveriam viver estes dados? para uma org. Ao 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 os deveria ter de todo.

Núcleo, fora do núcleo e Hyperforce

Há outra fronteira a entender: nem o «Salesforce» é um só runtime e uma só base de dados. No capítulo 3, no núcleo (on core) queria dizer onde ficam os dados: na sua secretária, nos próprios objetos da org. Aqui as mesmas palavras descrevem onde corre um produto. Vai ouvir arquitetos usar os dois sentidos.

Historicamente, o runtime Core alojava a maior parte da plataforma. Hoje a Salesforce descreve uma plataforma de centenas de serviços independentes orientados por metadados, com o Core a continuar como o único sistema de registo dos metadados das aplicações (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), em inglês). É por isso que vai ouvir arquitetos dizer que uma capacidade corre 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 porque é 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. Os flows e os triggers vivem no núcleo, por isso um produto construído ali recebe com ele os metadados, as personalizações e a automação da plataforma. Esse produto de cotações já deu lugar ao Revenue Cloud, mas a lição mantém-se. Depois há o próximo do núcleo (near-core), e o Data 360 é o exemplo que uso. O Data 360 não é núcleo. O seu tenant fica fora do núcleo: os dados e os mecanismos que os processam correm no seu próprio lakehouse, ao lado da base de dados relacional da org, e não dentro dela (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), em inglês). Mas os ecrãs que usa para o configurar e controlar são apresentados no núcleo, na org. Por isso, a forma mais precisa que encontro de o dizer é: gerido no núcleo, alojado fora do núcleo. Nenhum dado nem processamento corre de facto 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 sequer é Salesforce.

Importa-me menos decorar que produto corre onde este 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. Por isso, não presuma que, por um produto dizer Salesforce, os seus dados ficam mesmo ao lado dos seus registos 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 centros de dados próprios tradicionais, dando aos clientes mais escolha sobre onde residem os seus dados (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 empresariais. Mover uma org para a nuvem pública não lhe diz quem é dono do cliente, onde vive o inventário, onde corre a análise, ou que dados podem atravessar uma fronteira. O Hyperforce pode moldar algumas dessas decisões, especialmente a residência. 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 fornecedor 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, encomendas, faturas, documentos, eventos, identidades. Depois pergunte quem é dono de cada um. Só então decida o que pertence ao Salesforce. Caso contrário, está a projetar uma caixa sem saber a que se liga.

Click to enlarge

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

Click to enlarge

Passo 2 de 3: reduza 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, encomendas saem: dizem onde a empresa acredita que a verdade vive.

O panorama muda o modelo de dados

É por isso que isto importa para um arquiteto de dados. O capítulo 2 diz que o cliente é uma entidade importante. Certo. Depois 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 todos os dias, mas agora precisamos do identificador do ERP como ID externo; precisamos de saber que campos o Salesforce pode alterar (marco os campos do ERP com um prefixo erp_, como vamos ver no módulo 3); com que rapidez chegam as mudanças do ERP; se o Salesforce pode criar um cliente antes de o ERP saber dele; e o que acontece quando os dois discordam. Estas não são perguntas de integração para depois. São perguntas de arquitetura de dados, e o panorama expô-las.

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 passa para o ERP. Mas a empresa faz negócio com essa empresa de bebidas há anos, e o ERP já a tem. Agora são duas. O vendedor deveria sequer ter conseguido criar essa Conta? Os capítulos 5 e 6 voltam a isso; o panorama é onde vê o problema a chegar.

O que um arquiteto decide aqui

• Que sistemas rodeiam o Salesforce, e que papel desempenha cada um.
• Que 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.
• Que dados o Salesforce deve possuir, copiar, referenciar, federar, arquivar ou deixar em paz.
• Que fronteiras de plataforma e de infraestrutura importam, em vez de presumir que tudo com a marca Salesforce vive num só lugar.

A passagem de programador a arquiteto muitas vezes não é aprender mais uma funcionalidade. É aprender quando deixar de olhar para o Salesforce: afastar a câmara, seguir os dados, encontrar quem é dono da verdade, e depois 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.