Écouter les noms
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)
Module 1 sur 6 du chapitre Modéliser les données pour leur sens, chapitre 2 du cours Data Architect. Chaque module se suffit à lui-même. Précédent : la présentation du chapitre · Suivant : Dessiner les relations
La question à laquelle répond ce module : comment trouver les débuts d’un modèle de données dans une conversation métier ?
L’une des choses que je fais lors d’un premier appel avec un client, c’est écouter les noms.
Je ne parle pas de la première séance de conception. Je parle de cette toute première conversation où j’essaie encore de comprendre l’activité et ce que le client cherche à accomplir.
Ils parlent. J’écoute.
Et j’écoute des mots comme :
Partenaire distributeur. Destinataire. Centre de distribution. Manifeste. Livraison. Tournée. Équipe. Camion.
Ces noms retiennent immédiatement mon attention, parce que quelque part dans cette conversation se trouvent les débuts de mon modèle de données.
Je n’attends pas de croire avoir complètement compris le problème. Je commence à voir les données pendant que j’écoute encore : j’entends les noms, je commence à esquisser comment ils sont liés, et cette esquisse m’aide à cadrer la conversation suivante. Parfois, à la fin d’une première réunion avec un client, j’ai déjà dessiné mon propre modèle de données personnel.
Pour moi, tout commence par les noms.
Oubliez Salesforce un instant
Section intitulée « Oubliez Salesforce un instant »C’est ici que je veux que vous résistiez à un réflexe, particulièrement fort si vous êtes administrateur Salesforce depuis un moment.
Le client dit client, et vous pensez :
Compte.
Il dit personne, et vous pensez :
Contact.
Il dit centre de distribution, et vous vous demandez déjà s’il vous faut un objet personnalisé.
Pas encore.
À ce stade, peu m’importe qu’un client devienne finalement un compte, un compte personnel, un objet personnalisé ou autre chose. Je veux d’abord comprendre le métier.
C’est la différence entre modéliser le métier et configurer Salesforce. Si je commence par les objets Salesforce, j’ai déjà enfermé ma réflexion dans une seule mise en œuvre. J’arriverai peut-être exactement là où je m’y attendais, mais je veux y arriver parce que le métier m’y a mené, pas parce que Compte et Contact étaient les deux premiers objets que je connaissais.
Alors, pendant quelques minutes, oubliez Salesforce. Écoutez comment les gens qui font réellement tourner l’activité décrivent leur monde.
Assis, pas bouger, modèle
Section intitulée « Assis, pas bouger, modèle »Avant d’écouter un métier, écoutons quelque chose que tout le monde comprend déjà. Quand j’enseigne cela en direct, je commence par les chiens.
Voici un chien : Marcus est le propriétaire de Bella. C’est Maple Ridge Kennels qui l’a élevée. C’est un labrador, et elle connaît « Assis », « Pas bouger » et « Donne la patte ».
Écoutez les noms : Marcus, Bella, Maple Ridge Kennels, labrador, « Assis ». Mais ce sont des noms propres : les choses précises. Ce que je veux, c’est le type de chose auquel appartient chaque nom. Bella est un Chien. Marcus est un Propriétaire. Maple Ridge Kennels est un Éleveur. Le labrador est une Race. « Assis » est un Tour. Cinq noms, cinq boîtes candidates.
Puis la question que je pose à chaque nom : est-ce une personne qui fait un travail, ou une donnée ? Marcus est une personne. Mais être le propriétaire de Bella n’est pas un travail ; c’est un fait sur Bella, et tôt ou tard quelqu’un demande : « À qui est ce chien ? » Le Propriétaire a donc sa place dans le modèle. Le dresseur qui a appris à Bella à donner la patte est une personne qui fait un travail, et n’aura peut-être jamais besoin d’une boîte, sauf si le métier commence à demander qui a appris quel tour.
Et remarquez le mot candidate. La Race est-elle vraiment une boîte à part entière, ou juste un mot écrit sur le chien ? Gardez cette question en tête ; nous y répondrons quand nous normaliserons, au module 4.
Voilà toute la technique, sur quelque chose de petit. Écoutons maintenant un vrai métier.
Les noms vous donnent des entités candidates
Section intitulée « Les noms vous donnent des entités candidates »Écoutons Steve Trucking, l’entreprise familiale que nous utiliserons tout au long de ce cours. Elle livre de gros articles (réfrigérateurs, lave-linge, téléviseurs) depuis les centres de distribution de grandes enseignes jusqu’au domicile des gens, et en installe certains.
Lors de la première conversation, nous entendons :
- Partenaire distributeur
- Destinataire
- Centre de distribution
- Manifeste
- Livraison
- Tournée
- Équipe
- Camion
C’est déjà utile. Je peux commencer à mettre des boîtes sur un tableau blanc.
Mettez donc les noms dans des rectangles. C’est tout ce qu’ils sont à ce stade : des boîtes. Pas de traits, pas de couleurs, rien qui dise Salesforce. Plus tard dans le cours, les formes et les couleurs commenceront à avoir un sens. Pour l’instant, un rectangle n’est qu’une chose dont le métier parle.
Puis commencez à les orienter. En plaçant chaque boîte, pensez à deux choses : comment elles sont liées entre elles, et de quel type de données il s’agit. Certaines sont des données client : les entreprises et les personnes avec qui nous travaillons. D’autres sont des données transactionnelles, comme les commandes et leurs lignes : ce qui se produit, encore et encore. Et d’autres sont des données de référence, comme les produits ou services qu’une entreprise propose : ce dont le travail dépend.
Chez Steve Trucking, le partenaire distributeur et le destinataire sont des données client. Le manifeste, la livraison et la tournée sont des transactions. Le centre de distribution, l’équipe et le camion sont ce dont le travail dépend.
Mais il y a ici un mot important : candidate.
Un nom est un indice. Ce n’est pas automatiquement une entité, et ce n’est certainement pas automatiquement un objet Salesforce.
En séance de découverte, je note chaque nom. Pour chaque nom prononcé, je me pose une question : est-ce une personne qui fait un travail, ou est-ce une donnée ? Un responsable du développement commercial est une personne qui fait un travail. C’est un utilisateur, un rôle, peut-être un ensemble d’autorisations. Les commandes, les factures, les lignes : ce sont des données. Les deux comptent, mais ils finissent à des endroits très différents de la conception, et les trier tôt m’évite de dessiner une boîte pour chaque intitulé de poste de l’organigramme.
Certains de ces noms seront des personnes. Chez Steve Trucking, c’est le destinataire qui attend son réfrigérateur, les personnes chez le partenaire distributeur qui envoient le manifeste, et l’équipe : les chauffeurs et les aides dans le camion. Ce sont des rôles, et un rôle peut ne pas ressembler à une donnée. Mais quand des personnes agissent sur des données, ou y sont liées, elles doivent elles-mêmes être représentées dans les données. Qui a livré ceci ? Qui a signé ? Qui a envoyé le manifeste ? Beaucoup de rôles, parfois tous, finissent donc aussi dans le modèle.
Écoutez la façon dont Steve Trucking parle, et vous remarquerez quelque chose. Ils ne disent jamais simplement « client ». Il y a deux sortes de clients. Le partenaire distributeur est la grande enseigne pour laquelle Steve Trucking livre : il envoie le manifeste et paie à la livraison. Le destinataire est la personne chez qui le réfrigérateur est livré. Le destinataire l’a acheté au magasin et n’a peut-être jamais entendu parler de Steve Trucking.
Si j’avais dessiné une seule boîte appelée Client, j’aurais mélangé deux choses complètement différentes.
Peut-être que le centre de distribution est assez important pour avoir son propre enregistrement, son historique, ses relations et ses attributs.
Peut-être qu’un autre nom s’avérera n’être qu’un attribut d’autre chose.
C’est ce que nous cherchons à découvrir. Nous ne créons pas encore d’objets. Nous construisons notre compréhension du métier.
Écoutez maintenant les relations
Section intitulée « Écoutez maintenant les relations »Les noms me donnent un point de départ. Ensuite, j’écoute comment le métier les relie.
Un partenaire distributeur exploite des centres de distribution.
Un partenaire distributeur envoie un manifeste pour chaque centre et chaque jour de livraison.
Un manifeste liste des livraisons.
Une livraison va à un destinataire.
Une tournée est le parcours d’une journée, d’une dizaine d’arrêts.
Une équipe de deux conduit un camion.
Quelque chose se passe. Je ne regarde plus une liste de noms. Je commence à voir un modèle.
C’est aussi là que les questions commencent à apparaître.
Un partenaire distributeur peut-il avoir plusieurs centres de distribution ?
Une livraison est-elle la même chose qu’un arrêt ?
Un arrêt peut-il livrer deux destinataires ?
Une équipe est-elle toujours composée des deux mêmes personnes ?
Voulons-nous savoir quelle équipe avait quel camion le mois dernier, ou seulement quel camion elle conduit aujourd’hui ?
Remarquez ce que nous faisons. Nous ne posons pas encore de questions Salesforce. Nous posons des questions métier. Et ces réponses finiront par piloter la conception Salesforce.
Votre premier modèle n’a pas besoin d’être parfait
Section intitulée « Votre premier modèle n’a pas besoin d’être parfait »Je ne m’attends pas à ce que les premières boîtes que je dessine survivent telles quelles. En fait, je me méfierais si c’était le cas.
Le but du premier modèle n’est pas d’être juste. Le but est de nous donner quelque chose d’assez concret pour découvrir où nous nous trompons.
Mettez Livraison, Tournée, Équipe et Camion au tableau, et les gens peuvent réagir.
« En fait, une livraison n’est pas toujours un seul article. Ça peut être un lave-linge, un sèche-linge et l’enlèvement des anciens. »
Bien. Dites-m’en plus.
« On n’affecte pas une équipe à une livraison. On affecte l’équipe à une tournée. »
Parfait. Qu’y a-t-il dans la tournée ?
« Et s’il y a une installation, l’équipe ne peut pas clore l’arrêt tant que la liste de contrôle et les photos ne sont pas faites. »
Nous apprenons quelque chose d’important.
Un schéma a transformé une conversation floue en quelque chose qu’on peut remettre en cause. C’est l’une des raisons pour lesquelles j’aime modéliser tôt. Je n’essaie pas d’impressionner la salle avec un beau schéma. J’essaie d’apprendre plus vite.
Le modèle fait partie de la conversation.
Voici votre modèle conceptuel
Section intitulée « Voici votre modèle conceptuel »Ce que nous avons commencé à construire porte un nom formel : un modèle de données conceptuel.
À ce niveau, je m’intéresse aux choses importantes pour le métier et à leurs relations. Je ne me soucie pas encore des objets standard ou personnalisés, des noms d’API des champs, des relations de référence ou principal-détails, des champs obligatoires, des index, de l’automatisation, de l’Apex ou des flows. Ces choses comptent, et nous y viendrons. Mais si nous les décidons avant de comprendre ce que nous modélisons, nous résolvons d’abord le mauvais problème.
Le modèle conceptuel doit avoir du sens pour les personnes présentes qui ne connaissent pas Salesforce. C’est un test utile. Si je dois expliquer ce que signifie Delivery__c avant que le responsable des opérations puisse lire mon schéma, je suis passé trop tôt à la mise en œuvre.
Je veux qu’ils regardent le modèle et disent :
« Oui, c’est comme ça que notre activité fonctionne. »
Ou, mieux encore :
« Non, ce n’est pas comme ça que ça marche. »
Parce que maintenant, j’ai quelque chose à corriger.
La même technique fonctionne quand personne ne parle
Section intitulée « La même technique fonctionne quand personne ne parle »Ce n’est pas seulement une technique que j’utilise en découverte client. Elle fonctionne aussi quand le « client » est un document.
Quand je travaille sur un cahier des charges, je fais à peu près la même chose. Quels sont les concepts métier importants ? Quelles relations sont décrites ? Qu’est-ce qui revient souvent ? Qu’est-ce qui a son propre cycle de vie, doit être identifié à part, ou a besoin d’un historique ? Qu’est-ce qui est créé, modifié, affecté, transféré, planifié ou retiré ?
Ce sont les mêmes choses que j’écoute lors de cette première réunion. Sur une page, ces indices transforment des paragraphes d’exigences en un modèle sur lequel je peux raisonner, et en meilleures questions pour la conversation suivante.
Un modèle n’est pas seulement quelque chose que vous produisez après avoir résolu le problème. C’est l’un des outils que vous utilisez pour résoudre le problème.
Ce que l’architecte décide ici
Section intitulée « Ce que l’architecte décide ici »À la fin de ce premier passage, j’essaie de décider :
- Quels noms représentent des entités candidates significatives.
- Quels mots différents représentent le même concept métier, et quel mot unique en cache deux (comme « client »).
- Quels concepts ont besoin de leur propre enregistrement et de leur propre cycle de vie.
- Comment les principaux concepts sont liés entre eux.
- À quelles questions le métier doit répondre avant que je puisse les modéliser en confiance.
Je ne décide pas encore la mise en œuvre Salesforce. Il faut d’abord comprendre le métier assez bien pour le dessiner. Et une fois les noms au tableau, la prochaine chose que je veux comprendre, ce sont les traits entre eux.
Au-delà de l’examen : ce que l’IA change. Donnez un cahier des charges à un outil d’IA et il trouvera les noms, proposera des entités et esquissera des relations en quelques secondes. Utilisez-le pour accélérer la découverte, mais ne sous-traitez pas la compréhension : il ne peut pas savoir que « client » veut dire deux choses différentes chez Steve Trucking à moins que le métier ne vous le dise. Montrez son premier modèle à ceux qui font tourner l’activité et demandez : « Est-ce vraiment comme ça que votre activité fonctionne ? »