Découvrez ici nos planifications de mise à jour.

Les solutions intentionnelles offrent une valeur métier immédiate et au fil du temps. Les architectures intentionnelles sont planifiées et livrées de façon stratégique, peuvent être maintenues efficacement et sont faciles à lire et à comprendre pour les humains.

Les fonctionnalités et les correctifs sont priorisés et livrés de façon transparente pour les parties prenantes commerciales et technologiques. Les choix d'ingénierie créent des implémentations faciles à utiliser pour les équipes de livraison et de maintenance, sans fonctionnalités ou complications supplémentaires. Les architectures intentionnelles sont plus faciles à approprier, à gérer et à faire évoluer avec l'entreprise, car elles suivent des modèles d'implémentation clairs et cohérents. Les générateurs peuvent interpréter et implémenter des conceptions pour de nouvelles fonctionnalités, et les équipes de maintenance peuvent comprendre la documentation sur les éléments implémentés.

Vous pouvez créer des systèmes plus intentionnels en vous concentrant sur trois domaines clés : stratégie, maintenabilité et lisibilité.

La stratégie en architecture signifie que les systèmes sont soigneusement planifiés et livrés. Cela signifie que les équipes de livraison et de maintenance ont une vue claire du travail à réaliser aujourd'hui et à l'avenir, et que tout le monde est aligné sur le « pourquoi » du travail à réaliser. Cela signifie que les demandes urgentes peuvent être triées de façon efficace et efficiente, et que les parties prenantes peuvent comprendre clairement les impacts et les compromis des demandes.

Vous pouvez élaborer une stratégie plus claire dans votre architecture en vous concentrant sur la priorisation, la feuille de route et la gouvernance.

La priorisation signifie planifier l'ordre et la portée du travail que vous allez réaliser. La priorisation consiste à comprendre l'impact réel des livrables sur l'entreprise, à évaluer ces impacts par rapport à d'autres demandes de travail et à la feuille de route globale de votre produit ou programme.

Une façon d'évaluer l'impact d'un élément de travail donné est d'examiner le coût ou l'avantage réel pour l'entreprise. Une fois les indicateurs de performance clés identifiés pour l'automatisation, vous pouvez utiliser une feuille de calcul d'impact métier pour évaluer le coût ou les avantages globaux de l'implémentation. Ces calculs peuvent vous aider à obtenir l'adhésion de vos parties prenantes sur les automatisations à élaborer et dans quel ordre. Ils peuvent également vous aider à identifier les automatisations à reporter ou à éviter. Pour les automatisations, consultez Conception de processus pour plus d'informations sur l'identification d'un travail efficace.

L'établissement d'un cadre de priorisation de la livraison vous aidera également, vous et vos équipes de maintenance, à gérer les attentes des utilisateurs et à respecter votre feuille de route.

Voici quelques considérations que vous pouvez prendre en compte pour prioriser :

• Impact commercial (coût/avantage) du produit livrable
• Montant des nouveaux travaux requis pour le livrable
• Volume de travail requis pour maintenir le produit livrable

La liste des modèles et anti-modèles ci-dessous montre à quoi ressemble la priorité appropriée (et mauvaise) en ce qui concerne le travail Salesforce. Vous pouvez les utiliser pour valider vos plans de mise en œuvre, ou identifier les zones où vous devez mieux identifier les priorités avant de les élaborer.

Pour plus d'informations sur les outils disponibles dans Salesforce pour faciliter la définition des priorités, consultez Outils pertinents pour Intentionnel.

Une feuille de route est une vue prioritaire, validée et bien définie des actions à réaliser. Des feuilles de route efficaces donnent une image claire de l'impact commercial et technologique des travaux à venir. L'engagement de vos parties prenantes commerciales et techniques est un élément clé de la feuille de route. Les feuilles de route permettent de recueillir des commentaires et d'obtenir l'adhésion sur l'approche et les résultats avant le début des travaux. En fin de compte, les feuilles de route alignent chaque partie prenante sur le « pourquoi » du travail à venir.

Si votre équipe utilise un backlog, il est important de comprendre que votre feuille de route n'est pas un résumé ou une liste des éléments du backlog. La relation est inverse : Les éléments doivent entrer dans le backlog uniquement s'ils peuvent être liés de façon claire et crédible à un livrable de votre feuille de route. Des feuilles de route de grande qualité, créées avec l'engagement des parties prenantes, fournissent aux équipes de livraison et de maintenance une vue claire des éléments sur lesquels elles doivent se concentrer et de la façon dont elles doivent prioriser les demandes, ce qui facilite le tri des demandes conflictuelles et la gestion des attentes des parties prenantes.

