Vélocité négative : comment relever la limite de complexité
L'un des objectifs les plus courants au sein des organisations d'ingénierie est de livrer rapidement des logiciels de haute qualité.
Il suffit d'observer l'énoncé de mission du CIO ou du CTO de votre entreprise. Il y a de fortes chances qu'il cherche à atteindre cet objectif. Cependant, même s'il s'agit d'un objectif commun, certaines entreprises arrivent à atteindre cet objectif quand d'autres sont bloquées dans le purgatoire de la livraison de logiciels. Certaines équipes mettent régulièrement du nouveau code en production avec peu d'incidents ou d'impact négatif sur les clients, tandis que d'autres connaissent des difficultés pour publier des versions trimestrielles.
Qu'est-ce qui provoque ces divergences de performances ?
La complexité de la livraison de logiciels fait la différence entre la livraison rapide de logiciels de haute qualité… ou tout le contraire. C'est la différence entre la danse de la joie hebdomadaire à chaque livraison réussie et une équipe de livraison de logiciels désengagée, frustrée par le fait que des mois de travail sur la dernière version se soldent par six nouveaux bugs et une restauration.
Comparez la vitesse et la qualité des livraisons de produits et de fonctionnalités des start-ups à celles d'une grande organisation établie. Par exemple, dans le secteur financier, les start-ups spécialistes des technologies financières ont réduit la part de marché des grandes banques traditionnelles au cours des dix dernières années. Les grandes banques invoquent souvent les avantages injustes des start-ups spécialistes des technologies financières. En effet, ces dernières opèrent dans un environnement soumis à une moindre surveillance réglementaire et n'ont aucun parc applicatif monolithique hérité à gérer. Des équipes plus petites sont synonymes d'agilité accrue. De plus, elles peuvent évoluer en fonction des besoins des clients. Fondamentalement, les entreprises spécialistes des technologies financières ne sont pas aussi complexes que les banques traditionnelles. Elles peuvent ainsi agir plus rapidement et avec moins de risques. Bien qu'elle puisse ralentir les équipes de développement, la complexité n'est pas toujours mauvaise.
The benefits of SOA
SOA's modularity and standardized protocols enable services to communicate effectively, promoting reusability, interoperability, and scalability. These key benefits translate into tangible advantages for companies:
- Reusability: Reusing existing services reduces development time and costs and promotes consistency and quality. Companies can accelerate development cycles and improve overall efficiency.
- Interoperability: Services can communicate and exchange data regardless of their underlying technology or programming language. This facilitates enterprise-wide data integration and collaboration. Interoperability streamlines business processes and helps companies adapt to evolving technologies.
-
Scalability: SOA's modular design enables independent scaling of services to meet fluctuating demands. It ensures applications can handle spikes in traffic or expanding user bases without compromising performance or stability. Companies can adapt their infrastructure to changing needs without costly rewrites or redesigns.
Ressource connexe
Contrôlez la multiplication des logiciels
DÉCOUVRIR LA SOLUTION
Gérez vos composants grâce à Compass
Complexité dans le domaine de la livraison de logiciels
La complexité peut être une bonne chose : la résolution de problèmes complexes est très gratifiante. Cela motive les équipes à relever le défi, à résoudre des problèmes complexes et à chambouler un secteur. À l'inverse, il y a un moment où la complexité ne permet plus de résoudre un problème difficile et a des répercussions négatives sur les équipes de développement.
La complexité organisationnelle joue un rôle clé dans la réduction de l'efficacité des équipes de développement. Le dictionnaire Collins définit la complexité comme « le fait d'avoir de nombreuses parties différentes connectées ou reliées les unes aux autres de manière compliquée ». Concrètement, la complexité organisationnelle est l'ensemble des informations, des dépendances, des changements, des autres équipes, des outils et des demandes, que les équipes de développement doivent gérer lorsqu'elles interagissent avec le reste de l'organisation.
Plus la complexité organisationnelle est élevée, plus il est difficile de livrer rapidement des logiciels de haute qualité, car les équipes passent plus de temps à naviguer dans l'organisation qu'à résoudre des problèmes complexes. Les organisations en plein essor se rendent rapidement compte que les équipes de développement atteignent une limite de complexité. Cette limite correspond au niveau de complexité que les équipes peuvent gérer avant que cela n'ait un impact sur la satisfaction professionnelle et sur la qualité et la vitesse de développement des logiciels. Il peut donc sembler logique que la réduction de la complexité organisationnelle permette aux équipes de se concentrer sur la résolution des problèmes complexes, en livrant des logiciels plus rapidement et de façon plus qualitative. Voyons pourquoi ce n'est pas nécessairement le cas.
Benefits of microservices
Compte tenu des avantages, une plus grande partie de l'organisation a commencé à adopter une architecture de microservices, ce qui a naturellement commencé à accroître la complexité organisationnelle. Des équipes plus autonomes nécessitaient une collaboration accrue, et l'augmentation des microservices impliquait davantage de dépendances. Le rythme des changements a décollé, signe d'une multiplication des logiciels. La complexité croissante a nui à l'efficacité de l'équipe de développement. En témoigne une baisse de la vélocité de changement. De plus, la charge cognitive est devenue un problème pour les équipes de développement.
Comment savoir si vous approchez de la limite de complexité ?
Atteindre la limite de complexité peut sembler inévitable, mais certains signes indiquent que les équipes s'en approchent. Tout d'abord, il convient de préciser qu'il n'y a aucune métrique absolue permettant de savoir à quel point vous êtes proche de la limite de complexité, mais les indicateurs suivants peuvent vous donner une idée.
L'indicateur le plus clair qu'une équipe a atteint la limite de complexité ? Elle passe plus de temps à gérer la complexité organisationnelle qu'à résoudre les problèmes complexes sur lesquels elle devrait se concentrer. L'analyse des métriques DORA du délai d'exécution des changements (vitesse) et du taux d'échec des changements (qualité) montre si les équipes ralentissent ou accélèrent au fil du temps. Même si d'autres facteurs influencent ces métriques, elles constituent un bon indicateur de l'efficacité de l'équipe.
La satisfaction des développeurs est un autre indicateur de la complexité organisationnelle à laquelle les équipes de développement sont confrontées. Plus que tout autre profil, les personnes qui occupent des rôles de développeurs aiment passer leur temps à résoudre des problèmes complexes, et détestent les tâches inutiles qui se présentent. Le faible niveau de satisfaction des développeurs indique clairement que la complexité organisationnelle pose problème à votre équipe de développement.
| Feature | SOA | Microservices |
| Architectural style |
|
|
| Service granularity |
|
|
| Independence |
|
|
| Communication |
|
|
| Data storage |
|
|
| Scalability |
|
|
| Deployment |
|
|
| Coupling |
|
|
Comment savoir si vous approchez de la limite de complexité ?
Atteindre la limite de complexité peut sembler inévitable, mais certains signes indiquent que les équipes s'en approchent. Tout d'abord, il convient de préciser qu'il n'y a aucune métrique absolue permettant de savoir à quel point vous êtes proche de la limite de complexité, mais les indicateurs suivants peuvent vous donner une idée.
L'indicateur le plus clair qu'une équipe a atteint la limite de complexité ? Elle passe plus de temps à gérer la complexité organisationnelle qu'à résoudre les problèmes complexes sur lesquels elle devrait se concentrer. L'analyse des métriques DORA du délai d'exécution des changements (vitesse) et du taux d'échec des changements (qualité) montre si les équipes ralentissent ou accélèrent au fil du temps. Même si d'autres facteurs influencent ces métriques, elles constituent un bon indicateur de l'efficacité de l'équipe.
La satisfaction des développeurs est un autre indicateur de la complexité organisationnelle à laquelle les équipes de développement sont confrontées. Plus que tout autre profil, les personnes qui occupent des rôles de développeurs aiment passer leur temps à résoudre des problèmes complexes, et détestent les tâches inutiles qui se présentent. Le faible niveau de satisfaction des développeurs indique clairement que la complexité organisationnelle pose problème à votre équipe de développement.
La simplification n'est pas la solution
Lorsque les entreprises se rendent compte que leurs équipes sont submergées par la complexité, elles lancent souvent un « projet de simplification » visant à rétablir la simplicité au sein de leur organisation. La simplification est une stratégie perdante pour deux raisons. Tout d'abord, la complexité augmente plus vite qu'une organisation ne peut simplifier son environnement. Ensuite, ces « projets de simplification » opèrent au sein même de l'environnement complexe qu'ils visent à simplifier.
Un point de départ commun pour la simplification consiste à réduire le nombre d'applications en les désactivant ou en les consolidant dans la mesure du possible. La désactivation d'une application exige que l'équipe comprenne toutes les dépendances en amont et en aval, qui utilise l'application, comment remplacer la fonctionnalité, où et comment les données seront archivées ou migrées. Elle doit également s'occuper de toutes les autres complications engendrées par ce type de tâche. Malheureusement, la réduction de la complexité n'est pas proportionnelle à l'investissement considérable en efforts nécessaires pour y parvenir. Il y a une limite à la quantité d'applications qu'une entreprise peut désactiver sans affecter l'activité principale ou l'expérience utilisateur, mais il n'y a pas de limite au nombre de nouveaux composants logiciels que les ingénieurs peuvent créer. Au cours des 12 mois nécessaires à la désactivation d'une application, il est probable que des centaines de nouveaux microservices aient été créés. Étant donné qu'un environnement technologique sain se développe au fil du temps, limiter l'environnement à un nombre fixe d'applications ou de composants logiciels pour réduire la complexité n'est pas pratique.
Les projets de simplification comprennent généralement le remaniement de la structure organisationnelle afin de simplifier le flux de communication. Les structures organisationnelles les moins compliquées impliquent de grandes équipes hiérarchiques où tout le personnel se trouve dans les mêmes locaux. Les structures organisationnelles les plus complexes impliquent de petites équipes distribuées et autonomes. La loi de Conway nous montre que les grandes équipes hiérarchiques sont susceptibles de créer des applications monolithiques, tandis que les petites équipes distribuées sont susceptibles de produire des applications à l'aide d'architectures modulaires, comme des microservices. La production rapide de logiciels de haute qualité est rendue possible par des modèles d'architecture modulaire tels qu'une architecture de microservices. Cela signifie qu'une structure organisationnelle plus complexe est plus susceptible de garantir la réussite. Même si la « simplification » de la structure organisationnelle simplifie la compréhension, elle va à l'encontre de l'objectif ultime du projet de simplification.
La simplification est importante et utile, mais il est préférable de l'intégrer en tant qu'amélioration continue pour les équipes de développement (et les équipes faites d'équipes) plutôt que comme une activité ponctuelle. La simplification peut retarder l'atteinte de la limite de complexité, mais ne redonnera pas à une organisation les libertés rythmées d'un environnement de start-up.
Relever la limite de complexité
What are the challenges of adopting SOA and microservices?
Pour retrouver l'efficacité de l'équipe de développement, les entreprises doivent relever la limite de complexité. Cette action implique essentiellement d'augmenter le degré de complexité organisationnelle que chaque équipe peut gérer avant que cela n'ait un impact sur la satisfaction au travail, ainsi que sur la qualité et la vitesse avec lesquelles l'équipe livre des logiciels.
L'ingénierie de plateforme est un concept important qui vise à relever la limite de complexité au sein d'une organisation. Des équipes d'ingénierie de plateforme solides se concentrent sur la réduction de la charge cognitive des équipes de développement, en faisant abstraction de la complexité de l'organisation dans leur travail quotidien. Lorsqu'elle est correctement implémentée, ce type d'ingénierie permet aux équipes de rééquilibrer l'essentiel de leurs efforts en faveur de la résolution des problèmes les plus complexes, tout en consacrant moins de temps à la complexité organisationnelle.
Can SOA and microservices coexist?
C'est pourquoi Atlassian a créé Compass, une plateforme dédiée à l'expérience des développeurs. Compass contribue à relever la limite de complexité en permettant aux équipes de développement de parcourir facilement la complexité organisationnelle grâce au catalogue de composants, aux métriques et aux cartes de performances, et de se concentrer sur la création d'une culture d'ingénierie saine. Ici, le point à retenir est que la complexité organisationnelle n'a pas diminué au sein d'Atlassian. En réalité, elle a continué à croître à mesure qu'une part de plus en plus importante de l'organisation migrait vers une architecture de microservices. Nous avons réduit le temps passé par les équipes de développement à gérer cette complexité. C'est ce qui fait la différence entre un projet de simplification et le fait de relever la limite de complexité.
Atlassian compte plus de 10 000 employés et plus de 17 000 composants logiciels. Pourtant, nos équipes de développement fonctionnent en grande partie avec une liberté digne de celle d'une start-up, en livrant des logiciels de haute qualité. La clé de notre réussite ? Relever la limite de complexité pour améliorer l'efficacité de l'équipe de développement.
Voici deux actions pour commencer à relever votre limite de complexité :
- Suivre et évaluer vos métriques DORA. Comment se portent les métriques DORA pour votre équipe ? Si vous ne les suivez pas déjà, les métriques DORA sont intégrées de série à Compass.
- Comprendre et évaluer la satisfaction des développeurs. Comment se sentent les développeurs au sein de vos équipes de développement ? La plupart des organisations mènent des enquêtes de satisfaction auprès de leurs employés. Demandez les résultats, répartis par domaine fonctionnel, pour obtenir des informations sur la satisfaction des développeurs. Les questions clés comprennent l'évaluation des affirmations suivantes :
- Je suis fier de mes livraisons
- Le niveau de stress lié à mon travail est gérable
- Je comprends en quoi mon travail contribue aux objectifs de l'entreprise
Par ailleurs, Compass recueille ces informations lors du rituel CheckOps, au cours duquel les équipes partagent leurs impressions sur la semaine écoulée, ainsi que des informations sur ce qui aurait pu être amélioré.
Pour relever la limite de complexité, il faut combiner des outils, des processus et des rituels. Une plateforme dédiée à l'expérience des développeurs telle que Compass peut vous aider à comprendre l'intégrité du système, à cartographier les dépendances et à créer des rituels continus. Cela contribue à relever la limite de complexité et à libérer le potentiel des équipes de livraison de logiciels au sein de votre organisation.
Essayez Compass gratuitement sans plus attendre.
How does each architecture impact deployment and DevOps practices?
Both SOA and microservices deployments benefit from Open DevOps practices. However, the specifics will differ depending on the architecture.
SOA typically involves monolithic deployments, where teams deploy an entire application as a single unit. This approach requires careful coordination between teams. It can be time-consuming and complex, especially for large applications.
DevOps emphasizes collaboration and automation between development and operations teams to address these challenges. This enables more frequent and reliable deployments. By automating testing, configuration management, and infrastructure provisioning, DevOps can help streamline SOA deployments and minimize errors.
Microservices architecture enables more granular deployments. Teams deploy each microservice independently.
DevOps principles are also essential for microservices deployments. DevOps practices such as continuous integration and continuous delivery allow teams to automate the process of testing, deploying, and building microservices. This facilitates rapid and frequent releases.
Partager cet article
Thème suivant
Lectures recommandées
Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.
Communauté Compass
Tutoriel : Créer un composant
