A pergunta que este módulo responde: Como desenho um panorama que mostra para onde vão os dados?
Me dê um cenário novo e um quadro branco vazio, e uma das primeiras coisas que vou desenhar é o panorama de sistemas. Não bonito, não cada API, ainda não o modelo de dados. Quero ver a empresa: quem são os usuários, quais sistemas estão envolvidos, onde o Salesforce fica, o que o cerca, de onde os dados vêm e para onde vão. E depois quero percorrer as setas. Um bom panorama não é um desenho de caixas. É uma forma de expor decisões de arquitetura.
Faço os candidatos a CTA praticarem isto. Leia o cenário, depois comece a desenhar. Não espere até ter resolvido tudo na cabeça; o desenho ajuda você a resolver. É por isso que a lição de casa depois do primeiro dia é começar o panorama antes de arriscar o modelo de dados. Desenhe o modelo de dados primeiro e você já presumiu o que pertence ao Salesforce. Desenhe o panorama primeiro e você consegue ver os sistemas que deveriam moldar essa decisão.
Comece pelo alto nível, depois desça: primeiro a empresa inteira, depois o detalhe onde ele importa.
Existem muitas formas de desenhar um panorama de sistemas. Esta é só a minha, uma que refinei ao longo de muitos anos, e eu a compartilho para você ver como montar um rapidamente. Uso esse layout em todo panorama Salesforce, e ele 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.
As pessoas à esquerda, de cima para baixo: usuários internos, parceiros, clientes. Ainda não cada persona; o bastante para responder quem está tentando chegar a esta arquitetura? Cada grupo aponta para onde entra: os usuários internos para o Salesforce, os parceiros para a comunidade de parceiros, os clientes para a comunidade de clientes. Os sistemas não existem sozinhos. Alguém, ou algo, está tentando usá-los.
Passo 2 de 6: quem está tentando chegar a esta arquitetura?
O Salesforce no centro. Uma caixa simples. Não porque o Salesforce seja o centro da empresa (acabamos de passar três módulos dizendo que não é), mas porque é o sistema em torno do qual estou projetando. É a âncora.
As comunidades logo abaixo dele, encostadas. Uma comunidade de parceiros e uma comunidade de clientes são pontos de acesso separados, então ganham as suas próprias caixas. Mas ficam encostadas no Salesforce, porque nada precisa ser integrado para chegar a elas: elas rodam na mesma org.
Passo 3 de 6: o Salesforce no centro, as comunidades logo abaixo dele.
A identidade acima. Os provedores de identidade vão no topo, aqueles que os desenvolvedores esquecem: um para os usuários internos, talvez outro para os parceiros. Os pacotes do AppExchange também vão lá em cima, deslocados para a direita, porque são capacidades trazidas para dentro da org, e não sistemas de back office trocando dados com ela. Os sites públicos ficam no canto superior esquerdo.
Passo 4 de 6: a identidade acima, a caixa que os desenvolvedores esquecem.
A integração, depois o back office, à direita. A camada de integração, um ESB ou iPaaS (ou o MuleSoft, quando ele é citado), é uma barra alta logo à direita do Salesforce. Os sistemas internos ficam atrás dela: os ERPs, o financeiro, a gestão de pedidos, os sistemas legados, o data warehouse. Agora a página se lê da esquerda para a direita: pessoas, Salesforce, integração, back office.
Os canais abaixo. Tudo o que tem uma linha direta com os clientes: email-to-case, web-to-lead, telefone, mensagens.
Dados que entram e saem, no canto inferior direito. Fontes de dados externas, arquivos históricos, cargas de dados.
O Data 360 à direita, abaixo da camada de integração. Os usuários nunca se conectam a ele, e o tenant dele se conecta a muitos sistemas de back-end, então ele fica com o encanamento, onde essas linhas ficam curtas: ao lado dos sistemas internos, do data warehouse e dos dados no canto inferior direito. As equipes de dados abrem, sim, as telas dele, mas essas telas ficam na org: o Data 360 é próximo ao núcleo (near-core), gerenciado no núcleo e hospedado fora do núcleo (módulo 1). Uma linha de volta para o Salesforce mostra quem o gerencia. O lugar onde você coloca a caixa deve contar a história do que ela faz.
Nada dessa geometria é sagrado. O valor de uma convenção é que não reinvento a linguagem visual toda vez, e quem já viu um dos meus diagramas lê o próximo mais rápido.
Mantenha a notação simples. Todo sistema é um cartão: o nome dele, o papel dele e um pequeno ícone que diz que tipo de coisa ele é: um ERP, um banco de dados, um provedor de identidade, um grupo de pessoas. As regiões que acabei de descrever são desenhadas como zonas suaves e rotuladas, para que o próprio layout fique visível. Uma legenda embaixo diz o que cada ícone e cada linha significam.
Não coloque coisa demais dentro de uma caixa. Só num panorama muito complicado eu abro o Salesforce em suas partes (Sales Cloud e Service Cloud dentro da org, com setas entre elas). E não invente quinze formas, a menos que cada uma diga algo ao leitor. Quero que alguém olhe para o panorama por trinta segundos e comece a entender a arquitetura. Enfeite não ajuda. Clareza ajuda.
Não espere o design detalhado para pensar em volume. Uma seta que carrega 500 produtos por noite e uma que carrega 200 mil leituras de GPS por dia podem parecer exatamente iguais no panorama. Não são o mesmo problema. Então, antes de desenhar uma única seta, conte o que se move. Comece o inventário por trás do desenho com as contagens: uma linha por conjunto de dados importante, com o seu volume. Os zeros talvez nunca apareçam nas setas, mas você precisa saber quando entra em números altos: milhares ou milhões em uma hora, centenas de milhares de transações, até dezenas a centenas de transações por segundo.
Esses números determinam o mecanismo. Algumas centenas de registros por noite são um lote (batch). Uma chamada pela qual alguém espera pode ser síncrona, se o volume permitir. Dezenas a centenas por segundo podem precisar de eventos, como os platform events, em vez de uma chamada por registro. A seta vai parecer a mesma; o volume decide o que a carrega, então registre-o no inventário, onde o mecanismo é escolhido.
O mecanismo pode até mudar o sentido da seta. Envie um ou dois registros por minuto, e o Salesforce pode simplesmente fazer uma chamada de saída: a seta começa no Salesforce. Envie muito mais, e o Salesforce pode, em vez disso, publicar eventos no barramento de eventos; o sistema externo os assina e chama o Salesforce para buscá-los, então agora a seta começa na outra ponta. Maior ainda, digamos uma sincronização noturna de milhões de registros, e é um processo em lote. Então conheça as suas contagens cedo, quando começar a projetar os mecanismos, porque as contagens podem redesenhar as setas.
O volume importa em dois lugares, por dois motivos. Num modelo de dados, preciso dele para ficar de olho em grandes volumes de dados e planejar o arquivamento; a Parte 2 se aprofunda nisso. Num panorama de sistemas, os números grandes do inventário determinam a escolha do padrão e do mecanismo de integração. O módulo 6 coloca zeros reais no panorama da Steve Trucking e no inventário dele. Com as contagens em mãos, desenhe as setas.
Com os sistemas no lugar, conecte-os, e o panorama vira arquitetura. Uma caixa é um sistema; a seta mostra quem inicia a conexão. Ela começa no sistema que abre a conexão e aponta para aquele que ele chama: do cliente para o servidor. O rótulo diz o que se move, e em que sentido.
Essa regra vale para os panoramas de sistemas, onde sistemas conversam com sistemas. Num diagrama de fluxo de dados, a seta segue os dados, como você esperaria. Não leve a regra do panorama para outros diagramas; ela só acrescenta confusão.
As setas chegaram. Toda caixa está onde estava; cada seta começa no sistema que abre a conexão, e o rótulo dela diz o que se move e em que sentido.
Então, se a camada de integração empurra produtos para o Salesforce, a seta vai da camada de integração para o Salesforce, rotulada produtos entram. Se o Salesforce faz a chamada para buscá-los, a seta começa no Salesforce, ainda rotulada produtos entram. Os mesmos dados, uma conversa diferente, e essa diferença me diz quem precisa das credenciais e quem precisa lidar com a falha. O Salesforce envia o pedido pela camada de integração: pedidos saem. O atendimento do ERP volta: status do pedido entra. Agora consigo ver quem começa cada conversa, onde os dados entram no Salesforce e onde saem, quais fluxos cruzam fronteiras, onde provavelmente está a propriedade, e onde preciso perguntar mais.
E lembre-se do módulo 1: sempre que vejo um fluxo só, fico preocupado. No nível alto, uma seta de pedidos saem depende de fluxos de retorno: clientes entram, produtos entram, preços. Olhe ainda mais a fundo e lá está a viagem de volta: aceite, rejeição, status, um número de fatura, um cancelamento. As setas me dão algo concreto para questionar.
É aqui que o panorama deixa de ser arte de PowerPoint. Na banca de revisão, qualquer seta pode atrair três perguntas, e quero que você tenha as respostas:
Como ela se autentica? OAuth, um certificado, uma credencial nomeada, outra coisa?
É síncrona ou assíncrona? O Salesforce espera o ERP, ou publica e segue em frente? Com que rapidez o negócio precisa do resultado?
Qual é o mecanismo? Uma chamada REST, um evento, um arquivo, uma fila de mensagens, pelo MuleSoft ou direto?
E depois: o que acontece quando o outro lado está fora do ar? Toda seta precisa de um mecanismo. Se você não consegue explicá-lo, a linha é decoração.
E “fire and forget” (dispare e esqueça) não é resposta. Normalmente significa “não projetei o que acontece depois do disparo”. Chegou? Foi aceito? Falhou? Vai tentar de novo? Quem sabe que travou? E se a mesma mensagem chegar duas vezes? Nada disso vai no panorama, que ficaria ilegível. Mas a seta deve fazer você saber que essas perguntas existem.
Aproxime o zoom em qualquer seta e há um cliente e um servidor, e cada um é dono da sua metade. O cliente abre a conexão: ele precisa do endpoint e da porta, obtém primeiro um token do servidor de autenticação, chama o protocolo e o contrato que o servidor define, e escolhe se vai esperar. Só o cliente vê a viagem de ida e volta inteira, então só o cliente pode tentar de novo. O servidor escuta, define o protocolo, o contrato e o payload, valida o que chega, e vê só a sua própria parte. Quando desenho uma seta, já sei qual ponta é qual, e isso me diz quem é dono de cada uma dessas perguntas.
Uma seta, vista de perto: o cliente trata, o servidor define. Nada disso vai para o panorama, mas toda seta tem isso.
Agora inverta a seta. Quando o ERP chama o Salesforce, o Salesforce é o servidor: ele define as APIs, roda o seu próprio servidor de autorização, e decide, por meio de um External Client App (aplicativo cliente externo) e de um usuário de integração, o que quem chama pode fazer. As mesmas perguntas, do outro lado.
É aqui que os arquitetos estragam um bom diagrama: fazem um artefato responder a tudo. O panorama ganha nomes de API, payloads, novas tentativas, filas de erro, transformações, cada callback, e logo ninguém consegue lê-lo. Não faça isso. O panorama é o quadro geral: os sistemas e os fluxos importantes entre eles.
Quando preciso explicar uma interação, desenho um segundo diagrama, mas não para cada integração. Se o sistema A envia algo para B, ou até pergunta e recebe uma resposta, a seta rotulada basta. Quero uma raia (swim lane) quando o processo vira uma conversa: A chama B, B consulta C, C responde, B cria algo e chama A de volta, uma pessoa aprova, outro sistema continua. Minha regra prática: mais de uma ou duas idas e vindas, e a sequência ganha sua própria raia. Setas no panorama; a conversa na raia.
E repare que uma seta significa outra coisa ali. No panorama, uma seta é uma conexão: quem a abre, e o que se move. Numa raia, cada seta é uma mensagem numa conversa, lida em ordem: uma requisição vai num sentido, uma resposta volta no outro, e o próximo passo vem em seguida.
Quando o panorama parecer quase pronto, percorra-o, seta por seta. ERP para Salesforce: o que está se movendo, quem é o dono, como se autentica, qual é o mecanismo, síncrono ou assíncrono, quão atual precisa estar? Depois a próxima seta, e a próxima. É aqui que as lacunas aparecem. “Ah, nunca descobrimos como o parceiro realmente envia aquilo.” “Mandamos os pedidos para o ERP, mas não projetamos como os rejeitados voltam.” Ótimo. Você encontrou isso no quadro branco em vez de em produção.
O desenho precisa continuar legível, então os detalhes vão para o inventário por trás dele. Você o começou com as contagens; agora termine-o, uma linha por conjunto de dados ou fluxo importante:
Coluna
O que quero saber
Conjunto de dados
Cliente, produto, pedido, entrega, fatura
Tipo
Mestre, de referência, transacional, analítico, não estruturado
Dono
Quem é dono do significado e do ciclo de vida dele?
É por isso que gosto deste artefato: ele me ajuda a pensar. “Como vamos fazer relatórios cruzando Salesforce e ERP?” É a pergunta do módulo 3: qual dos meus diagramas resolve isso lindamente? O panorama. Se está tudo no núcleo, relatórios padrão. Se os dados estão no ERP e no data warehouse, você vê isso na hora. “Onde este atributo do cliente deve ser mestre?” Veja quais sistemas o usam e qual já é dono do cliente. “O Salesforce precisa de cada leitura de GPS?” Quem a produz, quem a consome, qual é a carga de trabalho? Talvez o Salesforce precise da posição atual e outra plataforma guarde o histórico. O panorama não lhe entrega a resposta. Ele lhe dá a visão certa do problema.
Mais uma disciplina. Numa empresa existente, desenhe o que existe, não o que você gostaria que existisse. A planilha enviada por e-mail toda sexta: desenhe. O CSV do parceiro num servidor SFTP: desenhe. A integração que contorna o ESB por razões históricas: desenhe. Pessoas redigitando dados entre dois sistemas: mostre. Não limpe a realidade enquanto a documenta. Você precisa do panorama atual antes de projetar o panorama-alvo, e é isso que fazemos com a Steve Trucking no módulo 6.
Além do exame: o que a IA muda. O panorama está virando um mapa de agentes. Se um agente responde “cadê minha entrega?”, o panorama precisa dizer se a resposta vem do Salesforce, de um sistema de parceiro, da telemetria, do ERP ou de uma mistura. Os agentes não eliminam as fronteiras entre sistemas; eles tornam ainda mais importante saber qual sistema tem autoridade, e como alcançá-lo com segurança.
Quais sistemas e populações de usuários pertencem ao panorama, e como a posição deles mostra seu papel.
Quais fluxos cruzam fronteiras entre sistemas, em que direção, e o que volta.
Como cada conexão se autentica, que mecanismo a carrega, e se ela é síncrona, assíncrona, em lote ou federada.
Quando uma seta rotulada basta e quando uma interação precisa da sua própria raia.
O que o inventário por trás do desenho registra: dono, carga de trabalho, volume, org, tempo, autenticação, e copiar, referenciar ou federar.
O panorama não é algo que desenho depois que a arquitetura está pronta. É como eu encontro a arquitetura. E quando você achar que terminou, não fique admirando. Percorra. Cada seta que você ainda não consegue explicar mostra onde está o trabalho.
