Les APIs sont omniprésentes. Les métiers en demandent car elles promettent les plus belles perspectives commerciales, des effets boules de neige et de la démultiplication de valeur. Les consultants ne jurent que par cette solution. Pas un schéma d’architecture sans que l’API Gateway ne règne en maitresse, ayant comblé le moindre interstice entre les applications et s‘érigeant en barrière impérieuse entre les deux mondes du Legacy et des frontaux Web, chantre et cœur de l’IT bi-modal.
Obnubilé par les promesses de l’API management, la réflexion sur le bien-fondé de l’utilisation d’un échange synchrone est morte née.
Votre direction a donc investi (cher) et la cellule d’architecture applique une stratégie d’API par défaut.
Mais obnubilé par les promesses bien connues de l’API Management, la réflexion sur le bien-fondé de l’utilisation d’un échange synchrone est passée au second plan. Tout comme la SOA avait imposé ses Web-Services pour des raisons de vitesse de propagation, l’API Management assoit sa domination sur sa supériorité technologique pour l’exposition à l’ensemble des partenaires.
Les échanges synchrones n’offrent aucun mécanisme efficient de reprise des erreurs.
On en oublie une caractéristique et une limite intrinsèque à ce type de flux. Les échanges synchrones ne se justifient en effet que quand une réponse (et donc un aller-retour) est nécessaire, et ils imposent en contrepartie un couplage fort entre l’appelant et l’appelé, l’échange ne pouvant pas aboutir si l’appelé n’est pas disponible au moment précis de l’appel. Les échanges synchrones n’offrent ainsi aucun mécanisme efficient de reprise des erreurs techniques (des retry toutes les 5 secondes ? Pendant 1 heure par exemple ? avec de plus en plus de services qui ne répondent plus… ? Autant sortir les arva® et attendre le Saint Bernard).
On tombe ainsi dans des cas où le rejeu devient très gênant et où la responsabilité de ce rejeu est déporté vers l’appelant alors que son message était correctement émis, correctement formaté et qu’il ne tire aucun bénéfice de l’acquittement HTTP qui lui reviendra. On rencontrera particulièrement ce cas sur des appels visant à créer ou modifier des données. Qui est responsable du rejeu d’une fonction POST ou PUT tombée en erreur ? Pour peu que le partenaire appelant soit une application SaaS, un logiciel propriétaire voire pire un partenaire B2B, on se retrouve dans une impasse.
Les échanges asynchrones et leur pattern publish-subscribe apportent par construction une extrême résilience à ce type d’incident en persistant les messages et en laissant les destinataires maitres de leur rythme de consommation. Ajouter à cela la grande facilité de paramétrage d’une nouvelle cible -là ou une plateforme d’API demandera une nouvelle règle de routage- et l’on retrouve pourquoi les solutions asynchrones sont des impératifs d’un SI bien structuré.
Il serait bien trop limitant de se passer d’un portail d’API et de l’accessibilité externe qu’il offre.
Favoriser l’asynchronisme est un bon principe de conception de flux.
Si l’échange est unidirectionnel, que la donnée peut être stockée chez le consommateur et que la fréquence de modification n’est pas trop importante, oubliez le synchronisme, rendez sa liberté au fournisseur d’information et appuyez-vous sur votre MOM ou EAI !
Pour autant il serait bien trop limitant de se passer d’un Portail d’API et de l’accessibilité externe qu’il offre. La facilité d’exposition offerte par ces solutions est sans pareil sur le marché actuel.
Appliquez-vous donc à construire un système hybride. Pensez l’API Gateway, et le package HTTP, REST et JSON comme un connecteur, une porte d’entrée sur votre SI, et débrayez immédiatement derrière sur une solution de bus de messages (MOM ou EAI) dès que cela est sensé.
En cassant la chaine du synchronisme on récupère la souplesse souhaitée, en maintenant la Gateway en frontal on conserve l’ouverture et la facilité d’utilisation.
La fonction Architecture évolue souvent de manière cyclique : animatrice des transformations de l’entreprise un jour, décriée et sans ressources le lendemain; tel le phœnix elle doit souvent renaître de ses cendres. Ces cycles ne sont pas inéluctables, pour peu que l’architecte sache résoudre cette équation : se montrer indispensable et préserver son existence.
En matière de système d’information, le rôle de l’Architecte est régulièrement discuté, remis en cause et doit en permanence être justifié. Pourtant, dans le secteur du bâtiment, aucun promoteur sensé n’envisagerait de se passer d’un Architecte, garant à la fois de la bonne réponse de l’ouvrage à ses besoins, mais aussi de sa conformité et de son évolutivité.
Dans nombre d’entreprises, nous voyons naître une fonction d’Architecture soit à l’occasion d’un grand programme de transformation, soit parce que la complexité du SI ou simplement le déficit de connaissance de celui-ci rend son évolution difficile et coûteuse. Dès lors, l’Architecte est reconnu comme le messie qui va résoudre tous les problèmes et réaligner le SI avec les enjeux stratégiques de l’entreprise.
Pour autant, une fois ces tâches réalisées avec efficacité, son existence sera remise en cause et éventuellement sacrifiée sur l’autel des réductions budgétaires ou simplement de la volonté de réduire son influence.
Ainsi, selon un cycle plus ou moins long, les fonctions Architecture alternent des périodes de forte influence et d’autres de désintérêt. L’Architecte, comme nos amies les abeilles, doit composer avec ce paradoxe : être indispensable tout en luttant pour sa survie.
Certaines entreprises ont démontré que ces cycles ne sont pas inéluctables et la bonne nouvelle est que l’Architecte lui-même dispose des clés de son succès :
L’apport permanent de valeur ajoutée
Il en va en théorie de toute fonction de l’entreprise, mais c’est encore plus vrai de l’Architecte. Ses interventions doivent toujours apporter de la valeur aux projets ou à l’actualisation de la trajectoire au bénéfice de l’entreprise dans son entier. Pour cela, il faut choisir ses combats. Si l’Architecte doit tout voir de l’évolution du SI à un moment ou un autre, il ne doit en aucun cas apparaître comme un administratif qui appose son tampon sur tous les dossiers. Il doit savoir sélectionner les projets ou études sur lesquels il apportera de la valeur à l’entreprise, en regard des enjeux d’architecture qu’ils portent, eux-mêmes en lien avec les orientations stratégiques de l’entreprise.
Dans cette logique, la fonction Architecture ne pourra plus être vue comme un coût mais comme un investissement dont la rentabilité réside dans le rapport qualité/prix des solutions et les erreurs évitées.
L’ajustement du dispositif
L’activité des architectes varie en fonction des plans d’évolution du SI. Pourtant, les équipes d’architectes sont généralement très stables, ce qui se justifie souvent par la volonté de conserver les sachants qui seront précieux lors des futures sollicitations. Plutôt que de meubler les périodes de baisse d’activité par des travaux d’intérêts limités, le responsable de l’architecture doit construire un dispositif ajustable en fonction de la charge, par exemple avec un minimum de recours à la sous-traitance, sans attendre qu’une directive budgétaire vienne s’en charger à sa place.
Le renouvellement des forces
La fonction Architecture doit faire preuve d’innovation, ou à minima de créativité afin de challenger en permanence la pertinence des choix et des règles établies. L’apport d’un regard neuf est indéniable et évite de reproduire par la routine les mêmes réflexes. Pour reprendre l’image du bâtiment, il n’est pas si fréquent de confier la réhabilitation d’un immeuble à l’Architecte qui l’a conçu. Ce renouvellement peut être obtenu grâce au pilotage de la mobilité des collaborateurs, ou encore par un apport régulier de conseil spécialisé pour les travaux les plus structurants. Pour permettre ce renouvellement dans la continuité, il faut bien entendu tenir à jour la documentation des plans du SI et de ses règles de construction.
L’influence plutôt que le pouvoir
Enfin, et c’est peut-être le point le plus essentiel, l’Architecte doit avoir pour rôle principal d’éclairer les décisions des décideurs de l’entreprise sans se substituer à eux. La tentation est grande pour l’architecte d’imposer ses points de vue, en particulier lors de grands plans de transformation. En effet, la vision globale et à long terme qu’il est souvent le seul à apporter peuvent le convaincre de posséder seul les solutions aux problèmes posés et donc de les imposer aux différents acteurs sans que ceux-ci les comprennent vraiment. Or, si l’Architecte se doit d’exercer une influence sur les décisions structurantes pour le SI de l’entreprise, il ne doit pas chercher à exercer un pouvoir sur celle-ci. A défaut, ceux qui possèdent réellement le pouvoir saurons le lui rappeler le moment venu, et ainsi réduire considérablement son potentiel voire son existence même.
Au final, il est bien normal que les architectes soient challengés en permanence et c’est aussi ce qui rend ce métier passionnant. L’application de ces quelques règles conduit à apporter la valeur, l’agilité, l’innovation et l’influence de nature à répondre à ce challenge.
Bien que tentante par sa concision et sa fluidité, cette formulation est une chausse-trape tant elle semble précise alors qu’elle est absolument vide de sens. Elle donne l’impression aux parties prenantes de s’être exprimées alors qu’elle masque complètement la réflexion qu’ils doivent mener.
« Faire du temps réel » n’est en effet pas un besoin. On voit tout juste pointer le bout du nez d’une information sur la vitesse de propagation mais c’est une exigence non fonctionnelle qu’il sera nécessaire d’arriver à quantifier, l’ubiquité de la donnée n’étant pas encore accessible. Et ce sera d’ailleurs l’occasion de parler volumétrie, supervision, sécurité.
Et rappelons que le synchronisme n’a rien à voir là-dedans… De nos jours des API complexes vont mettre beaucoup plus de temps à répondre qu’une transmission asynchrone utilisant un outil correctement dimensionné.
Pour être sûr de ne plus faire l’erreur, reprenons les bases
L’important dans la conception d’un échange de données est de comprendre la relation entre le consommateur et le producteur. Et ça, c’est bien les sachants fonctionnels qui sont les mieux placés pour l’exprimer (un accompagnement par une personne exercée peut être utile) :
Qui déclenche le flux ? Est-ce le besoin d’accéder à la donnée -et donc le consommateur- ou le fait d’avoir capté un événement (création, modification d’information) -et donc le créateur ?
Est-on dans le cadre d’une communication bidirectionnelle -question-réponse-, ou unilatérale ?
S’il y a réponse, doit-elle être liée à la question et à son contexte ou garde-t-elle tout son sens et sa pertinence quel que soit le timing de retour ?
Un petit exemple, car je sens que cette phrase absconse peut laisser pantois : Quand je lance un calcul d’itinéraire avec G**gle, la réponse est entièrement liée au contexte d’appel, i.e. ma position. L’information n’a plus de sens si elle arrive trop tard ou si j’ai depuis déclenché une nouvelle demande (si j’ai raté une intersection par exemple). En revanche si je demande le score de Lyon/Paris-Saint Germain d’hier, le contexte de ma demande n’influe pas, je veux la réponse dès que possible, et si cela arrive dans 2 minutes cela m’intéresse toujours !
Il est maintenant clair que ces trois questions dépassent largement la notion de « temps réel ». Délaissez donc cette formulation passe partout et cantonnez-la aux discussions dont le fond n’est pas réellement l’architecture des échanges (et heureusement elles sont nombreuses !).
