Empilez des choses plus « simples » et faites du DevOps !
Un système d'informations peut rapidement se transformer en une véritable usine à gaz tant les applications et fonctionnalités sont interconnectées ou deviennent trop complexes et imposantes...
Dans ces conditions, la moindre évolution de telle ou telle application peut avoir un effet désastreux sur l'intégralité du système d'information, du coup on passe plus de temps à analyser les nouveaux besoins, plus de temps à les spécifier, plus de temps à les tester et la mise en production ressemble plus souvent à un chemin de croix qu'à un réel plaisir d'apporter de nouvelles fonctionnalités à vos utilisateurs.
Résultats des courses : pour 10 jours de développement, vous en demandez 50, voire 100, car vous n'êtes plus en mesure d’analyser rapidement les conséquences des évolutions demandées. Ce « travers » est spécifique aux « grosses » organisations mais je suis sûr qu'il touche également les organisations de taille moyenne et il est donc temps de réagir !
La solution : « Diviser pour mieux régner !»
Cette « solution » peut s'appliquer à deux niveaux :
- dans l'interaction entre les applications (ou données d'applications),
- dans vos travaux de développement d'applications et de leurs mises en production.
Dans l'interaction entre les applications (ou données d'applications)
Beaucoup d'applications ont besoin d’interagir avec une ou plusieurs autres applications et l'on croit souvent, à tort, que ces interactions doivent s'établir en temps réel or, dans beaucoup de cas, quelques secondes sont largement acceptables... Et bien ce sont ces quelques secondes qui vont nous permettre, d'insérer, entre ces deux applications un processus « tampon » qui fera la passerelle entre les deux applications et qui permettra de décorréler les deux applications. C'est pas clair ? Je donne un exemple :
- l'application A envoie un flux de données régulier à l'application B
- ce flux de données est composé de Data1, Data2 et Data3
- suite à une évolution demandée pour l'application A, le flux de données est désormais composé d'une donnée supplémentaire (ex. Data4) qu'il faudra, peut-être, aussi donner à l'application B
- le processus « tampon » reçoit alors les 4 données de l'application A mais n'en renvoie que 3 à l'application B qui fera l'objet d'une évolution ultérieure...
Cette manière de procéder permet d'entrevoir les évolutions d'une manière différente et peut-être aussi utilisée de différentes façons :
- l'application B peut être modifiée avant l'application A, charge au « tampon » de créer la Data4 (vide ou avec une valeur par défaut) tant qu'elle n'existe pas du côté de l'application A,
- le process qui extrait toutes les données de l'application A peut ne pas être modifié et c'est alors le « tampon » qui n'enverra pas Data4 à l'application B si elle n'en a pas besoin,
- l'application A peut être mise en production très rapidement et indépendamment de l'application B qui fera l'objet d'un évolution ultérieure,
...etc...
Ne serait-ce qu'au niveau de votre planning de développement, imaginez un peu quelle souplesse cela peut apporter ?
Dans vos travaux de développement d'applications et de leurs mises en production.
Dorénavant il existe pléthore de solutions pour déployer rapidement des applications sur des postes de travail et c'est encore plus simple s'il s'agit d'une application centralisée (ex. application en mode web). Il n'y a donc plus aucunes excuses pour déployer de nouvelles versions très régulièrement.
Le déploiement n'étant plus un frein vous allez pouvoir déployer de nouvelles versions très fréquemment et cela va permettre :
- de réduire drastiquement l'ampleur d'un nouveau développement en diminuant le nombre d'évolutions ou de corrections faites en une seule fois et en multipliant les petits cycles de développement,
- de réduire du coup la charge de test et de recette souvent vécue comme un « mal nécessaire »,
- de réduire naturellement le nombre de bugs découverts après la mise en production,
- de répondre beaucoup plus rapidement à une demande de vos utilisateurs, et aux demandes de votre « marché » (le fameux « time to market »).
Et quand vous serez en mesure de développer de nouvelles choses, sans exiger de cahier des charges de 100 pages mais juste en réunissant les parties prenantes, sans oublier les utilisateurs, alors vous serez dans le « DevOps » mais ça, c'est une autre étape !
