Service Ownership

Introduction

Toute entreprise s’appuyant sur des applications basées sur des microservices à forte granularité a tout à gagner du service ownership, une bonne pratique permettant d’augmenter la satisfaction client, d’aligner les équipes et de réduire les incidents. En effet, même les petites entreprises qui utilisent des microservices ont tout intérêt à adopter la mentalité « vous le construisez, vous le gérez ».

Et voici pourquoi : au lieu de distinguer les développeurs des responsables d’une application, la gestion d’un service est confiée à la même équipe ou personne tout au long de son cycle de vie. Autrement dit, la personne ou équipe en question est également responsable de la sécurité, la performance, la qualité et la fiabilité de cette application.

En améliorant la responsabilisation en matière de microservices, vous renforcez la fiabilité moyenne de vos équipes et vos logiciels peuvent être déployés avec rapidité et efficacité. Autrement dit, il est beaucoup plus facile de surpasser la concurrence au niveau des parts de marché, de la rentabilité ou de tout autre indicateur important pour vous et votre entreprise. 

Cependant, le service ownership n’est pas une pratique naturelle, particulièrement dans les entreprises les plus traditionnelles qui sont toujours habituées aux systèmes monolithiques. Afin d’adopter des structures compétitives qui sont compatibles avec un environnement de microservices, il est nécessaire de reconcevoir les équipes afin qu’elles puissent assumer la responsabilité et se rapprocher des clients.

Découvrez toute l’importance du service ownership et comment fournir de meilleurs produits et services en transformant la culture de votre entreprise.

Qu’est-ce que le service ownership ?

Le service ownership, également connu sous le nom de philosophie « code it, ship it, own it » (le coder, l’expédier, se l’approprier), part du principe que les développeurs ou les équipes de développement qui créent un produit ou un service conservent la responsabilité de son code et de ses performances, même après sa livraison.

Il ne fait aucun doute que, quel que soit le secteur d’activité, les entreprises délaissent de plus en plus les technologies on-premise au profit des environnements cloud et environnements de microservices, qui offrent une plus grande flexibilité, une meilleure évolutivité et sont plus faciles à maintenir. Ce qui commence généralement par quelques services à faible granularité se transforme rapidement en services à forte granularité.

Ceci est totalement normal, car à mesure que l’architecture microservices se développe, les services sont divisés et adaptés. Après tout, les services sont beaucoup plus faciles à maintenir et à déployer lorsqu’ils existent sous leur forme modulaire la plus élémentaire.

Dès lors que la granularité de service atteint un certain niveau, de nombreuses applications se composent généralement de plusieurs microservices conçus pour une finalité précise, à savoir, l’exécution d’une tâche client donnée. En cas d’incident, il doit être facile de joindre le responsable du microservice concerné, qui sera chargé de résoudre le problème.

Cependant, à défaut de véritable service ownership, il est difficile de régler le problème le plus rapidement possible. Alors naturellement, reconcevoir l’infrastructure informatique de votre entreprise et intégrer de plus en plus de microservices nécessite aussi de revoir sa structure organisationnelle.

Si une entreprise s’accroche à une structure organisationnelle centralisée, reposant sur des équipes informatiques dans des silos établis de longue date et sur une séparation claire des tâches, elle perd les divers avantages que l’architecture microservices peut offrir. La centralisation des opérations informatiques, qui repose sur des systèmes monolithiques, est apparue au tournant des années 2010, lorsque des composants consolidés de plus grande taille semblaient rimer avec économies. Mais même à l’époque, ce modèle rigide ralentissait les performances, ce qui explique aussi pourquoi des entreprises plus petites et plus agiles ont pu perturber les poids lourds du secteur.

Le service ownership est une manière d’atténuer les problèmes propres aux structures monolithiques. Il est donc nécessaire d’adopter une nouvelle mentalité ou un nouvel état d’esprit, ainsi que de nouvelles technologies de microservices. Notez que même si le microservice ownership part du principe qu’une équipe dédiée se sente responsable de la sécurité, des performances, de la qualité et de la fiabilité du service, le code du service doit toujours être ouvert et accessible à l’ensemble de l’organisation pour faciliter la collaboration. Ainsi, d’autres développeurs pourront intervenir si le responsable du service n’est pas disponible ou a quitté l’entreprise.

Dans la prochaine section, découvrez les responsabilités d’un responsable de service et l’importance des sponsors de services et des gestionnaires de services.

Quel est le rôle d’un responsable de service ?

Le rôle d’un responsable de service consiste à gérer un ou plusieurs microservices durant tout leur cycle de vie. Les responsables de service sont indispensables au développement des stratégies de service et sont en charge de l’intégralité du contenu du portefeuille de services, quel que soit l’emplacement des différents composants ou capacités technologiques.

Le travail d’un responsable de service dépasse le simple cadre des réparations techniques ou de la maintenance des codes du service, même si une parfaite connaissance des composants des services techniques est requise. Le rôle repose sur diverses disciplines et peut donc être comparé à celui d’un directeur général, mais pour un service particulier. Un directeur général doit avoir un « business plan » solide, saisir et articuler la valeur du service en termes d’utilité pour l’entreprise et prévoir son évolution dans le temps.

Les responsables de services gèrent le portefeuille de services (catalogue) et les risques liés à l’utilisation des différents services. En cas d’incident majeur, ils sont responsables d’essayer de résoudre celui-ci. En plus de s’occuper des mesures de sécurité, les responsables sont chargés de concevoir une feuille de route pour les services, hiérarchiser les différentes initiatives et garder un oeil sur les innovations technologiques qui pourraient réduire la structure des coûts du service concerné. Il est également impératif pour un responsable de service de communiquer avec clarté avec les parties prenantes et d’aligner les processus opérationnels avec les objectifs métier globaux.

Certaines entreprises disposent, outre des responsables de services, de sponsors de service et de gestionnaires de service. Même si leurs responsabilités peuvent se chevaucher, tous trois ont un rôle bien défini au sein d’une infrastructure informatique basée sur les microservices. Les sponsors de service fournissent généralement le financement et les ressources nécessaires pour développer et livrer le service. Ils approuvent également des éléments tels que les risques ou les coûts associés au service et contribuent à l’orientation stratégique du service avant que le responsable du service ne prenne une décision.

Un gestionnaire de services est comparable à un gestionnaire de relations commerciales ou de processus qui gère le cycle de vie d’un service pour le développement de la stratégie d’entreprise ainsi que les relations avec les fournisseurs, en étant en même temps responsable des coûts et tout l’inventaire liés au service. Le gestionnaire de services effectue également des analyses comparatives de la concurrence ou des études de marché, et supervise en interne les efforts en matière de gestion des fournisseurs. Ses autres responsabilités comprennent l’analyse des indicateurs financiers et de ceux relatifs aux clients.

Dans la prochaine section, vous apprendrez comment restructurer vos équipes de manière efficace et comment instaurer un état d’esprit de service ownership qui transformera votre entreprise.

Commencer au niveau des équipes

L’instauration d’une nouvelle culture ou d’un nouvel état d’esprit au sein d’une entreprise est un défi de taille qui demande de la patience. Après tout, un changement opérationnel aussi fondamental ne se fait pas du jour au lendemain. Il s’agit d’un exercice d’équilibriste, dans lequel les dirigeants doivent convaincre des équipes ayant des motivations contradictoires de travailler ensemble.

Puisque les équipes qui travaillent non pas ensemble mais l’une contre l’autre sont préjudiciables à une culture de microservice ownership, il est important de commencer directement au niveau des équipes. En d’autres termes, vous devez unir les équipes et vérifier que leurs objectifs sont communs. Et si l’objectif d’une équipe n’est pas de contribuer aux objectifs globaux de l’entreprise, elle doit être restructurée.

Mais pour commencer, comment des équipes peuvent-elles avoir des objectifs différents ? Lors du développement d’un nouveau microservice, chaque équipe peut avoir ses propres motivations. Pendant qu’une équipe se concentre sur les problèmes de sécurité, une autre s’occupe principalement de l’innovation des produits et du développement de nouvelles fonctionnalités.

La direction peut faire naître un état d’esprit de service ownership en réunissant ces équipes autour d’un objectif commun. Il faudrait, dans l’idéal, axer cet objectif autour des intérêts du client, ce qui bénéficiera en fin de compte également à l’entreprise.

