O panorama da Steve Trucking

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

Imagem gerada com IA

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

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

A pergunta que este módulo responde: O que nos diz um panorama real antes de projetarmos seja o que for?

Este capítulo tem andado a afastar a câmara: o Salesforce como um sistema entre muitos, os tipos de dados, os sistemas à volta do Salesforce, como desenhar o panorama, e a estratégia de orgs. Agora vamos juntar tudo na Steve Trucking. Mas ainda não vamos corrigir 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 corre uma org Salesforce, nos EUA. O Service Cloud trata os casos de Destinatários e Parceiros retalhistas; o Field Service trata das marcações, das equipas e da aplicação móvel; o Experience Cloud dá aos Parceiros retalhistas um portal, usado hoje só para reclamações e relatórios; o Sales Cloud acompanha contratos com parceiros e propostas para novos CD. Por isso o Salesforce vai no centro.

À esquerda, as pessoas: 45 coordenadores de expedição a trabalhar dentro dos CD dos Parceiros retalhistas, cerca de 700 membros de equipa em 330 camiões, 60 agentes de relação com o cliente, 40 pessoas de operações, finanças e vendas, e cerca de 300 utilizadores dos Parceiros retalhistas. Isso já nos diz algo: este não é um CRM departamental. É uma plataforma operacional para a maior parte do negócio. Mas continua a ser uma caixa. Agora vamos ver o que a rodeia.

Click to enlarge

A Steve Trucking hoje, antes de uma implementação a sério. Cada manifesto chega ao RouteDesk; os coordenadores reintroduzem as rotas no Salesforce e as paragens concluídas de volta, à mão; ao FleetLink falta a sua ligação.

Marque o que está errado

Este é um estado atual, antes de uma implementação a sério, e digo-o no desenho. Depois abro a paleta. No panorama de um sistema acabado não uso vermelho; num estado atual, uso. Vermelho marca um processo mau ou inadequado, tracejado marca algo feito à mão, e pontos vermelhos marcam uma ligação que está em falta. Deixar uma seta de fora também diz alguma coisa. Nada disto é enfeite: cada linha vermelha é um requisito à espera de ser escrito.

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

Os três Parceiros retalhistas enviam manifestos de três formas diferentes, por isso desenhe cada um separadamente.

A Keystone deixa um manifesto CSV num servidor SFTP todas as tardes, para entrega dois dias depois, e quer um ficheiro de estado de volta todas as noites. Duas setas: manifesto a entrar por ficheiro, aberta pela Keystone, e estado a sair por ficheiro, aberta pelo RouteDesk. Assíncrono, com uma janela de tempo larga.

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

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

Os mesmos conceitos de negócio (manifesto, entrega, estado), três integrações completamente diferentes. Não simplifique o desenho por gostar que fossem consistentes. Não são. Esse é o estado atual.

Depois percorra-as. Keystone: como se autentica a ligação SFTP, onde cai o ficheiro, o que o vai buscar, como sabemos que o ficheiro inteiro foi processado, o que acontece a uma linha má, e como fica a Keystone a saber de uma mudança antes do ficheiro desta noite? Redrock: como se autentica a API, o que acontece quando um dos lados está em baixo, o que conta como um webhook bem-sucedido, e se o mesmo estado chegar duas vezes? Brightwave: quem opera a rede EDI, onde fica a tradução, que confirmações voltam? Não estamos a reprojetar nada. Estamos a descobrir as perguntas. Esse é o trabalho do panorama.

O RouteDesk continua lá

O RouteDesk é a ferramenta legada de expedição e planeamento de rotas para desktop que os coordenadores usam em cada CD para transformar manifestos em rotas. Guarda oito anos de histórico de entregas, e a sua retirada está programada. Desenhe-o na mesma. Um erro comum é deixar de fora o sistema «de que nos estamos a livrar». Quando? Digamos que a resposta é dezoito meses. Então faz parte da arquitetura durante pelo menos dezoito meses, e os seus oito anos de histórico, cerca de cinco milhões de entregas, não desaparecem quando a aplicação desaparece. E veja o que o panorama expõe: o RouteDesk e o Salesforce não estão ligados. As equipas trabalham as suas paragens na aplicação de Field Service do Salesforce, mas as rotas são montadas no RouteDesk, por isso os coordenadores reintroduzem-nas no Salesforce todas as noites, e depois reintroduzem as paragens concluídas de volta no RouteDesk para que ele possa enviar o estado aos parceiros. Cerca de 3.300 paragens por dia, duas vezes, à mão. Isso fica tracejado e a vermelho no desenho. Também lhe diz que o webhook «à medida que acontecem» da Redrock não é bem à medida que acontecem. De que é o RouteDesk dono hoje? O que depende dele? Que histórico tem de lhe sobreviver, e onde: no Salesforce, no data warehouse, num arquivo? Ainda não estamos a responder. O panorama só expôs as perguntas.

O FleetLink é uma ilha

O FleetLink, a plataforma de telemetria, recebe o GPS de cada camião: cerca de 200 mil leituras por dia, cada camião, cada minuto em que está em andamento. E não está ligado a nada. Os coordenadores olham para ele num ecrã separado. Por isso desenhe o FleetLink sem setas. Nenhuma linha de integração mágica por acharmos 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. É uma pergunta de design para depois.

