In this article I am going to assess various approaches to interoperability and examine some building blocks which if combined could offer a universal, scalable and relatively easy to implement framework.
Why Current Interoperability Methods Are Unsatisfactory
Most DAM vendors now offer an API that enables third party access to their data. Using them for actual integration tasks, however, is a harder task than it appears — especially if there are multiple DAM systems involved.
Proprietary DAM APIs
Many DAM APIs use web protocols like REST or SOAP but each still has its own conventions, methods and terminology. Although developers can re-use their knowledge to work with them, the specifics generally require amendments for each different product and they often find they have to code separate libraries. The work involved to maintain interoperability with these multiple asset sources using their APIs is becoming an excessively time consuming (and sometimes confusing) undertaking.
CMIS And DAM Systems
There are some standards emerging for exchanging data across ECM systems. One example is CMIS (Content Management Interoperability Services). CMIS is comprehensive and provides a generic layer of abstraction to allow third party applications to access data within other CMIS-compliant systems in a consistent fashion.
There is a school of thought that claims that CMIS-compliant DAM systems might one day be the only interoperability game in town and all DAM vendors will eventually need to support it. I do not know if that prediction is accurate, but I suspect that even if it is, it might take some time to occur. I would agree that CMIS offers many (if not all) the interoperability features that DAM systems could make use of, but the adoption of CMIS in DAM faces some significant challenges.
The DAM market is highly fragmented and is composed of hundreds of vendors. There is a good reason for this. Digital Asset Management describes an ever widening scope of user requirements. Lots of people from all kinds of backgrounds think they are uniquely placed to understand and implement DAM. Each of these groups develop their own unique DAM applications based on their widely differing understanding of what DAM means. The development teams responsible are similarly varied and range from lone bedroom coders right up to those with multiple global offices and hundreds of staff.
Some DAM vendors have already committed the investment required to providing this in their solutions, but most have not and probably have no immediate plans to either. It could be argued that you should only deal with DAM vendors who offer CMIS compliant applications, but there are further standards out there. oData (Open Data Protocol) is supported by Microsoft (they also back CMIS too). The Open Archives Initiative Protocol for Metadata Harvesting (OA-IPMH) is another standard. There are several others I have not mentioned.
It is a somewhat easier proposition for larger vendors to hedge their bets across multiple standards and then just drop the one(s) that don't gain traction. However, those DAM vendors with more limited budgets and resources have to adopt a "wait and see" approach before they press ahead with complex and expensive implementation work only to find it was a waste of time and effort. They will still be acquiring new clients and extending their products in the meantime (and building out their own custom APIs too).
The practical reality is that when integration tasks come up, you usually don't get any opportunity to decide what you need to interoperate with, only that someone, somehow has to make it all happen — and this is where we came in with proprietary APIs.
Simpler DAM Interoperability Solutions
I should stress I am not criticizing any of the standards like CMIS, but they are still a functional tier above what many DAM vendors are currently willing or able to offer. There is a pressing need to find more immediate interoperability solutions that are more likely to be implemented by many vendors. That requires simpler techniques that can be assembled in a more bottom-up fashion.
There are potential answers to this problem emerging. They originate from different sources, but some synthesis between them might provide the basis for an interoperability framework. There are four elements:
Continue reading this article:
Source : cmswire[dot]com
No comments:
Post a Comment