DAM Confusion Or Irreparable Fragmentation?

Last week, CMSWire ran an article with the title DAM Confusion in the Marketplace by Elizabeth Keathley of Atlanta Metadata Authority and author of the book Digital Asset Management: Content Architectures, Project Management, and Creating Order out of Media Chaos.  This prompted a fair amount of interest, mainly because Elizabeth made an analysis of the DAM market based on the top 50 global brands, which appears to have proven a complex task, made all the more difficult by the data she had to work with.  Having read some of her other expertly researched articles (and book) I would have to conclude that if Elizabeth couldn’t make sense out of this then I doubt anyone else in DAM could either.

There are some points I’m not totally certain about – mainly with the initial paragraphs about SharePoint and ADAM, where Elizabeth states that Microsoft have conceded defeat over SharePoint becoming a DAM, specifically with reference to their use of ADAM for their own marketing communications purposes.  While there are a lot of third parties who want to promote SharePoint as a serviceable DAM platform, I’m not sure the chaps in Redmond really care that much about it as DAM is still not a big enough market for them to lose a lot of sleep over.  The greatest demand for trying to get SharePoint to act like a DAM seems (in my experience, at least) to originate from IT departments who are faced with the twin problem of a barrage of requests from users for a proper DAM solution and an already considerable sunk-cost into a SharePoint platform implementation which they need to extract more value from due to their own budget constraints.

The ADAM news is more from Microsoft’s own internal marketing people who have decided to use their platform rather than a general decision to back ADAM over and above SharePoint for DAM as a matter of general company policy.  I have no doubt they had a good look over SharePoint as a candidate and although they would have liked to use it, they probably reached the same conclusion that everyone else does: that it’s not really up to the job other than as a basic faux-DAM of the type which you can coax out of other generalist commodity ECM platforms like Box etc with a lot of effort and many functional compromises.  The next ‘must have’ item likely to have been on their DAM wishlist was that it must be built using Microsoft technology – which is a criteria that ADAM’s platform obviously meets.  There are quite a few DAM systems which can integrate with SharePoint (especially others built using MS technologies) and those implementations where a real DAM integrates with SharePoint (as a content repository) rather than to try to adapt it to pretend to be a real one tend to be more successful based on evidence I have seen.

In the other part of Elizabeth’s article, she analyses the 50 top brands and how their usage of DAM breaks down across different vendors.  The research for this is based on a spreadsheet that was worked on collectively a few years ago, but the sources were mainly provided by representatives of DAM vendors.  I believe that the original intention of the exercise was to provide some free technical detail on products that you could get from one place.  This means the data has the same flaws as our own DAM vendor directory, i.e. the data is provided by the subjects themselves, who are not impartial. Some vendors are honest and do not misrepresent their products or client lists, others far less so (and unfortunately they are in the majority unless challenged to prove their assertions).

Elizabeth points out other issues:

“This list only includes DAMs as they are used within brand/marketing/creative divisions. Sounds simple enough, but even that becomes unclear in cases where the creative team and the marketing division use separate DAMs. Corporations as large as these usually have several DAMs that exist as information silos, due to the specific needs of a department, international communication difficulties or office politics.  For example, both OpenText and Brand Wizard list Honda as a customer. It’s possible that these systems exist in divisions of the company that rarely communicate, and have duplicate information silos — it’s also possible that Honda has managed to build tunnels to pass information between the two very different systems so as to suit two very different internal audiences. Either way, this shows how difficult it is to judge DAM market share as it exists in top companies today. While the chart column listing vendors is labeled ‘DAM Vendor likely used for Brand Management or Creative Assets,’ it might as well continue ‘… in at least one location or instance.'” [Read More]

The multiple DAMs point is not an insignificant one.  I currently work with a client that has 47 different DAMs, a few of them could be merged together, but a good number fulfil radically different and essential functions which the organisation in question could not now do without.  The only real common factor is they hold ‘rich media’ .  This is one of the key problems for those who plan to use a single DAM solution for all of their needs, the actual range of use cases is highly diverse.  DAM is currently seen as a single classification, but in reality, it is the business function to which a DAM is applied which determines whether you need more than one system or not, rather than merely your need to store and search for images or video.

