Le paysage de Steve Trucking

🌐 Aussi en 28 langues

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

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Module 6 sur 6 du chapitre Comprendre les données de l’entreprise, chapitre 4 du cours Data Architect. Chaque module est autonome. Précédent : La stratégie d’organisation est une décision de paysage · Suivant : le chapitre suivant, Qualité et gouvernance des données

La question à laquelle répond ce module : que nous dit un vrai paysage avant que nous concevions quoi que ce soit ?

Ce chapitre a reculé la caméra : Salesforce comme un système parmi d’autres, les types de données, les systèmes autour de Salesforce, comment dessiner le paysage, et la stratégie d’organisation. Assemblons maintenant tout cela sur Steve Trucking. Mais nous n’allons encore rien corriger. C’est ça, la discipline : dessiner ce qui existe, parcourir chaque flèche, et voir ce que le paysage nous dit.

Partez de ce que nous savons

Steve Trucking a une seule organisation Salesforce, aux États-Unis. Service Cloud gère les requêtes des destinataires et des partenaires distributeurs ; Field Service gère les rendez-vous, les équipes et l’application mobile ; Experience Cloud donne aux partenaires distributeurs un portail, utilisé aujourd’hui seulement pour les réclamations et les rapports ; Sales Cloud suit les contrats des partenaires et les appels d’offres pour de nouveaux centres de distribution. Salesforce va donc au centre.

À gauche, les personnes : 45 coordinateurs de répartition qui travaillent dans les centres de distribution des partenaires distributeurs, environ 700 membres d’équipe sur 330 camions, 60 agents du service client, 40 personnes des opérations, de la finance et des ventes, et environ 300 utilisateurs chez les partenaires distributeurs. Cela nous dit déjà quelque chose : ce n’est pas un CRM de service. C’est une plateforme opérationnelle pour la plus grande partie de l’entreprise. Mais c’est toujours une seule boîte. Voyons maintenant ce qui l’entoure.

Click to enlarge

Steve Trucking aujourd’hui, avant une vraie mise en œuvre. Chaque manifeste arrive dans RouteDesk ; les coordinateurs ressaisissent les tournées dans Salesforce et les arrêts terminés en retour, à la main ; il manque à FleetLink sa connexion.

Marquez ce qui ne va pas

C’est un état actuel, avant une vraie mise en œuvre, et je le dis sur le dessin. Ensuite, j’ouvre la palette. Sur le paysage d’un système terminé, je n’utilise pas de rouge ; sur un état actuel, si. Le rouge marque un processus mauvais ou inadapté, les tirets marquent quelque chose fait à la main, et les points rouges marquent une connexion qui manque. Laisser une flèche de côté dit aussi quelque chose. Rien de tout cela n’est de la décoration : chaque ligne rouge est une exigence qui attend d’être écrite.

Trois partenaires, trois intégrations

Les trois partenaires distributeurs envoient leurs manifestes de trois façons différentes, alors dessinez chacun séparément.

Keystone dépose chaque après-midi un manifeste CSV sur un serveur SFTP, pour une livraison deux jours plus tard, et veut un fichier de statut en retour chaque nuit. Deux flèches : le manifeste en entrée par fichier, ouvert par Keystone, et le statut en sortie par fichier, ouvert par RouteDesk. Asynchrone, avec une large fenêtre de temps.

Redrock envoie ses manifestes par une API REST et attend des mises à jour de statut par webhook au fil de l’eau. Deux flèches, deux mécanismes : Redrock appelle avec les manifestes par l’API, et RouteDesk appelle vers l’extérieur avec le statut par le webhook. En quasi temps réel.

Brightwave envoie des fichiers EDI par un réseau tiers et attend des messages de statut EDI en retour. Un autre format, un autre mécanisme.

Les mêmes concepts métier (manifeste, livraison, statut), trois intégrations complètement différentes. Ne simplifiez pas le dessin parce que vous aimeriez qu’elles soient cohérentes. Elles ne le sont pas. C’est l’état actuel.

Puis parcourez-les. Keystone : comment la connexion SFTP s’authentifie-t-elle, où atterrit le fichier, qu’est-ce qui le récupère, comment savons-nous que tout le fichier a été traité, qu’arrive-t-il à une ligne erronée, et comment Keystone apprend-il un changement avant le fichier de ce soir ? Redrock : comment l’API s’authentifie-t-elle, que se passe-t-il quand l’un des deux côtés est en panne, qu’est-ce qui compte comme un webhook réussi, et si le même statut arrive deux fois ? Brightwave : qui gère le réseau EDI, où se fait la traduction, quels accusés de réception reviennent ? Nous ne reconcevons rien. Nous découvrons les questions. C’est le travail du paysage.

RouteDesk est toujours là

