Si la culture fonctionne, la technique fonctionne aussi

Le mouvement DevOps - une combinaison de culture, de pratique et d'outils qui permet aux entreprises de déployer des applications et des services à très grande vitesse - est fortement influencé par le concept CALMS, qui signifie Culture, Automation, Lean, Measurement et Sharing.

La culture et l'échange - on pourrait et devrait peut-être plutôt dire la communication pour ce dernier - sont au début et à la fin, ils forment pour ainsi dire le cadre de l'ensemble du concept. Mais pourquoi les deux parties - Dev et Ops - doivent-elles apprendre à se parler davantage ? La question peut sembler au mieux naïve, au pire superflue ou même stupide.

Et pourtant, elle se pose régulièrement depuis l'effondrement de l'engouement pour Internet en 2000 et 2001. Par la suite, il a beaucoup été question d'industrialisation de l'informatique, y compris chez SAP. Depuis lors, la technique n'était plus considérée comme une fin en soi, mais devait servir l'entreprise et se soumettre à ses exigences.

Des normes telles que l'ITIL (IT Infrastructure Library ; recueil des meilleures pratiques en matière de gestion des services) ont été mises en avant par de nombreux clients SAP existants, afin de les aider à aligner systématiquement leur informatique sur leurs activités.

Et pourtant, le débat s'enflamme à nouveau avec force depuis que l'informatique d'entreprise est mise au défi par les grands fournisseurs de cloud. Ce sont surtout les utilisateurs qui font sentir à leurs collègues informaticiens leur insatisfaction quant à leur travail.

En effet, ils attendent le même niveau de disponibilité, de rapidité, de simplicité et de confort auquel ils sont désormais habitués en tant que consommateurs. Est-ce un hasard si le Manifeste Agile, une sorte de charte pour le développement agile de logiciels, place l'orientation client en tête de ses priorités ?

Il est donc de plus en plus évident que l'ITIL n'a pas répondu à toutes les attentes, voire à très peu d'entre elles. Mais quelle en est la raison ? L'ITIL a effectivement permis de rapprocher l'informatique et l'entreprise. Cependant, les

La contradiction entre le développement et l'exploitation ne peut pas être résolue par les règles. En effet, la tâche fondamentale des développeurs est de répondre le plus rapidement et le mieux possible aux modifications des exigences commerciales et de les mettre en œuvre.

D'un autre côté, la tâche fondamentale des opérations informatiques est de veiller à la stabilité et à la fiabilité des services informatiques, qui sont menacés par les modifications apportées au code du programme. Or, l'ITIL n'a jamais été conçu pour résoudre ce conflit d'objectifs fondamental, alors que les grands fournisseurs de services en nuage semblent justement y parvenir.

La confiance plutôt que la peur

La plupart des entreprises sont organisées selon le principe de la division du travail. Chacun est expert dans son domaine et maîtrise sur le bout des doigts les tâches relevant de son domaine de responsabilité. Mais comme seuls les experts d'un même domaine parlent la même langue, des murs invisibles se dressent autour d'eux, avec la barrière de la langue.

De minuscules portes entre les deux permettent de transmettre le résultat du travail. Ce qui se passe à l'intérieur des murs reste invisible pour les autres. Celui qui a transmis ses résultats est déchargé de toute responsabilité et n'a pas à se soucier du résultat global - le modèle parfait de la cascade.

"Dans les projets organisés selon ce modèle, les différents membres de l'équipe se concentrent souvent presque exclusivement sur la réussite de leur tâche respective, et non sur la réussite de l'ensemble.

Plus le projet est vaste et stratégique, plus il est facile d'accepter les erreurs ou les retards qui en résultent presque inévitablement, afin de remplir malgré tout les objectifs supérieurs et les engagements pris envers les départements spécialisés".

sait par expérience James Roberts, directeur technique chez Basis Technologies.

"Malheureusement, nous voyons toujours et encore assez souvent cette approche chez les clients SAP existants".

Là où les frontières entre les silos font partie du quotidien, les développeurs SAP et leurs collègues de l'exploitation informatique ne communiquent pas entre eux, ou du moins pas assez. Les premiers sont responsables des changements, du Customizing, etc. et transmettent les résultats de leur travail sans comprendre ou vérifier s'ils contiennent des problèmes pour leurs collègues de l'administration des serveurs, du stockage ou du réseau, de l'assurance qualité ou de la gestion de l'environnement de test.

Si le logiciel ne fonctionne pas comme prévu, les développeurs ne sont pas tenus pour responsables, tandis que l'exploitation informatique a fort à faire pour trouver des solutions de contournement afin de réduire au maximum le nombre et la durée des interruptions.

