Os sistemas à volta do Salesforce

🌐 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 3 de 6 do capítulo Entender os dados empresariais, capítulo 4 do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: Os tipos de dados empresariais · Próximo: Desenhe o panorama de sistemas

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

O último módulo classificou os dados. Agora quero pô-los em algum lado, e é aqui que os arquitetos Salesforce se complicam. Conhecemos o Salesforce, por isso dados de cliente significam Conta, dados de encomenda significam Encomenda, documentos significam Ficheiros, análise significa Relatórios. Mas a empresa não comprou o Salesforce para substituir tudo o resto que tem. Pode haver um ERP a tratar das finanças e do processamento de encomendas, um data warehouse com anos de histórico, uma plataforma de integração, um fornecedor de identidade, sistemas de parceiros, uma plataforma de eventos, uma plataforma de MDM, e o Data 360 a ligar 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 suficiente. Nem Snowflake, MuleSoft, Tableau ou Data 360. Quero saber o que esse 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 vai abaixo. Duas empresas podem ter exatamente os mesmos produtos e arquiteturas completamente diferentes.

Por isso rotulo os sistemas pelo papel. Quatro papéis cobrem a maior parte:

• Sistema de registo: onde é mantida a versão com autoridade de algo.
• Sistema de envolvimento: onde as pessoas fazem o trabalho.
• Sistema de referência: onde 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 registo dos casos, o sistema de envolvimento dos agentes de atendimento e um consumidor dos dados de produto de que o ERP é dono. Por isso, quando alguém disser «o Salesforce é o nosso sistema de registo», termine a frase: sistema de registo de quê?

O ERP: o back office tem gravidade

O ERP é o sistema que vai encontrar ao lado do Salesforce com mais frequência, a tratar de finanças, inventário, compras, processamento de encomendas e faturação. O padrão do módulo 1 (clientes e produtos entram, encomendas saem) significa que o ERP é dono dos produtos, mas os comerciais continuam a precisar deles no Salesforce. Tudo bem: traga-os. Mas copiar dados não transfere a propriedade. Uma cópia não é autoridade.

A minha posição: os dados de que o ERP é dono são lidos localmente e gravados sob controlo. Os utilizadores 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 que leia o objeto saiba quem é dono de cada campo e tenha cuidado ao alterá-lo. O prefixo não impõe nada; são as permissões, a validação e o padrão de integração que o fazem. Comunica a intenção, e é o mapa de autoridade tornado visível.

O data warehouse, o data lake e o lakehouse

Os sistemas operacionais fazem o negócio funcionar; os sistemas analíticos ajudam a entendê-lo. «Mostre as minhas oportunidades abertas» é um relatório do Salesforce. «Mostre cinco anos de vendas, processamento de encomendas, devoluções, casos, inventário e finanças em todos os canais» é outro problema.

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 em bruto. Um lakehouse combina os dois: armazenamento ao estilo do lake com análise ao estilo do warehouse. Conheça-os, porque aparecem nos panoramas. Mas a minha experiência é que os lakehouses e o 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 ande atrás do vocabulário.

A análise vive onde os dados vivem

Esta é uma das minhas posições mais firmes: onde vive a análise segue onde vivem os dados. Se o relatório só precisa de contas, oportunidades e vendedores, está tudo no núcleo: relatórios e dashboards padrão. Depois o negócio pede para acrescentar as faturas do ERP. Depois o custo do produto. Depois cinco anos de encomendas do data warehouse. Depois a atividade no site. A dada altura, arrastar tudo isso para o CRM operacional só para fazer relatórios deixa de fazer sentido. Quando entram outros repositórios de dados, 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 já é usado. É essencial quando os dados do Salesforce são combinados com um data warehouse. O requisito não ficou só mais complicado; o panorama mudou o lugar onde a pergunta deve ser respondida. Por isso nunca começo com «que ferramenta de análise?» Começo com onde estão os dados?

Pergunto o mesmo aos candidatos ao CTA: «Qual dos meus diagramas resolve isto lindamente? O panorama.» Se está tudo no núcleo, use relatórios. Se tem dados noutros repositórios, quero ver uma plataforma de análise. O panorama responde à pergunta dos relatórios antes de alguém abrir um criador de relatórios. (Os nomes dos produtos mudam; o capítulo de Data 360 trata de onde está hoje a análise da Salesforce.)

MDM: quem é este cliente, de verdade?

