Plusieurs experts et acteurs du secteur partagent leurs conseils sur la manière de développer une architecture logicielle composable, capable de rapidement s’adapter à l’évolution du marché.
Il y a une dizaine d’années, le PDG de Red Hat, Jim Whitehurst (aujourd’hui président d’IBM) utilisait le terme « composabilité » comme accroche lors de son discours d’ouverture. « Je veux vous parler de l’ère de la technologie composable et de la façon dont vous, développeurs, allez tous contribuer à la construire », déclarait Jim Whitehurst.
Développer des logiciels de manière composable, à l’aide de portions de code, semble bien plus flexible et facile que de créer des applications sous forme de blocs verticaux monolithiques intégrés.
« Si vous êtes en mesure d’écrire du code dans de petites sections qui peuvent être testées et déployées indépendamment, vous simplifiez l’intégration des nouveaux composants de l’application et réalisez ces mises à jour beaucoup plus rapidement. Vous prendrez une véritable longueur d’avance sur vos concurrents », explique Antony Bourne, vice-président senior chez IFS.
En pratique, cela signifie qu’il est bien plus facile d’exploiter des technologies, comme l’automatisation robotisée des processus (RPA), l’intelligence artificielle ou la kyrielle de fonctionnalités d’hyperautomatisation disponibles aujourd’hui, pour schématiser les workflows et optimiser les processus métier.
Ariel Assaraf, PDG de Coralogix, plateforme d’analyse en streaming stateful, estime que la pensée composable est le premier élément constitutif d’une entreprise composable. « Notre façon de penser influence toutes nos actions. Elle nous guide pour savoir quoi composer, à quel moment et comment ? » dit-il. « Avec un état d’esprit dédié à la composabilité, nous pouvons commencer à mettre en place ce concept dans toute l’entreprise, plus particulièrement, dans l’architecture métier et les piles technologiques.
« Comment découpler l’entreprise et le produit de manière à ce que chaque composant puisse fonctionner plus ou moins indépendamment les uns des autres ? »
L’abstraction joue un rôle essentiel. Dans l’entreprise composable vue par Ariel Assaraf, chaque composant modulaire, de la pile technologique de l’organisation à l’architecture métier, est doté d’un certain niveau d’abstraction pour offrir un maximum d’agilité. Mais il ajoute : « il existe un seuil de rendement décroissant pour l’abstraction. Si nous allons trop loin et décomposons tout au niveau “atomique”, tout ralentit parce que tout part de zéro ».
« il existe un seuil de rendement décroissant pour l’abstraction. Si nous allons trop loin et décomposons tout au niveau “atomique”, tout ralentit parce que tout part de zéro ».
Ariel AssarafCEO, Coralogix
Pour Assaraf, chaque partie se doit d’être parfaitement autonome, c’est leur assemblage qui relève vraiment du défi. « Nous devons trouver un juste équilibre entre autonomie et abstraction », poursuit-il.
Réutilisation de code générique
Rod Cope, directeur technique chez Perforce, considère que plutôt que de travailler au niveau des widgets, les développeurs de logiciels parlent d’éléments réutilisables (bases de données, clouds et machines virtuelles). Par ailleurs, l’open source, dont l’adoption se répand rapidement dans les entreprises de toutes natures, est en soi une forme de développement composable.
Dans un monde idéal, rien ne devrait être construit à partir de zéro. Mais à l’heure où la demande impose des développements plus rapides et à grande échelle, l’assemblage de composants éphémères permettant de livrer rapidement des projets dicte le rythme du changement.
Comme Rod Cope le souligne, certains composants d’infrastructure sécurisés et validés, tels qu’Ansible, Chef et Puppet, permettent aux équipes de développement de logiciels d’accélérer le développement d’applications en partant simplement d’un composant générique, en le personnalisant pour des besoins particuliers, et en adoptant une approche IaC (infrastructure as code) automatisée.
Le résultat ? Selon lui, les développeurs peuvent intégrer des éléments testés et certifiés dans un workflow DevOps existant, pour améliorer l’agilité et la qualité, promptement et à grande échelle. « Bonne nouvelle pour les développeurs : ils passent moins de temps à créer les blocs constitutifs de base, peuvent fournir plus de code plus rapidement et se consacrer davantage, espérons-le, à la réflexion novatrice, ou du moins donner de la valeur ajoutée à une application, quelle que soit leur contribution particulière », précise-t-il.
Les API, les instruments de l’entreprise composable
Dans le monde de l’entreprise composable, les équipes produit doivent pouvoir proposer rapidement des logiciels sur mesure pour répondre aux nouvelles opportunités du marché, déclare Guy Sayar, directeur technique pour la région EMEA chez HashiCorp. « Les applications et l’infrastructure évolueront inévitablement de manière imprévisible », constate-t-il. « Cette fluidité ne peut être obtenue que dans un système défini par une API (application programming interface) ».
Guy Sayar recommande d’utiliser ces API lors de la création de l’architecture logicielle stimulant l’innovation, mais aussi dans le cadre des processus de conception et de maintenance de cette même infrastructure. Il s’agit d’un modèle orienté API porté par la maturité croissante des décideurs et des usagers de cloud. « Les équipes IT et métier sont de plus en plus disposées à intégrer des tierces parties de confiance dans leurs nouvelles infrastructures étendues, pour lancer leurs applications dans des environnements d’exécution innovants et fournir des services de valeur via ces API », ajoute-t-il.
Alors que les API aident les équipes internes et les partenaires externes à se connecter aux applications back-end, Kelly Goetsch, chef de produit chez Commercetools, explique que les utilisateurs finaux peuvent avoir des besoins très différents en matière de données, de puissance de traitement et de connectivité Internet.
Par exemple, « regardez le nombre d’API requis pour créer la chronologie Facebook d’un abonné », remarque Goetsch. « Imaginez maintenant exécuter toutes ces requêtes depuis une ancienne Apple Watch sur une mauvaise connexion Internet. »
Facebook a développé une spécification, nommée GraphQL, pour interroger les données. La GraphQL Foundation, jeune berceau de cette technologie, définit GraphQL comme un « langage de requête pour API ». Facebook l’utilise en interne depuis 2012 et a rendu la spécification publique en 2015. Depuis lors, elle a connu un vif succès et est notamment utilisée par Twitter, Microsoft, Amazon, Google et le New York Times.
Kelly Goetsch poursuit : « Avec GraphQL, il suffit de créer une seule requête, en spécifiant exactement les données que vous cherchez à récupérer. La couche GraphQL adresse ensuite les requêtes aux API individuelles [côté serveur] en vue de leur traitement. En tant que développeur, vous obtenez une seule réponse contenant tout ce dont vous avez besoin pour afficher la page détaillée de votre nouveau produit. GraphQL s’apparente à SQL. Vous pouvez récupérer des données depuis plusieurs tables de données à l’aide d’une seule requête. »
D’après Goetsch, GraphQL permet d’éviter de chercher trop de données (overfetching) ou pas assez (underfetching), et facilite l’accessibilité, l’autorisation/authentification et plus encore. Il dit aussi que ce langage est explicitement conçu pour permettre aux développeurs côté client de récupérer facilement les données des API et qu’il est devenu la norme et le « ciment » de la composabilité.
Guy Sayar de chez HashiCorp indique qu’une infrastructure composable exige une culture d’API indépendante. Mail il nous met en garde : « la démarcation entre indépendance et chaos est particulièrement mince. En cas de grands projets DevOps, les équipes créent et exécutent des milliers d’API. Résultat : cela génère une prolifération inutile d’API. La dette technique freinera la réussite sur le long terme. »
« la démarcation entre indépendance et chaos est particulièrement mince ».
Guy SayarCTO EMEA, Hashicorp
De par son expérience, il mentionne un autre défi : la multitude de frameworks de développement (Java, .Net, Node.JS, Python, etc.) utilisés dans une entreprise. « Le défi consiste à répercuter la composabilité dans toutes ces technologies disparates », explique Sayar.
Pour éviter la prolifération des API et gérer plusieurs frameworks, il faut utiliser une plateforme offrant des modèles d’architecture communs, un catalogue de service de fonctionnalités complémentaires et une série de contrats technologiques entre les équipes de développement et d’exploitation, ajoute-t-il.
Voir plus grand
Si les développeurs sont évidemment ravis d’avoir des bibliothèques de composants préconstruits à extraire pour créer de nouvelles fonctionnalités en minimisant les efforts, la composabilité a de nombreuses ramifications dans l’entreprise.
Dans un document publié en juin 2021, Ram Chandel, responsable de l’offre sur le marché du commerce numérique, et Paul do Forno, spécialiste du « commerce digital », directeur général chez Deloitte Consulting, ont partagé leurs opinions sur les tendances observées dans le e-commerce. Ils ont tous deux cherché à savoir pourquoi une plateforme d’e-commerce modulaire et composable permet aux entreprises d’étendre leur investissement en achetant ou en remplaçant uniquement les capacités dont elles ont besoin pour créer exactement l’expérience que leur marque souhaite offrir.
« Vous accédez aux fonctionnalités haut de gamme que propose tout un éventail de prestataires technologiques, plutôt que de tout confier à un seul fournisseur », expliquent-ils. « Un fabricant d’équipement industriel pourrait avoir besoin de moteurs de recherche et de recommandation sophistiqués pour mettre en évidence des détails ou des spécifications techniques. Une agence d’aménagement d’intérieur, en revanche, réfléchit à des moyens innovants de présenter ses canapés ou ses tables, y compris en 3D. »
L'essentiel est que ces fonctionnalités « personnalisées » soient plug-and-play de façon à aider l'entreprise à atteindre ses objectifs métiers.
En portant un regard plus large sur l’environnement économique, on s’aperçoit que les glissements de marché sont fugaces et, comme ces dix dernières années le prouvent, les nouvelles offres exploitant une niche peuvent vite supplanter des processus métier bien établis.
Bien que toutes les entreprises ne deviennent pas des éditeurs de logiciels, chacun sait que les plus compétitives se doivent d’utiliser les logiciels de manière stratégique pour se montrer agiles et saisir au plus vite les nouvelles opportunités du marché. Une architecture informatique professionnelle globale fondée sur la composabilité sera essentielle à la réussite d’une tactique de développement commercial pilotée par logiciels.