Les développeurs, quant à eux, sont sans cesse interrompus dans leur travail lorsqu'ils ne peuvent pas tester immédiatement leurs artefacts, mais doivent ouvrir des tickets et attendre que l'environnement de test adéquat soit techniquement et temporellement disponible pour eux. Les deux parties ne sont pas suffisamment satisfaites du travail de leurs collègues. Le silence risque ainsi de se transformer lentement en méfiance.

Dans une telle culture et avec les structures correspondantes, il n'est pas possible de répondre aux attentes des utilisateurs à l'ère du cloud. Les entreprises doivent trouver le moyen de passer d'une culture de la méfiance à une culture de la confiance.

Des tests de régression automatiques appropriés, qui permettent de déplacer l'assurance qualité vers le développement, sur le modèle du test shift-left, pourraient y remédier en grande partie.

Corriger les erreurs et intégrer les modifications de dernière minute des exigences avant même qu'une nouvelle version ne soit mise en service est généralement 20 à 40 fois moins cher, surtout dans l'environnement SAP.

Modèle de fabrication

Cela peut surprendre, mais l'idée d'une meilleure collaboration, parce que responsable et basée sur la confiance, est bien plus ancienne que l'industrie informatique. Elle a d'abord été appliquée dans l'industrie manufacturière, il y a environ quatre-vingts ans déjà. Car il est évident que les problèmes de division du travail et de spécialisation sont aussi vieux que ces derniers - et ne sont pas le produit de nouvelles technologies et méthodes de travail.

En réponse à ces problèmes, le physicien et statisticien Walter Shewhart a développé la boucle de régulation PDSA (Plan-Do-Study-Act), qui a été développée en une théorie par l'élève de Shewhart, William Edwards Deming.

Le programme de gestion développé par l'ingénieur et docteur en physique mathématique n'a toutefois pas trouvé d'utilisateurs zélés aux États-Unis dans un premier temps, mais dans le Japon d'après-guerre.

Le système de production de Toyota, qui a fait de l'entreprise le premier constructeur automobile mondial en quelques décennies, est un exemple de l'influence des idées de Deming, qui n'ont été perçues et partiellement mises en œuvre par un public plus large, et notamment par les managers, que dans les années 1980 aux États-Unis.

Des concepts tels que la gestion de la qualité totale, dans le cadre de laquelle la qualité est mesurée à tout moment et en tout point de la chaîne de processus, contrairement à l'échantillonnage, ou la production en flux tendu, aujourd'hui connue et pratiquée par tous, illustrent ce changement de perception.

Le clou et la révolution de cette approche était que chacun était non seulement responsable de son propre domaine, mais que la qualité à chaque étape était rendue transparente pour tous et en particulier pour la direction.

Le principe sous-jacent : Les erreurs arrivent. Mais si elles ne sont pas détectées ou si elles ne sont constatées qu'à la fin du processus de fabrication, il est peut-être trop tard pour pouvoir encore apporter des corrections, ou alors cela demande beaucoup de travail et d'efforts, en termes de temps et d'argent. De plus, il manque les points de mesure qui permettraient de faire des évaluations afin d'améliorer continuellement le processus.

Continuous Everything

Les méthodes d'assurance qualité et d'amélioration continues sont depuis longtemps la norme dans l'industrie manufacturière. Elles sont basées sur la responsabilité, la transparence, les cycles courts et l'orientation vers l'équipe, qui sont transposées de manière très similaire dans le monde de l'informatique grâce à DevOps.

L'intégration continue, le test continu, la livraison continue et l'amélioration continue sont tous des éléments d'une approche DevOps réussie. Celle-ci poursuit l'objectif de déployer tout changement sans risque et, idéalement, sans intervention humaine, dès qu'il est disponible.

Les méthodes de travail et les rôles doivent être adaptés en conséquence pour obtenir les résultats que DevOps permet d'obtenir, comme cela a déjà été le cas dans la fabrication.

Les frontières entre les silos doivent être abattues, les tâches clairement délimitées doivent être remplacées par le travail en équipes multidisciplinaires. Avec un seul objectif en tête : une meilleure collaboration. C'est la clé pour atteindre les objectifs commerciaux définis grâce à DevOps.

Comme nous l'avons déjà mentionné, la culture est en effet une partie essentielle du concept DevOps et concerne en particulier les éléments C, M et S dans l'approche CALMS. Ne manquez pas la deuxième partie de l'article dans le prochain numéro, qui traitera de l'impact de l'automatisation (A) et du lean management (L) sur les structures et processus de travail. Vous en apprendrez également plus sur le rôle que jouent divers outils pour faire de DevOps un standard simple, même dans des environnements SAP complexes.