Pular para o conteúdo
SteveTechArcSteveTechArc Courses

Desenhe o panorama antes da org

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)

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

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

As pessoas se surpreendem com a ordem. Somos arquitetos de dados; não deveríamos começar pelo modelo de dados? Eis por que não começo. Se desenho o modelo de dados primeiro, já decidi o que pertence ao Salesforce. Se desenho o panorama primeiro, 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 provedor de identidade que decide quem entra, o parceiro que manda um arquivo toda tarde, o sistema legado que todo mundo diz que está sendo aposentado.

Os capítulos 2 e 3 projetaram a org: o que o modelo deve ser, e como ele vive no Salesforce. Este capítulo afasta a câmera e desenha o que cerca 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.

Um arquiteto líder desenha um panorama de sistemas em torno do Salesforce num quadro branco para dois colegas, numa manhã de neblina

Imagem gerada com IA.

As ideias deste capítulo

Seção intitulada “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. Pedidos 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 opera o negócio; data warehouses e data lakes o analisam.
  • Os sistemas têm papéis, não só logotipos. Registro, engajamento, referência, insights. “O Salesforce é o nosso sistema de registro”: de quê?
  • Onde a análise fica segue onde os dados ficam. Tudo no núcleo: relatórios padrão. Dados em outros 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 ao núcleo (near-core): gerenciado no núcleo, hospedado fora do núcleo. Os usuários nunca se conectam a ele, então ele fica junto com o encanamento.
  • Dados de propriedade do ERP são lidos localmente e gravados sob controle, com um prefixo erp_ para que o esquema mostre quem é dono de cada campo.
  • Em um 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. Dois fluxos são duas setas; uma seta de duas pontas é só para um conector.
  • Toda seta tem um cliente e um servidor, e cada um é dono da sua metade. Nada disso vai para o panorama, mas toda 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 ela roda.
  • Um estado atual mostra o que está errado. Vermelho para um processo ruim, tracejado para o que é feito à mão, pontos vermelhos para o que está faltando.

O layout de panorama do Steve

Seção intitulada “O layout de panorama do Steve ”

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

OndeO que vai ali
EsquerdaAs pessoas, de cima para baixo: usuários internos, parceiros, clientes
CentroO Salesforce, uma caixa simples, com as suas comunidades encostadas nele por baixo
TopoProvedores de identidade acima do Salesforce; o AppExchange deslocado para a direita; sites públicos no canto superior esquerdo
DireitaA camada de integração, depois os sistemas internos: ERP, financeiro, depósito
Abaixo da camada de integraçãoO Data 360, próximo ao núcleo (near-core), com o encanamento
EmbaixoCanais do cliente: e-mail, formulários web, telefone, mensagens
Embaixo à direitaDados 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, seu dono, volume, mecanismo e tempo, autenticação, e se ele deve ser copiado, referenciado ou federado.

O panorama com as suas setas O mesmo panorama de antes, agora com setas; cada uma começa no sistema que abre a conexão, e o seu rótulo diz o que se move e em que sentido. Os usuários internos chegam ao Salesforce, os usuários parceiros à Partner Community, os clientes à Customer Community. Cada provedor de identidade e o Salesforce compartilham um certificado, mostrado como uma linha verde pontilhada com um certificado em cada ponta: confiança, não uma chamada direta, porque o login passa pelo navegador do usuário como redirecionamentos. O provedor de identidade dos funcionários também envia atualizações de usuários ao Salesforce. O Salesforce envia documentos para o aplicativo de assinatura eletrônica do AppExchange, e pedidos para a camada de integração, que envia produtos para o Salesforce. A camada de integração envia pedidos para o ERP e traz produtos dele; o ERP envia o status do pedido para a camada de integração; a camada de integração traz pagamentos do financeiro. O Data 360, abaixo da camada de integração, abre as suas conexões: dados do CRM saindo do Salesforce, zero copy com o data warehouse, e uma referência aos dados externos. De baixo, o e-mail traz casos e os formulários web trazem leads para o Salesforce; o Salesforce envia casos antigos para o arquivo histórico; as cargas de dados trazem registros. ACIMA: IDENTIDADE, APPEXCHANGE, WEB PESSOAS DIREITA: SISTEMAS INTERNOS ABAIXO: CANAIS DE CLIENTES ABAIXO À DIREITA: DADOS QUE ENTRAM E SAEM Usuários internos vendas, atendimento, operações Usuários parceiros Clientes Site público IdP dos funcionários single sign-on IdP dos parceiros single sign-on App do AppExchange assinatura eletrônica Partner Community Customer Community Data 360 próximo ao núcleo: gerenciado no núcleo, hospedado fora dele CAMADA DE INTEGRAÇÃO (ESB) ERP pedidos, faturas Financeiro pagamentos Gestão de pedidos Data warehouse análise E-mail email-to-case Formulários web web-to-lead Telefone central de atendimento Mensagens SMS, chat Arquivo histórico casos antigos Cargas de dados migração Dados externos referenciados, não copiados Salesforce a org em torno da qual projetamos certificado compartilhado atualizações de usuários certificado compartilhado documentos saem pedidos saem produtos entram pedidos saem, produtos entram status do pedido entra pagamentos entram dados do CRM saem zero copy referenciado casos entram leads entram casos antigos saem registros entram Salesforce uma comunidade pessoas identidade, apps, web um sistema interno um canal de clientes dados que entram e saem a camada de integração tracejado: ainda não ativo, ou referenciado parte do sistema que abre a conexão; o rótulo diz o que se move um certificado compartilhado: confiança, sem chamada direta © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

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

O caminho por este capítulo

Seção intitulada “O caminho por este capítulo ”

Seis módulos, cada um se sustentando sozinho.

  1. Salesforce é um sistema entre muitos. Por que o panorama vem antes da caixa, a integração que vejo de novo e de novo e os fluxos de retorno dos quais ela depende, os dados em ondas, e o núcleo, o próximo ao núcleo (near-core) e o Hyperforce.
  2. Os tipos de dados corporativos. 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 ao redor 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 provedor de identidade que os desenvolvedores esquecem; onde fica o Data 360.
  4. Desenhe o panorama de sistemas. Meu layout, construído a partir de uma tela 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 provedor; uma divisão motivada pelo GDPR em AMER e EMEA; o que a segunda org acrescenta.
  6. O panorama da Steve Trucking. Hoje, antes de uma implementação de verdade, com marcações: manifestos chegando ao RouteDesk, rotas redigitadas no Salesforce e de volta à mão, uma ilha de dados de GPS, uma planilha alimentando o financeiro, e 108 mil ligações de “cadê 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 para conhecer e algumas perguntas.

O que um arquiteto decide aqui

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

Além do exame: o panorama está virando um mapa de agentes. Antes que um agente consiga responder “cadê minha entrega?”, alguém precisa saber qual sistema tem autoridade sobre cada fato, quão atual ele é, e como o agente pode alcançá-lo. Cada módulo termina com o que a IA muda na sua parte do quadro.

Para saber mais

Seção intitulada “Para saber mais ”

Próximo: Qualidade e governança de dados