Entendendo os dados corporativos

🌐 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

Guia de estudo do capítulo 4 do curso Data Architect. Leia primeiro os seis módulos; esta página ajuda você a verificar o que ficou.

Sobre este guia de estudo. Ele foi construído apenas a partir do conteúdo deste curso e da lista de objetivos publicada no guia do exame da Salesforce. Ele nunca se baseia em questões reais do exame e não afirma saber o que cai na prova. Se você já fez o exame, por favor não me envie as questões: o contrato de certificação proíbe compartilhá-las, e decorar respostas é, de qualquer forma, o jeito errado de se tornar arquiteto.

O guia do exame diz que ele não cobra conceitos de bancos de dados que não sejam Salesforce, e a maior parte deste capítulo trata da empresa ao redor do Salesforce. Por isso, como no capítulo 1, esta lista diz quais objetivos cada ponto apoia. Mas não a pule: muitos cenários do exame começam com um ERP, um data warehouse ou uma segunda org, e a resposta depende de quem é dono dos dados.

Para o exame

Marque conforme avança. Cada item tem um link para onde é ensinado.

Quem é dono dos dados (apoia SDM-2, SDM-3 e o capítulo de dados mestres)

• Consigo dizer qual sistema é o sistema de registro de cada tipo de dado, e termino a frase: sistema de registro de quê? (Muitas vezes o Salesforce não é o sistema de registro, Não comece pelo nome do produto)
• Conheço o padrão comum: clientes, produtos e preços entram vindos do ERP, pedidos saem, e sei que a seta de pedidos depende das outras; depois pergunto sobre a viagem de volta. (A integração que vejo de novo e de novo, Setas de mão única me deixam nervoso)
• Faço três perguntas sobre os dados mestres: onde são criados, onde são editados e onde são referenciados? (As quatro perguntas por trás das categorias)
• Sei que uma cópia não é autoridade: dados de propriedade do ERP são lidos localmente e gravados sob controle, com o identificador do ERP guardado como ID externo. (O ERP: o back office tem gravidade, O panorama muda o modelo de dados)

Os tipos de dados e suas cargas de trabalho (apoia DM-1, LDV-1 e MDM-4)

• Consigo distinguir dados mestres, de referência, transacionais, metadados, analíticos e não estruturados, e o que cada um significa para onde eles vivem. (Comece pelo tipo, não pelo objeto)
• Sei que os dados de referência são pequenos mas são onde as suposições de integração se escondem (Delivered, Complete, D). (Dados de referência)
• Sei distinguir as cargas de trabalho operacional (OLTP), analítica (OLAP) e de streaming: a org opera o negócio, data warehouses e data lakes o analisam. (O tipo é só metade da pergunta)
• Conheço o síncrono (esperar na porta), o assíncrono (seguir em frente e lidar com a resposta quando ela voltar) e o lote (batch) (de hora em hora, a cada poucas horas, diariamente), sei quando o lote basta, e que o tempo real tem um custo. (Com que rapidez ele precisa se mover?)
• Faço as quatro perguntas sobre cada conjunto de dados: quem é o dono, com que rapidez muda, quão grande fica e qual é o ciclo de vida. (As quatro perguntas por trás das categorias)

Os sistemas ao redor do Salesforce (apoia SDM-3, LDV-3 e os capítulos de integração)

• Conheço os quatro papéis de sistema: registro, engajamento, referência e insights. (Não comece pelo nome do produto)
• Sei que onde a análise vive segue onde os dados vivem: relatórios do núcleo quando está tudo no Salesforce; uma plataforma de análise (o Tableau, incluindo o Tableau Next, ou o CRM Analytics onde ele é usado) ou o data warehouse quando outros repositórios entram. (A análise vive onde os dados vivem)
• Sei o que são um data warehouse, um data lake e um lakehouse, e o papel do MDM, de um ESB ou iPaaS e dos eventos. (O data warehouse, o data lake e o lakehouse, A camada de integração e os eventos)
• Coloco o provedor de identidade no panorama desde o primeiro dia, e sei que a configuração de SSO é implantada, mas segredos e certificados não viajam junto; no panorama ele é um certificado compartilhado (confiança), não uma chamada, porque o login passa pelo navegador. (O sistema que os desenvolvedores esquecem: identidade)
• Sei que o Data 360 é próximo ao núcleo (near-core) (gerenciado no núcleo, hospedado fora do núcleo), e que o seu zero copy permite consultar dados sem copiá-los. (Onde fica o Data 360?, Núcleo, fora do núcleo e Hyperforce)

Orgs e hospedagem (apoia SDM-4)

