Desenhe o panorama antes da org

🌐 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)

Traduzido com IA. Ainda não revisto pela comunidade. Ler em inglês

Capítulo 4 de Data Architect, Parte 1: Tornar-se arquiteto de dados. Anterior: Arquitetura de dados Salesforce.

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. Depois, e só depois, arrisque o modelo de dados.

As pessoas surpreendem-se com a ordem. Somos arquitetos de dados; não devíamos começar pelo modelo de dados? Eis porque não começo. Se desenho primeiro o modelo de dados, já decidi o que pertence ao Salesforce. Se desenho primeiro o panorama, consigo ver tudo o que deveria moldar essa decisão: o ERP que é dono dos clientes e dos produtos, o data warehouse que responde às perguntas de cinco anos, o fornecedor de identidade que decide quem entra, o parceiro que envia um ficheiro todas as tardes, o sistema legado que toda a gente diz que está a ser retirado.

Os capítulos 2 e 3 projetaram a org: o que o modelo deve ser, e como vive no Salesforce. Este capítulo afasta a câmara e desenha o que rodeia a org, antes de a org ser projetada. O Salesforce é um sistema entre muitos, e com bastante frequência não é ele o dono dos dados.

Imagem gerada com IA.

As ideias deste capítulo

• O panorama vem primeiro. Encontre os sistemas, depois os dados que se movem entre eles, depois quem é dono de cada peça. Só então decida qual é o trabalho do Salesforce.
• Uma seta depende de outras setas. As encomendas que saem para o ERP precisam que clientes, produtos e preços tenham entrado antes. Sempre que vejo uma integração com um único fluxo, começo a ficar preocupado.
• Os dados vêm em tipos, e em cargas de trabalho. Dados mestres, de referência, transacionais, metadados, analíticos e não estruturados mudam, crescem e são usados de formas diferentes; as cargas de trabalho operacional (OLTP), analítica (OLAP) e de streaming pedem lugares diferentes. A org gere o negócio; os data warehouses e os data lakes analisam-no.
• Os sistemas têm papéis, não só logótipos. Registo, envolvimento, referência, insights. «O Salesforce é o nosso sistema de registo»: de quê?
• Onde fica a análise segue onde ficam os dados. Tudo no núcleo: relatórios padrão. Dados noutros repositórios: uma plataforma de análise, e o data warehouse quando os dados do Salesforce são combinados com ela.
• O Data 360 é próximo do núcleo (near-core): gerido no núcleo, alojado fora do núcleo. Os utilizadores nunca se ligam a ele, por isso fica junto da canalização.
• Os dados de que o ERP é dono são lidos localmente e gravados sob controlo, com um prefixo erp_ para que o esquema mostre quem é dono de cada campo.
• Num panorama, uma seta começa no sistema que abre a ligação, e o seu rótulo diz o que se move e em que sentido. Dois fluxos são duas setas; uma seta de duas pontas é só para um conector.
• Cada seta tem um cliente e um servidor, e cada um é dono da sua metade. Nada disso vai para o panorama, mas cada seta tem isso.
• Conte antes de desenhar as setas. Os zeros vão para o inventário, e são eles que escolhem o mecanismo: lote (batch), síncrono ou eventos.
• A estratégia de orgs é uma decisão de panorama, tomada nos primeiros minutos: uma org ou várias, e onde correm.
• Um estado atual mostra o que está errado. Vermelho para um processo mau, tracejado para o que é feito à mão, pontos vermelhos para o que está em falta.

O layout de panorama do Steve

Há muitas formas de desenhar um panorama de sistemas. Esta é a minha, refinada ao longo de muitos anos, e lê-se como uma frase: as pessoas à esquerda chegam ao Salesforce no centro, com a confiança dada pelos sistemas acima dele, servidas pelos canais abaixo dele, e ligadas ao back office à direita.

Onde	O que vai ali
Esquerda	As pessoas, de cima para baixo: utilizadores internos, parceiros, clientes
Centro	O Salesforce, uma caixa simples, com as suas comunidades encostadas a ele por baixo
Topo	Fornecedores de identidade acima do Salesforce; o AppExchange deslocado para a direita; sites públicos no canto superior esquerdo
Direita	A camada de integração, depois os sistemas internos: ERP, finanças, armazém
Abaixo da camada de integração	O Data 360, próximo do núcleo (near-core), com a canalização
Em baixo	Canais do cliente: e-mail, formulários web, telefone, mensagens
Em baixo à direita	Dados que entram e saem: arquivos históricos, cargas de dados, fontes externas, parceiros

Os sistemas são cartões em zonas suaves e rotuladas, cada um com um ícone, e uma legenda diz o que tudo significa. Por trás do desenho há um inventário: para cada conjunto de dados ou fluxo, o seu dono, volume, mecanismo e tempo, autenticação, e se deve ser copiado, referenciado ou federado.

Click to enlarge

O panorama do módulo 4, com as suas setas.

O percurso deste capítulo

Seis módulos, cada um a sustentar-se sozinho.

1. Salesforce é um sistema entre muitos. Porque é que o panorama vem antes da caixa, a integração que vejo uma e outra vez e os fluxos de retorno de que ela depende, os dados em ondas, e o núcleo, o próximo do núcleo (near-core) e o Hyperforce.
2. Os tipos de dados empresariais. Seis tipos; criados, editados, referenciados; OLTP e OLAP; tempo real, quase em tempo real e lote (batch); as quatro perguntas por trás das categorias.
3. Os sistemas à volta do Salesforce. Papéis dos sistemas; o ERP, o data warehouse e o lakehouse; a análise segue os dados; MDM; integração e eventos; o fornecedor de identidade de que os programadores se esquecem; onde fica o Data 360.
4. Desenhe o panorama de sistemas. O meu layout, construído a partir de uma folha em branco; os zeros antes das setas; setas que começam no iniciador; o cliente e o servidor por trás de cada seta, nos dois sentidos; raias para conversas; o inventário por trás do desenho.
5. A estratégia de orgs é uma decisão de panorama. Comece com uma org; o que justifica outra; a região, não o fornecedor; uma divisão motivada pelo RGPD (GDPR) em AMER e EMEA; o que a segunda org acrescenta.
6. O panorama da Steve Trucking. Hoje, antes de uma implementação a sério, com marcações: manifestos a chegar ao RouteDesk, rotas reintroduzidas à mão no Salesforce e de volta, uma ilha de dados de GPS, uma folha de cálculo a alimentar as finanças, e 108 mil chamadas de «onde está a minha entrega?» por ano.

Quando terminar, teste-se com o guia de estudo do capítulo: uma lista para o exame, os hábitos que vão além dele, as palavras a conhecer e algumas perguntas.

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.
• Como funciona cada ligação: o que se move, em que direção, como se autentica, com que rapidez, e o que volta.
• Quantas orgs, e onde correm, decidido primeiro, porque todo o resto do panorama depende disso.
• Se o estado atual está entendido suficientemente bem para projetar um estado-alvo.

Além do exame: o panorama está a tornar-se um mapa de agentes. Antes de um agente conseguir responder «onde está a minha entrega?», alguém precisa de saber que sistema tem autoridade sobre cada facto, quão atual ele é, e como o agente pode chegar até ele. Cada módulo termina com o que a IA muda na sua parte do quadro.

Para saber mais

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (em inglês), consultado em 2026-10-14.
• Leitura complementar para candidatos ao CTA: o Salesforce Architects publica as suas próprias orientações de diagramação, How to Build Salesforce Diagrams (opens in a new tab) (em inglês).

Próximo: Qualidade e governação de dados