La question à laquelle répond ce module : comment dessiner un paysage qui montre où vont les données ?
Donnez-moi un nouveau scénario et un tableau blanc vierge, et l’une des premières choses que je dessinerai, c’est le paysage des systèmes. Pas joli, pas toutes les API, pas encore le modèle de données. Je veux voir l’entreprise : qui sont les utilisateurs, quels systèmes sont impliqués, où se trouve Salesforce, ce qui l’entoure, d’où viennent les données et où elles vont. Et ensuite, je veux parcourir les flèches. Un bon paysage n’est pas une image de boîtes. C’est une manière de mettre au jour les décisions d’architecture.
Je fais pratiquer cela aux candidats CTA. Lisez le scénario, puis commencez à dessiner. N’attendez pas d’avoir tout résolu dans votre tête ; le dessin vous aide à résoudre. C’est pourquoi les devoirs après le premier jour consistent à commencer le paysage avant de faire un premier essai de modèle de données. Dessinez d’abord le modèle de données et vous avez déjà supposé ce qui a sa place dans Salesforce. Dessinez d’abord le paysage et vous voyez les systèmes qui doivent orienter cette décision.
Commencez haut, puis descendez dans le détail : d’abord l’entreprise entière, puis le détail là où il compte.
Il existe de nombreuses façons de dessiner un paysage des systèmes. Ce n’est que ma façon de faire, que j’ai affinée pendant de nombreuses années, et je la partage pour que vous voyiez comment en assembler un rapidement. Je l’utilise pour chaque paysage Salesforce, et elle se lit comme une phrase : les personnes à gauche atteignent Salesforce au centre, reconnues par les systèmes au-dessus, servies par les canaux en dessous, et connectées au back-office à droite.
Les personnes à gauche, de haut en bas : les utilisateurs internes, les partenaires, les clients. Pas encore chaque persona ; assez pour répondre à qui essaie d’atteindre cette architecture ? Chaque groupe pointe vers son point d’entrée : les utilisateurs internes vers Salesforce, les partenaires vers la communauté partenaire, les clients vers la communauté client. Les systèmes n’existent pas pour eux-mêmes. Quelqu’un, ou quelque chose, essaie de les utiliser.
Étape 2 sur 6 : qui essaie d’atteindre cette architecture ?
Salesforce au centre. Une simple boîte. Pas parce que Salesforce est le centre de l’entreprise (nous venons de passer trois modules à dire le contraire) mais parce que c’est le système autour duquel je conçois. C’est le point d’ancrage.
Les communautés juste en dessous, qui le touchent. Une communauté partenaire et une communauté client sont des points d’entrée distincts, elles ont donc leurs propres boîtes. Mais elles sont collées à Salesforce, car rien n’a besoin d’être intégré pour les atteindre : elles tournent dans la même organisation.
Étape 3 sur 6 : Salesforce au centre, les communautés juste en dessous.
L’identité au-dessus. Les fournisseurs d’identité vont en haut, ceux que les développeurs oublient : un pour les utilisateurs internes, peut-être un autre pour les partenaires. Les packages AppExchange vont aussi là-haut, décalés vers la droite, car ce sont des capacités apportées dans l’organisation plutôt que des systèmes de back-office qui échangent des données avec elle. Les sites web publics se placent en haut à gauche.
Étape 4 sur 6 : l’identité au-dessus, la boîte que les développeurs oublient.
L’intégration, puis le back-office, à droite. La couche d’intégration, un ESB ou un iPaaS (ou MuleSoft, quand il est nommé), est une haute barre juste à droite de Salesforce. Les systèmes internes se placent derrière elle : les ERP, la finance, la gestion des commandes, les systèmes hérités, l’entrepôt de données. La page se lit maintenant de gauche à droite : les personnes, Salesforce, l’intégration, le back-office.
Étape 5 sur 6 : l’intégration, puis le back-office.
Les canaux en dessous. Tout ce qui a une ligne directe avec les clients : e-mail vers requête (email-to-case), web vers piste (web-to-lead), téléphone, messagerie.
Les données entrantes et sortantes, en bas à droite. Les sources de données externes, les archives, les chargements de données.
Data 360 à droite, sous la couche d’intégration. Les utilisateurs ne s’y connectent jamais, et son tenant se connecte à de nombreux systèmes back-end, il se place donc avec la tuyauterie, là où ces lignes restent courtes : à côté des systèmes internes, de l’entrepôt de données et des données en bas à droite. Les équipes data ouvrent bien ses écrans, mais ces écrans sont dans l’organisation : Data 360 est proche du cœur (near-core), géré sur le cœur et hébergé hors du cœur (module 1). Une ligne qui le relie à Salesforce montre qui le gère. L’endroit où vous placez la boîte doit raconter ce qu’elle fait.
Rien de cette géométrie n’est sacré. La valeur d’une convention, c’est que je ne réinvente pas le langage visuel à chaque fois, et que quiconque a vu un de mes diagrammes lit le suivant plus vite.
Gardez une notation simple. Chaque système est une carte : son nom, son rôle et une petite icône qui dit de quel genre de chose il s’agit : un ERP, une base de données, un fournisseur d’identité, un groupe de personnes. Les régions que je viens de décrire sont dessinées comme des zones pâles et étiquetées, pour que la disposition elle-même soit visible. Une légende en bas dit ce que signifient chaque icône et chaque ligne.
Ne mettez pas trop de choses dans une boîte. Ce n’est que sur un paysage très compliqué que j’ouvre Salesforce en ses parties (Sales Cloud et Service Cloud dans l’organisation, avec des flèches entre eux). Et n’inventez pas quinze formes à moins que chacune dise quelque chose au lecteur. Je veux que quelqu’un regarde le paysage trente secondes et commence à comprendre l’architecture. Le sophistiqué n’aide pas. Le clair, si.
N’attendez pas la conception détaillée pour penser au volume. Une flèche qui transporte 500 produits par nuit et une autre qui transporte 200 000 relevés GPS par jour peuvent sembler exactement identiques sur le paysage. Ce n’est pas le même problème. Alors, avant de dessiner la moindre flèche, comptez ce qui circule. Commencez l’inventaire derrière l’image avec les volumes : une ligne par jeu de données important, avec son volume. Les zéros n’apparaîtront peut-être jamais sur les flèches, mais vous devez savoir quand vous passez dans les grands nombres : des milliers ou des millions en une heure, des centaines de milliers de transactions, voire des dizaines à des centaines de transactions par seconde.
Ces nombres déterminent le mécanisme. Quelques centaines d’enregistrements par nuit, c’est un traitement par lots. Un appel que quelqu’un attend peut être synchrone, si le volume le permet. Des dizaines à des centaines par seconde peuvent nécessiter des événements, comme les événements de plateforme, plutôt qu’un appel par enregistrement. La flèche aura le même aspect ; c’est le volume qui décide de ce qui la porte, alors notez-le dans l’inventaire, là où le mécanisme est choisi.
Le mécanisme peut même changer le sens de la flèche. Envoyez quelques enregistrements par minute, et Salesforce peut simplement appeler vers l’extérieur : la flèche part de Salesforce. Envoyez-en beaucoup plus, et Salesforce peut plutôt publier des événements sur le bus d’événements ; le système externe s’abonne et vient les chercher, et la flèche part désormais de l’autre bout. Plus gros encore, disons une synchronisation nocturne de millions d’enregistrements, et c’est un traitement par lots. Alors connaissez vos volumes tôt, dès que vous commencez à concevoir les mécanismes, car les volumes peuvent redessiner les flèches.
Le volume compte à deux endroits, pour deux raisons. Sur un modèle de données, j’en ai besoin pour surveiller les gros volumes de données et planifier l’archivage ; la partie 2 approfondit ce point. Sur un paysage des systèmes, les grands nombres de l’inventaire déterminent le choix du modèle d’intégration et du mécanisme. Le module 6 met de vrais zéros sur le paysage de Steve Trucking et son inventaire. Avec les volumes en main, dessinez les flèches.
Une fois les systèmes en place, reliez-les, et le paysage devient une architecture. Une boîte est un système ; la flèche montre qui initie la connexion. Elle part du système qui ouvre la connexion et pointe vers celui qu’il appelle : du client vers le serveur. L’étiquette dit ce qui circule, et dans quel sens.
Cette règle vaut pour les paysages des systèmes, où des systèmes parlent à des systèmes. Sur un diagramme de flux de données, la flèche suit les données, comme on s’y attend. N’emportez pas la règle du paysage dans d’autres diagrammes ; elle ne fait qu’ajouter de la confusion.
Les flèches ajoutées. Chaque boîte est restée à sa place ; chaque flèche part du système qui ouvre la connexion, et son étiquette dit ce qui circule et dans quel sens.
Donc si la couche d’intégration pousse les produits dans Salesforce, la flèche va de la couche d’intégration vers Salesforce, étiquetée produits entrants. Si Salesforce appelle vers l’extérieur pour les récupérer, la flèche part de Salesforce, toujours étiquetée produits entrants. Mêmes données, conversation différente, et cette différence me dit qui a besoin des informations d’identification et qui doit gérer l’échec. Salesforce envoie la commande à travers la couche d’intégration : commandes sortantes. L’exécution de l’ERP revient : statut de commande entrant. Je vois maintenant qui commence chaque conversation, où les données entrent dans Salesforce et où elles en sortent, quels flux franchissent des frontières, où se trouve probablement la propriété, et où je dois creuser.
Et souvenez-vous du module 1 : chaque fois que je ne vois qu’un seul flux, je m’inquiète. À haut niveau, une flèche commandes sortantes dépend de flux de retour : clients entrants, produits entrants, les prix. Regardez encore plus loin et il y a le trajet retour : une acceptation, un rejet, un statut, un numéro de facture, une annulation. Les flèches me donnent quelque chose de concret à questionner.
C’est là que le paysage cesse d’être de l’art PowerPoint. Devant le jury, n’importe quelle flèche peut susciter trois questions, et je veux que vous ayez les réponses :
Comment s’authentifie-t-elle ? OAuth, un certificat, des informations d’identification nommées, autre chose ?
Est-elle synchrone ou asynchrone ? Salesforce attend-il l’ERP, ou publie-t-il et continue-t-il ? À quelle vitesse le métier a-t-il besoin du résultat ?
Quel est le mécanisme ? Un appel REST, un événement, un fichier, une file de messages, via MuleSoft ou en direct ?
Et ensuite : que se passe-t-il quand l’autre côté est en panne ? Chaque flèche a besoin d’un mécanisme. Si vous ne pouvez pas l’expliquer, le trait est de la décoration.
Et « fire and forget » (envoyer et oublier) n’est pas une réponse. Cela veut généralement dire « je n’ai pas conçu ce qui se passe après l’envoi ». Est-ce arrivé ? Est-ce accepté ? Est-ce que ça a échoué ? Y aura-t-il une nouvelle tentative ? Qui sait que c’est bloqué ? Et si le même message arrive deux fois ? Rien de cela ne va sur le paysage, qui deviendrait illisible. Mais la flèche doit vous faire savoir que ces questions existent.
Zoomez sur n’importe quelle flèche et vous trouvez un client et un serveur, et chacun possède sa moitié. Le client ouvre la connexion : il a besoin du point de terminaison et du port, obtient d’abord un jeton auprès du serveur d’authentification, appelle selon le protocole et le contrat que définit le serveur, et choisit d’attendre ou non. Seul le client voit l’aller-retour complet, donc seul le client peut réessayer. Le serveur écoute, définit le protocole, le contrat et la charge utile, valide ce qui arrive, et ne voit que sa propre partie. Quand je dessine une flèche, je sais déjà quel bout est lequel, et cela me dit à qui appartient chacune de ces questions.
Une flèche, vue de près : le client gère, le serveur définit. Rien de cela ne figure sur le paysage, mais chaque flèche l’a.
Maintenant, retournez la flèche. Quand l’ERP appelle Salesforce, Salesforce est le serveur : il définit les API, fait tourner son propre serveur d’autorisation et décide, au moyen d’une application client externe (External Client App) et d’un utilisateur d’intégration, de ce que l’appelant peut faire. Mêmes questions, de l’autre côté.
Voici comment les architectes gâchent un bon diagramme : ils font répondre un seul artefact à tout. Le paysage reçoit les noms d’API, les charges utiles, les nouvelles tentatives, les files d’erreurs, les transformations, chaque rappel, et bientôt plus personne ne peut le lire. Ne le faites pas. Le paysage, c’est la vue d’ensemble : les systèmes et les flux importants entre eux.
Quand je dois expliquer une interaction, je dessine un second diagramme, mais pas pour chaque intégration. Si le système A envoie quelque chose à B, ou même demande et obtient une réponse, la flèche étiquetée suffit. Je veux un couloir (swim lane) quand le processus devient une conversation : A appelle B, B vérifie auprès de C, C répond, B crée quelque chose et rappelle A, une personne approuve, un autre système prend le relais. Ma règle empirique : plus d’un ou deux allers-retours, et la séquence a droit à son propre couloir. Les flèches sur le paysage ; la conversation dans le couloir.
Et remarquez qu’une flèche y signifie autre chose. Sur le paysage, une flèche est une connexion : qui l’ouvre, et ce qui circule. Dans un couloir, chaque flèche est un message d’une conversation, lu dans l’ordre : une requête part dans un sens, une réponse revient dans l’autre, et l’étape suivante suit.
Trois flèches sur le paysage ; six étapes dans le couloir. Sur le paysage, une flèche est une connexion ; dans un couloir, chaque flèche est un message, dans l’ordre.
Quand le paysage semble à peu près terminé, parcourez-le, flèche par flèche. De l’ERP à Salesforce : qu’est-ce qui circule, qui le possède, comment ça s’authentifie, quel est le mécanisme, synchrone ou asynchrone, à quel point les données doivent-elles être à jour ? Puis la flèche suivante, et la suivante. C’est là que les trous apparaissent. « Ah, on n’a jamais établi comment le partenaire envoie réellement ça. » « On envoie les commandes à l’ERP, mais on n’a pas conçu comment reviennent celles qui sont rejetées. » Très bien. Vous l’avez trouvé sur le tableau blanc plutôt qu’en production.
L’image doit rester lisible, alors les détails vont dans l’inventaire derrière elle. Vous l’avez commencé avec les volumes ; terminez-le maintenant, une ligne par jeu de données ou flux important :
Colonne
Ce que je veux savoir
Jeu de données
Client, produit, commande, livraison, facture
Type
Maître, référence, transactionnel, analytique, non structuré
Propriétaire
Qui possède son sens et son cycle de vie ?
Système d’enregistrement
Où est la version qui fait autorité ?
Charge de travail
Opérationnelle, analytique, en flux
Volume
Le Nombre de zéros
Organisation
Quelle organisation Salesforce, s’il y en a plusieurs ?
Authentification
Comment la connexion établit-elle la confiance ?
Mécanisme et rythme
API, événement, fichier, fédération ; synchrone, asynchrone, par lots
Approche
La copier, la référencer ou la fédérer ?
Il y a maintenant deux artefacts : le paysage me permet de voir l’architecture, et l’inventaire me permet de l’interroger.
C’est pourquoi j’aime cet artefact : il m’aide à réfléchir. « Comment ferons-nous des rapports sur Salesforce et l’ERP ? » C’est la question du module 3 : lequel de mes diagrammes résout cela à merveille ? Le paysage. Si tout est sur le cœur, des rapports standard. Si les données sont dans l’ERP et l’entrepôt de données, vous le voyez immédiatement. « Où cet attribut client doit-il être maîtrisé ? » Regardez quels systèmes l’utilisent et lequel possède déjà le client. « Salesforce a-t-il besoin de chaque relevé GPS ? » Qui le produit, qui le consomme, quelle est la charge de travail ? Peut-être que Salesforce a besoin de la position actuelle et qu’une autre plateforme garde l’historique. Le paysage ne vous donne pas la réponse. Il vous donne la bonne vue du problème.
Une discipline de plus. Dans une entreprise existante, dessinez ce qui existe, pas ce que vous aimeriez qui existe. Le tableur envoyé par e-mail chaque vendredi : dessinez-le. Le CSV du partenaire sur un serveur SFTP : dessinez-le. L’intégration qui contourne l’ESB pour des raisons historiques : dessinez-la. Des gens qui ressaisissent des données entre deux systèmes : montrez-le. N’embellissez pas la réalité pendant que vous la documentez. Il vous faut le paysage actuel avant de concevoir le paysage cible, et c’est ce que nous faisons pour Steve Trucking au module 6.
Au-delà de l’examen : ce que l’IA change. Le paysage devient une carte des agents. Si un agent répond à « où est ma livraison ? », le paysage doit dire si la réponse vient de Salesforce, d’un système partenaire, de la télématique, de l’ERP, ou d’un mélange. Les agents ne suppriment pas les frontières entre systèmes ; ils rendent encore plus important de savoir quel système fait autorité, et comment l’atteindre en toute sécurité.
Quels systèmes et quelles populations d’utilisateurs ont leur place sur le paysage, et comment leur position montre leur rôle.
Quels flux franchissent les frontières entre systèmes, dans quel sens, et ce qui revient.
Comment chaque connexion s’authentifie, quel mécanisme la porte, et si elle est synchrone, asynchrone, par lots ou fédérée.
Quand une flèche étiquetée suffit et quand une interaction a besoin de son propre couloir.
Ce que consigne l’inventaire derrière l’image : propriétaire, charge de travail, volume, organisation, rythme, authentification, et copier, référencer ou fédérer.
Le paysage n’est pas quelque chose que je dessine une fois l’architecture terminée. C’est ainsi que je trouve l’architecture. Et quand vous pensez qu’il est fini, ne l’admirez pas. Parcourez-le. Chaque flèche que vous ne savez pas encore expliquer vous montre où se trouve le travail.
