Formation DevOps écrite

Comment structurer votre organisation DevOps et concevoir votre architecture logicielle ?

Selon la loi de Conway, les organisations qui conçoivent des systèmes sont contraintes de produire des systèmes qui reproduisent leurs propres structures de communication. En d’autres termes, la qualité de vos logiciels est limitée par l’efficacité avec laquelle vos équipes communiquent et interagissent. La façon dont vous structurez vos équipes a donc des conséquences sur l’architecture logicielle, sur les performances informatiques et, finalement, sur les résultats de l’entreprise.

La structure de votre organisation détermine le type de logiciel que vous obtenez

La plupart des entreprises, probablement la vôtre aussi, cloisonnent leurs équipes de livraison logicielle et finissent par produire des logiciels dont l’architecture comporte autant de couches que d’équipes. Des expériences contrôlées ont également montré que lorsqu’une organisation comptant six équipes a dû créer un logiciel, ses équipes ont conçu une architecture à six couches. Quand une autre organisation, qui comptait trois équipes, a reçu la même tâche, elle a conçu une architecture à trois couches. Les exemples similaires sont nombreux.

Une compagnie d’assurance réputée, comptant 86 000 salariés dans le monde, avait structuré l’un de ses services informatiques en deux grandes équipes fonctionnelles pour livrer le système côté serveur qui gérait ses clients, contrats, factures et services. L’une était spécialisée en Java et l’autre dans les procédures stockées PL/SQL. Elles dépendaient aussi de services centralisés à l’échelle de l’organisation pour l’exploitation informatique, l’administration des bases de données, l’infrastructure, le réseau, la sécurité et l’assurance qualité. Cela compliquait encore la livraison de leurs logiciels dans de bonnes conditions.

L’organisation rencontrait une autre difficulté. Ses équipes étaient distinctes, mais leur architecture ne séparait pas correctement la logique d’orchestration métier en Java de la logique d’accès aux données en PL/SQL. Elles livraient des centaines de fonctionnalités, chacune formant un enchevêtrement de code Java et PL/SQL. Chaque modification ou demande de fonctionnalité nécessitait donc des dizaines de transferts entre équipes, entraînant de longues files d’attente et de longs délais, même pour des changements mineurs. En outre, dans cet environnement complexe, les effets d’un changement même mineur étaient très difficiles à prévoir. Les équipes endommageaient régulièrement des fonctionnalités existantes en production et provoquaient des interruptions dont la résolution exigeait du temps, des reprises, des escalades et beaucoup d’efforts.

Pour sortir de ce mode de fonctionnement, les deux équipes fonctionnelles ont fusionné en une seule équipe produit. Elles ont progressivement repensé leur logiciel en transformant la couche d’accès aux données en un ensemble de fonctions d’API. Elles ont également créé un nouveau système métier complètement découplé du fonctionnement interne de cette API. Dès le début, l’initiative a amélioré le moral de l’équipe, puisque les spécialistes Java et PL/SQL travaillaient désormais à la réussite d’une équipe produit commune au-delà des intérêts de leurs anciens silos. Avec une architecture faiblement couplée, il est plus facile de cerner les effets des changements, de les mettre en œuvre rapidement et de localiser et corriger les défauts. Le délai moyen de livraison des nouvelles fonctionnalités est ainsi passé de quatre mois à trois semaines. La file d’incidents est aujourd’hui presque vide, ce qui donne à l’équipe du temps pour relire, refactoriser et améliorer son code source.

Organisations matricielles, équipes fonctionnelles et illusion de l’optimisation des coûts

Vos entreprises comptent des équipes fonctionnelles organisées par domaine de spécialité, par exemple les bases de données, les réseaux, l’exploitation, la sécurité de l’information, l’assurance qualité et la gestion des mises en production, des projets et des produits. Les équipes projet rassemblent des personnes issues de différents silos fonctionnels. Dans ces organisations matricielles qui cherchent à livrer des produits et services métier, le chef de projet est généralement responsable de livrer quelque chose, et le responsable produit de veiller à ce que l’on livre ce qu’il faut.

Dans cette configuration, les équipes fonctionnelles comprennent peu ou pas la portée du travail auquel elles contribuent. Dans des cas extrêmes mais fréquents, elles ne se préoccupent guère de la vue d’ensemble ni des résultats informatiques et métier du produit ou service. Elles cherchent surtout à se protéger si les projets tournent mal et que chacun rejette la faute sur les autres.