RouteDesk est l’outil de bureau hérité de répartition et de tournées que les coordinateurs utilisent dans chaque centre de distribution pour transformer les manifestes en tournées. Il contient huit ans d’historique de livraisons, et son retrait est prévu. Dessinez-le quand même. Une erreur courante consiste à laisser de côté le système « dont on se débarrasse ». Quand ? Disons que la réponse est dix-huit mois. Alors il fait partie de l’architecture pendant au moins dix-huit mois, et ses huit ans d’historique, environ cinq millions de livraisons, ne disparaissent pas avec l’application. Et regardez ce que le paysage met au jour : RouteDesk et Salesforce ne sont pas connectés. Les équipes travaillent leurs arrêts dans l’application Field Service de Salesforce, mais les tournées sont construites dans RouteDesk, alors les coordinateurs les ressaisissent dans Salesforce chaque soir, puis ressaisissent les arrêts terminés dans RouteDesk pour qu’il puisse envoyer le statut aux partenaires. Environ 3 300 arrêts par jour, deux fois, à la main. Sur le dessin, c’est en tirets et en rouge. Cela vous dit aussi que le webhook « au fil de l’eau » de Redrock n’est pas vraiment au fil de l’eau. Que possède RouteDesk aujourd’hui ? Qu’est-ce qui dépend de lui ? Quel historique doit lui survivre, et où : Salesforce, l’entrepôt de données, une archive ? Nous ne répondons pas encore. Le paysage vient simplement de mettre les questions au jour.

FleetLink est une île

FleetLink, la plateforme télématique, reçoit le GPS de chaque camion : environ 200 000 relevés par jour, chaque camion, chaque minute où il roule. Et il n’est connecté à rien. Les coordinateurs le consultent sur un écran séparé. Alors dessinez FleetLink sans flèches. Pas de trait d’intégration magique parce que nous pensons qu’il devrait y en avoir un.

Puis comptez les zéros : 200 000 par jour, cela fait plus de 70 millions par an. Ce n’est pas « nous avons des données GPS ». C’est une source en flux avec beaucoup de zéros, qui se trouve en dehors de l’expérience Salesforce. Salesforce a-t-il besoin de 70 millions de relevés par an ? Probablement pas de tous. C’est une question de conception pour plus tard.

La finance a sa propre vérité

L’ERP financier facture chaque partenaire distributeur par livraison, installation et enlèvement, et paie les primes des équipes. Et le nombre de livraisons lui parvient par un tableur mensuel. Dessinez le tableur. Ne le remplacez pas par une jolie flèche d’API parce que nous sommes architectes et que nous savons mieux ; il fait partie de l’architecture actuelle. Et une fois dessiné, les questions arrivent : qui le fait, à partir de quel système, qui le vérifie, que se passe-t-il si une livraison change après l’envoi, et quel chiffre l’emporte ? Il y a de l’argent attaché aux réponses.

Snowflake reçoit un export hebdomadaire

Snowflake contient l’analytique des opérations et de la finance, alimenté par un export hebdomadaire. Snowflake ne peut pas le faire lui-même ; c’est quelque chose au milieu qui s’en charge : une tâche d’export planifiée, qui tourne en dehors de Salesforce, extrait les données via la Bulk API et les charge dans Snowflake. L’analytique vit là où vivent les données, et Snowflake est déjà la maison de l’analytique. Mais le rythme nous dit aussi quelque chose. « Que s’est-il passé le mois dernier ? » Un flux hebdomadaire convient. « Où est cette livraison en ce moment ? » Ce n’est pas par Snowflake que je commencerais. Même entreprise, charge de travail différente, fraîcheur différente, réponse différente.

L’identité n’atteint pas tout le monde de la même façon

Le fournisseur d’identité de l’entreprise se place au-dessus de Salesforce. Le personnel de bureau utilise l’authentification unique. Mais les coordinateurs et les équipes se connectent avec des identifiants Salesforce. Une seule ligne de confiance de l’IdP vers Salesforce cacherait donc la moitié de l’histoire. La vraie question est quels utilisateurs se connectent par quel chemin, et cela a sa place sur le paysage.

L’expérience du destinataire a un trou

Le fournisseur de SMS et de courriels envoie aux destinataires un message générique « votre livraison est prévue demain » depuis RouteDesk. Il n’y a pas de lien de suivi. Pendant ce temps, il y a environ 180 000 requêtes par an, et environ 60 % d’entre elles sont « où est ma livraison ? » : environ 108 000 requêtes par an qui posent la même question. Mettez maintenant cela à côté de FleetLink. L’entreprise sait où sont ses camions. Ses destinataires continuent d’appeler pour le demander. Et le système qui sait n’est pas connecté à celui qui répond. Je n’ai pas encore besoin de concevoir la solution. Le paysage raconte déjà l’histoire.

