API-First, Headless DAM and the DXP

This article has been provided by Murray Oles, President of Chalex Corp, with additional credit to Chalex CTO Garry Bollinger.

 

API-First is an evolving discipline prescribed for the ever changing constraints of enterprise software development. The application program interface, or API, is the universal connector in a SOA (service-oriented architecture) computing solution. The API-First concept promotes RESTful web APIs at the connection point of every component providing computational services throughout the architecture. The benefit is realized through greater agility in the ongoing management of services within the total solution architecture.

The many components of all Digital Asset Management systems are knitted together through internal APIs. These may be internal APIs with a variety of connection protocols selected to perform under current constraints. A headless DAM assumes that components are “plug and play” and connect through a JSON-API. XML web-based APIs are accessed through the XML http protocol. The architecture standardizes component communications with web formatted APIs. In a client-server architecture, the server and its internal components use the same client protocol to connect to the server components internally.

File-transfers, thumbnail and preview rendering, user authentication, files storage and back-up, email server, and so on, are connected seamlessly through RESTful web APIs to create the most efficient user experience within web-based constraints.

Headless DAM

The notion of the “Headless DAM” has been evolving since the origins of DAM in the mid 1980s. There have been hundreds of DAM systems brought to market with more or less the same architecture. More modern DAM systems have embraced a component architecture. Most of the legacy system DAM companies have been rolled up by the investment community to create larger entities driving stronger multiples.

Chopping the head off a legacy DAM system can range from complicated to pure folly. This is where lipstick and make-up can do wonders. Unfortunately, the application of RESTful web APIs to a legacy architecture has its challenges, the biggest being degradation of performance. Almost as big a challenge is the attempt by modern DAM architectures to add value by implementing workflow wizards.

Wizards are special purpose applications that can be referred to as one-trick-ponies, and are designed for a particular workflow concept. In DAM that process is called “Approval”. Media Asset Management DAM systems adopted media approval processes. PIM optimized systems adopted product approval workflow concepts with added emphasis on product metadata and compliance. Alas, the fundamental architectural shortfall of the legacy DAM is the constrained way workflows are considered.

The headless DAM is truly independent regarding workflow and other services. The DAM component becomes a service to the enterprise business processes. The headless DAM becomes a very lightweight service requiring fewer resources. Headless DAMs are accessed through a set of RESTful web APIs that can be called by any other web service using a secure token. For example, in a headless DAM architecture, user authentication is an independent component configured to support operations, process, and task management with or without SSO. The net result is a much tighter architecture devoid of clumsy “workarounds” such as stored procedures.

Headless Architecture

The headless DAM is architected using RESTful Web APIs expressed as JSON files to connect the DAM service to the platform. Other APIs link the DAM service to projects and jobs running workflows expressed using the ISO standards for defining processes, BPMN and “XPDL”, (extensible process definition language). Every BPM system has a workflow engine at its core. BPM systems often also have some crude form of a DAM. The workflow engine is the central task manager. The Headless DAM is configured as a service. File transfers are a separate service, as is the rendering of derivative or proxy assets such as thumbnail and preview images, along with the file manager service for securing access to assets in repositories linked to projects, jobs, and user managed repositories.

API-First provides software developers with greater agility to service and support the users. However, the web-service layer of the computing stack is the least efficient level of the stack. XML, and JavaScript development is relatively slow work compared with more efficient lower-level coding methods and protocols.

In summary, API-First is a philosophically sound approach to architecture design with a component-based architecture that provides for interchangeable and extensible features.  Organisations should consider how components connect, identify the services that build the experience, and then transition to JSON APIs appropriately and in concert with the business. VDXP (virtual digital experience platform) is the emerging trend supporting business communities and offers core services in a plug and play architecture where the platform is optimized to support interchangeable component services through RESTful web service APIs.  The logical core for a VDXP is a programmable workflow engine that users can optimize through custom workflow models with user-defined actions to trigger task assignments, send notifications, and update product and service data.

The components in a headless DAM connect to the platform through custom configurations optimized to serve the current and future needs of the organization. The combination of a web-services architecture and less complicated purpose-built components is a scalable architecture that is built to last as companies embrace the benefits of automation through AI with less disruption.

About Murray Oles

Murray Oles is President of Chalex  – a company specialising in enterprise process and information management solutions.  Their product line includes SmartFlo and ArtFlo – a multi-tenant SaaS workflow and process management platform with an accompanying DAM.

You can connect with Murray via his LinkedIn profile, along with his colleague Garry Bollinger.

Share this Article: