‘API Management & Backends’ : intégration ‘as-is’ ou réurbanisation ? - 1ère partie

Auteurs :

Laurent Baumard

Directeur associé

Contactez

En collaboration avec Jérôme Besson

4 minutes

A l’instar de ce que l’on a vécu pour les architectures orientées services, concilier « API Façade » pensée consommation et « API Ressource » fournit par un composant SI existant n’est pas simple. La 'SOA' avait d’ailleurs fini par accoucher d’une méthode de conception visant à autoriser la dénormalisation de la cible idéale ‘top-down’ du service et l’adaptation de la ressource existante ‘bottom-up’ autour d’un compromis ‘meet-in-the-middle’ lorsque l’accostage aux ressources SI existantes en était trop éloigné. La problématique reste aujourd'hui entière même si la nature même des APIs et l’avènement des architectures micro-services permettent d'y porter un regard et d'y apporter une réponse différente. Entrez de plein pied dans le futur de l'intégration. Comprenez comment accoster les 'APIs' sur les services métier 'backend' existants en s'appuyant sur des microservices plutôt qu'un 'ESB' (Enterprise Service Bus).

# Un leg SI pas API du tout

D'importants systèmes d'information ont été rénovés au cours de la dernière décennie afin de développer des applications numériques ‘Front End’ SOAisées au-dessus des systèmes ‘backends’ existants. Si de nombreux systèmes ont été servicés, l’urbanisation des services existants n’est pas adaptée dans la plupart des cas aux APIs souhaitées par l’entreprise en réponse aux nouveaux enjeux digitaux. Dans le déploiement d’une stratégie API, la mise en œuvre d’une plateforme d’API Management n’est pas le plus compliquée. En revanche, l’implémentation de l’API peut être complexe dès lors qu’elle s’appuie sur des systèmes existants : orchestration et intégration de services existants, APIsation de système monolithique qui peut s’avérer difficile et onéreuse, implémentation de façade applicative. Plusieurs possibilités s’offrent à l’entreprise pour réaliser l’accostage de l’API dans le SI. Pour les comprendre, un petit retour arrière sur le modèle d’architecture SOA s’impose.

# Un cœur 'ESB' pour articuler 'Frontend' et 'Backend'

Le modèle d’architecture SOA (‘Service Oriented Architecture’) a modelé le système d’information en 5 couches principales, souvent autour d’un SI dit de distribution (B2C & B2B) et d’un SI dit de Production :

  • Interaction ‘Frontend’ (IHM & Services orientés UX & B2B)
  • Services ‘Frontend’ (Services orientés Clients & Partenaires)
  • Orchestration ‘Front-to-Back’ (Moteurs BPM/ACM)
  • Intégration ‘Front-to-Back’ (ESB)
  • Services Backend (Services Cœur de gestion)

Dans ce modèle d’architecture, la pierre angulaire de l’intégration est portée par un ESB (‘Enterprise Services Bus’). Ce dernier apporte usuellement 3 capacités d’intermédiation :

  • Normalisation : assure la connectivité avec les services ‘Backend’, les expose sous la forme de services canoniques, normalisés et réutilisables par et pour l’ensemble des consommateurs.
  • Adaptation : réalise la normalisation des services ‘Backend’ sous forme de services applicatifs consommables aux standards 'SOA' ('SOAP' historiquement, 'REST' aujourd’hui)
  • Exposition : expose les services applicatifs ‘Backend’ aux ‘FrontEnd’.

# SOA ne vaut pas API

La 'SOA' est un modèle d'architecture SI ‘inside-out’ c’est-à-dire centrée sur l'entreprise et régit par 7 principes majeurs (autonomie, réutilisabilité, composition, découvrabilité…) qui déterminent le design et la gouvernance des services, usuellement par grands domaines fonctionnels de l’entreprise (client, comptabilité, finances…). Un des travers majeurs de la 'SOA' est la constitution de services ‘one size fits all’ à très forte granularité, voire multi-opérations. Une approche certes vertueuse en termes de non-prolifération des services mais sclérosante en matière d’agilité et de variété des usages digitaux à adresser. Des usages qui nécessitent à contrario une approche ‘outside-in’, centrée ‘business model’, client et l’écosystème de l’entreprise. Une approche API qui vise la production d’APIs utiles, utilisables et adaptées aux usages.

# L’ESB en REST

Au même titre que la 'SOA', une architecture APIsée répond à des codes spécifiques, des de-facto standards qui ont émergé des géants d’Internet et aujourd’hui du Cloud, faisant de l’API l’espéranto de la ‘digital mesh’ : 'RESTFul', self-service, 'developer friendly', securisé, modèle de tarification ‘freemium’…

Là où la 'SOA' prônait la réutilisabilité quitte à être trop générique, l’API prône l’utilité et l’utilisabilité quitte à se diversifier.

Il n’est donc pas étonnant que les technologies, les règles de conception et les principes de gouvernance notamment en matière de gestion du cycle de vie des services développés pour la 'SOA' ne soient pas alignés aux exigences du nouveau monde digital.

Les 'ESB' pêchent ainsi en fonctionnalités de gestion du trafic, de gestion des quotas, d'authentification et l'autorisation, de traçabilité, de supervision technique & fonctionnelle et d’analyse métier d’utilisation des services.

Les annuaires de services, lorsqu’ils ont été déployés, sont quant à eux loin en matière de promotion et de self-services en regard des portails 'APIs' qui offrent des fonctions avancées de découvertes, de tests, de modèle de consommation et de tarification et d’intégration sans aucun recours à une équipe technique.

L’ESB implique, par ailleurs, une approche centrale de gouvernance impactant potentiellement le délai d’implémentation des projets.

# API Resource vs API Usage

Quand on parle d’API, on pense généralement et uniquement aux 'APIs' exposées dans le portail 'APIs'. Ces 'APIs' façades, dénommées aussi « API Usages » pour leur vocation de consommation ne sont que la partie visible de l’iceberg. L’API usage est l’exposition d’une API ressource sur laquelle sont appliquées des politiques d’usage essentiellement technique (sécurité, gestion de quotas, gestion de trafic, cache).

L’API Usage est très simple à déployer sur la solution d’API Management ('swagger API Resource' + Politiques d’usage).

En revanche, l’API Ressource peut être complexe à implémenter, notamment si elle a été conçue avec une approche Top Down en faisant abstraction de l’existant. En effet, il peut exister un réel effort d’intégration pour accoster cette API ressource idéale sur des services existants : adaptation fonctionnelle (ex : mapping de format), orchestration de services, adaptation technique (ex : 'SOAP to RESTful'), gestion d’habilitation…

Une approche 'Bottom-up' consistant à exposer un service existant en 'REST' sous la forme d’une 'API' ressource est facile, mais elle présente le risque de ne pas apporter la valeur métier attendue et de ne pas répondre aux besoins.

Découvrez comment Sentelis a déployé une plateforme d’API Management pour un leader mondial de la grande distribution.