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.
- Hey Cloudera & MapR: Open Data Platform is the Real Deal
- Don't Hold Your Breath: SharePoint Release Delayed
- Discussion Point: Why Do Intranets Fail?
- Does the Apple Watch Signal a Post-Browser World?
- 11 Ways to Ruin Your CMS Project Without Even Trying
- The Sticking Point with Social Collaboration Tools
- Is There a Future in Content Marketing?