Transforming DAM From A Product To Service-Oriented Delivery Model

David Diamond, author of the DAM Survival Guide and marketing director of Picturepark, has contributed an article for CMSWire: Reinventing Digital Asset Management.  He covers a number of the themes which we have discussed on DAM News for the past few years (and David is gracious enough to give us a brief mention too).  The essence of the item is that rather than DAM being an application with its own identity which you go to as a separate digital venue, instead digital assets are delivered to you at the point you need them.  He uses the metaphor of water and faucets (or ‘taps’ as they are more commonly referred to in the UK) versus having to go and fetch water from a well:

“We want digital asset access, not from some random website location, but from within our apps and anywhere else we happen to be — Google plus, a Disqus comments thread, Facebook, Twitter, etc. We don’t want to go to a DAM well to get what we need, and we certainly don’t want to have to learn a bunch of UIs that vary with each consumption point.” [Read More]

We usually try and find something to take issue with in most articles we review, but apart from the comparison with MailChimp, I have to agree with all of this.  Even with that example, in the latest edition, they appear to have sacked that irritating cartoon chimp character who regularly interjected with various pearls of wisdom like an impertinent version of the Word 97 paperclip, so perhaps David has more of a point than I have given him credit for.

David goes through a few examples of the various current approaches and describes what is wrong with them, from DAM vendors attempts to apply ‘glide and slide’ style embellishments to make their apps look more appealing to users through to the recent trend for marketing technology suites that have expanded the scope and scale of what is provided, but without making any one element that much better (with particular reference to Adobe).  His point that DAM is about more than marketing is also a good one.

A lot of the issues described in this article are symbiotic ones where the responsibility is shared by both DAM system providers and their users reacting to each other in ways that are not necessarily advantageous to either.  When users come to the realisation that they need to be able to find their ever-growing stocks of digital media more easily, they ask someone who they believe to be knowledgeable about technology in general.  This person is usually either an IT consultant or their in-house IT manager.  Most generalist IT personnel have heard of Digital Asset Management now, especially as it relates to images and video so they tell their users to get a DAM system.  As seasoned DAM pros know, DAM isn’t a ‘thing’, it is a process or management strategy.  While there is software available which can help you realise your Digital Asset Management objectives, the tail doesn’t wag the dog and you have to know what you want to do with it first for it to be as useful as it should be.

People, however, don’t often consciously buy ideas.  They like to think in terms of products.  Buying a software system confers an illusion of commitment to doing something about the problem, especially if talks are opened with prospective vendors, by contrast, strategy and planning implies having to give up more of everyone’s precious time and taking some ownership of (and therefore responsibility for) the problem.  At some stage into the third or fourth demo, someone works out that lining up yet another WebEx session and conference call with the next people chosen at random by Google’s lucky dip of possible options might not be the most effective use of everyone’s time.  At this point, the decision is made to try to specify the requirements a bit more.  Everyone gets sent an email asking them to describe what they want and they all send it back to someone else who appends the suggestions together into a big document with numerous repeating requests that are slightly rephrased each time.  The requirements are based on a hybrid of what they have already seen, what someone told them that DAM systems should do and a sprinkling of leftfield unrelated requests that they hope can get bundled into “whatever this DAM thing is all about”.

The users think in terms of products, because that is easier for them to contextualise and gives a false sense of hope that by purchasing something, it will solve all (or at least most) of their digital asset-related problems.  When the vendors deliver the aforementioned demos, they get asked if they support feature X,Y or Z.  If not, there are usually fear-induced long pauses followed by either lying, disingenuous re-interpretation of the question to suit the vendor’s current capabilities (see previous point) or an assurance that ‘it will be available in the next version’ (see first point).  When vendor sales and marketing people convene to discuss current progress, lack of features (along with price) is a convenient way to address the issue without really tackling it and explain away why some prospect went elsewhere.  The vendor development teams then get issued with instructions to ensure that the missing feature is provided and they go off and pour over the websites and datasheets of the competitor who they think they lost out too in order to replicate what they thought cost them the business.  The reality, of course, can be far more random and perverse than anything that can get fixed with software engineering alone and meanwhile the successful vendor are now finding a whole new series of issues that neither them nor the end users have even thought about before.

The scenario is analogous to two people, one deaf, the other blind, both of whom are trying to collaboratively complete some complex task.  Both have the required faculties, but not together and neither are confident enough to admit to the other about what there limitations are, or to call in other people to help them out.  This is the environment in which the DAM software industry currently operates and why it is so structurally inefficient, or just ‘broken’ (if you prefer a simpler description).

With Digital Asset Management, the clue is in the title, it should be about the assets (i.e. binary data + metadata).  They are the real stars of the show.  The system is only the container that provides access to them, it should be as transparent and unobtrusive as possible.  One of the major reasons why DAM solutions are currently monolithic systems that try to be all things to all people is the commercial and logistical complexity of breaking them down now.  So much time and money has been piled into developing these software Towers of Babel that replacing them with modular components that can be freely exchanged will be an inordinate amount of effort and one there is currently little motivation to engage with.

As I talked about a week or two ago, some of the larger players are trying to own the digital asset supply chain.  To them, that means controlling every interaction point with the user.  To borrow David’s metaphor, they want to sell you a bus ticket to get to their own well and a bucket with their logo on it when you get there, rather than simply pipe the water to your house.  In that article, I suggested that the elephants might start breaking down the walls to the room and the sheer scale might make it difficult to compete.  However, like most empires, having achieved world domination and crushed or assimilated your foes, you then have to perpetually maintain your pre-eminent position.  That presents the opportunity for competitors with more efficient solutions to specific problems to establish their own rebel outposts and to form mutually beneficial alliances with each other (even if perhaps only temporarily).  In software terms, this will be the rise of the best of breed DAM solution.  There will be a period where everyone attempts to build the biggest and most comprehensive solution.  Users will begin to understand the problems they face more clearly than they do now and will selectively replace what they do not like with a superior alternative, but they will want to pick and choose exactly how they do it and who with.

I do subscribe to the theory that nothing in the world is inevitable, but it seems very difficult to argue against David’s prediction, since it offers the most flexible way to solve Digital Asset Management problems and it follows a model that most other industries (software and otherwise) have generally repeated throughout history.  The more interesting discussion point is how long we will go through this current ‘aggregation’ phase and whether (when we emerge from the other side) if the term ‘Digital Asset Management’ will have become damaged goods (in branding terms) such that another description has to be invented for it instead.

Share this Article: