La mise en place d’une nouvelle pratique autour d’une plateforme et/ou d’une technologie suit un schéma relativement classique. La mise à l’échelle de cette pratique est un exercice qui peut s’avérer difficile si l’on n’a pas les bonnes clés : comment accompagner sereinement la croissance de l’entreprise et la généralisation de cette pratique à travers toutes les équipes qui en ont besoin? Comment éviter que l’équipe devienne un goulot d’étranglement pour ses clients internes ?
Toutes ces questions sont particulièrement pertinentes dans le cadre d’une pratique d’Intégration. Je vous propose ci-dessous quelques axes de réflexion, issus largement de mon expérience sur le terrain.
Dans une perspective de déploiement à l’échelle de l’entreprise, il peut être efficace de « casser » une équipe centralisée en :
Et d’accompagner les équipes orientées métier dans leur appropriation de la plateforme et de la pratique plutôt que d’implémenter des flux à leur place.
Passons l’éventuelle phase de benchmarking des plateformes d’intégration qui est hors sujet et concentrons-nous plutôt sur la phase de mise en œuvre.
L’approche classique est le démarrage d’un projet phare « sponsor » (ex : mise en place d’un ERP ou d’un CRM), qui est l’occasion de mettre en place une nouvelle plateforme d’intégration. Ce projet est bien souvent adossé à – ou s’inscrit dans – une stratégie plus vaste de digitalisation ou de modernisation du SI : peu importe, le point à retenir est cette notion de sponsoring au moins partiel par un projet métier (on verra par la suite pourquoi c’est important).
Cette phase se déroule généralement bien et tout le monde est content (enfin sauf gros couac bien sûr…). A l’issue de cette phase, on obtient :
A partir de là, on constate souvent l’organisation suivante :
Tout se passe bien pendant un certain temps (qui peut être relativement long), en fait tant que la plateforme reste à peu près dédiée à quelques contextes bien délimités et que l’alignement en termes d’objectifs et d’organisation entre les équipes métiers concernées et l’équipe en charge de l’Intégration est fort.
Néanmoins, avec la généralisation de l’usage de la plateforme à une plus grande partie de l’entreprise, cette équipe centrale va devoir adresser les besoins de plus en plus de clients internes. La relation de partenariat qui pouvait exister auparavant n’est mécaniquement plus possible à cette échelle et s’instaure alors une relation plus classique de client à fournisseur.
Avec le temps, plusieurs des symptômes ci-dessous risquent d’apparaitre.
La forte isolation du traitement des problématiques d’Intégration dans une seule et même équipe centralisée peut à la longue induire une confusion dans le découpage des responsabilités.
Des affirmations telles que les suivantes en sont symptomatiques :
En effet dire que « c’est de l’Intégration » est certes littéralement juste mais réducteur et simpliste : cette affirmation omet le vrai sujet du RACI.
Prenons l’exemple d’une API consommée par la couche d’Intégration. Cette « API », ou plus généralement un endpoint (quelle que soit sa forme) exposé par un système est une porte ouverte sur ledit système. Son utilisation/consommation peut avoir un impact sur son état interne, et cet état interne ne peut pas relever de la responsabilité de l’Intégration. D’autre part l’éventuel besoin d’orchestration des opérations de cette API revêt lui-même une dimension fonctionnelle, dont la connaissance est liée au domaine métier. Cette connaissance et maîtrise du domaine métier revient naturellement à l’équipe cliente métier en charge du système, pas à l’Intégration.
C’est en revanche bien la responsabilité de l’équipe Intégration de savoir mettre en œuvre au mieux la plateforme pour consommer ces endpoints quels qu’ils soient : on se retrouve donc avec une véritable dichotomie entre la maitrise de la dimension fonctionnelle et celle de la dimension technique.
Par extension, le même flou peut s’installer concernant la logique même d’un flux, c’est-à-dire la nature et le séquencement des traitements qui sont appliqués.
L’équipe Intégration ayant réalisé le flux (et souvent en assurant la maintenance et le support), cette confusion est tout à fait compréhensible. Elle peut même être accentuée par le fait qu’en toute logique, la documentation technique de ce flux sera intégrée à un espace documentaire centralisé, sous la responsabilité de l’équipe Intégration.
Malheureusement, cette responsabilité perçue ne s’accompagne pas toujours de l’autorité qui devrait en découler. En effet, le vrai problème de fond de découpage des responsabilités émerge lorsque un besoin d’évolution est motivé par un changement dans la Pratique (ex : changement d’une norme de sécurité) ou la Plateforme (ex : migration de namespace Azure Service Bus). Bien souvent, l’évolution requise fait l’objet de tractations acharnées avec le vrai owner, aussi bien pour son financement que pour sa planification.
Le même constat peut s’appliquer par exemple lorsque la conception fonctionnelle du flux n’a pas pris en compte certains cas non nominaux et que le flux en question génère en conséquence des erreurs « normales ». Le traitement de ces cas nécessite généralement une évolution – qui ne se limite pas forcément à la couche d’intégration. Dans ce cas, l’équipe responsable du support et de la maintenance du flux (aka : l’équipe centralisée d’Intégration) est celle qui a le plus intérêt à ce que l’évolution soit faite, mais c’est rarement elle qui a l’autorité ni les moyens pour la faire.
Il y a donc une vraie dichotomie entre responsabilité des flux et autorité pour les faire évoluer.
Du fait de la nouvelle relation de client à fournisseur avec un nombre croissant de clients, les organisations des équipes se désolidarisent et l’alignement n’est plus aussi parfait entre chaque client interne et l’équipe Intégration. Dans le même temps, une dépendance forte s’est installée vis-à-vis de l’équipe Intégration, seule à même de mettre en œuvre la plateforme pour réaliser les flux.
Les équipes de part et d’autre de la relation de dépendance attendent souvent des livrables, des confirmations ou approbations ou tout simplement des informations de l’autre équipe. La coordination inter-équipe nécessite une communication intensive, induisant des blocages fréquents, des délais prolongés et ralentissant ainsi le rythme du projet.
Cette situation crée également une surcharge de travail en particulier pour l’équipe centralisée d’Intégration, qui doit gérer des demandes constantes, avec des plannings souvent subis, tout en accomplissant ses propres tâches. Cela se traduit par une complexité accrue dans la planification et la priorisation, et une difficulté à maintenir l’autonomie et la réactivité des équipes.
Dès lors le sentiment de ne pas faire partie du même bateau se répand, et des crispations peuvent se faire sentir. L’organisation en place est vécue comme un frein (et dans les cas extrêmes comme un obstacle).
Quelle que soit la quantité et la profondeur des « services » effectivement mis en place sur la plateforme d’intégration dans la phase initiale, le risque est :
De plus, un autre symptôme à surveiller est la nécessité d’arbitrage entre d’un côté le delivery des projets et de l’autre l’évolution de la plateforme. Le fait qu’un arbitrage soit nécessaire est déjà un signal : faible certes, mais à ne pas négliger. Le fait que cet arbitrage soit généralement fait en faveur du delivery (outre urgence et cas de force majeure) est, lui, un signal fort.
Résumons les symptômes décrits précédemment :
Notons ici que ces symptômes ne sont aucunement la manifestation de mauvaises volontés, mais simplement d’une incohérence entre l’organisation d’une part et les chemins de communication effectifs dans l’entreprise d’autre part : on peut considérer que l’organisation mise en place ne respecte pas (ou plus) la loi de Conway.
Par conséquent plus vous constaterez de ces symptômes, plus un réalignement de l’organisation aura du sens. Cela signifie que cette organisation mise en place (reposant sur une équipe centralisée qui se retrouve sur le chemin critique de tous les projets) est devenue un obstacle et qu’il devient nécessaire de la changer.
En complément, 2 questions à garder en tête simultanément :
Cette plus-value essentielle réside avant tout dans la qualité de la pratique et de la plateforme, et le développement du business (ou en tout cas la fluidification des projets) passe par l’autonomisation des clients internes dans le delivery de leurs flux.
Concrètement, et si l’on reprend la terminologie des Team Topologies de Matthew Skelton et Manuel Pais, le principe de cette évolution d’organisation doit donc être de clairement séparer les 3 aspects fondamentaux suivants :
Depuis le début de cet article, je parle de plateforme sans en donner une définition claire.
Fondamentalement, une plateforme est un socle offrant une couche d’abstraction masquant les détails techniques complexes aux utilisateurs et développeurs. Cette couche d’abstraction leur permet de se concentrer sur leurs objectifs métier plutôt que sur des détails d’implémentation. Idéalement, ces abstractions sont en self-service pour éviter qu’à nouveau une équipe (l’équipe plateforme) soient sur le chemin critique des projets.
Autrement dit, c’est un ensemble d’abstractions efficaces permettant de :
Par exemple en tant que développeur Azure, je ne veux surtout pas avoir besoin de savoir ce qui se passe derrière le rideau (= de l’autre côté de l’API / l’UI) lorsque je provisionne un service quel qu’il soit. La plateforme Azure est conçue pour réduire ma charge mentale : je me contente de consommer son API, je suis déchargé de savoir ce qui se passe au niveau infra dans les data centers de Microsoft pour effectivement provisionner ce service. De plus, je peux provisionner ces services en totale autonomie, sans avoir besoin de dépendre des équipes produits de Microsoft (qui sont ni plus ni moins des équipes de plateforme).
NOTE 1 : une plateforme peut bien évidemment être elle-même construite par-dessus une ou plusieurs autres plateformes. Par exemple : une plateforme d’intégration peut être construite au dessus des services Azure Integration Services, qui constituent eux-mêmes une plateforme.
NOTE 2 : il ne s’agit pas ici de décrire en détail ce que peut être une plateforme d’intégration ni comment on la construit. C’est un vaste sujet qui mérite un article dédié.
Comme pour la plateforme, il convient de définir plus clairement ce que signifie le terme « Pratique » : il s’agit de l’ensemble des méthodes, processus et normes adoptés pour utiliser efficacement une technologie (le caractère efficace étant à rapporter à la vision de l’entreprise).
Les équipes orientées métier étant focalisées sur la réponse aux besoins du métier, elles ont peu de temps à accorder aux recherches et à l’expérimentation nécessaires à l’acquisition, la construction et l’évolution d’une pratique. C’est pourquoi celle-ci doit être sous la responsabilité d’une équipe, dont la responsabilité est double :
C’est le rôle d’Enablement évoqué plus haut. Si ce rôle est bien rempli, alors les équipes orientées métier n’auront besoin de l’accompagnement par l’équipe d’Enablement que pendant une durée limitée, puis uniquement ponctuellement.
A ce rôle va s’ajouter une forme d’autorité comme on le verra plus loin : c’est ce que dans la littérature on appelle souvent le Center for Excellence.
ATTENTION : le rôle de cette équipe est bien d’accompagner les équipes orientées métier, pas de faire à leur place ! Son rôle n’est pas non plus d’être un inspecteur des travaux finis : elle peut (et doit) contrôler que les éléments de pratiques sont respectés, mais en accompagnant de manière proactive. Tout éventuel point de contrôle en bout de processus de build ne peut être qu’un garde-fou, mais l’essentiel de la plus-value de cette équipe réside dans l’accompagnement en amont.
La Pratique pose des standards garantissant une certaine qualité, tandis que la Plateforme en améliore l’accessibilité en en abaissant/masquant la complexité. Elle permet donc de builder rapidement et relativement simplement avec un haut niveau de qualité.
Les deux sont complémentaires mais distinctes, reprenant l’opposition entre Shift left (la Pratique) et Shift down (la Plateforme) décrit par Richard Seroter.
Les 2 équipes travaillent souvent en étroite collaboration, mais leurs missions sont bien différentes. Comme décrit plus haut, le risque de mélanger des missions différentes est que l’une des missions prenne le pas sur l’autre du fait de contraintes comme des impératifs de délai sur des projets. C’est pourquoi il est nécessaire de bien cloisonner leurs champs d’action respectif, et de les sanctuariser.
Nous l’avons vu plus haut : les premières itérations de la plateforme sont souvent financées par des projets sponsors. Malheureusement si ce « sponsoring » devient le seul moyen de financement des activités de construction et de maintenance de la plateforme :
NOTE : Comme le souligne Martin Fowler :
« Any code that has not been deployed to production is an unfinished work. Once deployed to production it becomes legacy code.”
Ce qui s’applique évidemment aux éléments de la plateforme. Il est donc obligatoire d’en prévoir l’évolution constante.
Les mêmes schémas se produisent sur les activités liées à l’Enablement des équipes. Notamment, la tentation peut être grande de considérer que :
L’équipe de plateforme doit bien évidemment avoir toute autorité sur la plateforme elle-même, tout en fournissant en contrepartie des engagements ou promesses claires à ses clients (par ex : « aucune fonctionnalité ne sera dépréciée sans un avis 12 mois à l’avance »).
Il en va de même avec l’équipe d’Enablement qui est dépositaire de la pratique. Son rôle est avant tout basé sur l’encouragement et l’éducation plutôt que la contrainte et elle est à l’écoute des équipes qu’elle accompagne pour faire évoluer si besoin des éléments de la pratique. Néanmoins, elle doit également pouvoir garantir que certains points de gouvernance et certains standards sont bien respectés à travers l’entreprise : son autorité sur ses points doit être clairement affirmée.
Bien évidemment que non. Ou plus exactement, elle présuppose plusieurs choses pour être réellement efficace :
Pour résumer, on peut dire que tout le but du jeu est de faire tout ce qu’il faut pour que le volume d’interactions nécessaires entre équipes soit le plus réduit possible.
Pour aller plus loin : est-on condamné à suivre ce schéma d’évolution ?
Comme bien souvent dans ces sujets qui couvrent aussi bien l’organisation que la technique, la manière dont la question est posée et les hypothèses implicites sous-jacentes sont presque plus importantes que la réponse.
Une meilleure question serait de savoir ce que ça implique de refuser ce schéma d’évolution dans un contexte de croissance (au sens : élargissement de l’usage de la pratique).
ATTENTION : Il faut prendre l’ensemble du contexte pour faire un choix de topologie d’équipes avisé. Néanmoins dans une logique de développement de la pratique, opérer les changements d’organisation qui permettent de soutenir les orientations stratégiques de l’architecture de l’entreprise va bien souvent s’avérer nécessaire.
Et puisque c’est dans l’air du temps, un petit mot complémentaire sur l’émergence des outils basés sur les intelligences artificielles génératives. Ces outils ont certes le potentiel de changer la donne (au moins partiellement). Par exemple, il est possible qu’un tel outil permette de réduire significativement la charge cognitive évoquée plus haut, moyennant un travail de documentation et d’indexation. Néanmoins, de tels outils ne sont pas arrivés à maturité et le recul est aujourd’hui trop faible pour en mesurer l’impact. Attendons de voir ce que donnerons des outils tels que Devin ou Copilot Workspace dans un environnement réel et à grande échelle avant d’enterrer les conclusions ci-dessus 🙂
À la lecture de cet article, il est probable que certain(e)s y trouvent des ressemblances avec leurs propres expériences dans d’autres pratiques techniques.
En effet, de nombreuses considérations abordées ici ne sont pas spécifiques à l’intégration, mais relèvent de principes universels applicables à divers domaines de l’ingénierie et du développement logiciel.
Même mal, même remède ? 🙂
