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?