Depuis les premiers balbutiements de la gestion des services TI dans les années 80, et jusqu’à récemment, les organisations, qui avaient adopté la gestion des services TI basée sur les version 1, 2 et 3 d’ITIL, avaient pour objectif la stabilité et la résilience de leurs systèmes d’information. C’est donc l’aversion du risque qui a essentiellement prévalu dans la conception et l’exécution des processus de gestion des services informatiques, ce afin d’atténuer l’impact des pannes ou autres indisponibilités sur les services TI.
Cependant, l’avènement des méthodes de travail agiles et DevOps a démontré que de nombreux processus ITSM « legacy » sont souvent rigides, à taille unique et relativement bureaucratiques.
Ce qui amène les praticiens de la gestion des services TI à se concentrer sur la conformité plutôt que la valeur à atteindre, alors que les équipes DevOps sont préoccupées par leur capacité à livrer à un rythme soutenu. Elles perçoivent l’ITSM comme un frein.
Prenons l’exemple du processus de gestion des changements informatiques. Dans certaines organisations, tous les changements, peu importe leur priorité, doivent respecter des délais de soumission stricts. Les réunions du comité consultatif des changements (CAB) ont lieu à des jours préétablis de la semaine (par exemple le mardi matin et le jeudi matin) et c’est seulement là qu’ont lieu les approbations pour les déploiements.
Si l’équipe DevOps venait à manquer le délai de soumission, alors la demande d’approbation du changement se retrouve au dessous de la pile, avec nulle autre possibilité que d’escalader pour faire passer le-dit changement. Ceci amenant son lot de risques, frustrations et de perte de temps en aller-retour.
Les processus legacy ne peuvent plus faire face au rythme soutenu des changements apportés par l’approche Agile/DevOps. Ces changements ont parfois lieu quotidiennement dans certaines organisations (ex : Google effectue 9 changements par jour sur leurs algorithmes, soit 3300 changements par an en 2019).
Ceci a conduit certaines organisation à enfreindre les politiques en place pour leur processus et à qualifier les changements DevOps en changements « urgents », plutôt que d’adapter le processus de gestion des changements aux nouvelles demandes.
Dans le cas ci-dessus, les pratiques ITSM sont perçues comme des ralentisseurs plutôt que comme des facilitateurs. Ces changements « urgents », qui de fait n’en sont pas, viennent perturber le reste de la cadence, ce qui a des implications négatives sur la qualité, la stabilité et la conformité de toute la chaîne d’exploitation des services.
