Digital Asset Management Systems: An Open Specification
Today we have released the DAM News Open Specification for a Digital Asset Management System that describes in some detail the features and capabilities that a reference DAM might be expected to provide. The document is grouped by 20 functional areas (at the time of writing) and is further sub-divided into basic, intermediate and advanced categories. I have worked on the initial version of the specification in close collaboration with Henrik de Gyor who operates Another DAM Podcast (which I know many DAM News readers also tune into).
Why have we done this? At present, there is very little to define what a DAM system should provide and not many ways of benchmarking different systems. The (now defunct) DAM Foundation released their 10 core characteristics of DAM specification six years ago in 2014, but this has not been updated in the intervening period and it lacks a few elements which (I would argue) have become essential such as APIs, reporting or audit trails. I can see why there was some reluctance to include these as then ’10 core’ would need to become ’13 core’ and the numbers would keep going up.
As we looked into the work that was done, it became apparent that some of the latter sections were somewhat vague with descriptions like ‘administrative capabilities’. I understand the rationale behind the choices of headings and descriptions, but it points towards the format being too rigid to be sustainable over an extended period. To make it clear, I think the 10-core was a great first attempt at formalising a description of what a DAM is and what it should do. To that end, it does answer the majority of the key requirements that DAM users may have. Being static, however, it as risk of being not responsive enough to adapt to either updates and changes in the nature of the software developed by vendors nor issues like simple omissions and oversights (which I acknowledge is very easy to do with a complex field like DAM).
To address these limitations, we decided to use a structured functional specification narrative model instead. The document can be reviewed by anyone and edited by those who register an account (which is free and open to all). We have devised an initial list of functional areas, but I fully expect (and, indeed, hope) that others will contribute their own changes and extensions. We are inviting participation from across the DAM community, including end-users, vendors and consultants. In this specific instance, vendors have a particularly useful role to play as they track end-user requirements far more actively than many other stakeholders since they are so integral to the success of their businesses.
I should also add a few caveats. Simply because one system ‘checks all the boxes’ does not mean it is superior to another which may superficially present as having less functionality. There are softer considerations such as user interfaces or user experience which cannot be covered in a format like this but which may well be of equivalent or greater importance. Further, there is the more fundamental issue that the specification will never entirely represent all the functionality which is offered by every system out there.
Lastly, this depends entirely on participation from the community. In the past when we have established other similar projects, I have seen comments along the lines of ‘x is missing’ or ‘y should be different’ etc. If you don’t contribute and/or you try to use this as a cheap form of self-promotion, the results will probably reflect that. You get the government you deserve, as the political adage goes.
The DAM Open Specification is here: https://digitalassetmanagementnews.org/open-specification/spec/
Share this Article: