Is Content Management 2.0 the Death of DAM?

Having worked in Digital Asset Management since 1998, David Diamond has seen a number of changes within the industry. In his books, DAM Survival Guide and Metadata for Content Management, Diamond predicts a changing landscape for the industry.

A group of authors, which included Diamond, years ago wrote about the stagnation of innovation in the DAM industry. Since then, there have been countless articles on the subject.

So, is the Picturepark Content Platform the change so many have envisioned all these years?

Is Digital Asset Management dead?

I guess that depends on your perspective. Customer relationship management can be considered dead, too, if you manage customers via rolodex cards. The concept of managing digital assets is far from dead because digital assets are content, and no one today would argue that content management isn’t necessary.

But, yes, the ways in which digital assets are managed today needs to die so the industry can move forward. Today’s DAM systems are still based on the DAM 1.0 paradigm introduced by MediaBeacon and Cumulus back in the early 1990s, wherein a DAM is a place that files can be stored, tagged and found.

But the idea of “going to the DAM” to find things is analogous to having to go to a well in the yard to get water. The DAM can’t be a place to which we must go to; it must be a thing that makes content available to us no matter where we are. It needs to be content plumbing, not just a content store.

DAM also needs to let go of the concept that all content is file-based and should, therefore, be managed as files. The vast majority of content that is produced across the world each day is shared via links, not via file uploads and downloads. Even Google search supports this: How often do you search Google to download a file?

Another big change is that the line between creating content, managing content and using content isn’t as distinct as it once was. When we create a Facebook post, for example, we create the content by typing the post, manage the content by adding tags or linking images, and distribute the content by choosing those with whom the post will be shared. Google Docs is another example where we create, manage and share content from within the same place.

When one thinks of content in this sense, it’s clear that today’s digital asset management systems are not up to the task. They’re fine for what they do, but the concern is that what they do won’t be important in the coming years.

In a sense, DAMs are like fax machines: While DAM vendors argue about whose fax is the best, the world has moved on from the practice of faxing.

Was this the goal for the Picturepark Content Platform?

Basically, yes. Instead of creating a new DAM or brand management tool or marketing resource management tool, or anything else along those lines, we set out to simply build a system that worked well for the creation, management and routing of content in its purest form. What customers do with that content is up to them. We just aimed to build a system that could do what it was asked to do, without getting in the way.

Explain what you mean by content routing

Bringing content to the point of consumption was an early goal for the Content Platform. But this lead to the realization that we also had to collect content at the point of creation, and we then needed to route it wherever it needed to go. So, yes, while there is an interface in the Content Platform that you can use to work with content via desktop or mobile, our assumption is that this isn’t the future of working with content.

Taking that plumbing analogy further, we don’t work with water, we consume water. We bathe with it, cook with it, clean with it, garden with it, use it to put out fires—these are very diverse use cases for a single thing.

Content is the same now. We create a single piece of content, thinking, for example, that it’s a blog post. But then we realize there are so many other things we can do with that same content. Today, we usually copy and paste to move content across channels, but this makes no sense.

Mobile devices seem to support this routing concept

That’s true. Think about all the things you can do with a photo that you take on your phone. You can share it to social media, attach it to email, make it a profile image and countless other things. Never once are you asked to make a copy of that photo, or move it into a new location so that it becomes accessible to other applications.

Mobile content management means rethinking use cases, not just shrinking interfaces.

Mobile operating systems were designed to abstract the creation of content from the multiple purposes we find for that content. DAMs were not designed with this in mind.

Is this the basis of the “headless” content management of the Content Platform?

In part, yes. Headless content management basically refers to keeping core content separate from its intended use, emphasizing an API-based exchange. For example, when you write a blog post in WordPress, that content is directly available only to the part of WordPress that renders the website. But what do you do if you want to include all or some of that content in an email, or push it to your mobile apps? Copy and paste.

In a headless system, all publishing channels access the same content. The website, the mobile apps—everything. When you think about it, it’s a fantastic concept that’s long overdue.

We’re used to creating content that is earmarked for certain purposes because our creation apps define the output. Create a document in Word and you can print it; create a blog post in WordPress and you can publish it to the website, create a message in Gmail and you can email it.

Imagine how the volume of content on Facebook would diminish if each post had to first be authored in Microsoft Word and saved to disc before it could be uploaded to Facebook.

Social media tools like Hootsuite and Buffer demonstrate the need to publish a single update to more than one social media channel. But even that isn’t enough. Content shouldn’t be confused with, or surgically attached to, any output. A Facebook post is not just a Facebook post—it’s content that has been posted to Facebook. That same content might be valuable when used across other channels too.