• Começo com uma org e procuro uma fronteira real (residência, regulação, separação legal, um modelo operacional diferente, uma aquisição) antes de acrescentar outra. (Comece com uma org, Procure fronteiras reais)
• Sei quanto várias orgs custam: relatórios globais, dados mestres, integração, identidade e deploys, cada um multiplicado. (Percorra as setas de novo)
• Sei que o Hyperforce dá a escolha da região onde os dados de uma org residem (não do provedor de nuvem), mas não promete que todo serviço fique lá; e que o GDPR (RGPD) sozinho não exige uma org separada: ele estabelece regras para os dados pessoais que saem da UE, e uma empresa pode escolher uma org europeia para cumpri-las. (A hospedagem faz parte do desenho, Quando a Europa ganha a sua própria org)

Desenhar e ler um panorama (apoia todos os cenários)

• Sei desenhar um panorama: as pessoas à esquerda, o Salesforce no centro com as suas comunidades encostadas por baixo, a identidade acima, a integração e o back office à direita, o Data 360 abaixo da camada de integração, os canais embaixo, os dados que entram e saem no canto inferior direito. (O layout de panorama do Steve)
• Num panorama, uma seta começa no sistema que abre a conexão e o rótulo dela diz o que se move e em que sentido; num diagrama de fluxo de dados, as setas seguem os dados. Dois fluxos são duas setas. (Agora desenhe as setas)
• Para cada seta sei o que o cliente trata e o que o servidor define: onde, autenticação, protocolo e contrato, payload, tempo, rastreamento, erros. Uma Named Credential (credencial nomeada) e a sua External Credential (credencial externa) quando o Salesforce faz a chamada de saída; um External Client App (aplicativo cliente externo) e um usuário de integração só de API quando algo chama o Salesforce. (Toda seta precisa de um mecanismo)
• Conto antes de desenhar as setas: o volume vai para o inventário e determina o mecanismo, e pode até mudar para que lado a seta aponta. (Ponha os zeros no inventário)
• Desenho uma raia (swim lane) só quando um processo tem mais de uma ou duas idas e vindas. (Setas no panorama, conversas numa raia)

Além do exame

O exame é o piso, não o teto. Estes são os hábitos deste capítulo de que um arquiteto precisa, quer alguma pergunta trate deles ou não.

• Desenhe o panorama antes de projetar a org. Comece numa tela em branco.
• Afaste a câmera. O Salesforce é um sistema entre muitos.
• A onda nova raramente faz a antiga desaparecer. Arquitete a empresa que existe, não a do folheto.
• Leia o panorama como responsabilidades, não como logotipos.
• Setas de mão única me deixam nervoso. De que esse fluxo depende, e o que volta?
• Toda seta precisa de um mecanismo. “Fire and forget” não é resposta.
• Setas no panorama, conversas numa raia.
• Conte antes de desenhar as setas. Os zeros vão para o inventário, e são eles que escolhem o mecanismo.
• Desenhe o estado atual antes de consertá-lo: a planilha, o depósito SFTP, o sistema “que estamos aposentando”.
• Marque um estado atual com honestidade: vermelho para um processo ruim, tracejado para o que é feito à mão, pontos vermelhos para o que está faltando. Cada linha vermelha é um requisito esperando para ser escrito.
• Dois fluxos, duas setas. Uma seta de duas pontas é só para um conector.
• Não brinque de advogado. Pergunte que requisito específico você está atendendo, e traduza-o com as pessoas que são donas dele.
• Separado não é o mesmo que simples.

Palavras para conhecer

Termo	Em uma linha
Panorama de sistemas	Os sistemas ao redor do Salesforce, as pessoas que os usam e os fluxos importantes entre eles
Sistema de registro	Onde a versão com autoridade de um tipo de dado é guardada
Sistema de engajamento	Onde as pessoas fazem o trabalho
Sistema de referência	Onde um sistema consulta informação de que precisa, mas da qual não é dono
Sistema de insights	Onde os dados se juntam para medir, analisar e prever
ERP	O sistema de back office para finanças, produtos, estoque, compras e atendimento de pedidos
Dados mestres	As coisas duráveis em torno das quais um negócio funciona: clientes, produtos, locais
Dados de referência	O vocabulário compartilhado que classifica outros dados: códigos, status, categorias
Dados transacionais	Registros do que aconteceu: pedidos, entregas, pagamentos, casos
Dados analíticos	Dados derivados de outros dados para medir e comparar
Dados não estruturados	Documentos, imagens, áudio, vídeo, transcrições
Data warehouse / data lake / lakehouse	Repositório analítico estruturado / repositório bruto em escala / uma mistura dos dois
ESB / iPaaS	Uma camada de integração que faz a mediação entre sistemas
OLTP / OLAP	Trabalho operacional em poucos registros por vez / análise sobre muitos
Próximo ao núcleo (near-core)	Gerenciado no núcleo, hospedado fora do núcleo: o Data 360
Named Credential / External Credential	Onde o Salesforce guarda um endpoint de saída / a autenticação dele
External Client App	Como um sistema de fora é autorizado a chamar o Salesforce
Estado atual	O panorama como ele é hoje, antes do design; marcado com o que está errado
Provedor de identidade (IdP)	O sistema que autentica os usuários e estabelece a identidade em que o Salesforce confia
Síncrono / assíncrono / lote (batch)	Esperar pela resposta / seguir em frente e tratar a resposta quando ela vier / mover os dados em grupo, num horário programado
Hyperforce	O Salesforce em infraestrutura de nuvem pública, com escolha de região
Zero copy	Consultar os dados onde eles vivem, sem copiá-los

