Point de contrôle 1, dessiner et défendre la conception des données de Steve Trucking

Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · 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)

Un exercice original, fondé sur un scénario. Jamais calqué sur de vraies questions d’examen. Il est écrit dans le style « Ce que j’architecturerais » : l’enjeu est de rendre votre jugement visible, pas de choisir une lettre. Ce défi clôt la partie 1 du cours Data Architect ; mon parcours commenté se trouve au point de contrôle 1, alors essayez d’abord.

Scénario

Steve Trucking est une entreprise de livraison du dernier kilomètre. De grands distributeurs partenaires vendent de l’électroménager, des téléviseurs et des meubles ; les équipes de deux personnes de Steve Trucking les livrent aux clients des partenaires distributeurs (les destinataires), en installent certains et emportent les anciens. Lisez le dossier Steve Trucking (en anglais), sections 1 à 8. Laissez de côté la section 9 (les changements tardifs) ; ils arrivent à la fin du cours.

Exigences

Tout ce qui figure dans la section 5 (R1 à R15) et la section 6 (S1 à S5) du dossier. Celles sur lesquelles ce point de contrôle s’appuie le plus :

R1. Recevoir les manifestes de chaque partenaire distributeur dans son propre format (fichier SFTP, API, EDI) et les transformer en tournées, arrêts et articles sans ressaisie.
R3. Les responsables de centre de chaque partenaire distributeur voient dans le portail leurs propres livraisons, incidents, photos et réclamations, et jamais ceux d’un autre partenaire.
R4. Les manifestes sont révisés le jour même ; les changements après l’affectation aux tournées doivent être gérés.
S2. Un partenaire distributeur ne doit jamais voir les livraisons, les tarifs, les volumes ou les destinataires d’un autre partenaire.
S3. Le lien de suivi du destinataire ne montre que cette livraison-là, sans compte, et il expire.
S4. Les adresses, les numéros de téléphone et les notes de livraison des destinataires sont des données personnelles ; les équipes ne les voient que pour leurs propres arrêts, et seulement le jour même.

Contraintes

Environ 3 300 livraisons par jour ouvré, un million par an, en hausse de 30 % par an ; environ 1,6 article et huit changements de statut par livraison ; quatre à cinq millions de photos par an ; environ 200 000 relevés GPS par jour.
Une seule organisation Salesforce aux États-Unis, qui utilise déjà Service Cloud, Field Service et un portail partenaire ; MuleSoft sous licence ; Data 360 sous licence mais non mis en œuvre.
Trois partenaires distributeurs, trois styles d’intégration ; neuf centres de distribution.

Votre tâche

Dessinez et défendez la conception de la partie 1. Utilisez ce que vous avez appris aux chapitres 1 à 6 :

Le paysage (chapitre 4) : dessinez le paysage des systèmes de l’état actuel de Steve Trucking selon la disposition de Steve, chaque flèche étiquetée avec ce qui circule et comment.
Le modèle (chapitre 2) : modélisez le domaine des livraisons au niveau conceptuel, puis logique. Partenaires distributeurs, centres de distribution, manifestes, livraisons, articles, tournées, camions, équipes, listes de contrôle d’installation, photos, signatures, incidents et destinataires. (Défi D1.)
La conception physique (chapitre 3) : lesquels sont des objets standard (Field Service a les ordres d’exécution, les rendez-vous de service, les ressources de service et les territoires de service) et lesquels sont personnalisés ? De quelles licences ont besoin les utilisateurs partenaires et les destinataires ? Où vit chaque type de données : dans l’organisation, hors du cœur, dans l’entrepôt de données ?
La clé (ce chapitre) : quelle clé rapproche la ligne de commande d’un partenaire distributeur de votre livraison, et que se passe-t-il quand le manifeste est révisé après l’affectation aux tournées ? (Défi D3.)
Le destinataire (ce chapitre) : un contact, un compte personnel, ou ni l’un ni l’autre ? Argumentez à partir de la relation, du volume, de l’isolement entre partenaires et du cycle de vie des données.
Unifier ou non (ce chapitre) : des destinataires apparaissent dans les manifestes de plusieurs partenaires, parfois plus d’une fois par an. Les unifieriez-vous, ou délibérément pas ? Quel est le risque, compte tenu de S2 ? (Défi DC1, sans les changements tardifs.)
L’autorité : pour cinq champs clés (la référence de commande du partenaire, le statut de livraison, le numéro de téléphone du destinataire, le créneau de livraison, la raison sociale du partenaire), dites qui le crée, qui le possède, quel système fait autorité et qui peut le modifier.

Rédigez chaque décision avec les deux options, puis votre choix : « à mon avis de professionnel… »

Discussion

Mon parcours commenté est Point de contrôle 1 : Steve Trucking, ce que j’architecturerais. Comparez votre raisonnement, pas seulement vos boîtes. Là où vous avez choisi différemment, savez-vous dire ce que vous gagneriez et ce que vous abandonneriez ?

Revue de conception

Gardez votre conception pour l’instant. La partie 2 la met à l’épreuve face au volume, aux requêtes, à l’intégration, à la migration, aux transactions et à la sécurité, et la fiche de revue du chapitre 18 la vérifie à l’an trois.

Objectifs d’examen travaillés

DM-1, DM-2 (conception du modèle de données ; le modèle respecte le partage)
MDM-1, MDM-2, MDM-3, MDM-4 (maîtrise, autorité, rapprochement, traçabilité)
SDM-1 (licences), SDM-3 (une vue unique, et quand ne pas en construire une)