En outre, lorsqu’une équipe est responsable de la gestion d’un service, elle obtient presque automatiquement une fonction transversale et sera responsable de la sécurité, de la fiabilité et de la mise en œuvre de nouvelles fonctionnalités.

Mobiliser les responsables de l’ingénierie

Une fois les objectifs des équipes alignés, l’étape suivante consiste à intégrer les responsables de l’ingénierie. Il est essentiel de reconnaitre l’importance des responsables de l’ingénierie dont la coopération est indispensable au succès du service ownership.

Dans le cadre de leur rôle de premier plan consistant à rendre compte à la direction de la santé des services et à procéder à la planification des capacités et au suivi des besoins de l’entreprise, il est important qu’ils saisissent les avantages d’une culture de service ownership, et comment ils peuvent la promouvoir activement.

S’il est correctement mis en place, le microservice ownership ne remet pas en question le rôle des responsables de l’ingénierie, mais les aide au contraire à livrer un code de service de haute qualité, car il existe un sens commun de la responsabilité pour la livraison de produits plus performants. Ce sens accru de la responsabilité entraîne également une réduction des points de défaillance et un meilleur contrôle des dommages.

En cas d’interruption de service, il n’y a pas d’intermédiaire, car le développeur qui a créé le code peut être directement contacté. Les ingénieurs de service peuvent contribuer à instaurer cette culture et responsabiliser les membres de l’équipe en leur donnant les pouvoirs nécessaires.

La section suivante vous montrera comment instaurer un état d’esprit de service ownership en appliquant deux méthodes testées et approuvées.

Établir une culture de service ownership

Le service ownership étant une culture vécue et non un outil tangible, elle doit se construire au fil du temps. Cependant, il existe des manières de favoriser un changement de mentalité afin que les équipes s’épanouissent dans un environnement où ils ont plus de responsabilités et où les meilleurs services sont fournis aux clients. Les deux méthodes ci-dessous sont des moyens éprouvés d’initier ce changement et de mettre tout le monde d’accord.

Mentalité du « client d’abord »

Comme mentionné auparavant, le service ownership ne peut se développer si les équipes ont des objectifs opposés. Et le meilleur moyen de les aligner est d’établir un objectif commun, comme se concentrer sur le besoin des clients. Bien sûr, une approche axée sur le client permet non seulement d’unifier les équipes, mais aussi de satisfaire les clients et d’augmenter la croissance et donc les bénéfices. Pour soutenir une culture de service ownership, vous pouvez utiliser des SLO (service-level objectives, en français « objectifs de niveau de service ») afin d’aligner les indicateurs et les motivations.

Célébrer l’échec et le courage

Assumer l’entière responsabilité d’une chose peut s’avérer effrayant. C’est pourquoi les développeurs doivent résister à l’idée qu'ils seront le premier point d’appel si le code de leur service ne fonctionne plus. C'est la raison pour laquelle les dirigeants doivent créer un environnement favorisant la sérénité de tous les membres de l’équipe. Personne ne doit être préoccupé par l’idée de perdre son travail ou de commettre une erreur. Au contraire, avec le service ownership, il doit y avoir un consensus sur le fait que les erreurs sont une opportunité d’apprendre et d’améliorer les produits.

Conclusion

Ces dernières années, le microservice ownership est devenu une bonne pratique, dans le sens où les microservices à forte granularité ajoutent de la complexité à toute architecture informatique. En effet, la refonte d’applications web monolithiques en composants plus petits et plus agiles ne représente qu’un côté de la médaille.

Pour pleinement profiter d’applications plus légères et plus agiles, il est tout aussi important de remanier les équipes IT centralisées et de les transformer en responsables de services polyvalents.

Toutefois, faire évoluer les mentalités et instaurer une véritable culture de service ownership nécessite beaucoup de temps et d’efforts. Il faut commencer au niveau des équipes, inclure les chefs ainsi que les responsables de l’ingénierie et définir des objectifs communs centrés sur le client. Enfin et surtout, vous devez créer un environnement qui favorise la sérénité, célèbre l’échec et récompense le courage.