O panorama da Steve Trucking

🌐 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

Módulo 6 de 6 do capítulo Entendendo os dados corporativos, capítulo 4 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: A estratégia de orgs é uma decisão de panorama · Próximo: o próximo capítulo, Qualidade e governança de dados

A pergunta que este módulo responde: O que um panorama real nos diz antes de projetarmos qualquer coisa?

Este capítulo vem afastando a câmera: o Salesforce como um sistema entre muitos, os tipos de dados, os sistemas ao redor do Salesforce, como desenhar o panorama, e a estratégia de orgs. Agora vamos juntar tudo na Steve Trucking. Mas ainda não vamos consertar nada. Essa é a disciplina: desenhe o que existe, percorra cada seta, e veja o que o panorama nos diz.

Comece pelo que sabemos

A Steve Trucking roda uma org Salesforce, nos EUA. O Service Cloud trata os casos de Destinatários e Parceiros varejistas; o Field Service cuida dos agendamentos, das equipes e do app móvel; o Experience Cloud dá aos Parceiros varejistas um portal, usado hoje só para reclamações e relatórios; o Sales Cloud acompanha contratos com parceiros e propostas para novos CDs. Então o Salesforce vai no centro.

À esquerda, as pessoas: 45 coordenadores de despacho trabalhando dentro dos CDs dos Parceiros varejistas, cerca de 700 membros de equipe em 330 caminhões, 60 atendentes de relacionamento com o cliente, 40 pessoas de operações, finanças e vendas, e cerca de 300 usuários dos Parceiros varejistas. Isso já nos diz algo: este não é um CRM departamental. É uma plataforma operacional para a maior parte do negócio. Mas continua sendo uma caixa. Agora vamos ver o que a cerca.

Click to enlarge

A Steve Trucking hoje, antes de uma implementação de verdade. Todo manifesto chega ao RouteDesk; os coordenadores redigitam as rotas no Salesforce e as paradas concluídas de volta, à mão; ao FleetLink falta a sua conexão.

Marque o que está errado

Este é um estado atual, antes de uma implementação de verdade, e eu digo isso no desenho. Depois abro a paleta. No panorama de um sistema pronto não uso vermelho; num estado atual, uso. Vermelho marca um processo ruim ou inadequado, tracejado marca algo feito à mão, e pontos vermelhos marcam uma conexão que está faltando. Deixar uma seta de fora também diz alguma coisa. Nada disso é enfeite: cada linha vermelha é um requisito esperando para ser escrito.

Três parceiros, três integrações

Os três Parceiros varejistas enviam manifestos de três jeitos diferentes, então desenhe cada um separadamente.

A Keystone deixa um manifesto CSV num servidor SFTP toda tarde, para entrega dois dias depois, e quer um arquivo de status de volta toda noite. Duas setas: manifesto entrando por arquivo, aberta pela Keystone, e status saindo por arquivo, aberta pelo RouteDesk. Assíncrono, com uma janela de tempo larga.

A Redrock envia manifestos por uma API REST e espera atualizações de status por webhook à medida que acontecem. Duas setas, dois mecanismos: a Redrock chama com os manifestos pela API, e o RouteDesk chama com o status pelo webhook. Quase em tempo real.

A Brightwave envia arquivos EDI por uma rede de terceiros e espera mensagens de status EDI de volta. Outro formato, outro mecanismo.

Mesmos conceitos de negócio (manifesto, entrega, status), três integrações completamente diferentes. Não simplifique o desenho porque você gostaria que fossem consistentes. Não são. Esse é o estado atual.

Depois percorra-as. Keystone: como a conexão SFTP se autentica, onde o arquivo cai, o que o pega, como sabemos que o arquivo inteiro foi processado, o que acontece com uma linha ruim, e como a Keystone fica sabendo de uma mudança antes do arquivo desta noite? Redrock: como a API se autentica, o que acontece quando um dos lados está fora do ar, o que conta como um webhook bem-sucedido, e se o mesmo status chegar duas vezes? Brightwave: quem opera a rede EDI, onde fica a tradução, que confirmações voltam? Não estamos reprojetando nada. Estamos descobrindo as perguntas. Esse é o trabalho do panorama.

O RouteDesk ainda está lá

