Practical Interoperability Challenges – Why Your Digital Assets Are Still In Their DAM Silos

Loraine Lawson, on IT Business Edge, wrote an article last month: Five Reasons Why Cloud Integration Is So Gosh-Darn Hard.  She references another article: The Cloud Experience Drives New Data Management Directions by Julie Hunt.  Julie’s article discusses the various reasons why users of Cloud or SaaS products find that integrating them with each other is more complicated than they expected it to be.  Many (if not all) of the points might be equally applied to on-premise software also, the hosting venue seems to make little difference:

• Switching SaaS vendors frequently increases the speed with which organisations need to adapt to new software services but still meet enterprise-level practices and security.
• A ‘massive explosion’ of APIs built on proprietary platforms and the complexity of managing all of them.
• APIs are not the ‘plug and play’ tool and there is a constant on-going flux in connections. See also the APIs Are Not Lego article by Matt Mullen.
• APIs themselves frequently change and adapt, so organisations are in the API maintenance business, whether they want to be or not.
• If you manage to handle the integration requirement, then you still face data quality and identity resolution issues.

Loraine describes some possible starting points for a strategy to manage the complexity introduced by having a multiplicity of APIs:

“So what’s the solution? You may not like it, but Hunt’s takeaway seems to be that whether it’s in the cloud or on-premise, data is data and it needs to be managed accordingly.That means, yes, integration is going to be a headache, particularly if you treat it as a one-off project, rather than developing a strategic approach that addresses all aspects of data management, including data quality and governance.” [Read More]

In my opinion, this is currently the biggest stumbling block to interoperability and as is clear from the above articles, it is by no means unique to DAM.

Earlier this week we analysed Tim Strehl’s blog post about his proposed method of using Linked Data concepts to create a global image search.  One of Tim’s legitimate criticisms of using current APIs is exactly the issue described in the articles above – there are loads of them.  From a practical perspective, developers who will need to implement the cogs and gears that will allow integration to become a practical reality will have to work with numerous APIs, read lots of associated documentation and deal with multiple possible points of failure.  This is all going to cost vendors or consultants time and money which they will almost inevitably need to pass on to their clients and customers.  At that point, there becomes a very real cost attached to maintaining DAM silos and it becomes a value judgement about whether the hassle and expense of getting assets out of them really does justify the expense involved.

Many organisations who are implementing DAM have barely got started with their digital media libraries.  Most are still just trying to get their assets ingested with some semblance of metadata applied.  Having surmounted that not inconsiderable challenge, the follow-up, to get all the DAM systems that were bought across the business by multiple departments and purchasing authorities working together, along with all their other enterprise applications, is likely to be one that gets pushed further on to the back-burner for as long as possible.  Organisations do not have bottomless pits of money, so integration projects will only get priority if there are very strong arguments for them that can be adequately explained to senior management.

From the wider DAM industry perspective, at some point, there will need to be a drawing together of these disparate API strands so everyone is using a common protocol – very much like the DAM Value Chain we have discussed recently.  While universally agreed standards might help, a further question is to what extent they will be adhered to, especially if the API lacks support for some item of functionality that a given vendor thinks gives them an edge or they choose to cherry pick how much they will implement anyway for the previously discussed cost reasons.

As we described in the original DAM Value Chain article, the standards might be more likely to be something imposed on the market through commercial natural selection rather than a grand convention with all the associated bickering and in-fighting that usually accompanies those exercises.

Share this Article: