Nous avons abordé dans les parties précédentes le contexte et les propositions d’organisation devops apportées par les formations ou les retours d’expériences. Désormais il nous faut trouver une solution pragmatique et adaptée au client en pleine phase de transformation. Cela suppose évidemment en premier lieu une phase d’audit et d’analyse qui permettra de dessiner les contours de la transformation et de fixer les objectifs de l’agilité et du devops. Car en dehors de la déclaration d’intention il faut apporter une vision claire et mesurable de ce qui est attendu. Il est peu probable que dans un grand groupe ce bond culturel soit réalisé en une seule fois et plus vraisemblablement qu’une seule partie de l’organisation ne souhaite ou ne soit éligible à l’agilité et au devops.
Ceci étant noté, il faut pour les opérations répondre au 3 modes exposés dans la première partie : Le mode cloisonné avec des cycles en V, le mode agile ad hoc avec des équipes scrum, le mode lab autonome qui peut déjà utiliser du SAFe ou du Spotify like. Au regard des typologies d’organisation que nous avons vu dans les parties deux et trois, cela implique pour les ops de démarrer avec des chefs de projet pour s’orienter vers la mise en place d’équipes ops dédiées.
Prenons une hypothèse contradictoire de changer toute la structure dans un même mouvement vers une organisation complètement devops, en prenant appui, par exemple, sur un modèle SAFe. Dans un premier temps cela implique de former tous les chefs de projet de production pour … et bien pour rien parce que leur rôle n’existe pas en SAFe ! Dans un deuxième temps cela implique de changer tous les métiers du RUN pour les réallouer en tant qu’ops polyvalents, sachant autant administrer en UNIX/LINUX que coder du provisionning d’infrastructure, analyser des défaillances, définir des stratégies chaos monkey, etc.. La marche serait sans doute un peu haute pour un seul mouvement. SAFe mentionne l’architecture runway comme étant la base système sur laquelle les projets sont adossés. Un architecte system, à côté du product owner, détermine la cohérence d’ensemble au niveau système, puis ce sont les équipes ops qui réalisent les environnements. Rien de précis sur le RUN des applications. Il parait donc à priori compliqué de réintroduire les systèmes existants, construits et maintenus par des services différents, dans le périmètre de responsabilité des trains.
Les questions qui vont rapidement se poser dans ce modèle :
Qui assure désormais la disponibilité du service 24/7, et comment ?
Qui assure désormais le niveau 3 des infrastructures in-house et comme continuer à construire et maintenir l’infrastructure ?
Comment sont utilisées/ventilées les ressources ops sans qu’elles ne deviennent une contention dans le fonctionnement du train ?
Qui s’occupe de l’adéquation des solutions techniques avec les compétences et systèmes disponibles, et comment ?
Qui s’occupe d’assurer que les applications développées ont bien le niveau de qualité et de fiabilité requis (et sur quels critères) ?
Pour être plus synthétique, comment assure-t-on un chemin entre l’existant technique et organisationnel et la cible SAFe ? Migrer en big bang vers SAFe pose la question de la réaffectation des ressources, de la formation technique (pas simplement organisationnelle), de la cohérence technique de l’ensemble du SI et de sa capacité à maintenir l’existant et soutenir l’ensemble des projets en cours.
Si nous prenons l’hypothèse DASA, même si l’accent est mis sur un modèle organisationnel qui répond de façon simple et cohérente aux besoins technique des équipes, pour autant le constat serait identique car l’autonomisation des équipes passe nécessairement par la polyvalence et donc l’appropriation de compétences auparavant dispersées. Cela nécessite un gros effort de formation technique et l’adaptation de quantité de personnes. Cela implique également un effort de synchronisation et de cohérence au niveau global du système d’information, même si l’idée générale est d’avoir une organisation simple pour construire des systèmes simples basés sur un couplage faible des équipes et des systèmes qu’elles développent.
Côté SPOTIFY on peut également trouver quelques réponses sur le cheminement à réaliser du point de vue technique. D’abord, comme le DASA, Spotify reprend l’idée d’une plateforme team qui héritera assez naturellement des équipes infrastructures et middleware en place. Ensuite Spotify a mis en place un rôle très intéressant avec le system owner. Spotify le définit comme suit : “The system owner is the “go to” person(s) for any technical or architectural issues related to that system. He is a coordinator and guides people who code in that system to ensure that they don’t stumble over eachother. He focuses on things like quality, documentation, technical debt, stability, scalability, and release process.” A la lecture de cette définition on comprend bien qu’il s’agit d’un rôle de transition permettant une jonction entre les équipes techniques et les squads.
J’ai finalement trouvé l’inspiration dans cette solution pour proposer un system owner qui ne soit pas uniquement le “go to person”, mais qui ait l’envergure d’un product owner, un pair qui est concentré sur les aspects techniques et qui garantit l’adéquation technique du produit avec le besoin. Le system owner est celui qui doit mettre les ops au coeur des équipes produits, ou plus précisément aux côtés des products owners. Il devient le rôle moteur du chemin vers le devops et s’assure que les mantras du devops que nous avons vu dans la partie 2 soient mis en œuvre et respectés.
A l’inverse de Spotify qui en fait un rôle relativement transverse en étant un référent du système auprès de l’ensemble des squads intervenant sur ce périmètre, le système owner proposé doit pouvoir s’intégrer et se dédier verticalement dans un train, une tribe ou une équipe autonome devops. Son rôle est d’accompagner le product owner et de mettre les ops dans le dispositif au même titre que les dev. Les missions qui le définissent sont donc multiples :
- Il construit la backlog technique en miroir au fur et à mesure que le product owner construit la sienne
- Il conseil l’équipe sur l’utilisation des briques techniques disponibles dans le catalogue de services ou au travers des compétences apportées par la platform team
- Il veille à la construction d’une architecture émergente
- Il favorise globalement l’émergence plutôt que la construction de grande planification et le choix de solution à priori (big plan up-front)
- Il veille à la mise en place des pipes CICD
- Il maintient le lien vers les platforms team et le pilotage du run.
- Il alimente les platforms teams en besoins d’innovation pour répondre aux besoins des métiers
- Il favorise l’interaction continue entre dev et ops
Au travers de ces missions le system owner s’intègre dans les différents types d’organisation que nous avons eu l’occasion de présenter : Dans SAFe il devient le référent technique du train qui permet de conserver un alignement constant entre les équipes scrum, les system team, et les architectes system. Dans une équipe devops autonomes sur le modèle DASA, il permettra de faire le lien avec la platform team, d’accompagner l’architecte système et les ops pour porter une responsabilité différente et plus englobante sur l’adoption des mantras devops. Enfin il permet aux chefs de projet opérationnels existant de pouvoir se projeter sur leur futur rôle dans une organisation devops, et c’est évidemment un gage d’implication dans la transformation.
Il reste évidemment à former ces nouveaux system owners qui deviennent ainsi le chaînon manquant dans le processus d’évolution d’une organisation ITIL vers une organisation devops.
Avec mes tous mes remerciements pour la relecture et l’aide précieuse de Nadia Djelassi, Pierre-Antoine Joly et Sébastien Coustal. Je remercie également toutes les personnes qui ont pris le temps d’y ajouter leurs commentaires et de repartager cette série d’articles.