Une mauvaise cartographie ou l'inexistence d'une carte routière entraîne :

• Manque de clarté quant à la date de disponibilité des nouvelles fonctionnalités
• Priorités conflictuelles entre les parties prenantes
• Un décalage entre les solutions livrées et la vision globale de l'organisation
• Difficulté à comprendre les travaux en cours
• Charges de travail inégales entre les équipes
• Manque de visibilité des relations et des dépendances entre les éléments de travail
• Implémentations bloquées, en raison de dépendances mal gérées

Les parties prenantes ont souvent besoin d'informations correspondant à leurs rôles pour prendre des décisions. La création de feuilles de route efficaces nécessite une compréhension claire de votre audience et du type d'information dont elle a besoin. Les feuilles de route sont classées en deux styles pour soutenir les audiences métiers et techniques. Chaque style contient deux niveaux de granularité pour prendre en charge différents types d'information.

Les feuilles de route métiers aident les parties prenantes à planifier les changements organisationnels, à tirer parti des opportunités de croissance et à respecter les objectifs de l'entreprise. Les feuilles de route métiers permettent également de s'assurer que les dépenses informatiques correspondent à la vision métier globale.

• Créez une feuille de route des capacités métiers pour montrer aux dirigeants les capacités qui seront activées. Ce type de feuille de route contient des détails généraux sur les capacités elles-mêmes et leur adéquation avec les objectifs métiers, par exemple l'augmentation de l'efficacité opérationnelle ou le lancement d'une nouvelle gamme de produits.
• Créez une feuille de route de fonctionnalité métier pour explorer une capacité spécifique, et montrez ses fonctionnalités de support et ses fonctionnalités lorsque vous devez aider les parties prenantes de l'entreprise avec la planification des ressources, l'élaboration du budget et la gestion du changement.

Les feuilles de route technologiques aident les parties prenantes techniques à planifier l'allocation de budgets et de ressources. Ils aident également les équipes de mise en œuvre à comprendre la place de leurs projets dans une perspective globale et à identifier les dépendances inter-équipes.

• Créez une feuille de route du système technologique pour montrer les systèmes spécifiques qui seront implémentés, ainsi que toutes les dépendances au niveau du système. Ce type de feuille de route montre des informations générales sur le système et l'alignement entre les systèmes et les capacités métiers.
• Créez une feuille de route pour les composants technologiques afin d'explorer les composants spécifiques d'un système qui sera déployé pour répondre aux exigences de planification et d'activation des ressources. Ce type de feuille de route affiche les informations au niveau du composant et les exigences de mise en œuvre (par exemple, développement déclaratif, pro-code, etc.).

Assurez-vous que vos feuilles de route contiennent des calendriers réalistes. Une erreur fréquente consiste à inclure uniquement le temps nécessaire pour implémenter un système sans tenir compte également du temps nécessaire pour réaliser les activités connexes. Cela peut entraîner une surallocation des membres de l'équipe d'implémentation et des délais plus longs que prévu. Lors de la création d'une feuille de route, tenez compte du temps nécessaire pour réaliser les éléments suivants :

• Documentation de toutes les fonctionnalités nouvelles et mises à jour
• Maintenance des fonctionnalités existantes nécessaires pour prendre en charge les nouvelles fonctionnalités
• Mises à jour des systèmes associés requises pour prendre en charge les intégrations
• Augmentation du soutien des équipes de projet immédiatement après la mise en ligne
• Tests, formation et gestion du changement

Des feuilles de route métiers et technologiques bien alignées présentent une vue globale de la mise en service des capacités et de la technologie qui les sous-tend. La liste des modèles et anti-modèles ci-dessous montre à quoi ressemblent les feuilles de route correctes (et médiocres) pour une organisation Salesforce. Vous pouvez les utiliser pour valider ou améliorer votre stratégie de cartographie routière.

Pour plus d'informations sur les outils Salesforce qui peuvent vous aider avec le mappage routier, consultez Outils pertinents pour Intentionnel.

