DevOps : où commence le continuum ?

DevOps n'est pas un spleen de quelques geeks. DevOps est plutôt un concept et une méthode en un. Concept parce qu'il exige une autre culture d'entreprise, loin de la division excessive du travail, vers un travail d'équipe interdisciplinaire.

Méthode parce que l'approche suit des principes et des procédures clairement définis et éprouvés, qui doivent être soutenus, en particulier dans l'environnement SAP, par une chaîne d'outils intégrée incluant des procédures de test automatisées.

DevOps concerne les fonctionnalités qui font avancer l'entreprise. Et dont le développement s'en tient strictement aux objectifs budgétaires, sans contrôles détaillés de la part des supérieurs. Ce qui nous amène directement au thème du lean management : L'écoute et la confiance plutôt que des obligations de documentation maximales, des projets gérables et ciblés plutôt que des grands chantiers qui rapportent beaucoup de prestige, mais qui coûtent deux fois plus cher que prévu.

Mais les équipes informatiques elles-mêmes doivent être "lean" et agiles, suivre les mêmes principes de procédures allégées que la direction. Mais qu'est-ce que cela signifie réellement ? Le Lean Enterprise Institute répond à cette question :

Pas de DevOps sans principes agiles

Le principe suprême est l'orientation client, l'utilité d'une nouvelle fonctionnalité pour les utilisateurs. Une fois que les responsables ont déterminé leur valeur, ils devraient ensuite examiner les processus pour voir s'ils apportent une valeur positive. Celles qui ne le sont pas devraient être supprimées.

Troisièmement, les processus devraient être (re)conçus de manière à réduire la durée moyenne d'un cycle entre le développement et la mise en production (sprint).

Cela permet de livrer des fonctionnalités en continu - et donc de contrôler et de mesurer plus précisément leur qualité et leur valeur ajoutée. Quatrièmement, c'est l'entreprise qui doit déterminer la valeur ajoutée de l'informatique, et non l'inverse.

Il faut se représenter ces quatre principes comme les perles d'un collier, dont la cinquième ferme la boucle : "Continuous Improvement" permet, grâce à des boucles de répétition, de tirer des enseignements qui permettent d'optimiser le processus global à chaque sprint.

Mais les améliorations ne sont reconnaissables en tant que telles que si elles peuvent être mesurées. Le concept DevOps recommande même de mesurer en continu, c'est-à-dire de collecter des indicateurs à de nombreux endroits différents du processus de développement.

Les clients SAP existants devraient par exemple compter les transports et les modifications qui sont livrés à un système SAP au cours de périodes données.

Combien de temps faut-il pour que les exigences soient coulées dans le nouveau code logiciel ? Combien de corrections y a-t-il par sprint ? Ce nombre augmente-t-il ou diminue-t-il ? Les nouvelles fonctionnalités demandées sont-elles livrées à temps ?

Tous ces indicateurs sont pertinents et peuvent être améliorés en permanence si les équipes DevOps réfléchissent, discutent et optimisent régulièrement leur travail.

Les clients SAP existants qui souhaitent introduire DevOps devraient s'orienter vers les principes Lean mentionnés. Lequel de ces principes est le plus facile à mettre en œuvre ou est déjà une réalité ?

Le point de départ pourrait être le flux de valeur Requirement-to-Deploy. Créez des indicateurs et mesurez le plus grand potentiel d'amélioration dans ce flux de valeur.

Est-ce l'ampleur et la taille des projets et des équipes ? Réduisez-les tout en augmentant leur nombre ! Réunissez les développeurs, les administrateurs et les responsables qualité autour d'une même table et vous voilà dans le monde DevOps. Des équipes petites mais puissantes, car travaillant de manière interdépartementale et autonome, apportent en somme une plus grande valeur ajoutée.

La raison concrète de l'introduction de DevOps sera, dans les années à venir, le passage à S/4. Pour un projet de cette ampleur et de cette pertinence, de nouvelles méthodes sont nécessaires.

SAP en tient également compte avec sa méthode d'introduction SAP Activate (voir aussi page 62), qui suit des principes agiles. Dans notre prochaine chronique, nous discuterons des approches de migration vers S/4 Hana et du rôle que joue l'automatisation dans ce processus.