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.

Première recommandation : Designer une API affordante avec une documentation claire

L’API expose des produits et non pas des services techniques.

Deux aspects sont à prendre en compte :

1. Les services exposés doivent être documentés.
2. « Eat your own dog food ». Les services exposés doivent être utilisés en premier par les développeurs eux-mêmes. Ceci permet de :
   1. Détecter des bugs
   2. Les corriger à temps
   3. Améliorer l’ergonomie (usage simple, accès clair) du service
   4. Réaliser les premiers tests de charge
   5. Vérifier les règles de sécurité.

Ceci implique que tous les services exposés doivent :

1. Avoir une interface bien définie, respectant les règles de nommage
2. Être bien structurées
3. Documenter :
   1. À quoi sert l’API ?
   2. Comment utiliser l’API ?
   3. Inclure des exemples
4. Prendre en compte la clarté et la facilité d’utilisation

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/

Deuxième recommandation : Bien réfléchir à sa stratégie de gouvernance de service

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.

Faire des services modulaires

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 :

• A une seule responsabilité
• Effectue une seule fonction.

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.

Dans le cadre de la banque Fantôme, le service « Créer prêt » ne fait que créer un prêt, il ne crée pas le client implicitement. En outre, le service « gestion de prêt » n’existe pas, il y a un service « Créer prêt », « supprimer prêt », « mettre à jour prêt » car il a été convenu, en termes de granularité, qu’un service expose des fonctions métiers unitaires.

Définir une politique de gestion de version des services

Ensuite, il faut prendre en compte l’évolution de ces APIs :

• Mise à jour
• Suppression
• Remplacement par une autre API

En fait, il faut être capable de répondre à ces questions :

• Faut-il maintenir plus d’une version en production au même temps ?  Si oui :
  • Quelle est la période de support nécessaire pour une version n-1 ?
  • Dois-je maintenir trois versions ou plus d’une même APIs en même temps ?
• Ou bien faut-il retirer la version la plus ancienne dès qu’une nouvelle version est mise en place ?
• Quels sont les impacts de la mise à jour ou de la suppression d’une version ?
• Comment décommissionner une version d’une API ?

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/

Troisième recommandation : ne pas exposer tous les traitements

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.

Dans le cadre de la banque Fantôme, il n’est pas possible d’exposer un service « ajouter candidat » lié au domaine métier gestion RH dans un ensemble d’APIs dédiés à la gestion du prêt.

D’autre part, exposer une palette de services cohérents et complémentaires fonctionnellement assure :

• Un couplage faible entre les APIs
• La non-redondance
• Les couches d’appels et le risque de se retrouver dans le cas d’un plat de spaghetti non maîtrisé.

Quatrième recommandation : avoir des métriques

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 :

• Définir des SLAs
• Mettre en place des KPIs
• Détecter les défaillances du système : un temps de réponse long qui peut être dû à une latence réseau, un algorithme non optimisé, un cache non utilisé, un CPU chargé, il faut mesurer pour mettre le doigt sur le vrai problème.
• Justifier la nécessité d’une évolution et ensuite mesurer son efficacité.

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.

  Dans le cadre de la banque Fantôme, la création d’un client est un processus métier orchestrant des appels vers plusieurs services :

• Vérification du nouveau client
• Validation de l’identité du client
• Création profil client dans le LDAP
• Création dossier client dans base de dossier dans certains cas.

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 :

• Le nombre de clients créé sur une période
• Le nombre de dossiers créés
• Le nombre de clients ayant un type de profil

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.

Cinquième recommandation : une API expose des traitements et de la data

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...).

Prenons le cas de la banque Fantôme, l’accord d’un prêt à un client est un workflow assez compliqué, on fait appel à plusieurs APIs et services internes de l’entreprise. Ce workflow peut être déroulé par différents acteurs, les prêts d'investissement sont gérés par une équipe métier différente de l’équipe qui gère les prêts immobiliers, mais techniquement un prêt se crée et se valide de la même façon. Dans ce cas, l'entreprise peut avoir dans son catalogue une API qui expose ce traitement.

Comment choisir son API Management ?

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 :

• Enrôlement, exposition et documentation des services et console interactive via le portail des développeurs
• Monitoring et métriques
• Authentification et habilitations (en direct ou s'appuyant sur une brique existante)
• Gestion du Traffic (quotas, caching, throttling, protocol transformation)
• Des transformations techniques limitées sur les services

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 :

• Ayant un périmètre étroit dans un domaine métier que vous connaissez, car s'appuyer sur cette connaissance simplifie la conception des services (rien de plus périlleux que de définir des services à l'aveugle alors qu'on ne sait pas comment ils vont être utilisés)
• Intéressant le plus grand nombre possible de types de consommateurs. Impliquez ces consommateurs dans le design afin d'augmenter les chances d'aboutir à une API générique avec des services adaptés et composables plutôt que du one shot et du sur-design.

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é.

Conclusion

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.