A pergunta que este módulo responde: Como desenho um panorama que mostre para onde vão os dados?
Dê-me 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 utilizadores, que sistemas estão envolvidos, onde fica o Salesforce, o que o rodeia, de onde vêm os dados 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.
Ponho os candidatos a CTA a praticar isto. Leia o cenário, depois comece a desenhar. Não espere até ter resolvido tudo na cabeça; o desenho ajuda-o a resolver. É por isso que o trabalho de casa depois do primeiro dia é começar o panorama antes de arriscar o modelo de dados. Desenhe primeiro o modelo de dados e já presumiu o que pertence ao Salesforce. Desenhe primeiro o panorama e 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.
Há muitas formas de desenhar um panorama de sistemas. Esta é só a minha, uma que refinei ao longo de muitos anos, e partilho-a para que veja como montar um rapidamente. Uso este layout em todos os panoramas Salesforce, 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.
As pessoas à esquerda, de cima para baixo: utilizadores internos, parceiros, clientes. Ainda não cada persona; o suficiente para responder quem está a tentar chegar a esta arquitetura? Cada grupo aponta para onde entra: os utilizadores 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á a tentar usá-los.
Passo 2 de 6: quem está a tentar chegar a esta arquitetura?
O Salesforce no centro. Uma caixa simples. Não porque o Salesforce seja o centro da empresa (acabámos de passar três módulos a dizer que não é), mas porque é o sistema à volta do qual estou a projetar. É a âncora.
As comunidades logo abaixo dele, encostadas. Uma comunidade de parceiros e uma comunidade de clientes são pontos de acesso separados, por isso têm as suas próprias caixas. Mas ficam encostadas ao Salesforce, porque nada precisa de ser integrado para chegar a elas: correm na mesma org.
Passo 3 de 6: o Salesforce no centro, as comunidades logo abaixo dele.
A identidade acima. Os fornecedores de identidade vão no topo, aqueles de que os programadores se esquecem: um para os utilizadores internos, talvez outro para os parceiros. Os pacotes do AppExchange também vão lá para cima, deslocados para a direita, porque são capacidades trazidas para dentro da org, e não sistemas de back office a trocar dados com ela. Os sites públicos ficam no canto superior esquerdo.
Passo 4 de 6: a identidade acima, a caixa de que os programadores se esquecem.
A integração, depois o back office, à direita. A camada de integração, um ESB ou iPaaS (ou o MuleSoft, quando é referido), é uma barra alta logo à direita do Salesforce. Os sistemas internos ficam atrás dela: os ERPs, as finanças, a gestão de encomendas, os sistemas legados, o data warehouse. Agora a página lê-se 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 utilizadores nunca se ligam a ele, e o seu tenant liga-se a muitos sistemas de back-end, por isso fica com a canalização, onde essas linhas ficam curtas: ao lado dos sistemas internos, do data warehouse e dos dados no canto inferior direito. As equipas de dados abrem, sim, os seus ecrãs, mas esses ecrãs ficam na org: o Data 360 é próximo do núcleo (near-core), gerido no núcleo e alojado fora do núcleo (módulo 1). Uma linha de volta para o Salesforce mostra quem o gere. O lugar onde põe a caixa deve contar a história do que ela faz.
Nada desta geometria é sagrado. O valor de uma convenção é que não reinvento a linguagem visual de cada vez, e quem já viu um dos meus diagramas lê o seguinte mais depressa.
Mantenha a notação simples. Cada sistema é um cartão: o seu nome, o seu papel e um pequeno ícone que diz que tipo de coisa é: um ERP, uma base de dados, um fornecedor 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 em baixo diz o que cada ícone e cada linha significam.
Não ponha coisas a mais dentro de uma caixa. Só num panorama muito complicado é que abro o Salesforce nas 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 durante trinta segundos e comece a entender a arquitetura. Enfeites não ajudam. A clareza ajuda.
Não espere pelo design detalhado para pensar no volume. Uma seta que transporta 500 produtos por noite e uma que transporta 200 mil leituras de GPS por dia podem parecer exatamente iguais no panorama. Não são o mesmo problema. Por isso, 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 precisa de saber quando entra em números altos: milhares ou milhões numa 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 registos por noite são um lote (batch). Uma chamada pela qual alguém espera pode ser síncrona, se o volume o permitir. Dezenas a centenas por segundo podem precisar de eventos, como os platform events, em vez de uma chamada por registo. A seta vai parecer a mesma; o volume decide o que a transporta, por isso registe-o no inventário, onde o mecanismo é escolhido.
O mecanismo pode até mudar o sentido da seta. Envie um ou dois registos 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 subscreve-os e chama o Salesforce para os ir buscar, por isso agora a seta começa na outra ponta. Maior ainda, digamos uma sincronização noturna de milhões de registos, e é um processo em lote. Por isso, 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 vigiar os grandes volumes de dados e planear o arquivamento; a Parte 2 aprofunda isso. 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 põe zeros reais no panorama da Steve Trucking e no seu inventário. Com as contagens na mão, desenhe as setas.
Com os sistemas no lugar, ligue-os, e o panorama torna-se arquitetura. Uma caixa é um sistema; a seta mostra quem inicia a ligação. Começa no sistema que abre a ligaçã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.
Esta regra vale para os panoramas de sistemas, onde sistemas falam com sistemas. Num diagrama de fluxo de dados, a seta segue os dados, como seria de esperar. Não leve a regra do panorama para outros diagramas; só acrescenta confusão.
As setas chegaram. Cada caixa está onde estava; cada seta começa no sistema que abre a ligação, e o seu rótulo diz o que se move e em que sentido.
Por isso, 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 os ir buscar, a seta começa no Salesforce, ainda rotulada produtos entram. Os mesmos dados, uma conversa diferente, e essa diferença diz-me quem precisa das credenciais e quem tem de lidar com a falha. O Salesforce envia a encomenda pela camada de integração: encomendas saem. O processamento do ERP volta: estado da encomenda entra. Agora consigo ver quem começa cada conversa, onde os dados entram no Salesforce e onde saem, que fluxos atravessam fronteiras, onde provavelmente está a propriedade, e onde preciso de perguntar mais.
E lembre-se do módulo 1: sempre que vejo um só fluxo, fico preocupado. Ao nível alto, uma seta de encomendas saem depende de fluxos de retorno: clientes entram, produtos entram, preços. Olhe ainda mais a fundo e lá está a viagem de volta: aceitação, rejeição, estado, um número de fatura, um cancelamento. As setas dão-me algo concreto para questionar.
É aqui que o panorama deixa de ser arte de PowerPoint. No painel de revisão, qualquer seta pode atrair três perguntas, e quero que tenha as respostas:
Como se autentica? OAuth, um certificado, uma credencial nomeada, outra coisa?
É síncrona ou assíncrona? O Salesforce espera pelo ERP, ou publica e segue em frente? Com que rapidez precisa o negócio do resultado?
Qual é o mecanismo? Uma chamada REST, um evento, um ficheiro, uma fila de mensagens, pelo MuleSoft ou direto?
E depois: o que acontece quando o outro lado está em baixo? Cada seta precisa de um mecanismo. Se não o consegue explicar, 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 aceite? Falhou? Vai tentar de novo? Quem sabe que encravou? E se a mesma mensagem chegar duas vezes? Nada disto vai no panorama, que ficaria ilegível. Mas a seta deve fazê-lo saber que estas perguntas existem.
Aproxime o zoom de qualquer seta e há um cliente e um servidor, e cada um é dono da sua metade. O cliente abre a ligação: 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, por isso 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 diz-me quem é dono de cada uma destas perguntas.
Uma seta, vista de perto: o cliente trata, o servidor define. Nada disto vai para o panorama, mas cada seta tem isto.
Agora inverta a seta. Quando o ERP chama o Salesforce, o Salesforce é o servidor: define as APIs, corre o seu próprio servidor de autorização, e decide, através de uma External Client App (aplicação cliente externa) e de um utilizador 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 artefacto responder a tudo. O panorama ganha nomes de API, payloads, novas tentativas, filas de erro, transformações, cada callback, e em pouco tempo ninguém o consegue ler. Não faça isso. O panorama é o quadro geral: os sistemas e os fluxos importantes entre eles.
Quando preciso de 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 se torna uma conversa: A chama B, B consulta C, C responde, B cria algo e volta a chamar A, uma pessoa aprova, outro sistema continua. A minha regra prática: mais do que uma ou duas idas e voltas, e a sequência ganha a 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 ligação: quem a abre, e o que se move. Numa raia, cada seta é uma mensagem numa conversa, lida por ordem: um pedido vai num sentido, uma resposta volta no outro, e o passo seguinte vem a seguir.
Quando o panorama parecer quase pronto, percorra-o, seta a seta. ERP para Salesforce: o que se está a mover, quem é o dono, como se autentica, qual é o mecanismo, síncrono ou assíncrono, quão atual tem de estar? Depois a seta seguinte, e a seguinte. É aqui que as lacunas aparecem. «Ah, nunca descobrimos como o parceiro envia realmente aquilo.» «Enviamos as encomendas para o ERP, mas não projetámos como voltam as rejeitadas.» Ótimo. Encontrou isso no quadro branco em vez de em produção.
O desenho tem de continuar legível, por isso os pormenores vão para o inventário por trás dele. Começou-o 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, encomenda, entrega, fatura
Tipo
Mestre, de referência, transacional, analítico, não estruturado
Dono
Quem é dono do seu significado e do seu ciclo de vida?
É por isso que gosto deste artefacto: ajuda-me a pensar. «Como vamos fazer relatórios que cruzem Salesforce e ERP?» É a pergunta do módulo 3: qual dos meus diagramas resolve isto lindamente? O panorama. Se está tudo no núcleo, relatórios padrão. Se os dados estão no ERP e no data warehouse, vê-se isso de imediato. «Onde deve ser mestre este atributo do cliente?» Veja que 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. Dá-lhe a visão certa do problema.
Mais uma disciplina. Numa empresa existente, desenhe o que existe, não o que gostaria que existisse. A folha de cálculo enviada por e-mail todas as sextas: desenhe-a. O CSV do parceiro num servidor SFTP: desenhe-o. A integração que contorna o ESB por razões históricas: desenhe-a. Pessoas a voltar a escrever dados entre dois sistemas: mostre-o. Não limpe a realidade enquanto a documenta. 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á a tornar-se um mapa de agentes. Se um agente responde «onde está a minha entrega?», o panorama tem de 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; tornam ainda mais importante saber que sistema tem autoridade, e como chegar a ele com segurança.
Que sistemas e populações de utilizadores pertencem ao panorama, e como a sua posição mostra o seu papel.
Que fluxos atravessam fronteiras entre sistemas, em que direção, e o que volta.
Como cada ligação se autentica, que mecanismo a transporta, e se é 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 de a arquitetura estar pronta. É a forma como encontro a arquitetura. E quando achar que terminou, não fique a admirá-lo. Percorra-o. Cada seta que ainda não consegue explicar mostra onde está o trabalho.
