Nous pourrions croire que ces deux mondes se complètent… mais ce n’est pas si simple ! Les organisations ITSM doivent prendre conscience de l’impact de DevOps sur leur structure traditionnelle.
DevOps et ITSM peuvent-ils co-exister ? La question mérite d’être posée. Et effet, l’ITSM (IT Service Management) est un pont érigé entre l’informatique et le business et ses clients qui permet de canaliser les flux et d’optimiser les réponses. Mais la philosophie DevOps, qui organise et rationalise la relation entre développeurs et opérationnels, vient heurter cette structuration au moins sur trois principes : la pensée systémique, l’amplification des boucles de rétroaction, la culture de l’expérimentation et l’apprentissage continu.
Face à la fois à des Directions générales qui commencent à voir DevOps comme un Graal, et à des DSI qui y voient une bouée qui va leur permettre de prolonger leur survie, le personnel ITSM se retrouve dans une position inconfortable, où leur vision du contrôle des processus ne fonctionne pas avec DevOps.
L’incompatibilité ITSM et DevOps
En effet, le système de pensée DevOps est incompatible avec ITSM sur trois points essentiels :
- DevOps nécessite une structure de boucle pour offrir de la valeur et d’amplifier la rétroaction qui est incompatible avec les fonctions de processus ITSM.
- En termes de mise au point, ITSM est axé sur les ressources (comment pouvons-nous rendre la gestion du changement efficace ?), alors que DevOps est orienté flux (comment pouvons-nous efficacement mettre de la valeur dans les mains des clients ?).
- En termes de contrôle et de processus, ITSM a des silos fonctionnels (changements et incidents), alors que DevOps dispose d’équipes produits (inventaire, facturation et commandes, par exemple) qui sont responsables du flux de valeur de leurs produits.
Quant au système bi-modal prôné par le Gartner, qui pourrait se traduire par un déplacement des silos fonctionnels à la distribution de la connaissance de l’entreprise dans les flux de valeur de DevOps, il semblerait qu’il ne fonctionne pas...
S’écarter de la voie ITSM
Le modèle d’organisation traditionnelle associé à ITSM repose sur la peur, de la panne ou de la violation de sécurité. Dans ces conditions, les systèmes ITSM mis en place, qui se targuent d’être le pont entre les IT et le terrain, se révèlent d’une grande lourdeur lorsqu’il s’agit de parler changement, mais également communication. De plus, DevOps tend à assurer que tout le monde dispose d’un accès aux flux de valeur, avec des processus interconnectés qui ne supportent pas les cloisonnements.
Or, avec DevOps, ITSM n’est plus le seul flux de communication et ne doit pas contrôler la boucle de rétroaction. De même, la concentration de la gestion des incidents vers l’extérieur doit évoluer du processus vers le produit. Enfin, les processus de gestion du changement, comme les conseils consultatifs, sont une malédiction pour DevOps, et doivent sortir de la ligne tracée.
Le modèle ITSM repose sur des ‘tribus’ organisationnelles alignées sur des processus abstraits. Le climat de peur évoqué plus tôt ne favorise pas l’expérimentation. L’apprentissage est axé sur la fonction et la tribu, ce qui ne favorise pas son partage, à moins d’être ventilé entre les silos ITSM. Dans le modèle DevOps, les tribus sont alignées avec des produits tangibles que consomment les clients qui en tirent de la valeur. L’organisation favorise le cross-équipes, impliquant jusqu’à des équipes extérieures.
Comment faire ?
Les organisations ITSM doivent prendre en compte les trois principes DevOps afin de favoriser l’apprentissage et l’expérimentation, en permettant aux équipes de développement de rester autonomes sur leurs produits sans les étrangler via le dictat d’un centre d’organisation. Et c’est au DSI, qui est au cœur des deux approches, ITSM et DevOps, d’être le coordinateur de la mutation et de donner les directions à suivre.
Image d’en-tête 25510162 @ iStock Topp_Yimgrimm
