Lorsque nous parlons d'architecture de microservices, il y a sous nos yeux un ensemble de composants autonomes, presque indépendants les uns des autres. L'isolation est la pierre angulaire de tout système de microservices. Mais, même si nous sommes confiants dans notre capacité à créer des microservices, la question se pose - dans quelle mesure la structure organisationnelle est-elle prête pour une telle tâche? Sommes-nous en mesure de tirer parti des opportunités et des limites apportées par les microservices? Comment adapter les équipes pour travailler avec succès avec cette architecture? Dans cet article, nous allons essayer de discuter de l'aspect organisationnel du développement d'un système de microservices.
Approche traditionnelle
Les grandes sociétés commerciales ont toujours été organisées comme un ensemble d'unités fonctionnelles: financières, marketing, opérationnelles, RH, etc. Le besoin d'automatisation numérique des processus métier a incité l'entreprise à former une autre unité fonctionnelle - le service informatique. À son tour, le service informatique a ensuite été divisé en équipes fonctionnelles de programmeurs, testeurs, administrateurs système - par le principe de combiner des groupes de spécialistes avec un certain ensemble de connaissances et de fonctions. Le schéma de la pensée organisationnelle est vu très clairement. Et sa stabilité est associée non pas tant à la réticence à faire des efforts pour analyser l'efficacité de la gestion, mais à la grande inertie des processus et à l'absence de défis évidents qui mettraient en péril le succès de l'organisation.
Cependant, la séparation du personnel en fonction de ses fonctions crée inévitablement une distance entre les équipes. Lorsque les tests de logiciels sont effectués par une équipe distincte de testeurs, les développeurs se concentrent uniquement sur l'écriture de code et se soucient peu de sa testabilité. En conséquence, le produit logiciel présente de nombreux écarts de spécifications et, pire encore, les équipes se transforment progressivement en unités distinctes.
Remarque: Une mentalité de silo est une réticence à partager.
informations avec les employés d'autres unités de la même organisation. Ces
conduisent souvent à une diminution de l'efficacité organisationnelle et, au pire,
cas conduit à la destruction de la culture d'entreprise.De plus, dans les unités strictement fonctionnelles, le processus de décision ralentit inévitablement. Les coûts de coordination des horaires de travail des équipes augmentent. Les qualifications et l'expérience des mêmes testeurs, par exemple, nécessitent un équilibre constant en tenant compte des spécificités requises par les équipes de développement. Oui, et un seuil d'entrée élevé et le besoin de transfert de connaissances ralentissent le processus: les experts externes nécessitent une commutation constante du contexte de la tâche pour répondre aux demandes des différentes équipes.
Ainsi, lorsque les entreprises à structure organisationnelle traditionnelle étaient confrontées à la nécessité d'une réponse quasi instantanée aux défis émanant en permanence de l'entreprise, leurs services informatiques n'étaient pas en mesure d'assurer l'efficacité des solutions. L'évolution rapide de la technologie n'a fait qu'exacerber ce décalage et compliqué la tâche de maintenir le niveau requis de motivation et de professionnalisme au sein d'équipes dédiées au service du développement. Et comme l'objectif principal de l'informatique était et est d'assurer efficacement le cycle de vie complet des produits autonomes (y compris les microservices), la nécessité de réorganiser les équipes d'équipes fonctionnelles orientées horizontalement en équipes orientées verticalement, autonomes et autonomes est devenue évidente.
Commandes fonctionnelles croisées
Selon Wikipedia, une équipe interfonctionnelle est un groupe de personnes ayant diverses tâches fonctionnelles et travaillant vers un objectif commun. Dans les affaires d'aujourd'hui, l'innovation est un avantage concurrentiel de premier plan. Les équipes interfonctionnelles favorisent l'innovation grâce à une collaboration créative - à la fois au sein de l'équipe et avec d'autres équipes de l'organisation.
Figure 1. Équipes fonctionnelles et interfonctionnelles.L'équipe de développement de microservices interfonctionnelle est composée de développeurs, d'ingénieurs de bases de données, de testeurs, d'ingénieurs en infrastructure et d'autres spécialistes. Ces équipes apportent des modifications plus rapidement que celles fonctionnelles, car elles peuvent prendre leurs propres décisions et travailler indépendamment des autres équipes. En se concentrant sur l'amélioration du temps de cycle de développement et la mise en œuvre d'un déploiement continu, ces équipes sont capables de résoudre les problèmes presque instantanément.
Shamim Mohammad, directeur informatique de CarMax, déclare: «Dans un monde en évolution rapide, il est important de créer des équipes de produits flexibles et interfonctionnelles capables de trier rapidement les solutions à un problème. Ils sont dotés de tous les pouvoirs nécessaires et la direction ne leur dit jamais comment résoudre le problème, mais seulement en quoi il consiste et quels sont les principaux indicateurs de performance avec lesquels travailler. Cette approche vous permet d'améliorer les commentaires, d'accélérer considérablement le processus de développement, d'utiliser les essais et les erreurs pour finalement trouver la meilleure solution pour les clients et les partenaires. Nous avons également constaté que les équipes sont plus raisonnablement à risque et créatives dans la réalisation de leurs objectifs. Si vous ne disposez pas de telles équipes entièrement intégrées, jetez un œil et réfléchissez, êtes-vous prêt pour une transformation numérique réussie? "
Selon les enquêtes du Massachusetts Institute of Technology et de Deloitte Global Human Capital Trend, les entreprises avec un haut niveau de digitalisation des processus dans le développement de leurs innovations sont extrêmement dépendantes de la présence d'équipes interfonctionnelles. 83% des entreprises matures admettent utiliser des équipes interfonctionnelles. Malgré une complexité opérationnelle accrue (coûts supplémentaires jusqu'à 16%), les entreprises ont bénéficié d'une amélioration significative des indicateurs de fonctionnement (jusqu'à 53%), d'un meilleur accès aux ressources et aux actifs (jusqu'à 37%), d'une plus grande flexibilité (jusqu'à 12%) et d'une diminution du niveau de bureaucratie excessive en raison de la réduction de la hiérarchie de la structure organisationnelle (jusqu'à 11%).
Figure 2. Avantages de l'adaptation d'équipes interfonctionnelles. Statistiques.Une transition en douceur et progressive d'équipes fonctionnelles vers des équipes interfonctionnelles est tout à fait possible. Les premières équipes interfonctionnelles sont constituées autour des opportunités commerciales les plus précieuses qui nécessitent une attention constante et une réponse rapide de l'informatique. Les membres des équipes fonctionnelles évoluent en équipes interfonctionnelles, tout en approfondissant leur expérience et en améliorant généralement l'autonomie de l'équipe et le processus décisionnel. À un moment donné, les commandes fonctionnelles sont complètement transformées en un ensemble de commandes interfonctionnelles.
Figure 3. Transition vers une équipe interfonctionnelle.L'émergence d'équipes de plateforme
Cependant, la simple présence d'équipes interfonctionnelles ne signifie pas que nous avons fourni les meilleures conditions pour la création de microservices et que nous répondons le plus efficacement aux exigences de l'entreprise. Il existe encore un certain nombre de tâches liées au développement, au support et à la maintenance, dont les plus importantes sont:
- Synchronisation (cohérence) des données;
- Obsolescence des données
- La sécurité;
- Communication interservices;
- Découverte de service;
- Journalisation et surveillance distribuées;
- Dépendances cycliques entre les services et le débogage;
- Test;
- Fiabilité et tolérance aux pannes;
- Performance.
La plupart d'entre eux ne sont pas des tâches locales d'un microservice particulier. Telles sont les tâches du niveau système dans son ensemble et se rapportent davantage à l'infrastructure du système de microservices. De nombreuses organisations appellent cette infrastructure une «plate-forme», la base sur laquelle les microservices sont créés et développés.
En effet, avec la croissance de l'organisation, sa dépendance à l'égard des technologies utilisées augmente. De multiples zones d'incohérence surviennent de plus en plus souvent, ce qui conduit l'organisation à perdre sa capacité à progresser rapidement sur le marché, à évaluer les opportunités émergentes et à innover. Une issue possible à cette situation est la transition vers l’utilisation d’une «plate-forme numérique» constituée de «blocs d’opportunités» dans les domaines les plus importants de l’activité de l’organisation (comme l’infrastructure pour fournir des solutions ou interagir avec le client). Les plateformes numériques minimisent l'écart entre les concepts et les investissements; améliorer la stabilité du système et, plus important encore, améliorer le microclimat au sein de l'organisation.
De nombreuses organisations informatiques se demandent: combien de personnel doit être alloué pour travailler directement sur le «produit» et lequel travailler sur la «plate-forme»? L'un des arguments les plus importants en faveur d'une telle séparation du personnel est le suivant: une plate-forme numérique a besoin de propriétaires qui se consacrent à garantir le respect des principes déclarés par la plate-forme, ayant une vaste expérience et un haut niveau d'expertise dans le développement, la mise en œuvre et la maintenance de plates-formes.
Pour illustrer la nécessité de l'introduction des plateformes numériques en tant que produit autonome, nous nous tournons vers l'un des principes fondamentaux des microservices: l'utilisation de filtres intelligents et de canaux simples.
Quelle que soit la simplicité de la chaîne, elle nécessite toujours un propriétaire. Et s'il y a beaucoup d'équipes, dont chacune «possède son propre microservice», alors qui est responsable de leur interaction? Pour la découverte de services, pour la sécurité, la surveillance au niveau de l'ensemble du système (ou même au niveau de l'organisation, s'il s'agit du niveau intersystèmes)? Qui sera responsable des tests complets? Si nous commençons à attribuer ces responsabilités à des équipes de développement de microservices particulières, quels seront notre stratégie et nos critères de sélection? Et enfin, ces équipes (développement, je vous le rappelle) resteront-elles flexibles et autonomes dans leurs produits? Il semble que le moment soit venu où l'équipe de développement de la plateforme devrait apparaître sur scène!
L'équipe de développement de plate-forme (abrégée en équipe de plate-forme) est une équipe interfonctionnelle spécialisée qui gère la plate-forme numérique - la base de la formation d'API, d'outils et de services, dont la connaissance et le support sont organisés en un produit interne indépendant.
La stratégie de la plateforme numérique est axée sur la création de valeur commerciale. Pour éliminer les incohérences dans la construction d'un écosystème de microservices, la stratégie se concentre sur cinq domaines principaux de livraison de solutions technologiques:
- Infrastructure de livraison;
- Architecture et correctif API;
- Données en libre-service;
- Infrastructure expérimentale et télémétrie;
- Interaction avec le client.
Figure 4: Stratégie de plate-forme numériqueLes équipes de microservices autonomes ont la possibilité d'utiliser la plate-forme pour accélérer la prise en charge des fonctions de leurs produits et en même temps réduire le degré de coordination inter-équipes nécessaire.
Sans aucun doute, le concept d'équipes de plateformes spécialisées dédiées présente à la fois des avantages et des inconvénients:
Les avantages comprennent:
- unification et séquence des canaux de communication;
- assurer le contrôle tout en conservant la flexibilité des équipes de développement individuelles.
Les inconvénients comprennent:
- coûts de temps pour adapter la stratégie dans l'organisation;
- le besoin de ressources supplémentaires - l'équipe de la plateforme doit étudier les spécificités des différentes équipes de microservices, ainsi que les exigences de forme pour la création d'une plateforme unifiée;
- si la plateforme n'est pas implémentée correctement, elle deviendra un goulot d'étranglement dans les processus de l'organisation.
Ainsi, nous devons prendre en compte les éventuels problèmes et risques lors de la planification des activités d'équipe et inter-équipes au sein de l'organisation.
Synergie d'interaction
Alors, comment l'interaction avec l'équipe de la plateforme peut-elle se produire? Il existe plusieurs approches possibles, parmi lesquelles deux peuvent être distinguées:
- Utilisation de la plateforme comme produit. L'équipe de la plateforme met régulièrement à jour les versions de la plateforme et les fournit aux équipes de microservices en tant qu'API de produit. Il peut s'agir d'une image d'une machine virtuelle, ou d'un conteneur avec des capacités améliorées (par rapport à la version précédente), ou d'un framework extensible.
- Pénétration dans les équipes de microservices lorsqu'un représentant de l'équipe de plate-forme est présent dans l'équipe de microservices (ou l'un des membres de l'équipe de microservices est affecté à la communication avec l'équipe de plate-forme). Lorsqu'elles utilisent cette approche, les équipes de microservices ont la possibilité de réagir plus rapidement avec l'équipe de la plate-forme et peuvent initier le processus d'introduction de modifications sur la plate-forme.
Figure 5: Interaction avec l'équipe de développement de la plateforme: à gauche se trouve la plateforme en tant que produit, à droite la pénétration dans les équipes.Conclusion
En conclusion, je voudrais souligner une fois de plus que la structure organisationnelle doit permettre d'exploiter efficacement les avantages du choix architectural et technologique. La loi de Conway stipule qu’une organisation cherche à créer des projets qui sont des copies de la structure organisationnelle. Mais j'ai également tendance à croire que le contraire est vrai: la structure du système indique à l'organisation la structure qui convient le mieux à sa mise en œuvre.
Pour garantir la qualité nécessaire de réponse aux demandes des entreprises, l'industrie informatique moderne doit avoir le plus haut niveau de flexibilité organisationnelle. Et, pour ne pas perdre l'efficacité du système que nous nous efforçons de créer, nous devons considérer la nécessité et la possibilité de transformations organisationnelles.