Agora suponha que a informação de cliente vive no Salesforce, no ERP, no e-commerce, numa plataforma de fidelização e num sistema de parceiro, e cada um acha que sabe quem é o cliente. É aí que entra a gestão de dados mestres (MDM): estabelecer e governar a identidade com autoridade dos dados-chave entre sistemas. Mas MDM não é «uma base de dados mestre de clientes». As perguntas difíceis são que sistema pode criar o cliente, de que atributos é dono cada sistema, como se encontram os duplicados, que 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, pode ser uma autoridade crítica entre o Salesforce e o resto da empresa.

A camada de integração e os eventos

Ligue cada sistema diretamente a todos os outros, e o panorama transforma-se em esparguete num instante. É 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 mais vai encontrar em panoramas Salesforce. Faz a mediação, para que cada aplicação não precise de entender todas as outras.

Mas uma caixa do MuleSoft no meio não torna a integração boa. Continuo a querer 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á em baixo, se é síncrona ou assíncrona, e como sabemos que uma mensagem teve sucesso. O curso Integration Architect vai a fundo; aqui, reconheça-a como um papel próprio.

E nem toda a integração é o sistema A a chamar o sistema B. Às vezes algo acontece (uma encomenda é criada, uma entrega muda de estado, um camião entra numa região), um evento é publicado, e quem estiver interessado reage. Os eventos em movimento também têm infraestrutura: as capacidades de eventos do próprio Salesforce, um barramento de eventos empresarial, outros sistemas de mensagens. Desenhe os mecanismos que transportam os dados, não só as bases de dados.

O sistema de que os programadores se esquecem: identidade

Há uma caixa que quero sempre no panorama e em que os programadores raramente pensam: o fornecedor de identidade. Os programadores entram diretamente nas suas sandboxes com utilizador e palavra-passe, por isso a identidade fica invisível durante a construção. Depois chega o UAT ou a produção, e de repente aparece o single sign-on da empresa para os colaboradores, talvez um segundo fornecedor para os parceiros, login social para os clientes. A identidade sempre fez parte da arquitetura. O programador só ainda não a tinha visto.

Um fornecedor de identidade (IdP) é o sistema que autentica um utilizador e estabelece a identidade em que o Salesforce confia. 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 pormenor prático: a configuração de identidade é implementável, mas não por completo. A configuração de single sign-on SAML e os fornecedores de autenticação são tipos da Metadata API, por isso viajam pelo pipeline (SamlSsoConfig (opens in a new tab), em inglês). Mas os segredos de consumidor dos fornecedores de autenticação já não são 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. Planeie para as partes que viajam e para as que não viajam.

Click to enlarge

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

Onde fica o Data 360?

O Data 360 levanta uma boa pergunta de desenho. Ponho-o à direita, abaixo do ESB ou do MuleSoft. O motivo são as suas ligações: os utilizadores nunca se ligam a ele diretamente, enquanto ele se liga diretamente a muitos sistemas de back-end. Por isso pertence à canalização de dados, onde essas linhas ficam curtas, não lá fora com os utilizadores. Desenhe-o como mais um ecrã em que as pessoas entram, e está a contar a história errada.

Os administradores e as equipas de dados abrem, sim, os ecrãs do Data 360, mas esses ecrãs ficam na org, no núcleo. O tenant que faz o trabalho, com os seus dados e o seu processamento, corre fora do núcleo. É por isso que digo que ele é próximo do núcleo (near-core): gerido no núcleo, alojado fora do núcleo (o módulo 1 explica os termos). O desenho segue o tenant: fica com a canalização, com uma linha de volta para a org que o gere.

O que faz, nas palavras da Salesforce, inclui o zero copy: uma tecnologia de federação de dados que permite a uma empresa aceder a dados e consultá-los sem os copiar (Zero Copy (opens in a new tab), em inglês). As capacidades e os conectores mudam depressa, por isso o capítulo de Data 360 trata-os como deve ser em vez de transformar este módulo numa visita guiada ao produto.

Leia o panorama como responsabilidades

Quando olhar para um panorama, não leia os logótipos; leia as responsabilidades. O ERP: de 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 liga, e para quê? O Salesforce: pelo que é realmente responsável? Quando consegue responder a isto, 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.
• Que sistema tem autoridade sobre cada conjunto de dados importante, e onde o Salesforce guarda só uma cópia local.
• Se os dados de que o ERP é dono estão disponíveis no Salesforce com as gravações controladas, e como essa propriedade aparece no esquema.
• Onde pertence a análise, com base em onde vivem os dados.
• 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; é um inventário. A arquitetura começa quando consegue apontar para cada retângulo e dizer porque é que está ali, de que é dono, quem o usa, de que precisa o Salesforce dele, e o que se estraga se perceber mal o seu papel.

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.