Teste-se

Cenários curtos no estilo do curso. Decida sua resposta antes de abrir.

1. Os vendedores trabalham contas no Salesforce, mas o ERP emite o número oficial de cliente quando eles compram. O Salesforce envia pedidos ao ERP. O que você precisa projetar?

Quem é dono do cliente em cada etapa; o número do ERP como ID externo na Conta; quais campos o Salesforce pode alterar; com que rapidez as mudanças do ERP chegam; e o que volta depois que um pedido é enviado (aceito, rejeitado, enviado, faturado). Releia O panorama muda o modelo de dados.

2. A liderança quer cinco anos de pontualidade por região, cruzados com o financeiro. Construir como relatórios do Salesforce?

Provavelmente não. É uma carga de trabalho analítica entre vários repositórios, então pertence ao lugar onde os dados se juntam: o data warehouse, com CRM Analytics ou Tableau por cima. Onde a análise vive segue onde os dados vivem. Releia A análise vive onde os dados vivem.

3. Uma empresa opera em 30 países e pede uma org por país. O que você pergunta?

Que requisito vem com cada país: armazenamento, processamento, transferência internacional, contratos, um host diferente. Sem uma fronteira real, comece com uma org, porque cada org a mais multiplica relatórios, dados mestres, integração, identidade e deploys. Releia Geografia não é automaticamente uma estratégia de orgs.

4. Os caminhões enviam 200 mil leituras de GPS por dia. O Salesforce deve guardar todas?

Provavelmente não. São dados de streaming: o despachante precisa da posição atual, enquanto o histórico e as tendências pertencem a uma plataforma feita para esse volume. Conte os zeros (mais de 70 milhões por ano) e separe “onde ele está agora?” de “o que aconteceu no último trimestre?”. Releia O tipo é só metade da pergunta.

5. As equipes trabalham as suas paradas no Salesforce, mas as rotas são montadas numa ferramenta de despacho legada, e nada conecta as duas. Como você desenha o hoje?

Como ele é, marcado como estado atual: as rotas redigitadas no Salesforce e as paradas concluídas redigitadas de volta, tracejadas porque são pessoas que fazem isso e vermelhas porque está errado. Não desenhe a integração que você gostaria que existisse; cada linha vermelha vira um requisito para o design. Releia Marque o que está errado e O RouteDesk ainda está lá.

6. Alguém diz que a lei de privacidade europeia exige uma org separada. Como você responde?

Nem aceite às cegas nem desautorize. O GDPR (RGPD) sozinho não exige uma org separada; ele estabelece regras para os dados pessoais, incluindo transferências para fora da UE. Pergunte que requisito específico isso atende (armazenamento, processamento, transferência, acesso de suporte, um contrato, uma política), depois trabalhe com privacidade, jurídico e segurança para transformar isso em arquitetura. Releia Não brinque de advogado e Quando a Europa ganha a sua própria org.

7. O Salesforce envia pedidos para a API do ERP. Qual lado trata as novas tentativas, e onde o Salesforce guarda o segredo?

O Salesforce é o cliente: ele abre a conexão, vê a viagem de ida e volta inteira e é o único lado que pode tentar de novo. Uma Named Credential (credencial nomeada) guarda o endpoint, e a sua External Credential (credencial externa), a autenticação. O ERP, o servidor, define o contrato e valida o que chega. Releia Toda seta precisa de um mecanismo.

8. Uma integração envia um ou dois registros por minuto hoje, e o negócio espera dezenas de milhares por hora no ano que vem. A seta muda?

Possivelmente o mecanismo dela, e até o sentido. Alguns registros por minuto podem ser uma chamada de saída do Salesforce; muito mais pode significar publicar eventos que o outro sistema assina, então a seta começa na outra ponta; milhões durante a noite são um lote. Conheça as contagens antes de escolher. Releia Ponha os zeros no inventário.

Para saber mais

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (em inglês, consultado em 2026-09-25): a lista oficial de objetivos e seus pesos. Sempre confira a versão atual antes de agendar o exame.