Mettez les zéros dans l’inventaire

Maintenant, comptez ce qui circule. Comme au module 4, les zéros ne vont pas sur les flèches ; ils vont dans l’inventaire derrière l’image, où ils détermineront les mécanismes quand nous concevrons. Environ un million de livraisons par an, environ 3 300 par jour, en croissance de 30 % par an ; environ 1,6 article par livraison ; environ huit mises à jour de statut chacune, donc huit millions de mises à jour de statut par an aujourd’hui ; quatre à cinq millions de photos par an, actuellement sur les téléphones personnels des équipes ; environ 200 000 relevés GPS par jour ; environ 180 000 requêtes par an. Une flèche étiquetée « statut de livraison » n’est pas un message occasionnel. Les boîtes vous disent ce qui existe. Les flèches vous disent ce qui circule. Les zéros vous disent si vos hypothèses survivent à la réalité.

Click to enlarge

L’inventaire derrière le paysage de Steve Trucking : le volume à côté du mécanisme qu’il déterminera.

Pas encore d’architecture cible, et je vois déjà où vivent les données importantes, de quel type elles sont, à quelle vitesse elles circulent et comment les systèmes les échangent.

Au-delà de l’examen : ce que l’IA change. Supposons que Steve Trucking construise un agent pour répondre au « où est ma livraison ? » d’un destinataire. À quel système doit-il demander ? Salesforce connaît le rendez-vous, FleetLink sait où est le camion, le manifeste du partenaire a défini la livraison. Le paysage actuel est la carte de l’agent, et avant que l’agent puisse répondre en toute sécurité, l’architecte doit savoir quel système fait autorité pour chaque fait et à quel point il est à jour. Dirigez un agent vers la mauvaise source et des données périmées deviennent une réponse pleine d’assurance.

Lisez la douleur, ne la corrigez pas encore

Prenez du recul. Trois partenaires, trois styles d’intégration. Un outil de répartition hérité qui contient huit ans d’historique, et des coordinateurs qui ressaisissent 3 300 arrêts par jour dans Salesforce et en retour. Une plateforme télématique avec 200 000 relevés par jour, déconnectée. La finance qui compte les livraisons à partir d’un tableur mensuel. L’analytique avec une semaine de retard. L’authentification unique pour certains utilisateurs, pas pour d’autres. Pas de lien de suivi, et 108 000 requêtes par an pour demander où est une livraison. Le tout en croissance de 30 % par an.

Cela fait beaucoup d’architecture à partir d’une seule image. La tentation est de commencer à corriger. Ne le faites pas. Pas encore. Je veux que vous soyez à l’aise pour laisser un diagramme d’état actuel laid, parce que parfois l’état actuel est laid. Le but n’est pas d’impressionner qui que ce soit avec un dessin propre ; c’est une compréhension partagée de la réalité. Reconcevez pendant que vous documentez, et vous perdez la base de référence. Plus tard, je veux pouvoir dire : voilà ce qui existait, voilà le problème que nous avons résolu, voilà ce que nous avons changé, et pourquoi. Le chapitre 6 commence à prendre des décisions sur la propriété et l’identité, et le point de contrôle 1 assemble la partie 1. Le cours Integration Architect conçoit en profondeur les flux des partenaires.

Ce qu’un architecte décide ici

À ce stade, l’architecte ne décide pas de l’architecture cible. La décision est de savoir si l’état actuel est assez bien compris pour en concevoir une :

• Quels systèmes, populations d’utilisateurs, stockages de données et partenaires externes existent réellement aujourd’hui.
• Quelles données franchissent chaque frontière importante, dans quel sens, à quelle fréquence et par quel mécanisme.
• Où vivent aujourd’hui les données opérationnelles, analytiques, en flux, historiques et non structurées.
• Quels flux portent le plus de volume et méritent une attention précoce.
• Quels trous, étapes manuelles, systèmes déconnectés, autorités floues et modèles incohérents deviennent des questions de conception explicites.

Ce chapitre a commencé par une idée : dessinez le paysage avant de concevoir l’organisation. Si j’avais commencé par le modèle de données de Steve Trucking, j’aurais pu passer des heures sur les objets et les relations pendant que FleetLink restait dehors avec 200 000 relevés par jour, que RouteDesk gardait huit ans d’historique, que trois partenaires parlaient trois langues, que la finance utilisait un tableur, et que cent mille requêtes par an demandaient où était une livraison. Ce ne sont pas des questions de modèle d’objets. Ce sont des questions de données de l’entreprise. Dessinez les intégrations laides, le tableur, le système que vous êtes censé retirer. Notez les zéros. Parcourez chaque flèche. Alors vous serez prêt à le changer.

Pour aller plus loin

• Le dossier Steve Trucking (en anglais), sections 2 à 4, et son diagramme de paysage.