Why Your DAM Needs Purpose And The Reason It Still Lacks It Now
Earlier this week, CMSWire published an article by David Diamond, author of The DAM Survival Guide and Marketing Director at Picturepark, called: Why Images Don’t Belong in Your DAM. The title isn’t really about not storing images in DAM or anywhere else, it’s a wider philosophical discussion about how DAM solutions (and to an extent, their users) approach the metadata subject. The essence of David’s item is that the purpose of a given asset is of far greater value than a generic classification, like what type of file it is:
“When we search, we don’t search first by file format, we search by content. For example, when searching for screenshots for a new product release, we think screenshots not images. Or when we need a copy of last year’s annual report, we think in terms of report attributes — the year, the business unit or maybe even the title “annual report.” If we’ve exhausted all search options to the point where we have to start browsing some “PDF” folder to find the report, something has gone horribly wrong in the DAM. Depending on our professions, we use different mental tags to describe what we want. Marketers think about collateral and advertising; salespeople think about pipelines and reports; and technical writers think about documentation and release notes.” [Read More]
This is another good article from David and I cannot argue with any of the points he raises. His discussion highlights a key area of differentiation across the DAM industry in terms of understanding of the significance of metadata and why it is so critical. There seems to be two opposing perspectives: those who view metadata in context of the asset itself and want to push their DAM implementations towards purpose-oriented models and those who view it as being less important than some of the other characteristics of DAM solutions (e.g. storage, transcoding etc). The latter tend to be more widely represented by technically inclined stakeholders in DAM. Despite being from a technology/software background myself, I would want to align myself with the former camp because their case is a superior one. The role of metadata is critical to DAM, because without it, you don’t have assets, just sacks of files – and they only get called ‘files’ because someone once decided to come up with a generic metadata classification system based loosely on metaphors from the prevailing paper-based storage technology prevalent at the time.
A lot of the reasons why this has occurred are due to the nature of software engineering and the whole industrialisation concept which technology is based upon. If you are developing mechanised devices, like software, you are required to take a reductionist and abstract perspective on real-world problems so you can code programs which will fit a multitude of scenarios that your users will come up with. The more of these your application can handle, the higher the likelihood that more people will be interested in it. By contrast, the users of software, normally have a tangible requirement that most definitely is not abstract. The fact that the application in question might handle more than one task is of lower value to them than whether it will handle their specific one, right now. There is a trade-off, or conflict, between the interests of the suppliers (developers, vendors, whatever you prefer to call them) and the users. Ultimately, the users are paying, so they will win out, but “in the long-term, we’re all dead” (to borrow the famous Keynes quote). In the here and now, as a user you won’t get everything you want and compromises will have to be made.
In the context of DAM, how this manifests itself is that many (but not all) DAM applications developers need you to use generic classification schemas, like ‘images’, ‘document’ or ‘folder’ etc because it makes it easier for them to implement something that can be applied to the problems of more than a single user. Most end users have got used to the idea that they will have to adapt their working practices to suit the abstract nature of the products. Irrespective of whether you buy or sell DAM solutions, how many times have you heard that euphemistic phrase ‘manage user’s expectations’? In reality, this just means telling people they won’t get what they want and then ‘negotiating’ (or arguing) where, exactly, the line in the sand will be drawn. The net effect of all this has been to influence user behaviour, so some people can’t think about DAM now unless there are groups of icons that look like the same folders they are used to on their network file server. Exactly as David says, this is a stage removed from what DAM user’s real intentions are and ultimately it has to become untenable for DAM systems to continue to shoe-horn their users into unsuitable abstract metaphors for the convenience of the software guys. I will acknowledge this will be a multi-phase process (‘phase 2’ being another great enterprise software euphemism) but it will happen because those who understand the force of momentum sooner than their peers will acquire more business as a result.
Recently, on LinkedIn and various other on-line discussion venues, I have read posts from people who to down-play the value of metadata, or alternatively that this is some kind of candidate for mass automation where it can be left to the software to do the thinking for you. They are both wrong. In DAM, metadata is what adds value to raw binary material to convert it into assets, hence why our subject is called “Digital Asset Management”. For DAM metadata to start getting more useful and relevant, it needs to be based on purpose (i.e. what you will use the asset for) rather than some abstract notion that suits the needs of the people selling you either the DAM solution or the implementation strategy to go with it.
Share this Article: