When one compares the user experience of something like Mail Chimp to digital asset management software, it’s easy to see why people complain that DAM software can be cumbersome to use.

And while DAM vendors scramble to repaint their UIs and, in at least a few cases, turn their backs on their legacy apps in favor of flavor-of-the-month “DAM Lite” variants, it’s clear that DAM vendors might not really understand the problem. The issue isn’t that DAMs are ugly, the issue is that the very paradigm upon which we’ve built these systems has become obsolete and, therefore, cumbersome.

A Little Too Far Off the Beaten Track

No matter how pretty the UI, a DAM remains a place people must go to get what they need. We place digital assets in a repository that is almost certainly not where we are when we actually need those assets.

A quick visit to the DAM might seem reasonable but actually it’s not. Not long ago -- and in some parts of the world still -- if you wanted water, you had to visit a well. Today, we have faucets. Even better, we have faucets throughout our houses, each located where the need for water is expected most -- at the point of consumption. When we leave our houses, we also find faucets at work and virtually wherever else we go.

Imagine how different life would be if every time you left the house, you had to take with you the water you’d expect to use throughout the day for drinking, washing and flushing.

Through the advent of plumbing, we discovered that by delivering water to the point of consumption, we could change the world. Better yet, by ensuring that all faucets worked in pretty much the same way, they could be used without training. (Unless you’re an American in a European hotel room.)

This is the paradigm upon which the next generation of DAM must be built. 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.

But this is exactly what today’s DAMs have been bred to be. Rather than part of the infrastructure, DAMs are pieces of furniture. They sit above the core of what makes a business a business and they’re ultimately expendable. What we see going on now, as ever more vendors claim to have the most beautiful or user-friendly DAM system, is not a reinvention of that failing paradigm; we’re seeing DAM vendors reupholster DAM software to hide its Avocado Green and Harvest Gold origins.

The DAM News team’s Ralph Windsor has suggested that DAM vendors are running low on ideas or that we’ve perhaps slammed into the limits of what we know how to do. I say he’s correct, particularly on that second part. DAM evolution has stagnated because we’ve slammed into the limits of this asset-from-a-well paradigm. Unfortunately, no DAM vendor has stepped forward to introduce a true alternative, and that’s where Ralph is correct on his first point.

And I think we’re all starting to realize it.

Integration Salvation

There is evidence that DAM vendors understand what’s going on. The flurry of DAM integration announcements we’ve seen in the past few years suggests that vendors have discovered life outside the DAM ghetto. Vendors are plugging DAMs into everything, and then displaying those product logos on websites, like they’re the stuffed heads of game conquered bare-handed. (It’s like we've traded taxonomy for taxidermy.)

This is a step toward point-of-consumption asset access but there is still one problem: each DAM integration is different. In some cases, the differences are forced by API limitations, leaving integration developers with limited options. But I think that in most cases, the problem is simply that integration developers are lazy -- and this includes DAM vendors who create their own. Rather than see each integration as another road leading to the Rome called DAM, they think “press release” first and they think “user experience” … well, maybe in the 2.0 version. You know, if enough copies sell.

Consider how difficult your computer would be to use if the Open and Print dialogs behaved dramatically different across applications. We have had UX standardization here for so long that we no longer even notice it when we see it. And when we don't see it, we consider the program we’re using to be garbage.

Hiding the Ugly Step-Child

Then you have the vendors that have started to hide their DAM components behind the premise of larger marketing operations or user experience suites.

On the one end of these “integrated solutions,” you have work-in-progress apps; on the other end, you have distribution and analytics apps. Connecting everything is the unloved DAM that has been renamed into something so inconceivable that I assume no one even bothers to ask about it. I’m sorry Adobe -- I love you dearly -- but “Experience Manager” is such a confusing name for a DAM, that you should have just called it Fred.

It’s tough for me to devalue the concept of taking digital assets from the point of creation through distribution, all under the same product family. In fact, the idea sounds wonderful! But let’s face it: acquisition doesn’t equal integration. We’re going to need more than brochures before we agree to see the emperor’s clothes.

And Adobe isn’t the only company promising to deliver such a marketing utopia. We’ve seen ADAM and Celum headed in this direction too. In fact, it’s starting to seem like “DAM” is a dirty word, again. Even more concerning, weren’t we all just a few weeks ago talking about how we preferred a best-of-breed approach to business technology? Best-of-breed enables customers to choose which system components they prefer. It’s the same concept that enables you to save thousands by not having to buy BMW-branded tires just because you bought a BMW.

Instead, we are now seeing vendors buy up and package complete suites for us to consume, lock stock and barrel, as if a common logo was all that was missing.

However, these do-it-all suites do support my primary point: DAM needs to be plumbed into all points of consumption in order to fulfill its true potential. The problem, however, with this “marketing suite” approach we’re seeing today is twofold:

  1. All components come from a single vendor, even when those components were not developed by a single vendor.
  2. DAM isn’t just about marketing! Not all DAM customers need marketing analytics, connections to product information management systems or even social media integration. DAM became about marketing for some DAM vendors when they realized that marketing departments had more money than universities and museums.

A DAM that Stands Alone - Invisibly

The next true innovation in DAM needs to come from reinventing the DAM paradigm. Instead of a DAM being a piece of furniture, DAM must be the wiring, plumbing, gas or network connection upon which a software application or business process is built.

In fact, digital asset management needs to replace the OS file system entirely. Yes, that’s a tall order, but the Cloud offers us a perfect opportunity to make it happen.

As our workflows migrate toward working with file-less content, we’ll find the file system becomes as awkward to use as today’s DAMs. It won’t be long before Adobe has us developing content that is born in the Adobe Cloud, is edited within the Adobe Cloud and is shared from within the Adobe Cloud. Microsoft and Apple are doing the same. And Google has already been there for a while.

So it’s not surprising that the file system -- just like the DAMs modeled on the file system metaphor -- is starting to outlive its usefulness.

If you doubt this prediction, consider file naming conventions. A file name is nothing more than a metadata value that’s intended to remind users about a file’s content, and to enable the computer to differentiate between chunks of content. But the file name is often the least flexible metadata value we have -- DAM users certainly know this. When you have 100 files, file names can conveniently identify each; when you have 100 million files, file names are nothing but trouble.

Plus, by the time you've added scores of other metadata values to a digital asset, do you even need a file name anymore? Like fax numbers, we still bother with file names only because it’s expected of us. And, of course, because we need to respect the limitations of file systems if we ever need that content to leave the DAM.

The dilemma we face is that the only ready replacement paradigm we have for the file system is DAM. And DAM was modeled after the file system.

See the problem?