L’architecture applicative composable, un parcours du combattant (Gartner)
Complexe, long et coûteux : Gartner prévient que les entreprises souhaitant tirer les bénéfices d’une architecture applicative composable à l’échelle de leur organisation devront payer un lourd tribut, d’autant plus si elles ne mettent pas en place les bonnes mesures.
En 2020, Gartner avait théorisé la notion d’entreprise composable, une stratégie d’entreprise qui mise sur la modularité de l’organisation pour gagner en agilité, en flexibilité et in fine s’adapter à toutes les situations.
Cette stratégie tient sur trois piliers que sont la pensée composable, l’architecture d’entreprise composable et les technologies composables.
Ce troisième pilier porte – a priori – à peu près toute technologie IT, à condition qu’elle réponde aux quatre critères suivants : il faut qu’elle puisse être orchestrée, modulaire, découvrable et autonome.
Les promesses d’agilité, d’innovation, de résilience, de prévention contre l’enfermement propriétaire sans forcément jeter tous les outils, les architectures, les infrastructures et les processus en place sont, forcément, séduisantes pour les entreprises.
Voilà pour la théorie. Jusqu’ici, Gartner n’avait pas réellement abordé les contreparties de ce modèle idyllique. Il peut maintenant le faire : certaines organisations ont tenté d’appliquer cette approche et lui ont fait ces retours.
Lors de l’IT Symposium 2022 de Barcelone, le cabinet d’analyse a évoqué la mise en place d’une stratégie d’architecture applicative composable. Une telle architecture est un exemple parfait de ce que Gartner entend par composabilité (ou modularité en bon français).
« Les fondations d’une architecture applicative composable sont des briques de construction modulaires. Ce sont essentiellement des actifs IT packagés qui peuvent être réutilisés afin de concevoir de nouveaux services et applications », explique Anne Thomas, vice-présidente et analyste distinguée chez Gartner.
« Ces briques modulaires et autonomes exposent leurs fonctionnalités à travers des API. Elles peuvent être assemblées, et augmentées en ajoutant du code », poursuit-elle.
Ces composants sont parfois spécifiques à une application ou ils sont totalement génériques. Ils peuvent être fraîchement déployés ou existants, résider dans le cloud ou sur site, être développés en interne ou à l’externe par un écosystème ou un fournisseur tiers.
« La majorité des actifs modulaires que vous possédez – environ 90 % d’entre eux – proviennent de votre organisation ».
Anne ThomasVP & Analyste, Gartner
« La majorité des actifs modulaires que vous possédez – environ 90 % d’entre eux – proviennent de votre organisation », précise Anne Thomas.
Une fois assemblés, ils doivent permettre de créer diverses « expériences », c’est-à-dire des applications ou des systèmes s’exécutant sur différents terminaux pour différents usages et différents protagonistes : métiers, développeurs, opérateurs IT, clients, fournisseurs, etc.
Dans une telle approche, la première difficulté est d’identifier ces composants. La définition qu’en donne l’analyste est très large. Si un bloc expose ses fonctionnalités par API, alors il peut s’agir d’un microservice, d’une application RH, d’une base de données, d’un ERP ou même un front-end monolithique. Pour un métier, il peut représenter la génération d’une facture, la validation d’un crédit, l’approbation d’une demande de congé, etc.
Un long travail d’identification des futures briques modulaires
Pour repérer les fonctions ou les briques à réutiliser, l’analyste recommande d’utiliser les méthodes et les outils de l’architecture d’affaires.
« Modèles de capacité d’entreprise, cartes du parcours de l’employé et du client, cartographie de la chaîne de valeur, modélisation des processus d’entreprise… Tous ces éléments permettent de comprendre où sont utilisées les différentes fonctionnalités logicielles et d’identifier les redondances », liste Anne Thomas.
Pour illustrer ses propos, l’analyste a évoqué le projet colossal de l’équipementier sportif Nike dont l’objectif est d’obtenir une architecture applicative composable transverse à son organisation.
En deux ans, Nike a identifié 85 plateformes logiques – et non des applications – qu’elle a catégorisées en trois grandes familles. Il y a les plateformes fondamentales, les plateformes « cœur » et les plateformes « expériences ».
Les plateformes fondamentales « fournissent des services et des données » aux deux autres plateformes : ce sont les ERP, les data warehouse, les outils d’automatisation type RPA, les outils de gouvernance, etc.
Les plateformes « cœur » supportent les processus métier les plus importants : ressources humaines, inventaires, tarification, gestion des taxes, ou encore de la logistique.
Les plateformes « expériences », chez Nike, ce sont les sites web, ses CRM, son moteur de recherche interne, les front-ends, etc.
« Nike a lancé un projet d’une durée de quatre ans. Quand ils ont commencé, ils avaient 2 700 systèmes et composants différents. Ils avaient beaucoup de disparité, de duplication, de silos et de composants fragiles. Tout cela coûtait très cher », relate Anne Thomas.
« Aujourd’hui, les métiers et les responsables technologiques sont alignés, ils ont rassemblé les fonctionnalités en 85 plateformes logiques, ils ont clairement établi les responsabilités de chacun et cela accélère l’engagement et l’accès aux plateformes par les parties prenantes », liste-t-elle.
Cependant, ces plateformes n’existent pour l’instant que sur le papier. « Nike n’a toujours pas extrait les composants [réutilisables] », note-t-elle. « C’est un objectif que l’entreprise espère atteindre dans un an et demi ».
Une fois cet inventaire effectué, une deuxième difficulté pointe rapidement le bout de son nez : l’interconnexion de ces systèmes.
Les API ne sont que trop rarement réutilisables
« Vous avez probablement déjà déployé des applications et des systèmes avec des API. Le problème, c’est que le réemploi est compliqué, cher à mettre en place et cher à maintenir », prévient d’emblée Anne Thomas.
Selon l’analyste, il est « pratiquement certain » que ces API ne sont pas réutilisables par défaut. Ces interfaces de programmation ne sont pas forcément adaptées, les flux de travail peuvent ne pas correspondre à un second usage, certaines données peuvent manquer. Pire, leurs sémantiques peuvent être incompatibles ou la gestion de version provoque la fin des échanges entre systèmes.
« J’ai discuté avec de nombreux clients souhaitant mettre en place une réutilisation massive de leurs systèmes. La grande majorité d’entre eux réutiliseront moins de 10 % de leurs API existantes », signale Anne Thomas.
« La grande majorité [des clients de Gartner] réutiliseront moins 10 % de leurs API existantes ».
Anne ThomasVP & Analyste, Gartner
« La plupart de vos API sont conçues pour s’exécuter dans un domaine applicatif et elles n’ont que peu de valeur une fois en dehors de ce domaine », estime-t-elle.
Une solution pourrait être de demander aux développeurs de concevoir des API réutilisables par défaut. « Ne faites pas ça », assène Anne Thomas.
L’analyste constate que la plupart des équipes de développement sont organisées pour livrer un produit aux fonctions bien précises. Faire en sorte que les API puissent être évolutives réclamerait un travail supplémentaire qui ralentirait la livraison des fonctionnalités souvent réclamées par des métiers pressés.
« Il y a un principe clé dans la programmation extrême [une méthode de développement agile, N.D.L.R] nommé YAGNI : You Aren’t Gonna Need IT (vous n’aurez pas besoin de ça, en VO). Et il s’applique aux API », affirme-t-elle.
« Quand vous développez des API pour supporter les besoins d’un système applicatif donné, concentrez-vous sur la livraison des fonctionnalités », recommande Anne Thomas. « Si vous percevez qu’une fonctionnalité pourrait être utile plus tard, ne la livrez pas dans le MVP, faites-le ultérieurement ».
En même temps, il faut éviter de modifier trop fréquemment les API : dans une architecture modulaire, plusieurs systèmes peuvent utiliser une même interface de programmation. Si celle-ci tombe, les applications qui en dépendent subiront le même sort.
La nécessité d’instaurer la conduite du changement
Plus généralement, elle considère que la modularité est complexe à livrer et à maintenir à large échelle. Il faut faire en sorte que les briques codées soient réellement indépendantes des unes des autres. Il faut déployer les plateformes, les outils pour créer ou sourcer les composants afin de les livrer, de les améliorer et de les maintenir dans le temps. « Vous devez gouverner les composants et leur partage », ajoute Anne Thomas. « Tout cela réclame de développer la culture du changement ».
L’analyste évoque la manie de certains développeurs qui déprécient le travail de leurs prédécesseurs et qui ont tendance à vouloir réécrire entièrement une fonctionnalité. Leur attitude s’apparente à celle du personnage de Léodagan dans la série TV Kaamelott (« tout cramer pour repartir sur des bases saines » est sûrement la réplique culte la plus réutilisée sur les Internet, justement).
« Il faut convaincre les gens qu’ils doivent d’abord vérifier si un composant existe déjà, s’il fonctionne pour leur besoin, puis les persuader de le réutiliser ».
Anne ThomasVP & Analyste, Gartner
« Il faut convaincre les gens qu’ils doivent d’abord vérifier si un composant existe déjà, s’il fonctionne pour leur besoin, puis les persuader de le réutiliser », indique l’analyste.
Ce changement culturel passe, selon Anne Thomas, par un dispositif transverse qui implique l’ensemble des parties prenantes dans l’entreprise, un soutien au plus haut niveau de l’organisation.
Nouveau programme, nouveau bureau, nouveaux rôles
Comme Rome ne s’est pas faite en un jour, selon Gartner, il faut mettre en place un bureau responsable du programme composable, à la manière d’un centre d’excellence cloud ou d’une équipe FinOps.
Une fois cela fait, « la première étape est d’établir un premier périmètre pour le programme ». Cela peut passer par un domaine spécifique de l’organisation, ou par le fait de se concentrer sur un ensemble de fonctionnalités fondamentales.
Le soutien du COMEX est nécessaire pour financer cette démarche coûteuse. Puis, il faut :
définir des règles et des processus consacrés à la réutilisation de composants ;
construire une feuille de route ;
mettre en service les briques essentielles ;
établir la liste des propriétaires des composants et la gestion du cycle de vie des composants partagés ;
et favoriser le changement de culture.
Autour de la table, il convient d’avoir :
des architectes d’entreprise qui priorisent les livrables modulaires ;
des ingénieurs qui les conçoivent et les construisent ;
des administrateurs qui gèrent une place de marché des briques documentées à disposition ;
des équipes fusionnées qui utilisent les briques à leur disposition pour concevoir des applications ;
et des métiers qui utilisent les applications selon un objectif commercial.
Et comme les fonctionnalités existantes ne sont pas réutilisables par défaut, cela réclame de commissionner une équipe transverse de développeurs ou une fusion team pour établir ce périmètre.
« Cette équipe doit travailler comme si elle développait un produit. Elle doit donc identifier ses clients et plusieurs cas d’usage qui justifient la réutilisation d’une brique », recommande Anne Thomas.
Gérer les interdépendances
Selon Anne Thomas, les entreprises qui souhaitent se lancer dans un tel projet ont besoin de nouveaux outils pour les nouveaux rôles afin de couvrir différents cas d’usage. Ainsi, les applications métiers peuvent être développées en low-code, tandis que les optimisations de tâches réclameront par exemple une solution iPaaS. L’automatisation peut passer par des bots RPA ou d’autres technologies.
Problème, il sera difficile d’obtenir un seul catalogue pour toutes les briques, des catalogues qu’il convient d’administrer. D’autant qu’une fois déployé, il est impératif de superviser les interdépendances entre les composants, les applications et les plateformes.
Bref, Gartner considère qu’avant même de déployer une architecture composable, il faut évaluer si le jeu en vaut la chandelle. Quitte à commencer par de petits bouts. Et en pensant d’abord au ROI, sans s’empêcher d’arrêter en cours de route si les premiers essais ne donnent rien. Et si cela fonctionne, l’agilité, la résilience et l’innovation promises devraient être au rendez-vous.
Pour approfondir sur Architectures logicielles et SOA