Comme vos équipes fonctionnelles doivent généralement traiter de longues files de tickets, les délais pour obtenir leur soutien sont souvent importants. Les projets se disputent les ressources fonctionnelles, si bien que les escalades sont le seul moyen d’obtenir rapidement de l’attention. Les escalades à répétition nuisent au climat de travail et à la confiance entre vos équipes.

Les transferts répétés entre équipes, les retards, les problèmes de qualité, les reprises, les goulets d’étranglement et le stress font désormais partie de votre quotidien. C’est le résultat d’une organisation matricielle qui continue de poursuivre une optimisation des coûts illusoire et opaque. En raison des problèmes de qualité, des reprises et des retards, les organisations fonctionnelles coûtent probablement plus cher que n’importe quelle autre réorganisation que vous puissiez imaginer. Si, de plus, votre organisation a externalisé certaines compétences fonctionnelles essentielles, comme l’assurance qualité ou l’exploitation informatique, vers des sites éloignés, votre service informatique peine sans doute à livrer en toute sécurité et à répondre aux demandes essentielles à la continuité de votre activité.

Comment le DevOps résout ce problème majeur avec des équipes orientées produits et services

Pour résoudre ce problème, le DevOps propose de passer de l’optimisation illusoire des coûts par équipes fonctionnelles à une optimisation éprouvée de la vitesse de livraison. Bien mis en œuvre, le DevOps vous permet aussi de réduire les coûts tout en livrant rapidement et en continu.

Le DevOps vous propose de créer des équipes orientées produits et services. Ces équipes indépendantes, pluridisciplinaires, autonomes et généralement petites couvrent toutes les phases du cycle de vie logiciel d’un produit et d’un service, au-delà d’un projet temporaire. Elles s’occupent de l’architecture, de la conception, du codage, des tests, de l’expérimentation, du déploiement, de l’exploitation et de la maintenance. Qui peut mieux exploiter et maintenir un logiciel que les personnes qui l’ont créé ? Il n’est donc pas surprenant que les équipes DevOps les plus performantes chez Amazon et Netflix continuent de s’occuper de leurs produits et services après leur mise à disposition. Elles exploitent et entretiennent aussi leurs logiciels dans leurs propres systèmes de production.

Votre organisation finance désormais des produits et des services

Pour améliorer ses résultats, votre organisation cesse de financer des projets temporaires dont les effets concrets sur l’activité sont difficiles à évaluer à long terme. Avec le DevOps, elle finance sa mission, sa raison d’être et les produits et services qui y sont associés. Vos équipes sont évaluées sur leurs résultats informatiques et métier, ainsi que sur le retour sur investissement dans les domaines où elles fournissent des produits, services et microservices à des clients internes ou externes. Elles assument désormais la responsabilité des produits et services qu’elles créent et fournissent, au lieu de travailler en silos fonctionnels avec peu d’attention aux résultats métier.

Comment constituer vos équipes DevOps et concevoir votre architecture logicielle ?

Le DevOps ne vous demande évidemment pas d’interrompre et de réorganiser tous vos projets en cours d’un seul coup. Intégrer des spécialistes fonctionnels aux équipes projet permet de les adapter au DevOps sans perturber leur travail, tout en obtenant des résultats. Une fois que les équipes disposent d’experts dans les domaines dont elles ont besoin, comme l’assurance qualité, la sécurité de l’information, les bases de données, les réseaux, les serveurs et l’exploitation, vous pouvez vous attendre à ce qu’elles conçoivent, déploient et entretiennent leurs produits et services logiciels en toute autonomie.

Dans ces nouvelles équipes DevOps orientées produits et services, la disponibilité, la qualité, les performances, la sécurité de l’information et la conformité font partie du travail quotidien de chacun. Comment créer des applications hautement disponibles, sécurisées et de qualité, capables de supporter la pression et la charge demandées par vos clients, si les équipes ne s’intéressent à ces exigences non fonctionnelles qu’après la conception et le développement ? Comment des experts externes pourraient-ils bien évaluer et valider la sécurité et la qualité de vos applications s’ils ne participent à aucune étape de l’ingénierie logicielle ? C’est pourquoi les équipes DevOps les plus performantes consultent des spécialistes externes, tout en restant entièrement responsables de toutes les exigences non fonctionnelles à chaque étape du cycle de vie logiciel.

Une autre approche est possible

Google est une organisation DevOps qui réussit particulièrement bien et fait encore largement appel à des équipes fonctionnelles aux côtés des équipes DevOps orientées produits et services. Chez Google, ces deux types d’équipes considèrent la mission de l’organisation, portée par ses produits et services, comme un objectif commun. Les équipes fonctionnelles élaborent des modèles réutilisables, comme des gabarits, des listes de contrôle et des squelettes d’applications, ainsi que des systèmes en libre-service, par exemple pour mettre à disposition et configurer des serveurs et des réseaux de façon autonome. Elles évitent ainsi de devenir des goulets d’étranglement. Elles collaborent avec les équipes produits et services dès le début du cycle de vie logiciel, examinent avec elles la conception, le code et les tests de façon constructive, et leur apportent des conseils en continu.

Quelle taille donner à votre équipe DevOps ?

Une équipe DevOps compte idéalement de cinq à dix personnes. Cette taille limitée réduit la complexité de la communication et de la coordination. Le responsable et les membres de l’équipe consacrent aussi moins de temps aux petites tâches et aux formalités. La taille des produits et services dont l’équipe a la charge reste ainsi limitée, ce qui réduit la complexité et les difficultés de maintenance et d’exploitation. Chaque membre dispose d’une vue d’ensemble et acquiert un peu d’expérience de direction en contribuant à une mission essentielle pour son organisation. Le responsable de l’équipe collabore avec la direction pour comprendre les objectifs et les transmettre à l’équipe.

Que faire si votre produit et votre service dépassent les capacités d’une équipe de dix personnes ?

Vous pouvez alors isoler un nouveau produit et service, puis former une autre équipe DevOps pour s’en charger. La notion de produit ou de service s’applique aussi à vos clients internes. Vous pouvez créer pour eux des produits ou services internes, notamment des « API de microservices », avec les équipes DevOps correspondantes. Si votre système de facturation devient trop important pour une équipe de dix personnes, vous pouvez confier l’API d’accès à la base de données à une autre équipe, puis éventuellement l’API de paiement en ligne et les traitements par lots à deux autres équipes. Toutes devraient utiliser un dépôt de code commun et un pipeline de déploiement partagé pour assurer l’intégration continue, la rapidité de livraison et la réussite de leur organisation.

Dans une architecture fortement couplée, de petits changements dans une application peuvent avoir de nombreux effets indésirables sur différents flux de travail. Les produits, services et API de microservices de votre architecture doivent donc être faiblement couplés. Chaque équipe DevOps doit être responsable d’une seule partie de cette architecture et pouvoir concevoir, développer et déployer ses logiciels de manière autonome. Un dispositif d’alerte précoce intégré au pipeline doit informer automatiquement et rapidement les équipes des effets indésirables que toute intégration de code pourrait provoquer.

Comment des équipes de dix personnes au maximum peuvent-elles couvrir seules toutes les phases du cycle de vie logiciel, de l’architecture à l’exploitation ?

Pour y parvenir, encouragez chaque membre de votre équipe à devenir généraliste et donnez à tous les moyens de développer en continu de nouvelles compétences.

Recrutez uniquement des personnes désireuses d’apprendre et de progresser, quel que soit leur niveau actuel de savoir-faire et d’expérience. Évitez impérativement les personnes qui s’attendent à être évaluées selon un ensemble fixe de rôles et de responsabilités. Votre organisation, vos produits et vos services sont appelés à évoluer.

La demande changera demain, si ce n’est aujourd’hui.

CONCLUSION

Dans ce chapitre, nous avons expliqué les résultats sous-optimaux des organisations matricielles, les silos fonctionnels qu’elles créent et la solution proposée par le DevOps.

Le DevOps vous invite à créer de petites équipes de dix personnes au maximum, orientées produits, services ou API de microservices.

Ces équipes DevOps devraient être composées d’ingénieurs logiciels généralistes qui maîtrisent l’ensemble de la pile et peuvent couvrir en toute autonomie toutes les phases du cycle de vie logiciel, de la conception à la maintenance.

Le DevOps s’appuie sur une architecture orientée services (SOA) à faible couplage dans laquelle chaque équipe est responsable d’une partie de l’architecture et en assure l’exploitation.