Chez Axway, nous avons compris qu’il ne suffit pas de publier quelques API pour faire naître une transformation digitale. C’est pourquoi nous accompagnons nos clients dans le temps long, et participons à leurs réflexions stratégiques, qui aboutissent souvent dans un repositionnement des activités dans ce nouveau paradigme digital.

Read this article in English below.

En 2023, cette transformation digitale passe pour 70% des entreprises par un engagement plus fort de son interaction avec l’écosystème, de plus en plus riche.

Découvrez notre baromètre “Marketplace : stratégie d’exposition et gouvernance des APIs” ici.

Cet engagement nécessite une ouverture du système d’information non plus, comme on l’imaginait il y a encore 2 ans, avec de simples API (techniques ou business), mais avec des produits digitaux.

Qu’est-ce qu’un produit digital ?

Derrière ce terme de « produit digital » ne se cache pas qu’un simple changement de nom, mais une nouvelle philosophie d’exposition et d’engagement des développeurs de l’écosystème, qui recherchent toujours plus de simplicité dans l’usage de ces services.

C’était l’un des thèmes abordés récemment lorsque de notre présentation du baromètre de stratégie d’exposition et gouvernance des APIs :

Une API, c’était un bout de code, un pauvre swagger/OAS qui traînait dans un catalogue, plus ou moins bien référencé.

Passer de l’API au produit digital, c’est un peu comme passer du petit pois dans un champ à la boîte de Bonduelle sur un rayon de Monoprix. Il y a tout un processus de transformation et de marketing qui s’applique identiquement aux produits digitaux :

• Identifier et inventorier le produit.
• Sélectionner (curation)
• agréger, orchestrer (recette)
• Emballer
• Poser une notice d’utilisation, vidéo explicative
• Pricing
• Référencement
• Exposition dans une belle vitrine, un beau rayon, dans un magasin facile d’accès

Ce processus doit s’inscrire dans une chaîne de fabrication prenant en compte les « feedback » clients et donner aux producteurs comme aux consommateurs des métriques précises.

Où se passe l’assemblage des produits digitaux ?

Ceci étant dit, il me semble important de se poser la question de l’assemblage des API techniques, des bouts de code (sample, webview, etc). Cet assemblage doit-il s’effectuer au niveau de vos plateformes d’API management (en général sous la tutelle de la DSI) ou bien doit-il être l’objectif d’un nouvel outil, au-dessus de ces APIM (souvent considérées à juste titre comme trop techniques), outil que l’on nomme désormais DSM (Digital Service Marketplace).

Ces nouveaux outils de DSM ont l’avantage d’être manipulables par des métiers, internes ou externes, pour exposer et pricer les services. Mais doivent-ils être le lieu pour réaliser l’assemblage des briques techniques sous-jacentes (API, ressources, méthodes, etc. ?)

Alors, pour vous, cet assemblage doit-il être à la main des DSI dans une APIM pour créer une sorte de « super API » ou bien doit-il être le fruit d’une activité métier dans une marketplace ?

La question se pose légitimement, et dépend grandement de la granularité initialement choisie pour exposer les services (grosse API avec 50 ressources ou bien API plus granulaire).

Ces questions touchent non seulement la manière de commercialiser ces produits (qui voudrait acheter une boîte de 100 kg de petits poids pour n’en consommer que 4 assiettes). À l’inverse, commercialiser les petits poids à l’unité est tout aussi fastidieux pour le client…

Pour les services digitaux, c’est la même chose avec, en plus, des problématiques de sécurité qui impliquent une distribution de jeton peu compatible avec une vision trop fine de la granularité des services…

Ces questions d’architectures sont aujourd’hui au cœur de la réflexion de nombreuses entreprises, et il nous semble intéressant d’ouvrir le débat.

Qu’en pensez-vous donc, vous ?

English version

Where should the production of digital products be positioned?

At Axway, we understand that simply publishing a few APIs is not enough to bring about digital transformation. That’s why we support our clients for the long haul and actively participate in their strategic thinking, which often leads to a repositioning of activities in this new digital paradigm.

In 2023, for 70% of companies, digital transformation involves a stronger commitment to interacting with an increasingly rich ecosystem (see our barometer (in French) here).

This commitment no longer requires merely opening up the information system, as many still believed just two years ago, with simple APIs (whether technical or business), but rather with true digital products.

Understanding digital products

Behind the term “digital product” lies not just a simple name change, but a new philosophy of exposing and engaging ecosystem developers who are always seeking greater simplicity in using these services.

An API used to be a piece of code, some sad Swagger/OAS document buried in a catalog, more or less well-documented.

Moving from an API to a digital product is somewhat akin to going from a pea in a field to a Del Monte can on a Costco shelf. There is a whole process of transformation and marketing that applies identically to digital products:

• Identify and inventory the product
• Select (curate)
• Aggregate, orchestrate (recipe)
• Package
• Provide usage instructions, explanatory videos
• Pricing
• Referencing
• Display in an attractive showcase, a beautiful section, in an easily accessible store.

This process must be part of a manufacturing chain that takes customer feedback into account and provides precise metrics to both producers and consumers.

See also: What is an API Product? Design better APIs with a product mindset. 

Where do digital products get assembled?

That being said, it’s important to consider how to assemble technical APIs, pieces of code (samples, webviews, etc.). Should this assembly take place at the level of your API management platforms (usually under the oversight of the IT department), or should it be the goal of a new tool above these API management platforms, now known as a DSM (Digital Service Marketplace)?

These new marketplace tools have the advantage of being usable by business units, both internal and external, to expose and price services. But should they be the place to carry out the assembly of underlying technical building blocks (APIs, resources, methods, etc.)?

So, in your opinion, should this assembly be in the hands of IT departments within an API management system to create a kind of “super API,” or should it be the result of a business activity within a marketplace?

It’s a question worth asking, and the answer depends greatly on the granularity initially chosen to expose services (a large API with 50 resources vs. a finer-grained API).

These architectural questions not only affect how these products are marketed (who would want to buy a 100 lb bag of peas when they only need 4 servings?), but also pose challenges when it comes to distributing tokens, which may not align well with a very fine-grained view of services.

These architecture questions are at the heart of the deliberations for many companies today, and we believe it’s interesting to open up the debate.

What do you think about this?