La gouvernance est la structure que vous utilisez pour gérer la priorisation, la prise de décision et la gestion du changement avec vos parties prenantes. La gouvernance indique clairement comment les décisions sont prises et communiquées. Il fournit des moyens cohérents pour les commentaires et les demandes d'entrée dans le processus décisionnel, et pour toutes les parties prenantes de comprendre l'état des travaux de maintenance et de développement. La gouvernance aide à définir des processus de gestion clairs et cohérents, et aide tous les membres de l'équipe à comprendre leurs rôles et responsabilités.

Sans gouvernance adéquate, les équipes seront confrontées à divers problèmes, notamment :

• Les demandes de superposition de fonctionnalités et de fonctionnalités arrivent au cas par cas
• Les équipes de mise en œuvre priorisent les efforts « plus faciles » ou les demandes des parties prenantes plus influentes, sans prendre en compte correctement la valeur métier, les compromis ou les objectifs généraux de l'organisation.
• Manque de cohérence des processus d'approbation et d'examen
• Cadences de publication et qualité incohérentes
• Taux de défauts élevés, écrasements, conflits et travail redondant dans les efforts de développement

Le signe le plus clair qu'un système n'a pas une gouvernance efficace est peut-être la lenteur et la lourdeur des publications. Il est important de reconnaître que la taille d'un système de gouvernance ne mesure pas son efficacité. En fait, des systèmes élaborés de gouvernance (comme ceux que l'on trouve dans de nombreuses grandes entreprises) peuvent limiter la vitesse et la fréquence des publications.

Une bonne gouvernance consiste à empêcher les mauvaises personnalisations de passer les premières étapes du développement, et à intégrer les bonnes personnalisations en production de façon prévisible et cohérente.

Trop souvent, les efforts de gouvernance sont réactionnaires. Ils sont initiés ou redoublés lorsqu'un problème, par exemple une dette technique excessive, commence à devenir un problème métier. Dans de nombreux cas, la réponse malheureuse est que l'entreprise « verrouille » les efforts de développement et les versions, au lieu de créer des normes de conception efficaces et d'élaborer une automatisation pour appliquer ces normes dans les chaînes d'outils pour développeur et les systèmes de contrôle de code source.

Lors de l'élaboration de l'infrastructure de votre système de gouvernance Salesforce, incluez les éléments suivants et tenez compte des questions clés suivantes auxquelles vous devez répondre :