As finanças têm a sua própria verdade

O ERP financeiro fatura cada Parceiro retalhista por entrega, instalação e recolha, e paga os incentivos das equipas. E as contagens de entregas chegam até ele por uma folha de cálculo mensal. Desenhe a folha de cálculo. Não a substitua por uma seta de API arrumadinha por sermos arquitetos e sabermos mais; faz parte da arquitetura atual. E, depois de desenhada, vêm as perguntas: quem a faz, a partir de que sistema, quem a confere, o que acontece se uma entrega muda depois do envio, e o número de quem conta? Há dinheiro associado à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, a correr fora do Salesforce, que extrai os dados pela Bulk API e carrega o Snowflake. Onde vive a análise segue onde vivem os dados, 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. A mesma empresa, outra carga de trabalho, outra atualidade, outra resposta.

A identidade não chega a todos da mesma forma

O fornecedor de identidade empresarial vai acima do Salesforce. O pessoal de escritório usa single sign-on. Mas coordenadores e equipas entram com credenciais do Salesforce. Por isso uma única linha de confiança do IdP para o Salesforce esconderia metade da história. A pergunta real é que utilizadores entram por que caminho, e isso pertence ao panorama.

A experiência do Destinatário tem uma lacuna

O fornecedor de SMS e e-mail envia aos Destinatários uma mensagem genérica de «a sua entrega é amanhã» a partir do RouteDesk. Não há link de seguimento. Entretanto, há cerca de 180 mil casos por ano, e cerca de 60% deles são «onde está a minha entrega?»: mais ou menos 108 mil casos por ano a fazer a mesma pergunta. Agora ponha isso ao lado do FleetLink. A empresa sabe onde estão os seus camiões. Os seus Destinatários continuam a telefonar para perguntar. E o sistema que sabe não está ligado ao que responde. Ainda não preciso de projetar a solução. O panorama já está a contar 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, a crescer 30% ao ano; cerca de 1,6 itens de linha cada; cerca de oito atualizações de estado cada, portanto oito milhões de atualizações de estado por ano hoje; quatro a cinco milhões de fotografias por ano, atualmente nos telemóveis pessoais das equipas; cerca de 200 mil leituras de GPS por dia; cerca de 180 mil casos por ano. Uma seta rotulada «estado da entrega» não é uma mensagem ocasional. As caixas dizem-lhe o que existe. As setas dizem-lhe o que se move. Os zeros dizem-lhe 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 constrói um agente para responder ao «onde está a minha entrega?» de um Destinatário. A que sistema deve perguntar? O Salesforce conhece a marcação, o FleetLink sabe onde está o camião, o manifesto do parceiro definiu a entrega. O panorama atual é o mapa do agente e, antes de o agente poder responder com segurança, o arquiteto precisa de saber que sistema tem autoridade sobre cada facto e quão atual ele é. Aponte um agente para a fonte errada e dados desatualizados tornam-se uma resposta confiante.

Leia a dor, não a corrija ainda

Dê um passo atrás. Três parceiros, três estilos de integração. Uma ferramenta de expedição legada a guardar oito anos de histórico, e coordenadores a reintroduzir 3.300 paragens por dia no Salesforce e de volta. Uma plataforma de telemetria com 200 mil leituras por dia, desligada. As finanças a contar entregas a partir de uma folha de cálculo mensal. A análise uma semana atrasada. Single sign-on para alguns utilizadores, não para outros. Nenhum link de seguimento, e 108 mil casos por ano a perguntar onde está uma entrega. Tudo a crescer 30% ao ano.

É muita arquitetura a sair de um desenho. A tentação é começar a corrigir. Não o faça. Ainda não. Quero que se sinta à 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 partilhado da realidade. Reprojete enquanto documenta e perde a linha de base. Mais tarde quero poder dizer: isto é o que existia, este é o problema que resolvemos, isto é o que mudámos, e porquê. 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á a decidir a arquitetura-alvo. A decisão é se o estado atual está suficientemente bem entendido para projetar uma:

• Que sistemas, populações de utilizadores, repositórios de dados e parceiros externos existem de facto hoje.
• Que dados atravessam cada fronteira importante, em que direção, com que frequência e por que mecanismo.
• Onde vivem agora os dados operacionais, analíticos, de streaming, históricos e não estruturados.
• Que fluxos transportam mais volume e merecem atenção cedo.
• Que lacunas, etapas manuais, sistemas desligados, autoridades pouco claras e padrões inconsistentes se tornam perguntas de design explícitas.

Este capítulo começou com uma ideia: desenhe o panorama antes de projetar a org. Se tivesse começado pelo modelo de dados da Steve Trucking, poderia ter passado horas em objetos e relações 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, as finanças usavam uma folha de cálculo, e cem mil casos por ano perguntavam onde estava uma entrega. Estas não são perguntas de modelo de objetos. São perguntas de dados empresariais. Desenhe as integrações feias, a folha de cálculo, o sistema que supostamente está a retirar. Anote os zeros. Percorra cada seta. Aí está pronto para mudar.

Para saber mais

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