Rethinking Digital Asset Management

In 2015, longtime Picturepark employee Olivia Schütt became the Picturepark product manager. Schütt inherited a legacy application with a sizable installed user base, just at a time when the Digital Asset Management industry was taking a long-overdue hard look at itself. Analysts were reporting low user satisfaction ratings for DAM software, the industry hadn’t grown at the explosive rates predicted, and blog posts started pointing fingers at a lack of product innovation.

Schütt’s team set out to not only improve Picturepark and address customer requests, but to surpass industry expectations, and prepare the product for the next decade of digital asset management.

This process lasted one year before the team started over.

What happened during that first year of designing what was intended to be Picturepark 9?

Picturepark 8 was, and still is, a great application for digital asset management. But DAM is based on a file management paradigm that’s now older than most of our employees!

If all you need to do is manage files, Picturepark 8 and some other DAM systems work pretty well. But organizations want to manage more than files now. Social media posts, Google Docs, corporate messaging—these are all examples of content that you don’t want to have to save into a file just so it can be uploaded to a DAM. But companies need to manage this virtual content too, of which many are borne and live in web apps. They want tweet archives and central access to conversational sales content—not just price lists and presentations—but messaging. What do we say when a prospect asks X, Y or Z? Where does that content live?

And what about managing and making findable valuable content that you don’t possess? YouTube videos that are useful for training, or random website pages that could help your sales teams are examples. Or, imagine being able to manage your own metadata for images or videos you find in stock houses, like Getty or Shutterstock. Stock houses might use the tag “people talking” for some image that for you is “2017 customer event.” You don’t want to have to buy all this content in order to upload it to the DAM and keep tabs on it, but you don’t want to lose track of it either.

If you can keep track of all these contents, and add the metadata you need, you make them findable and valuable to your internal teams. It’s no longer just about files you can save, upload, download, etc.; files have gotten in the way in many cases.

And then you have compound content types, like the content on landing pages, or all the details about your products, or the contents of your press kits. In these examples, contents of different types, with and without files, newly created or reused, need to be managed. It’s something that is increasingly complex.

You can build these pages in a website content management system, like WordPress or Sitecore, but you can’t easily manage that raw and live content through the website CMS backend. People are forced to do exports from one system and then import that content into a format that worked on the website—it is a lot of work, and it isn’t easy to keep the website in sync with the master data systems.

Plus, even if you do try to build such a system, that’s only one system. But you probably need to reuse that content in other systems too. Do you want to have to build such complex connections between every system? Of course not.

So this was our first thought—that we need to stop caring where content lives, where it needs to go, or what format it is in. Picturepark needed to become a content routing hub that was easy to access for real applications, not just theoretical possibilities.

But this presented a new challenge, which was the relationships between all this content. A tweet might reference some product or event, and a landing page probably includes images and textual content that is stored in the system on its own.

So, along with not caring where the content is stored or comes from, we saw that it was even more important now for customers to be able to track the relationships between all this content. Not just what was used in which project, but in what context was it used?

We invented Adaptive Metadata back in 2012 because we saw that the static one-size-fits-all-assets metadata schemas used in traditional DAMs made no sense. What we couldn’t see back then was that this new paradigm would be perfect for what we needed to do next. You can think of semantic metadata as Adaptive Metadata 2.0.

Okay, with a clear idea of what we wanted to offer, we researched how we could add this to Picturepark 8. We tested everything in every combination we could think of.

The conclusion we came to was that there were two possibly negative outcomes of updating Picturepark 8 to do everything we wanted. Most concerning was that such significant changes could compromise the stability of Picturepark 8. We didn’t want to take that chance on a system that is in such widespread use for mission-critical applications. The second concern was that not all customers and prospects are ready yet for everything the Picturepark Content Platform will offer. So such a major update to Picturepark 8 could be disruptive.

Plus, with Picturepark 8 and pretty much every other established DAM system out there, the API was something added after the product was originally designed. Customers and partners want to do so much more with their systems today than they used to, and we know that the only way to make this all possible, performant and reliable was to build a system that was all about the API from the very beginning—API-first, as they say.

So that was the start of the Picturepark Content Platform.

In what other ways does the Picturepark Content Platform differ from traditional digital asset management systems?

Our “any content, anywhere” management paradigm and the semantic relationships, are the two main differentiators. But to support these new technologies, we’ve developed and adopted a few new tricks that are pretty cool.

For example, in making it possible for customers to create and manage virtual content in Picturepark, we adopted and built upon the API-first, headless CMS concept. So Picturepark can be a content creation platform for those complex content types I mentioned, and even serve as a master data source for downstream systems, like product information management [PIM] or searchable website databases.

Through a big update to our Ports architectural concept, this virtual content is now API-accessible so that it can be formatted and presented online in any way the customer needs. This makes it possible for agencies and Web developers to create dynamic microsites that are populated using master data that comes from Picturepark or even an upstream system, like a PIM or ERP.

Then, to make the semantic relationships possible, we developed multi-dimensional lists. They’re like controlled vocabularies, but each term can have its own set of attributes. Those attributes can then even link to other lists.

What would be the user benefit to multi-dimensional lists?

You can build relationships between terms, so that the assignment of one tag provides additional context that would otherwise require the assignment of several tags.

For example, say you have an event photo. With Adaptive Metadata today in Picturepark 8, you can add a metadata layer that provides fields that are specific to events, like the event name, location and date, or the products you will feature at the event.

With the Content Platform, this gets even easier and more powerful. For example, the event itself can be a virtual object that includes a name, date and location. The event’s location field could link to a list of cities which again links to a list of countries (which could also be used for target markets). That country list could then be linked to a list of languages spoken in each country.

So, by assigning a single tag—say, the event name—the content inherits all those additional metadata values, by extension. So, if the event were in Berlin, you could find event images from Germany, even though “Germany” wasn’t explicitly assigned to the content as a tag, because the location field contains the “Berlin” tag and that term is related to Germany.

Or, you could look at records for products and see the events where they have been featured, and you can see all the content that was used for planning, such as signage, brochures, etc., and all the content that resulted from the event, such as photos or contact lists.

How will a new platform affect current Picturepark customers?

Part of the design considerations for the Content Platform were about migration. We have too many customers to just leave people behind or think that this could be handed manually on a case-by-case basis. So, as the new version has been developed, we have built and tested tools for migration.

We are also deploying the Content Platform in stages, so that customers have time to consider the new system, plan for it, and train employees. Customers won’t be forced onto the new system overnight. But we think that once they see all they’ll be able to do with the Content Platform, and they see how much easier it is to use, we think they’ll want to switch pretty soon.

Other interviews in this series:

• Picturepark Director of Global Marketing, David Diamond, talks about whether products like the Picturepark Content Platform will be the death of digital asset management. 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 now »
• 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 »

Read more about the Picturepark Content Platform »