The Picturepark Content Platform paradigm assumes you’ll want to create content in one place and use it wherever you like. Once people see the value in working like this, I imagine the concept of “locked in” content creation will start to feel pretty antiquated.

Can the Picturepark Content Platform be used to create any type of content?

No, the Content Platform was designed to enable users to create what we have dubbed “strictly structured” content. This describes content that has a known structure that doesn’t vary between each instance of content.

The value of this is that the creation of the content can be guided, so it is easier and faster for users to create, and the consumption of that content via API is easier and more reliable because the structure is known by the calling system.

Does this limit creative potential for content creation?

Yes, and that is the point. When you’re assembling a list of addresses or job postings, how creative do you want to get with regard to the structure of each? Does your organization think the format of each press release should be different than the format of previous releases?

In fact, when we see variance from structure-based content like this, we consider it erroneous or amateurish.

We’re not talking about replacing Photoshop or Microsoft Word; we’re talking about combining content into business-suitable formats that are easier for mortals to assemble, and for machines to digest and publish across diverse channels with greater reliability.

What is the benefit to creating such content in Picturepark?

Simplicity and consistency were the first values I saw as a marketer.

For example, a listing of featured customers is pretty simple: You have names, regions, markets, taglines and logos—nothing too complicated. Many organizations have data-based listings like these on their websites.

But what happens when a tagline needs to be updated, or a logo changes?

In most cases, an account manager would be asked by the customer to make the change. The account manager would then make a request to someone in Marketing. That person would, in turn, put it on the todo list of one of the website editors. In time, that editor would go onto the customer listing page and make the update.

And then the customer would call and ask why the old logo is still on the case study page.

By using the Content Platform as a master data source for content like this, there is only one location you need to worry about. Every connected system, including your website, can be updated automatically. And, if that account manager had been permitted to make the change in Picturepark, it could have been done immediately, involving only a single person.

How is the content actually routed to a website or mobile app?

There are a few options, which we refer to collectively as microsites.

The quickest option is via embed codes that you can copy and paste within a page or app to display the content in a template-based format, like a Twitter card, or something similar. Embed codes can display single pieces of content, or static or dynamic collections. They’re created in the same way you’d create an email share, so it’s pretty straightforward.

You can also access content via the API, which understandably provides more possibilities with regard to formatting and interaction.

What’s really cool about this is that the same microsites can be placed onto multiple external websites. So, for example, you could manage listings for your products, and then make that content available to partners via embed codes they use on their websites.

The benefit here is that you control what’s said about each product, and you manage the additions, updates and deletions—all from a single location. This is good for you because you know what’s being said about your products is true, accurate and complete. But it’s also good for partners because they know they’re providing current information from their websites or mobile apps or whatever, and they don’t ever need to think about it.

Isn’t this Product Information Management (PIM)?

There’s no denying that a company that makes thousands of products for which it publishes product data in many languages will want to use a PIM that’s designed for that purpose. Just the workflow aspect alone of managing datasets of that magnitude would make the vast feature sets of PIM systems worthwhile in that case.

But there are many organizations that currently do product information management in spreadsheets or other such systems because they don’t produce that many products, and PIMs are complex and can be extremely expensive to implement.

Likewise for master data management (MDM): Large enterprises might use SAP or Oracle to manage master data, but if all the master data you need to manage are office locations, partner network listings, employee profiles or job descriptions, those systems are too much.

Whether you call it product information or data, we see it as strictly structured content. Even if you have no traditional digital assets to manage, the Content Platform can be used for the modeling and management of this type of content so that you have a single master source that can publish to any channel you need.

Can the Content Platform be used only as a DAM?

Yes, if you just want to think of and use the Content Platform as a next-generation DAM, you can. But you won’t think that way for long. DAM might not be dead, but it’s damned boring by comparison to what you can do with the Content Platform. And any organization that has a need for digital asset management also has a need for master data management, even if they don’t yet realize it.

Other interviews in this series:

• Picturepark Director of Engineering, Urs Brogle, speaks about the technology choices made for the Content Platform, and the challenges his team faced during development. Read that interview »
• Picturepark Technology Program Manager, Stefan Seidl, discusses changes to the Picturepark API, and what new opportunities are available through the “API-first” approach. Read that interview »
• Picturepark Product Manager, Olivia Schütt, explains how the Content Platform came to be. Read that interview »

Read more about the Picturepark Content Platform »