Mike Loukides, vice-président chargé du contenu éditorial chez O'Reilly Media, propose une mise à jour de son article "What is DevOps" qui date d'il y a maintenant deux ans en se concentrant sur les changements culturels.
Loukides passe en revue les origines culturelles du mouvement DevOps, et la focalisation sur la coopération et la collaboration, non seulement entre développeurs et opérationnels, mais étendues à l'ensemble de l'organisation :
DevOps n'est pas un outil, c'est une culture, et cela dépasse de loin les développeurs et les opérationnels.
La base culturelle du mouvement DevOps a aussi été par ailleurs, soulignée par Jeff Sussna, fondateur et directeur de Ingineering.IT. Dans "Empathy: The Essence of DevOps", il décrit l'empathie comme la clé de la relation qui doit avoir lieu entre les équipes concernées :
DevOps ne consiste pas à faire en sorte que les développeurs et les administrateurs système dépendent du même vice-président. Cela n'est pas l'automatisation des procédures de configuration. Cela n'est pas lancer un serveur Jenkins, ou lancer vos applications dans le cloud, ou gérer vos sources à l'aide de Github. Cela n'est pas non plus laisser les développeurs déployer leur code dans un PaaS. La vraie essence de DevOps, c'est l'empathie.
Et il existe des moyens d'augmenter cette empathie entre les équipes, comme le fait de rassembler les équipes de développement et opérationnelles, les faire participer aux mêmes standup meetings, ou qu'ils sortent pour déjeuner ensemble. Tout ça pour créer un environnement qui encourage l'empathie.
Une approche descendante du management n'est plus adaptée pour penser ce type de relations entre les équipes. Comme Mark Burgges, directeur technique et fondateur de CFEngine, le fait remarquer dans "The Promises of DevOps", il y a un conflit d’intérêt entre les développeurs et les opérationnels. Les développeurs sont motivés pour créer des fonctionnalités aussi rapidement que possible alors que les opérationnels n'ont aucun intérêt à changer quoi que ce soit et à prendre le risque que quelque chose se passe mal. Burgess analyse DevOps du point de vue de la théorie de la promesse, un regard différent sur le management :
Dev promet des choses que Ops aime, Ops promet des choses que Dev aime. Les deux promettent de maintenir la chaîne d'approvisionnement à un certain niveau, c'est à dire Dev fournit à une fréquence qui permet à Ops de promettre de déployer.
En choisissant d’exprimer ceci sous la forme de promesses, nous savons que les estimations sont faites par les personnes qui sont en charge des tâches, et non par de pieux penseurs qui n'ont pas la moindre idée.
Cette relation Dev-Ops n'a rien de particulier, le même type de coopération s'applique au reste de l'organisation. Par exemple, le management promet des objectifs et le personnel promet de mettre en oeuvre ces objectifs à une certaine fréquence. Mike Loukides fait une prédiction :
Dans cinq ou dix ans, nous verrons qui a survécu et qui a prospéré, et nous verrons que les entreprises qui ont mis en place des communautés basées sur la collaboration, le respect mutuel et la compréhension auront surpassé la concurrence.
DevOps n'est pas seulement la somme de Dev et de Ops mais il affecte la gestion de l'entreprise dans son ensemble et la culture, de bas en haut, avec les différents acteurs faisant la promesse les uns aux autres de maintenir l'entreprise dans un environnement dans lequel chaque individu travaille dans l'intérêt de la société dans son ensemble.