• Demandes de travail. Comment les utilisateurs peuvent-ils demander des fonctionnalités ? Comment les bogues sont-ils signalés ?
• Priorité et planification des travaux. Qui décide quelles demandes de travail sont importantes ? Comment le travail est-il défini, priorisé, accepté ou approuvé ?
• Environnements et planification de versions. Quel est le pipeline d'environnement pour le développement, les tests et la publication ? Qui fait quoi pour provisionner, actualiser et accorder l'accès ? Qui gère les déploiements et la validation ? Comment et quand les modifications sont-elles publiées ? Comment gérer les déploiements ou les environnements pendant un cycle de publication de Salesforce ? (pour plus d'informations, consultez Gestion du cycle de vie des applications).
• Appui à la propriété du service et à la production. Qui prend en charge quoi ? Qui gère les problèmes de production « corrigés » ? Comment ces éléments sont-ils testés et publiés ? Qui est responsable des normes de sécurité globales de l'organisation ?

La liste des modèles et anti-modèles ci-dessous montre à quoi ressemble une bonne (et mauvaise) gouvernance pour une organisation Salesforce. Vous pouvez les utiliser pour valider ou améliorer votre stratégie de gouvernance.

Pour plus d'informations sur les outils Salesforce disponibles pour la gouvernance, consultez Outils pertinents pour Intentionnel.

Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier.

✨ Découvrez d'autres modèles de stratégie dans l'Explorateur de modèle et anti-modèle.

La maintenabilité signifie qu'un système peut être maintenu dans un état sain, avec de nouvelles fonctionnalités entrant dans le système et une dette technique sortant du système sur une base régulière et prévisible. Les systèmes maintenables permettent à vos équipes d'offrir de la valeur à l'entreprise avec une rapidité et une qualité prévisibles. La maintenabilité d'un système dépend de plusieurs facteurs, notamment de sa lisibilité, de son faible couplage et de la rigueur de sa stratégie de test.

Plus important encore, la maintenabilité d'un système dépend de la simplicité de sa conception. Cette section présente comment créer des conceptions de solutions plus simples et améliorer la maintenance.

Vous pouvez élaborer des solutions plus faciles à gérer en vous concentrant sur deux éléments clés : l'utilisation de fonctionnalités standard plutôt que personnalisées et le traitement de la dette technique.

Salesforce offre une gamme de solutions prédéfinies - Sales Cloud, Service Cloud et de nombreuses solutions de l'industrie Salesforce - ainsi que la flexibilité nécessaire pour créer vos propres solutions personnalisées. Les services de base qui propulsent les propres solutions cloud de Salesforce sont également disponibles pour toutes les solutions personnalisées élaborées sur Salesforce Customer 360 Platform. Utilisez les services et solutions prédéfinis de Salesforce comme fondation de confiance pour autant de solutions que possible.

L'utilisation de services de plate-forme prédéfinis présente deux avantages distincts. Tout d'abord, vos applications bénéficient naturellement des toutes dernières innovations Salesforce à chaque version. Ensuite, vos équipes de développement peuvent se concentrer sur l'expansion et l'approfondissement des capacités métiers fournies par vos solutions Salesforce plutôt que de gérer les tâches architecturales de base.

Bien choisir quand utiliser la fonctionnalité standard et quand élaborer une fonctionnalité personnalisée n'est pas difficile d'un point de vue architectural. Les clés sont :

• Personnaliser la plate-forme signifie modifier et étendre, pas copier. En concevant ou en évaluant votre architecture, vous devez demander : Existe-t-il déjà quelque part sur Salesforce Platform ? Si la réponse est « Oui, mais... [insérer les modifications souhaitées ici par une partie prenante...] », utilisez la fonctionnalité prédéfinie dans la plate-forme. Le travail architectural à réaliser consiste à identifier les méthodes les plus utiles pour configurer la fonctionnalité Salesforce prédéfinie afin de répondre aux attentes de l'entreprise.
• Aucune personnalisation n'est anodine. Au fil du temps, chaque changement a des conséquences. Si vous devez implémenter une solution personnalisée, vous pouvez limiter l'inévitable dette technique que votre système accumulera en choisissant d'utiliser une technologie à faible code dans la mesure du possible et en créant des unités composables dans vos implémentations.
• Considérez le spectre construction-achat. Salesforce AppExchange est une place de marché d'applications et de solutions pour étendre Salesforce. Les applications AppExchange peuvent offrir des fonctionnalités sans les frais généraux liés à l'élaboration et à la maintenance d'une solution personnalisée. Tenez compte des points suivants lors de l'évaluation des solutions AppExchange :
  • Identifiez les fonctionnalités et les lacunes de la solution. Idéalement, vous trouverez une application qui répond à toutes vos exigences métiers. En réalité, il se peut que vous ne trouviez pas un ajustement parfait. En évaluant les solutions, mappez les fonctionnalités de la solution potentielle avec une liste prioritaire d'exigences métiers. Cela vous aidera à trouver la solution qui répond le mieux à vos exigences les plus critiques.
  • Utilisez des sandbox et des évaluations gratuites. Utilisez des périodes d'évaluation gratuites pour évaluer les applications dans des environnements sandbox et identifier les plus adaptées. Déterminez si les applications nécessitent des modifications de configuration en conflit avec votre configuration existante.
  • Tenez compte des coûts à court et à long terme. Évaluez les économies à long terme réalisées en matière de maintenance des applications par rapport aux coûts récurrents des applications par abonnement. Évitez les scénarios dans lesquels vous devez payer des coûts récurrents pour de nombreuses fonctionnalités que vos parties prenantes n'utiliseront jamais.
• Utilisez les modèles de données prédéfinis de Salesforce. Salesforce fournit des modèles de données prédéfinis pour Sales, Service et divers secteurs d'activité. L'utilisation des modèles de données fournis par Salesforce garantit que les capacités de votre système sont définies une seule fois (en éliminant la redondance et les silos), établit une source de preuve unique dans l'ensemble du système, facilite la compréhension des données d'application avec les analytiques, facilite l'utilisation des services d'intelligence artificielle prédéfinis de Salesforce, réduit les coûts de maintenance (en réduisant les personnalisations que vous devez prendre en charge) et réduit la dette technique.

C'est aussi simple. Comme vous pouvez le voir dans les modèles et anti-modèles ci-dessous, les anti-modèles se résument à répliquer des fonctionnalités standard dans une solution personnalisée ou à utiliser une technologie plus complexe pour offrir des personnalisations.

Dans la pratique, vous pouvez rencontrer un scénario dans lequel une fonctionnalité personnalisée anti-modèle est considérée par les parties prenantes de l'entreprise comme la meilleure ou la seule voie viable à suivre. Dans ce cas, il est essentiel d'expliquer aux parties prenantes les compromis nécessaires pour choisir cette voie, puis de documenter en détail la décision, sa justification et sa mise en œuvre. Il s'agit également d'un domaine où la livraison anticipée de la valeur de base et l'adaptation au fil du temps peuvent aider vos parties prenantes à mieux comprendre la meilleure façon d'avancer.

Pour plus d'informations sur les outils Salesforce qui peuvent vous aider à améliorer la maintenance, consultez Outils pertinents pour Intentionnel.

La dette technique est une partie naturelle de tout système. Les conceptions sonores d'hier peuvent devenir anti-modèles lorsque la technologie ou les besoins métiers évoluent. Peut-être qu'un élément conçu pour combler une lacune dans les fonctionnalités de Salesforce Platform devient soudain redondant avec une nouvelle version Salesforce ou un lancement de produit. Peut-être qu'une technologie plus performante ou plus flexible remplace une technologie que vous avez déjà implémentée. La dette technique peut être créée de nombreuses façons.

L ' un des principaux avantages de l ' élaboration d ' applications avec Salesforce Customer 360 Platform est la rétrocompatibilité intégrée à la plate-forme. Cela signifie que les nouvelles innovations de plate-forme peuvent changer le modèle que vous devriez utiliser pour les solutions futures, mais la fonction quotidienne des solutions que vous avez élaborées à partir des technologies Salesforce précédentes continuera de fonctionner. Au fil du temps, toute solution basée sur une technologie plus ancienne commencera à présenter des risques ou des goulets d'étranglement pour l'ajout de nouvelles fonctionnalités à vos applications, et diminuera l'intégrité générale de la solution.

La planification et la réalisation de travaux réguliers pour traiter les dettes techniques sont essentielles pour maintenir des conceptions saines et simples dans une solution Salesforce. Ne pas planifier, auditer et réparer une dette technique est un moyen sûr de créer un système mal conçu.

Une façon de minimiser la dette technique est d'éviter de l'introduire autant que possible, en évitant les raccourcis et en préférant une fonctionnalité standard à une fonctionnalité personnalisée. Les raccourcis, comme les valeurs codées en dur, peuvent être tentants pour gagner du temps, mais à long terme, ils créent des dettes qui doivent être remboursées.

Les clés pour traiter la dette technique d'un point de vue architectural comprennent:

• Identification des coûts ou avantages réels de l'action par rapport à l'inaction
• Carte routière appropriée
• Élaboration de solutions composables

La difficulté peut être d'amener les parties prenantes à agir. Certaines parties prenantes peuvent percevoir la maintenance continue comme une correction des « erreurs d'hier » ou comme une suppression des fonctionnalités qu'elles souhaitent que leur budget prenne en charge.

Montrer les impacts métiers réels de l'action et de l'inaction, ainsi que des livrables et des échéanciers clairement définis, peut aider vos parties prenantes à comprendre la valeur et la priorité relative du traitement de la dette technique. Faire constamment le travail pour associer la dette technique aux impacts métiers n'aidera pas seulement vos parties prenantes à mieux comprendre le travail à réaliser. Il vous aidera également à identifier et à traiter les dettes techniques de manière à bénéficier réellement aux utilisateurs.

La liste des modèles et anti-modèles ci-dessous montre à quoi ressemble une bonne (et mauvaise) gestion technique de la dette pour une organisation Salesforce.

Pour plus d'informations sur les outils Salesforce qui peuvent vous aider à gérer les dettes techniques, consultez Outils pertinents pour Intentionnel.

Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier.

✨ Découvrez d'autres modèles de maintenabilité dans l'Explorateur de modèle et anti-modèle.

À la base, le concept de lisibilité consiste à créer une cohérence qui aide les gens à comprendre le fonctionnement. L'élaboration de systèmes lisibles aligne les équipes de livraison et de maintenance, et aide les personnes qui ne connaissent pas le système à comprendre rapidement comment les pièces s'agencent. Cela signifie que votre équipe peut être moins dépendante de personnes individuelles ayant des Knowledge institutionnelles ou historiques pour intégrer efficacement des fournisseurs ou de nouveaux membres d'équipe. Cela signifie que les personnes compétentes d'une équipe peuvent se concentrer sur la qualité et les compromis des choix faits, car la configuration et le code du système sont faciles à lire et à comprendre pour les humains. La lisibilité peut accélérer les processus de gouvernance et d'assurance qualité, et aider les équipes à mieux identifier quand elles créent des personnalisations redondantes. Il peut également augmenter les chances d'avoir un système qui se comporte de manière réutilisable et testable.

Vous pouvez améliorer la lisibilité grâce à des normes de conception et une documentation efficaces.

Les normes de conception fournissent des conseils pour maintenir toutes les personnalisations cohérentes, même aux premières étapes de développement. Les normes de conception agissent comme des garde-fous. Elles permettent à toutes les équipes de livraison et de maintenance qui travaillent sur votre système d'aborder et d'implémenter les personnalisations. La définition de normes de conception permet d'accroître la productivité de vos équipes de livraison et de maintenance, de faciliter la réalisation de révisions de code et d'architecture, et de fournir une base pour une meilleure documentation.

Sans normes de conception, les équipes sont plus susceptibles de travailler en vase clos. Sans la cohérence qu'offrent les normes de conception, les entreprises se trouveront aux prises avec :

• Les fournisseurs et les équipes de développement utilisent des modèles et des approches ad hoc dans les solutions, ce qui peut introduire des anti-modèles et réduire la réutilisation (voir Séparation des préoccupations).
• Augmentation du temps nécessaire pour résoudre les problèmes de production, et soutenir les équipes requises pour intégrer les nouveaux membres de l'équipe et les aider à comprendre un ensemble différent de modèles et d'approches.
• Mauvaise collaboration entre les équipes, redondances dans le travail entre les équipes, temps perdu dans la résolution des conflits et bogues découverts pendant les tests d'intégration.
• Frustration accrue et taux de rotation plus élevés.

Un avantage clé des normes de conception découle des conversations et des décisions que les parties prenantes doivent prendre pour les créer. Plus précisément, le processus donne à vos pistes commerciales et technologiques la possibilité de s'aligner sur la conception optimale pour votre entreprise.

Insérez les éléments suivants dans vos normes de conception

• Conventions de nommage pour les métadonnées Salesforce. Définissez une série de conventions pour nommer chaque personnalisation d'un système. Les bonnes conventions de nommage ne se contentent pas d'appliquer une cohérence entre les noms d'objets, de champs, de code, de flux et d'autres éléments de votre système. De bonnes conventions de nommage aident également les équipes de développement à utiliser des noms qui transmettent des informations sur l'objet et les fonctionnalités de ce qu'elles élaborent. Ainsi, les autres parties prenantes peuvent mieux comprendre une personnalisation particulière, simplement en voyant son nom.
• Les modèles de conception approuvés et leurs cas d'utilisation Établissez une bibliothèque d'Explorateur de schémas et d'anti-modèles, avec des informations importantes sur l'utilisation (et non) de chaque schéma. La bibliothèque peut inclure des modèles de déclencheur Apex requis ou des modèles d'orchestration de flux basés sur la composabilité souhaitée dans votre système.
• Environnement de développement et guide de l'outil. Tenez une liste claire des outils que les équipes de développement doivent utiliser pour leur travail. Cela peut inclure des chaînes d'outils et des langages approuvés pour toute personne écrivant un code, ou des fonctionnalités déclaratives approuvées (ou non) pour le développement à faible code. Vos normes peuvent inclure une liste de systèmes de contrôle de la source pour la personnalisation et la documentation, et les étapes requises d'entrée/sortie. Ils pourraient également inclure une liste d'environnements à utiliser pour différents types de travail de développement.

En plus de définir ces normes, vous devez déterminer comment et où les gérer et les stocker. Si les équipes de votre entreprise ne trouvent pas vos normes de conception (ou ne savent même pas qu'elles existent), elles ne seront pas efficaces. Idéalement, vos normes de conception résident dans le même système que votre documentation (pour plus d'informations, consultez la section suivante).

La liste des modèles et anti-modèles ci-dessous montre les normes de conception correctes (et médiocres) pour une organisation Salesforce. Vous pouvez les utiliser pour valider ou améliorer vos normes de conception.

Pour plus d'informations sur les outils Salesforce qui peuvent vous aider à définir des normes de conception, consultez Outils pertinents à l'intentionnel.

La documentation explique le quoi, comment et pourquoi de votre système. Sans documentation pertinente et cohérente, les équipes perdent beaucoup de temps à essayer de comprendre le système tel qu'il est (et les fonctionnalités et les personnalisations qui peuvent mal comprendre).

La création d'une bonne documentation prend du temps. Bien que la plupart des équipes conviennent que la documentation est importante pour les grands projets, il peut être tentant d'ignorer une étape lors de modifications rapides telles que des mises à jour de configuration ou des ajustements mineurs d'une automatisation. Ne pas documenter les modifications que vous apportez à votre système est toujours anti-modèle. Ignorer la documentation peut faire gagner un peu de temps à l'avance, mais le temps nécessaire pour dépanner une organisation qui n'est pas correctement documentée va plus qu'annuler ce gain de temps. Insérez toujours suffisamment de temps pour créer de la documentation dans toutes vos estimations, quel que soit le niveau d'effort requis pour les mises à jour que vous envisagez d'effectuer.

Le manque de documentation claire peut entraîner divers problèmes, notamment :

• Cycles de développement consacrés au remaniement des implémentations existantes
• Discussions répétitives revisitant ou laissant perplexe des décisions antérieures
• Intégration plus longue pour les nouveaux membres d'équipe ou fournisseurs
• Dépendance excessive à l'égard d'individus ayant des Knowledge institutionnelles ou historiques
• Architectures redondantes pour prendre en charge des capacités identiques ou similaires dans l'ensemble de l'entreprise
• Difficulté à communiquer l'objet et la valeur de votre solution aux principales parties prenantes

Pour les solutions Salesforce, gérez la documentation relative aux éléments suivants :

• Vues d'ensemble de la solution. Les diagrammes permettent à vous et à vos parties prenantes de visualiser les solutions à divers niveaux de détail. L'infrastructure de diagramme Salesforce facilite la création de diagrammes qui montrent les capacités métiers des solutions, ainsi que les détails d'implémentation technique.
• Enregistrements de décision. Notez les options envisagées, les compromis, la décision finale et le raisonnement à un emplacement central auquel tous les membres de l'équipe peuvent accéder pour référence ultérieure.
• Code. Le format du code lui-même est un élément clé de la documentation, qui peut (et doit) être conforme à vos normes de conception. Vous voudrez également avoir un journal des informations clés et le mettre à jour à chaque modification d'un élément de code. Pour toutes les classes, tous les déclencheurs et tous les composants, documentez les éléments suivants :
  • Qui est l'auteur du code
  • Quand le code a été écrit
  • Ce que le code est censé faire
  • Dépendances clés
  • Toutes les modifications
• Personnalisation déclarative. Pour chaque type de personnalisation qui peut être apporté aux métadonnées de votre organisation, Salesforce fournit des attributs intégrés permettant aux équipes de fournir des informations utiles sur l'objet et l'intention des métadonnées. Dans le cadre de vos normes de conception, indiquez comment les équipes doivent utiliser ces fonctionnalités intégrées et comment nommer les personnalisations déclaratives. Tenez également un journal des informations clés identiques à celui que vous utilisez pour le code.

Élaborer un ensemble de normes de documentation pour s'assurer que tous les membres actuels et futurs de l'équipe seront en mesure d'interpréter les documents de la même façon (les normes de conception peuvent y contribuer). Il est également important de déterminer comment les utilisateurs peuvent rechercher dans la documentation des sections ou des termes pertinents. À mesure que votre système vieillit et gagne en complexité, votre documentation s'enrichira. L'utilité des informations contenues dans votre documentation dépendra directement de la fréquence, de la rapidité et de la facilité avec lesquelles les utilisateurs peuvent rechercher et trouver des éléments pertinents.

La liste des modèles et anti-modèles ci-dessous montre à quoi ressemble la documentation appropriée (et médiocre) pour une organisation Salesforce. Vous pouvez les utiliser pour valider ou améliorer votre stratégie de documentation.

Pour plus d'informations sur les outils de documentation Salesforce, consultez Outils pertinents à Intentionnel.

Le tableau ci-dessous présente une sélection de modèles à rechercher (ou à élaborer) dans votre organisation et d'anti-modèles à éviter ou à cibler pour remédier.

✨ Découvrez d'autres modèles de lisibilité dans l'Explorateur de modèle et anti-modèle.

Aidez-nous à garder Salesforce Well-Architected pertinent pour vous ; répondez à notre sondage pour nous faire part de vos commentaires sur ce contenu et nous dire ce que vous souhaitez voir ensuite.