Pular para o conteúdo

Checkpoint 1, desenhe e defenda o design de dados 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)

Prática original, baseada em cenário. Nunca inspirada em perguntas reais do exame. Ela é escrita no estilo “O que eu arquitetaria”: o objetivo é tornar visível o seu discernimento, não escolher uma letra. Este desafio encerra a Parte 1 do curso Data Architect; meu passo a passo vem no Checkpoint 1, então tente primeiro.

A Steve Trucking é uma empresa de entregas de última milha. Grandes Parceiros varejistas vendem eletrodomésticos, TVs e móveis; as equipes de duas pessoas da Steve Trucking os entregam aos clientes dos Parceiros varejistas (os Destinatários), instalam alguns e recolhem os antigos. Leia o briefing da Steve Trucking (em inglês), seções 1–8. Deixe a seção 9 (as mudanças de última hora) de lado; elas vêm no fim do curso.

Tudo o que está na seção 5 (R1–R15) e na seção 6 (S1–S5) do briefing. Os de que este checkpoint mais depende:

  • R1. Receber os manifestos de cada Parceiro varejista no formato dele (arquivo SFTP, API, EDI) e transformá-los em rotas, paradas e itens de linha sem redigitação.
  • R3. Os gerentes de CD de cada Parceiro varejista veem no portal suas próprias entregas, exceções, fotos e reclamações, e nunca as de outro parceiro.
  • R4. Os manifestos são revisados no próprio dia; mudanças depois da roteirização precisam ser tratadas.
  • S2. Um Parceiro varejista nunca pode ver as entregas, os preços, os volumes ou os Destinatários de outro parceiro.
  • S3. O link de rastreamento do Destinatário mostra só aquela entrega, sem conta, e expira.
  • S4. Os endereços, telefones e observações de entrega dos Destinatários são dados pessoais; as equipes os veem só nas suas próprias paradas, só no dia.
  • Cerca de 3.300 entregas por dia útil, um milhão por ano, crescendo 30% ao ano; cerca de 1,6 item de linha e oito mudanças de status por entrega; quatro a cinco milhões de fotos por ano; cerca de 200 mil leituras de GPS por dia.
  • Uma org Salesforce nos EUA, que já roda Service Cloud, Field Service e um portal de parceiros; MuleSoft licenciado; Data 360 licenciado, mas não implementado.
  • Três Parceiros varejistas, três estilos de integração; nove centros de distribuição.

Desenhe e defenda o design da Parte 1. Use o que você aprendeu nos capítulos 1–6:

  1. O panorama (capítulo 4): desenhe o panorama de sistemas do estado atual da Steve Trucking no layout do Steve, com cada seta rotulada com o que se move e como.
  2. O modelo (capítulo 2): modele o domínio das entregas de forma conceitual, depois lógica. Parceiros varejistas, centros de distribuição, manifestos, entregas, itens de linha, rotas, caminhões, equipes, checklists de instalação, fotos, assinaturas, exceções e Destinatários. (Desafio D1.)
  3. O design físico (capítulo 3): quais deles são objetos padrão (o Field Service tem ordens de serviço, compromissos de serviço, recursos de serviço e territórios de serviço) e quais são personalizados? De quais licenças os usuários parceiros e os Destinatários precisam? Onde vive cada tipo de dado: na org, fora do núcleo, no data warehouse?
  4. A chave (este capítulo): que chave casa a linha de pedido de um Parceiro varejista com a sua entrega, e o que acontece quando o manifesto é revisado depois da roteirização? (Desafio D3.)
  5. O Destinatário (este capítulo): um Contato, uma conta pessoal, ou nenhum dos dois? Argumente a partir do relacionamento, do volume, do isolamento entre parceiros e do ciclo de vida dos dados.
  6. Unificar ou não (este capítulo): os Destinatários aparecem nos manifestos de vários parceiros, às vezes mais de uma vez por ano. Você os unificaria, ou deliberadamente não? Qual é o risco, dado o S2? (Desafio DC1, sem as mudanças de última hora.)
  7. Autoridade: para cinco campos-chave (a referência de pedido do parceiro, o status da entrega, o telefone do Destinatário, a janela de entrega, a razão social do parceiro), diga quem o cria, quem é o dono, qual sistema tem autoridade e quem pode alterá-lo.

Escreva cada decisão com as duas opções, e depois a sua escolha: “na minha opinião profissional…”

Meu passo a passo é o Checkpoint 1: Steve Trucking, o que eu arquitetaria. Compare o seu raciocínio, não só as suas caixas. Onde você escolheu diferente, consegue dizer o que ganharia e do que abriria mão?

Guarde o seu design por enquanto. A Parte 2 o testa contra volume, consultas, integração, migração, transações e segurança, e o cartão de revisão do capítulo 18 o confere no terceiro ano.

  • DM-1, DM-2 (design do modelo de dados; o modelo respeita o compartilhamento)
  • MDM-1, MDM-2, MDM-3, MDM-4 (gerenciamento de dados mestres, autoridade, correspondência, rastreabilidade)
  • SDM-1 (licenças), SDM-3 (uma visão única, e quando não construir uma)