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

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

Prática original, baseada em cenário. Nunca inspirada em perguntas reais do exame. Está escrita ao 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; a minha resolução comentada vem no Checkpoint 1, por isso tente primeiro.

Cenário

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

Requisitos

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

• R1. Receber os manifestos de cada Parceiro retalhista no formato dele (ficheiro SFTP, API, EDI) e transformá-los em rotas, paragens e itens de linha sem voltar a escrever nada.
• R3. Os gestores de CD de cada Parceiro retalhista veem no portal as suas próprias entregas, exceções, fotografias e reclamações, e nunca as de outro parceiro.
• R4. Os manifestos são revistos no próprio dia; as mudanças depois do planeamento das rotas têm de ser tratadas.
• S2. Um Parceiro retalhista nunca pode ver as entregas, os preços, os volumes ou os Destinatários de outro parceiro.
• S3. O link de seguimento do Destinatário mostra só aquela entrega, sem conta, e expira.
• S4. As moradas, telefones e notas de entrega dos Destinatários são dados pessoais; as equipas veem-nos só nas suas próprias paragens, só no dia.

Restrições

• Cerca de 3.300 entregas por dia útil, um milhão por ano, a crescer 30% ao ano; cerca de 1,6 itens de linha e oito mudanças de estado por entrega; quatro a cinco milhões de fotografias por ano; cerca de 200 mil leituras de GPS por dia.
• Uma org Salesforce nos EUA, que já corre Service Cloud, Field Service e um portal de parceiros; MuleSoft licenciado; Data 360 licenciado, mas não implementado.
• Três Parceiros retalhistas, três estilos de integração; nove centros de distribuição.

A sua tarefa

Desenhe e defenda o design da Parte 1. Use o que 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 retalhistas, centros de distribuição, manifestos, entregas, itens de linha, rotas, camiões, equipas, checklists de instalação, fotografias, 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 trabalho, marcações de serviço, recursos de serviço e territórios de serviço) e quais são personalizados? De que licenças precisam os utilizadores parceiros e os Destinatários? Onde vive cada tipo de dado: na org, fora do núcleo, no data warehouse?
4. A chave (este capítulo): que chave faz corresponder a linha de encomenda de um Parceiro retalhista à sua entrega, e o que acontece quando o manifesto é revisto depois do planeamento das rotas? (Desafio D3.)
5. O Destinatário (este capítulo): um Contacto, uma conta pessoal, ou nenhum dos dois? Argumente a partir da relação, 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 do que uma vez por ano. Unificá-los-ia, 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 encomenda do parceiro, o estado da entrega, o telefone do Destinatário, a janela de entrega, a denominação social do parceiro), diga quem o cria, quem é o dono, que sistema tem autoridade e quem o pode alterar.

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

Discussão

A minha resolução comentada é o Checkpoint 1: Steve Trucking, o que eu arquitetaria. Compare o seu raciocínio, não só as suas caixas. Onde escolheu de forma diferente, consegue dizer o que ganharia e de que abdicaria?

Revisão do design

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

Objetivos do exame exercitados

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