Aujourd’hui, les solutions d’API Management sont de plus en plus utilisées. Toutes les entreprises veulent ajouter cette nouvelle brique à leurs écosystèmes afin d’exposer leurs données ou leurs services aux clients et partenaires ou seulement aux applications internes.
Cependant, une solution d’API Management ne fait qu’exposer les services que le système d’information propose déjà. La mise en place de cette solution ne change rien à l’existant et surtout à la structure du système d’information. Or la finalité derrière la mise en place d’une solution d’API Management est d’APIser son système d’information.
Donc avant d’ajouter cette nouvelle brique, on vous recommande de prendre le temps d’étudier vos systèmes, de poser une stratégie claire pour votre architecture et de définir des APIs qui répondent à vos besoins métiers. La mise en place de la solution d’API Management se fera sans douleur ensuite et remplira toutes vos attentes.
Ce qui suit donne les grandes lignes à suivre pour réussir à APIser son système d’information et réussir à mettre en place efficacement une solution d’API management.
L’application de ces recommandations permet de construire un catalogue de services cohérents, modulaires et indépendants (couplage faible).
Nous allons utiliser le contexte suivant :
La banque Fantôme qui rend des services de prêt, d’épargne, la possibilité d’avoir un compte courant avec un service RH.
L’API expose des produits et non pas des services techniques.
Deux aspects sont à prendre en compte :
Ceci implique que tous les services exposés doivent :
Ne pas oublier que les développeurs sont des utilisateurs finaux de cette API aussi, ils consomment des produits autant que les clients.
Donc, une API réussie est une API qui répond à des fonctionnalités et assure une facilité d’utilisation.
Pour plus d’illustration sur le principe Eat your own dog food
https://en.wikipedia.org/wiki/Eating_your_own_dog_food
https://blog.newrelic.com/2013/11/07/dogfooding-is-good-for-your-users-and-for-you/
La décomposition du SI est nécessaire, mais il faut prendre en compte les évolutions et la possibilité d’adresser de nouveaux besoins. Les services définis doivent être modulaires et « clairement gouvernables » afin que la v2 de l’API ne soit pas un nouveau big bang pour les développeurs ou les consommateurs.
Un des premiers principes de développement orientés objet (SOLID) est Single responsability.
L’énoncé de ce principe est : « A class should have only one reason to change ».
Dans le cadre des APIs, ce principe se traduit par un service :
L’application de ce principe assure la construction d’un catalogue de services modulaires et maintenables.
Ceci dit, avant de commencer toute implémentation, il faut définir le bon niveau de la granularité des services. Ce niveau se définit en se basant sur l’aspect métier du service. Une API expose un service qui réalise une fonction métier unique, claire avec des périmètres bien définis.
Ensuite, il faut prendre en compte l’évolution de ces APIs :
En fait, il faut être capable de répondre à ces questions :
Les réponses à ces premières questions vont permettre de commencer à mettre en place une politique de gouvernance de vos APIs.
Pour vous aider à adopter une stratégie de versionning, les méthodes les plus courantes sont décrites ici : https://blog.octo.com/versioning-des-services-principes-et-elements-darchitecture%E2%80%A6/
Il est plus logique d’exposer seulement des services utiles pour les consommateurs. Ceci mène à exposer des services cohérents reflétant un domaine métier clair.
En effet, le but d’une API est d’exposer des services qui répondent à un vrai besoin métier. Ces services peuvent être utilisés pour créer de nouveaux services (factorisation et réutilisabilité). La cartographie de l’API reflète, le métier de l’entreprise. Il est conseillé donc d’étudier les services à exposer.
D’autre part, exposer une palette de services cohérents et complémentaires fonctionnellement assure :
Mettre en place une solution d’Api management doit être le moyen pour superviser les services exposés.
L’API doit fournir des métriques techniques (nombre d’appels, temps de réponse, nombre de réponses KO, taux utilisation mémoire ou cache) qui sont nécessaires pour :
L’API peut aussi suivre fonctionnellement le traitement d’une tâche de bout en bout et ainsi fournir un moyen de supervision fonctionnel. Il serait intelligent de prévoir un mécanisme pour tirer profit de ces indicateurs via des dashboards métiers, des outils d’analytics et de machine learning.
Chaque service remonte via des fichiers de logs le résultat de son exécution.
Avec ces logs on peut construire un dashboard qui affiche :
Ainsi en définissant des APIs bien supervisées on peut fournir au métier des données agrégées qu’il peut exploiter.
Il ne faut pas limiter l’usage des APIs à l’exposition des données. Une API peut exposer un traitement métier. Les APIs ne se limitent pas à exposer une présentation de votre modèle de données, mais peuvent exposer tout un workflow, bien sûr il faut bien superviser et s’assurer que les cas d’erreurs sont bien gérés (logs, les reprises...).
Une fois que les APIs du système d’information sont bien mises en place, c’est-à-dire un système modulaire avec des fonctionnalités découplées et supervisées, investissez dans la mise en place d'une plateforme d’API management. Cette plateforme apporte les fonctionnalités suivantes :
Ainsi, une solution API management donne accès des fonctionnalités de l’entreprise et répond à des problématiques techniques assez pointues, mais ne définit ni l’architecture du système d’information, ni la granularité des fonctionnalités ni la modularité des services…
Il est tentant de penser que les fonctionnalités de transformation techniques d'un outil d'API management vont permettre de bâtir une API au-dessus d'une couche de service existant, mais ne vous y trompez pas !
Ne reproduisez pas l'erreur de ceux qu'il y a 10 ans pensaient que les outils d'ESB suffiraient à résoudre leurs problèmes d'urbanisation et qu'ils couperaient au besoin de changer leurs méthodes de travail.
Ensuite, il faut bien choisir sa solution d’API Management. Sur le marché, plusieurs plateformes sont disponibles pour un usage en SaaS ou on-premise, chaque plateforme apporte son lot de fonctionnalités répondant à différents besoins (types d’exposition, monitoring, cache, PCI-DSS, outil de mappping et de transformation…).
La question qui se pose : faut-il prendre une solution de l’étagère ou bien développer sa propre solution d’API management ? Si la décision est de prendre une solution sur étagère, étudier bien chaque solution afin de choisir celle qui répond mieux à vos besoins métiers et qui s'intègre facilement dans votre écosystème.
Ces recommandations sont des grandes lignes directrices à considérer quand on veut « APIser » son système. Vu d’emblée, la transformation paraît profonde et compliquée, ceci dit, évitez de vouloir trop vous préparer avant de sauter le pas en vous lançant dans un plan global de ré-urbanisation afin de définir un SI avec une API complète du sol au plafond sans toucher à une ligne de code.
Commencez par identifier avec le métier une opportunité nécessitant la création d'une API très limitée :
Ensuite, déroulez ce MVP (Minimum Viable Product) jusqu'en production en s'appuyant sur les méthodes agiles. Cela permettra de valider votre approche, et la plateforme d'API management.
Une fois cette étape franchie, enrichissez peu à peu ce noyau d'API de manière opportuniste et itérative.
le schéma ci dessous illustre d'une façon simple l'architecture du SI dans la banque Fantôme une fois le système à été APIsé.
Pour conclure, vouloir mettre en place une solution d’API management est légitime, mais ne suffit pas pour APIser votre système.
Il vaut mieux prendre le temps de réfléchir l’architecture de son système d’information, cette réflexion doit se faire via un travail collaboratif avec le métier. Vos APIs doivent émettre des usages et des besoins fonctionnels donc il est recommandé de travailler avec le métier pour les définir.
L’APIsation de votre système signifie aussi la transformation de vos méthodes de travail en apprenant à travailler plus avec les consommateurs, à mener des projets qui communiquent entre eux et à concevoir une API comme un produit entier à exposer en externe.