The one big opportunity which no one seems willing or able to exploit is to sub-contract or hire out some features or capabilities where one product excels such that another might make use of them rather than having to hastily build their own sub-optimal alternative from scratch.  A few people seem to be grasping this, but not enough and not very quickly. That alludes to the other point raised in the above quote about silos and integration.  It is not universally the case, but I would be fairly sure that if you have two different DAM systems in an enterprise, most of the time they won’t be integrated with each other, although there is an increased likelihood that they will send or receive data from some other third party non-DAM related application.

On the analysis in the article, the choice of 50 top brands makes some sense, but to an extent that frames the discussion around marketing oriented use cases.  It is true that this is the single biggest segment of the DAM market, but the rest combine together to make a very substantial minority covering a vast array of subject domains (and enough to support some vendors not in marketing DAM who you would not exactly call micro-businesses either).

Even within marketing, it is common to find multiple DAM systems in use – sometimes a few cubicles away from each other.  The other issue is user volumes.  For example, a vendor can claim a major corporation as a client, yet their product might be used by a handful of people, where another has had a six or seven figure budget spent on it and been rolled out globally to the entire workforce (some of whom then decide not to use it and go out and buy their own more focussed one instead).  To add yet more complexity into the mix, I am aware of more than a few marketing agencies, integrators and intermediaries who have global brands as clients and claim expertise in DAM, but in reality are using other people’s applications (free or open source ones, especially).  Who exactly ‘owns’ the client is hard to quantify, is it the people who wrote the original software, or those who applied it to the client’s problem (and assumed responsibility for implementing it)?  In commercial terms, it would be the latter, but without the core application they would not be able to participate in the market – there is a co-dependent relationship which neither party are willing to fully acknowledge.  In some cases, the intermediary actively wants to hide what they built their solution using and give the impression that they developed it in-house.  These are all clearly difficult issues to decipher if you want to identify DAM OEM vendor distribution across a range of end user organisations.

A point we have made on DAM News quite a few times before, is that if there are vendors who plan to corner the DAM market and achieve domination over everyone else, they are in-line to be disappointed and potentially waste a lot of capital trying, a point not lost on those who might have the money to mount a serious attempt to do it.  The reason is the deliverable or objective with DAM is very complex to define: the whole market is fragmented and based on varying degrees of interpretation which fluctuate wildly based on user’s expectations and circumstances.  There are some common themes which emerge, usually based on the core tasks such as search/metadata, storage and asset manipulation but discussions about DAM quickly turn to frameworks and general principles, where the users are eager to focus the debate and get attention directed towards their individual problems.  That is the case with all software, but with DAM there are not many tangible deliverables or outcomes to anchor the whole topic down (certainly that existed before you decided to implement a solution).  That diversity of interpretation is what is currently sustaining such as large number of independent DAM vendors and it is also partly why the mega-vendors find DAM an unattractive proposition, despite the obvious demand for what it promises to offer.

Operators like Amazon (and to extent Microsoft or Google) are willing to get involved in providing the tools to help others build solutions, but the prospect of supporting high-complexity applications that are still viewed as ‘niche’ (i.e. small budget) by board-level decision makers is an unappealing one they would prefer to buffer through channel partners rather than deal with themselves.  A month or so ago, one of the various people I follow on Twitter posted a Dilbert cartoon where there is a discussion about 400 features being excessive for an application.  It’s clear that Dilbert doesn’t work in the Digital Asset Management software industry as 400 features would probably be towards the ‘lite’ end of our market (and, yes, ‘easy to use’ has already been added to the list about 7-8 years ago, that’s a general requirement, not a USP for DAM apps these days).

There is, Adobe of course, but the view of many I speak to in the DAM profession is that they have hardly covered themselves in glory with AEM as an example of a credible DAM solution and relative to the previously mentioned examples of larger players, they are still relative minnows (the acronym for their suite also seems to  be crushingly apt with reference to their DAM component).

Elizabeth’s final point is “The DAM Marketplace is still anyone’s game.” and I suspect it will remain anyone’s for the duration of the time that people still use the term “Digital Asset Management”.  The DAM market struggles under the weight of user expectation about how it will solve all of their problems.  I don’t think that will be sustainable forever and some kind of fracturing seems hard to avoid.  If we plan to call all these things ‘Digital Asset Management Systems’, I would imagine that the list of vendors and brands will become more like a team sports fixture grid than a simple sequential list.

Share this Article: