Connecteurs réussis: Meilleures pratiques et stratégies de mise en œuvre
La meilleure pratique avec les connecteurs est toujours de privilégier une approche basée sur des règles et de traiter les exceptions ultérieurement ou après l'épuisement des règles, plutôt que de commencer par une approche basée sur les exceptions.
L'approche basée sur les exceptions est séduisante et attrayante car elle valorise le choix humain et la préservation de la structure du processus actuel. Mais elle trace une trajectoire vers un endroit qui n'offrira aucune bonne alternative pour développer et maintenir des processus sains à long terme. À cet égard, commencer par penser aux exceptions plutôt qu'aux règles est une erreur que nous évitons à tout prix.
Un gain à court terme pour une douleur à long terme en un mot. La plupart des organisations avec lesquelles nous travaillons partagent ceci en commun : elles cherchent à préserver les processus actuels. Lorsque la technologie est recherchée, elle est destinée à embrasser le processus actuel plutôt que de trouver un compromis entre les limitations du processus et l'efficacité.
Nos connecteurs sont un moyen de relier le flux de contenu d'un référentiel à BWX, puis de revenir en arrière. Bien que nous comprenions le besoin occasionnel de sélectionner manuellement un fichier ou autre pour un travail basé sur un connecteur, la meilleure pratique pour les connecteurs est de suivre une approche basée sur des règles plutôt qu'une approche manuelle.
La tentation de l'approche manuelle expliquée
Les approches manuelles sont tentantes car elles ne nécessitent aucun changement de processus. Les personnes peuvent explorer le fichier exact qu'elles souhaitent faire traduire et lancer un projet de traduction à l'aide du connecteur. Le problème de l'approche manuelle est qu'elle n'est pas évolutive, durable et prévisible (difficile à améliorer).
C'est pourquoi nous n'explorons l'approche manuelle qu'après avoir épuisé toutes les possibilités d'adapter le comportement du connecteur au comportement basé sur des règles. Il est nécessaire de traiter les exceptions, mais on ne peut pas concevoir par exception.
Un produit réussi et sa mise en œuvre respective reposent sur des règles qui couvrent le plus grand pourcentage possible de cas d'utilisation. Les cas d'utilisation qui ne sont pas couverts doivent ensuite être soigneusement évalués afin d'explorer les contournements et les solutions pour les intégrer dans les paradigmes proposés.
Voici un exemple : le client A dispose d'un connecteur qui fonctionne selon un calendrier, mais parfois il a des projets qui nécessitent une exécution hors calendrier. Voici quelques options différentes pour aborder cela :
- Demander manuellement une exécution hors plan à notre équipe de support
- Utiliser notre interface de ligne de commande (CLI) pour demander une exécution hors programme
- Créer une branche/répertoire hors cycle qui est vérifié plus fréquemment que le calendrier habituel afin de récupérer les tâches urgentes.
Voici un autre exemple : le client B est utilisé pour sélectionner des fichiers afin de démarrer le processus de localisation. Au lieu de perpétuer l'approche manuelle, la plupart des processus de sélection suivent un comportement qui peut être inversé.
Il vaut toujours la peine de pousser cette rétro-ingénierie à ses limites. Si vous commencez par une approche manuelle ou si vous vous concentrez sur la couverture des exceptions dès le départ via l'interface utilisateur, cela deviendra alors une béquille handicapante plutôt qu'un accélérateur de programme. Lorsque nous pensons à un connecteur, nous pensons toujours à l'automatisation.
C'est la véritable efficacité du processus entraînée par un connecteur. L'exportation et l'importation de projets ne représentent qu'un petit gain en ce qui concerne les connecteurs. Le véritable avantage réside dans les règles métier et la prévisibilité et la gouvernance qu'elles génèrent.
Le problème est que si vous concevez et mettez en œuvre par exception, l'automatisation ne devient jamais vraiment une option. L'automatisation, par définition, nécessite un certain degré de changement de processus et si nous ne poussons pas pour cette adéquation processus-logiciel, nous ne dépassons pas les attentes et devenons des vendeurs de la numérisation du chaos.
Ce n'est pas ce que nous sommes et nous n'adopterons pas cela. Les connecteurs à petite échelle doivent suivre les mêmes conceptions et principes que les connecteurs à grande échelle afin de pouvoir se développer et croître efficacement. La plupart des programmes de localisation demandent des solutions basées sur des cas d'utilisation actuels (qui sont en réalité du passé) plutôt que sur des cas d'utilisation tournés vers l'avenir qui projettent plus de fichiers, plus de cadence, plus de localisations, moins de temps de mise sur le marché, moins de coûts et plus de personnes travaillant ensemble.
Si vous ne vous engagez pas dans la bonne direction dès le départ, la correction de trajectoire ultérieure est coûteuse et très difficile car vous manquerez la fenêtre de changement introduite par une nouvelle implémentation. Tous nos connecteurs, grands ou petits, sont basés sur des règles et des paramètres.
Ils sont régis par les mêmes principes de conception et aucun d'entre eux n'a besoin d'une interface utilisateur pour fonctionner correctement. L'interface utilisateur peut être un ajout intéressant à un connecteur mature, mais principalement pour modifier facilement les configurations du connecteur plutôt que pour démarrer manuellement des projets.
Nous ne pouvons pas promouvoir le succès à long terme si nous sommes complices de l'accélération des processus analogiques existants.
Au contraire, notre objectif est de traduire les processus analogiques en pensée numérique afin qu'ils deviennent vraiment compatibles avec les logiciels, permettant ainsi l'automatisation axée sur les données. Nous sommes habitués à gérer des connecteurs qui traitent des milliers de fichiers par jour dans près d'une centaine de localisations différentes.
Au fil des années, nous avons appris que les mêmes ingrédients qui font le succès d'un connecteur à grande échelle doivent également être respectés pour les connecteurs à petite échelle afin de respecter les principes de conception de base de la scalabilité et de la durabilité.
