Despite 2013 being generally acknowledged as the time when both DAM users and software providers saw the need for improved interoperability, very little has happened towards making that goal become a reality. The DAM industry is guilty of self-obsessed and narcissistic behavior or (at best) an apathetic and fatalistic attitude that assumes interoperability is someone else's problem which might never get solved anyway. System developers are more interested in telling you how brilliant their products are; consultants and analysts highlight the issue, but do not offer any solutions.
Meanwhile, the ongoing DAM interoperability crisis smoulders away and users whose assets are sourced from another system (whether another DAM or a different class of enterprise application entirely) continue to grapple with complex and expensive custom integration projects that try to fill a void which should be occupied by a definitive industry-wide standard.
Last year I introduced what myself and my co-contributors at DAM News refer to as the Digital Asset Management Value Chain, which is a conceptual model for more efficiently delivering integrated DAM services using a best of breed approach. I followed that post with a discussion about the building blocks of DAM interoperability, how digital assets might become more interchangeable between different systems and what tools and techniques might enable that to happen. In that article, I analyzed some existing ECM integration protocols (including CMIS) and also considered the issues DAM developers might face if they wanted to apply them.
I was far from being the only commentator to recognize the problem. A number of other authors from a variety of different backgrounds wrote articles that all reached similar conclusions. The heightened level of interest in this subject prompted the standards body, OASIS (Organization for the Advancement of Structured Information Standards) to convene two conference calls to discuss how existing interoperability standards like CMIS (Content Management Interoperability Services) could be adapted for Digital Asset Management.
A technical committee was initiated and a draft charter written which is now pending formal approval, providing a sufficient number of co-proposers can be found. In this article, I intend to briefly explain the purpose of CMIS4DAM, why anyone with an interest in DAM should be aware of it and what you can do to help see it progress.
What Is CMIS?
CMIS was approved as a standard in 2010 and was initially of primary concern to the ECM market. It offers a wide-ranging protocol that enables not only data exchange between applications but also the possibility for one system to use the facilities of another in a "black box" fashion.
Most major ECM vendors have accepted it and now provide connectors for their own applications. Some open source components have been produced that can be used by third party developers to provide CMIS-compliant interoperability features.
CMIS employs some widely understood web-based protocols to provide a language-agnostic series of methods to support interoperability. The two key benefits are this abstract layer (which means one system does not need to know much about how the other is implemented) and also a specific focus on content management operations. The data model is content-oriented and uses core entities with descriptions like "documents" to emphasize that relationship. In addition to the core content management capabilities, a number of subsidiary protocols have been added to deal with specialist topics, for example, collaboration.
Why Does CMIS Need a Subsidiary Protocol Just for DAM?
While CMIS offers a potential model for enabling DAM interoperability, there are a number of limitations which prevent it from being as useful as it could be which I will describe below.
Some of the media-specific requirements that DAM solutions deal with are not properly addressed in CMIS. For example, generating proxy and derivative files (or renditions) is limited to just previews in CMIS, where in a typical DAM system, this function has a far more diverse range of uses that might yield media that is used for production purposes, for example, changing dimensions or color space on images, converting file formats and editing segments of audio files. Some DAM solutions have asset origination capabilities, for example allowing users to create branded print-ready artwork or emails. While a few ECM systems might offer those options, it is not regarded as a core feature and CMIS reflects that.
In addition to a wider scope of operations on digital asset binary data, the controls for them need to be more flexibly applied than is currently possible in the CMIS protocol, for example push and pull version controls as available in some video-oriented DAM solutions or timeline metadata cataloguing. These can be constructed in an ECM platform as composite CMIS operations, but they are not core features so there is potential for different interpretations to become incompatible with each other, despite using the same common control protocol.
There are a multitude of DAM and digital preservation metadata standards such as IPTC, PLUS and SPECTRUM (to name just a few). None of these are properly integrated with CMIS and there is no common method for transferring embedded metadata from CMIS-compliant repositories back and forward between digital asset binary data.
The ECM market is composed of a small number of larger vendors, but DAM is highly fragmented and has hundreds of operators ranging from solo bedroom coders up to those with multiple global offices and hundreds of staff. The horizontal and vertical segments that different participants are involved with is also diverse and covers many specialist niches, including marketing, video, images and culture/heritage, law enforcement, sports as well as more generic products that target enterprise users. The term "Digital Asset Management" struggles under the weight of numerous different interpretations of what it actually means.
While DAM market consolidation has been predicted for many years, it has yet to occur, probably because end user DAM requirements are no less diverse than the range of products on offer. Even larger DAM vendors usually choose some broader niche and then try to place their solutions within that context (e.g., digital marketing or CXM, etc.).
It should be clear from the above why DAM requires a range of further capabilities than possible with the core CMIS protocol alone. As well as functional differences, the market itself has special challenges which make achieving adoption demanding, yet even more important as a result. Many DAM vendors wouldn't have the resources available to implement CMIS in full in just one iteration. An incremental and scalable option based on core elements and more immediate priorities would be required. There are open source libraries like Apache Chemistry, but the implementation effort is still non-trivial and has to be weighed up against current customer requirements.
A goal of CMIS4DAM is to break CMIS down and make it more of scalable proposition for DAM system developers.
Relationship with Other DAM Standards
As well as CMIS4DAM, DAM Foundation has been working on a standard called the 10 Standards Badge. This aims to define what the core characteristics of a DAM solution should be, i.e. the features it needs to have to be worthy of the title. Some have pointed out that more is required on the interoperability aspect to facilitate the integration which needs to happen. An objective of CMIS4DAM is to provide the technical detail which a systems architect or software developer might use to translate such requirements into a more detailed blueprint to facilitate integration between DAM systems and other sources of digital assets.
What's the Current Status of CMIS4DAM?
Last year, OASIS started a listserv to discuss a draft technical charter. Based on feedback from those who contributed, the draft charter has now been written. This is still very high level and defines objectives and scope rather than more in-depth topics, but that will likely occur in the next stage. In order to progress, CMIS4DAM requires five co-proposers who must be members of OASIS (two of whom need to have corporate membership). Co-proposers will be included in the call for comments, but are not required to make a financial contribution or commit other technical resources.
A few people in the DAM industry have been in touch with myself and representatives of OASIS about supporting this initiative. Everyone in our industry is well aware that interoperability is essential for the long-term sustainability of DAM as a class of enterprise software in its own right. If this is a subject that is of interest to you, now is your opportunity to get involved and help shape its future direction.