C'est la rigidité de l'organisation, et non du matériel, qui freine les déploiements d'applications
La consolidation du fossé entre l’informatique traditionnelle et une informatique plus agile, axée sur DevOps, se traduit par l’émergence d’une architecture de centre de données essentiellement à deux niveaux. Cela ne devrait pas surprendre ceux qui y prêtent attention. Pendant des années, j'ai été inondé de questions de la part des opérations et des développeurs qui souhaitaient avancer plus rapidement, plus fréquemment, mais qui étaient bloqués par la rigidité non pas du matériel du cœur de réseau, mais des processus qui nécessitent des approbations manuelles et des processus pour mettre en œuvre les changements.
Les frictions qui existent naturellement entre ceux qui sont chargés de maintenir un transfert sécurisé, stable et rapide des données entrant et sortant du centre de données et ceux qui sont chargés de mettre sur le marché – maintenant – les applications et fonctionnalités considérées comme le catalyseur de la croissance de l’entreprise provoquent beaucoup de discussions animées, de pointages du doigt et de ressentiments.
Beaucoup aiment blâmer les « boxen ». Ces éléments matériels vieillissants et hérités qui résident dans le réseau et qui, bien qu’ils fournissent les services critiques applications ont besoin pour évoluer et rester sécurisées, ne font que « gêner ». Mais la réalité est que ces boxeurs ne sont pas à blâmer eux-mêmes. Presque tous les systèmes actuels disposent d’une API qui permet à toute personne ayant accès à curl et une connaissance pratique de HTTP de configurer, de gérer et de manipuler les services qui accompagnent chaque déploiement application . Bon nombre de ces mêmes « boxes » sont elles-mêmes virtualisées et servent à fournir le même type d’expérience virtuelle que celle qui se trouve plus en profondeur dans le centre de données.
Il ne s’agit guère d’obstacles sur la voie rapide qu’est la notion de déploiement continu.
C’est plutôt la rigidité des organisations, dans la culture, comme ont l’habitude de dire les partisans de DevOps, qui provoque ces frictions et ralentit les déploiements application . Parce qu’il est nécessaire de maintenir la stabilité et la sécurité dans la production, ce qui n’existe pas nécessairement dans l’environnement plus volatil qu’est le développement d’applications, la tolérance aux erreurs et aux inévitables perturbations de l’activité qu’elles entraînent est moindre.
Ce n’est pas forcément une mauvaise chose. Le cœur de réseau doit certainement maintenir un niveau élevé de disponibilité, non seulement pour garantir l’accès aux applications à l’intérieur du centre de données, mais également pour les utilisateurs qui s’appuient sur des solutions SaaS publiques pour faire leur travail.
Les organisations doivent toutefois assouplir les contraintes afin de mieux équilibrer les besoins des deux niveaux architecturaux dans le centre de données moderne. Les déploiements d’applications doivent être plus rapides et plus fréquents. Pour y parvenir, les organisations doivent examiner sérieusement les processus actuellement en place, qui sont presque certainement plus rigides et inflexibles que les cadres qu’elles régissent. Les processus opérationnels informatiques sont aujourd’hui aussi importants pour les entreprises que leurs processus métier, ceux que les dirigeants d’entreprise comprennent doivent être examinés, évalués, documentés, automatisés et améliorés pour produire des avantages en termes d’efficacité et de performances commerciales. Plus important encore, ils doivent être suffisamment agiles pour pouvoir être modifiés si nécessaire. Mais pour y parvenir, les organisations doivent comprendre ces processus et être prêtes à les évaluer avec un œil critique sur l’inefficacité et les points d’étranglement.
Dans un rapport AIIM Industry Watch de 2016 intitulé « Gestion de l'information – État de l'industrie 2016 », cinquante-cinq pour cent des répondants ont déclaré que la gestion des processus métier (BPM) était importante (38 %) ou impérative (17 %) pour leur entreprise.
En ce qui concerne l’utilisation de la technologie pour améliorer les processus, les entreprises ont constaté des améliorations à tous les niveaux :
❶ Un tiers des organisations ont constaté une diminution de leurs cycles d’examen et d’approbation et 62 % déclarent avoir bénéficié d’un meilleur routage vers et entre les individus. Pour 42 %, les bénéfices proviennent d’une plus grande agilité organisationnelle et d’un routage entre les processus.
❷ Le traitement plus rapide des activités critiques de l’entreprise a apporté la plus grande valeur pour 53 % des répondants. 45 % citent comme plus grande valeur la réduction du traitement des erreurs et des exceptions.
❸ Le retour sur investissement a été réalisé dans un délai d'un an pour 41 % des répondants, dont 17 % citent un retour sur investissement dans les 6 mois. Pour 25 %, leur retour sur investissement a été obtenu en 18 mois.
Le service informatique utilise souvent le terme « orchestration », mais discute rarement de son lien avec le processus. C’est lorsque l’orchestration est utilisée pour automatiser les processus opérationnels qui régissent les déploiements que de réelles améliorations seront observées. C'est en découvrant les gaspillages et les lacunes dans la chaîne de valeur et en éliminant les temps d'attente, les approbations inutiles et les redondances que les organisations bénéficieront du même type de gains en termes de vitesse et d'agilité que ceux qu'elles ont constatés du côté des processus métier .
Nous pouvons l’appeler DevOps ou nous pouvons l’appeler Gestion des processus opérationnels (OPM), mais la réalité est que les deux sont étroitement liés. Les organisations doivent appliquer aux processus informatiques opérationnels ce qu’elles ont déjà fait avec les processus métier pour obtenir une plus grande agilité et une plus grande rapidité de déploiement des applications sans sacrifier la stabilité et la sécurité.
Et cela n'a pas grand chose à voir avec le fait qu'il y ait ou non des box dans le centre de données.