O RouteDesk é a ferramenta legada de despacho e roteirização para desktop que os coordenadores usam em cada CD para transformar manifestos em rotas. Ela guarda oito anos de histórico de entregas, e sua aposentadoria está programada. Desenhe-a mesmo assim. Um erro comum é deixar de fora o sistema “do qual estamos nos livrando”. Quando? Digamos que a resposta seja dezoito meses. Então ele faz parte da arquitetura por pelo menos dezoito meses, e seus oito anos de histórico, cerca de cinco milhões de entregas, não somem quando a aplicação some. E veja o que o panorama expõe: o RouteDesk e o Salesforce não estão conectados. As equipes trabalham as suas paradas no app de Field Service do Salesforce, mas as rotas são montadas no RouteDesk, então os coordenadores as redigitam no Salesforce toda noite, e depois redigitam as paradas concluídas de volta no RouteDesk para que ele possa enviar o status aos parceiros. Cerca de 3.300 paradas por dia, duas vezes, à mão. Isso fica tracejado e vermelho no desenho. Também lhe diz que o webhook “à medida que acontecem” da Redrock não é bem à medida que acontecem. Do que o RouteDesk é dono hoje? O que depende dele? Que histórico precisa sobreviver a ele, e onde: no Salesforce, no data warehouse, num arquivo? Ainda não estamos respondendo. O panorama só expôs as perguntas.

O FleetLink é uma ilha

O FleetLink, a plataforma de telemetria, recebe o GPS de cada caminhão: cerca de 200 mil leituras por dia, cada caminhão, cada minuto em que está rodando. E ele não está conectado a nada. Os coordenadores o olham numa tela separada. Então desenhe o FleetLink sem setas. Nenhuma linha de integração mágica porque achamos que deveria haver uma.

Depois conte os zeros: 200 mil por dia são mais de 70 milhões por ano. Isso não é “temos dados de GPS”. É uma fonte de streaming com muitos zeros, fora da experiência do Salesforce. O Salesforce precisa de 70 milhões de leituras por ano? Provavelmente não de todas. Essa é uma pergunta de design para depois.

O financeiro tem sua própria verdade

O ERP financeiro fatura cada Parceiro varejista por entrega, instalação e recolhimento, e paga os incentivos das equipes. E as contagens de entregas chegam até ele por uma planilha mensal. Desenhe a planilha. Não a substitua por uma seta de API arrumadinha porque somos arquitetos e sabemos mais; ela faz parte da arquitetura atual. E, depois de desenhada, as perguntas vêm: quem a faz, a partir de qual sistema, quem a confere, o que acontece se uma entrega muda depois do envio, e o número de quem vale? Há dinheiro atrelado às respostas.

O Snowflake recebe uma exportação semanal

O Snowflake guarda a análise de operações e finanças, alimentado por uma exportação semanal. O Snowflake não consegue fazer isso sozinho; algo no meio faz: um job de exportação programado, rodando fora do Salesforce, que puxa os dados pela Bulk API e carrega o Snowflake. Onde a análise vive segue onde os dados vivem, e o Snowflake já é a casa analítica. Mas o tempo também nos diz algo. “O que aconteceu no mês passado?” Um feed semanal serve. “Onde está esta entrega agora?” O Snowflake não é por onde eu começaria. Mesma empresa, carga de trabalho diferente, atualidade diferente, resposta diferente.

A identidade não chega a todos do mesmo jeito

O provedor de identidade corporativo vai acima do Salesforce. O pessoal de escritório usa single sign-on. Mas coordenadores e equipes entram com credenciais do Salesforce. Então uma única linha de confiança do IdP para o Salesforce esconderia metade da história. A pergunta real é quais usuários entram por qual caminho, e isso pertence ao panorama.

A experiência do Destinatário tem uma lacuna

O provedor de SMS e e-mail manda aos Destinatários uma mensagem genérica de “sua entrega é amanhã” a partir do RouteDesk. Não há link de rastreamento. Enquanto isso, há cerca de 180 mil casos por ano, e cerca de 60% deles são “cadê minha entrega?”: mais ou menos 108 mil casos por ano fazendo a mesma pergunta. Agora coloque isso ao lado do FleetLink. A empresa sabe onde estão seus caminhões. Seus Destinatários continuam ligando para perguntar. E o sistema que sabe não está conectado ao que responde. Ainda não preciso projetar a solução. O panorama já está contando a história.

Ponha os zeros no inventário

Agora conte o que se move. Como no módulo 4, os zeros não vão nas setas; vão no inventário por trás do desenho, onde vão determinar os mecanismos quando formos projetar. Cerca de um milhão de entregas por ano, cerca de 3.300 por dia, crescendo 30% ao ano; cerca de 1,6 item de linha cada; cerca de oito atualizações de status cada, então oito milhões de atualizações de status por ano hoje; quatro a cinco milhões de fotos por ano, hoje nos celulares pessoais das equipes; cerca de 200 mil leituras de GPS por dia; cerca de 180 mil casos por ano. Uma seta rotulada “status da entrega” não é uma mensagem ocasional. As caixas lhe dizem o que existe. As setas lhe dizem o que se move. Os zeros lhe dizem se as suas suposições sobrevivem à realidade.

Click to enlarge

O inventário por trás do panorama da Steve Trucking: o volume ao lado do mecanismo que ele vai determinar.

Ainda nenhuma arquitetura-alvo, e já consigo ver onde vivem os dados importantes, de que tipo são, com que rapidez se movem e como os sistemas os trocam.

Além do exame: o que a IA muda. Suponha que a Steve Trucking construa um agente para responder ao “cadê minha entrega?” de um Destinatário. A qual sistema ele deve perguntar? O Salesforce conhece o agendamento, o FleetLink sabe onde o caminhão está, o manifesto do parceiro definiu a entrega. O panorama atual é o mapa do agente e, antes que o agente possa responder com segurança, o arquiteto precisa saber qual sistema tem autoridade sobre cada fato e quão atual ele é. Aponte um agente para a fonte errada e dados desatualizados viram uma resposta confiante.

Leia a dor, não a conserte ainda

Dê um passo atrás. Três parceiros, três estilos de integração. Uma ferramenta de despacho legada guardando oito anos de histórico, e coordenadores redigitando 3.300 paradas por dia no Salesforce e de volta. Uma plataforma de telemetria com 200 mil leituras por dia, desconectada. O financeiro contando entregas a partir de uma planilha mensal. A análise uma semana atrasada. Single sign-on para alguns usuários, não para outros. Nenhum link de rastreamento, e 108 mil casos por ano perguntando onde está uma entrega. Tudo crescendo 30% ao ano.

É muita arquitetura saindo de um desenho. A tentação é começar a consertar. Não faça isso. Ainda não. Quero que você fique à vontade para deixar um diagrama de estado atual feio, porque às vezes o estado atual é feio. O ponto não é impressionar ninguém com um desenho limpo; é um entendimento compartilhado da realidade. Reprojete enquanto documenta e você perde a linha de base. Mais tarde quero poder dizer: isto é o que existia, este é o problema que resolvemos, isto é o que mudamos, e por quê. O capítulo 6 começa a tomar decisões sobre propriedade e identidade, e o Checkpoint 1 junta a Parte 1. O curso Integration Architect projeta os fluxos dos parceiros em profundidade.

O que um arquiteto decide aqui

Nesta etapa, o arquiteto não está decidindo a arquitetura-alvo. A decisão é se o estado atual está entendido bem o bastante para projetar uma:

• Quais sistemas, populações de usuários, repositórios de dados e parceiros externos existem de fato hoje.
• Que dados cruzam cada fronteira importante, em que direção, com que frequência e por qual mecanismo.
• Onde vivem agora os dados operacionais, analíticos, de streaming, históricos e não estruturados.
• Quais fluxos carregam mais volume e merecem atenção logo.
• Quais lacunas, etapas manuais, sistemas desconectados, autoridades pouco claras e padrões inconsistentes viram perguntas de design explícitas.

Este capítulo começou com uma ideia: desenhe o panorama antes de projetar a org. Se eu tivesse começado pelo modelo de dados da Steve Trucking, poderia ter passado horas em objetos e relacionamentos enquanto o FleetLink ficava lá fora com 200 mil leituras por dia, o RouteDesk guardava oito anos de histórico, três parceiros falavam três línguas, o financeiro usava uma planilha, e cem mil casos por ano perguntavam onde estava uma entrega. Essas não são perguntas de modelo de objetos. São perguntas de dados corporativos. Desenhe as integrações feias, a planilha, o sistema que você supostamente está aposentando. Anote os zeros. Percorra cada seta. Aí você está pronto para mudar.

Para saber mais

• O briefing da Steve Trucking (em inglês), seções 2–4, e seu diagrama de panorama.