Headless architecture and APIs, the 2 pillars of DAM integrability

To carry out its mission as the ”Single Source of Truth” for media, a DAM must be able to integrate with key applications within the information system.

‍

An enterprise DAM is not an isolated island within the information system (IS). Just the opposite, as the “Single Source of Truth” for media management, it is an integral part of this IS and is therefore highly integrated with its main applications.

‍

For example:

• the different CMS (Content Management Systems) used to deliver content to sites and apps 
• The ERPs (Enterprise Resource Planning) and PIMs (Product information Management) that feature valuable information on product taxonomy.
• the CRM (Customer Relationship Management) and CDP (Customer Data Platform) that store the information required to customize content

With respect to these systems, enterprise DAM is both a supplier and a consumer of information. Its integrability must be as strong as possible to guarantee the consistency of content (particularly for product information), its distribution (on the right frontals and channels) and its personalization. To do this, DAM relies on two key pillars: headless architecture and APIs.

‍

Enterprise DAM, natively headless (and we haven’t lost our heads)

The notion of “headless” architecture emerged in late 2018. Its boom is closely linked to the need to serve different front-end applications from a single back office: websites, mobile apps, screen networks, etc. Headless CMS emerged to address this omnichannel issue. Its characteristic?  Where a “classic” CMS has a back office coupled with a web frontal (a content restoration interface), the headless CMS is similar to a back office with no front-end. While content is stored, organized and published in the back office, it is up to developers to design front-ends able to consume and display this content. This is why the headless CMS comes with a set of APIs able to present content. Such CMS can thus serve different front-ends developed using varied technologies.

‍

While the distinction between coupled and headless still makes sense for CMS, it is not used as such for a Digital Asset Management solution. The reason is simple: the DAM is natively headless since its original mission is to make the content it hosts available to all channels. Those we know today and those, still yet unknown, that will be needed tomorrow. This implies a strong capacity to modify the formats of these contents, but also the capacity to deliver them in the best conditions. 

‍

Beware of shortcuts: integration of the DAM within a headless architecture doesn’t mean a plugin being available for one CMS or another. The plugin may appear to be an easy means to explore, from a CMS, the asset tree of a DAM, but it says nothing about the ability to really mobilize and deliver content of the Digital Asset Management solution.

‍

DAM, both producer and consumer of API

The bottom line here is the richness of the API proposed by a DAM to invoke the “right” content. In other words: pass to the DAM the information needed to display a video in the right technical format (resolution, ratio, encoding, etc.) with the language used, with or without subtitles, etc. It is by offering such depth that the API can truly give substance to what we call Content as a Service (CaaS): the capacity to mobilize an asset with precise characteristics from any IS call point. 

‍

DAM also needs this depth of query-making via APIs for third-party applications. In fact, to best serve an eCommerce platform, for example, it is in DAM’s best interests to rely on product taxonomy (to classify and/or tag assets). This requires being able to request the PIM or the ERP to draw this information. The same applies to audience information: to be able to customize content for a client logged into a platform, the DAM must be able to retrieve key information (country, language, purchasing history, preferences, etc.) from a CRM or a CDP.

‍

In other words, an enterprise DAM is also an integration platform: an environment allowing use of the APIs made available by other applications to better restore its contents via… its own APIs. An API producer and consumer within content architectures that are increasingly adopting the headless model. With a goal in sight: capitalize on content in order to better respond to the challenges of an omnichannel prospect and customer relationship.