DAM Navel Gazing... missing the excitement

DAM has really reached its maturity. There are lots of people writing all kinds of articles about it and the evangelists consultants who used to be fixtures, have moved on to more cutting edge disciplines. While I like the fact that there is more to read, as often happens, a lot of it is the same. A good portion of it is also remarkably negative navel gazing which is surprising considering much of it comes from within the vendor community. It seems there is too much emotion for so little information.

I think where DAM is at is extremely exciting. At this point, a new buyer can pick any of the more common systems and be relatively guaranteed of a successful implementation. Sure there are subtle improvements to come which better tie in use of assets with different applications, social media and websites. The truth is, any DAM system not nourishing dung beetles has a decent UI, a great API and is robust enough to run in almost any organization. Furthermore, the API has already been used to integrate it with multiple CMS, ERP, PIM, publishing, e-commerce, productivity and cloud systems. There are many DAM systems which fit this description and have competent people to implement them. This is very exciting. You don't have this much choice in Office software or creative software. You can't implement a CMS, ERP or PIM as easily.

Vendors can say what they want, but success of the system is up to the client. That is why it is so important to get the client excited about the possibilities and also let them know about the commitment that will be required. As is expected, the more sales focussed vendors could care less and just want to complete the sale and collect the money. This is why, when you look at the client list of each vendor, they seem to be the same. Do all of these large companies really own multiple DAM systems? Sure they do. In fact, we had one client we sold into twice and in between these sales - to two different departments - we demonstrated to all of them how they could work on the one existing system together. Functional silos, different departments and... we had a new sale to another department. Obviously, this is DAM gone wrong, but the point is, the client makes the DAM system successful, not the software company or integrator - we can only make it fail.

Why systems fail at the client is no mystery at all. Change. You take a group of people - for example the ones most affected by the introduction of DAM to their environment - content creators. They have their files all over the place but they basically know where to find them. They are always creating new places when they need to. But like my dad, an engineer by trade, he could thrust his hand into an apparent stack of recycling and pull out the relevant article to his point at hand. Creatives can do this quite well. The problems is, they are only part of the entire process. These assets get touched by up to 10 or more roles during the creation process (legal, approval, CSR, suppliers, project managers...) and most of these people need to find the assets and then they need to be changed and returned. After it is approved and final, it gets published to web, print, mobile and potential mail/POS/packaging. If you want to control your brand you need to control your assets and, you just can't leave that hanging on my dad being able to pull it out of his stack. So, you have to tell all of these roles (including the creatives who favour folder names like :Direct Mail Piece for Mother Tucker's Restaurant with the guy in red overalls standing out front) that what they done for the past n years is going to change. And even worse: they've been told this before. They had a DAM system and it didn't work out at all so you better just sell your damn system somewhere else.

That's the part that is depressing about DAM. The technology side keeps racing ahead and all the technology people can tell you how we can improve all sorts of things. Web technology alone is changing the face of integration with other systems - even old web services look passe. Integrators have all the technology tools to implement a good working system. It is building the excitement for the clients which will make it work. This is a great part of the success of SaaS or so-called cloud solutions. It already exists so the client really already knows it is completely up to them to make it work. The opportunity to blame the implementation team has passed as soon as the sale is made. SaaS isn't a one size fits all so many companies either have to implement in-house, or it just makes more sense. If you have to integrate your DAM with ECM, ERP or PIM, you really need to have a lot figured out and blessed by lawyers before you commit to anything externally hosted.

DRM Still Hasn't Found Its Way

There are many different schools of thought on DRM. Publishers and content creators tend to fall on the more severe side of it. Many are proponents of digital locking and are fairly relentless in pursuit of compensation for any type of use. Some are much more similar in stance to the shareware community where they don't want to stifle access but would like to be compensated for their property that others find useful. There are also those who support free and easy access to all content regardless of the creator.

I think content usefulness and proliferation are directly proportional - as one increases, so does the other. However, I also find quality and compensation are often inversely proportional - the cheaper the content, the lower the quality and therefore the value. From an internet perspective, I feel the need to define content whose rights are worth discussing. This will be contentious I'm sure but for the purposes of the discussion of rights management, I think it is appropriate to make a distinction. Chats and many posts or blogs, as well as many videos are consumed so quickly and the value so compressed that there is very little concern about the rights and corresponding compensation. This is both from the originator and consumer standpoint. The video of the nut cracking skateboard spill is usually posted in poor quality for free with no expectation of compensation and the gratification is simply the number of hits it gets. Similarly it is usually watched once and quickly and soon fades from consciousness.

Content requiring more substantial time, effort and investment deserves consideration with respect to rights and return on investment. There is a practical side to all of this though. Many bands have found that releasing their music for free on their website will generate more interest in a shorter period of time and reach more people that traditional channels for releasing music. There is a significant resistance to this because it has a negative impact on a large business segment that has developed a channel, which, when it was the only channel, generated controlled amounts of income but to possibly reduced markets and possibly rewarding too many people who had little to do with the creation of that content.

This causes one to question what role DRM has in the music industry. Is it actually better for the artist to manage the process on their own or do the music industry people actually provide better value? If both provide some value, should the music industry be focusing more on areas where they actually provide the value - possibly organizing and planning tours and similar activities where an individual might have difficulty raising the capital to support such endeavours.

I don't have the answers to efficiency and effectiveness of the different methods of content delivery but I'm pretty sure that the web as a channel is very accessible to individual artists and that the model of handling content should definitely change to utilize the value the web provides. When this happens - business realizes that  the cat is out of the bag and they need to rethink their value proposition - DRM will change for good and for the better. It really comes down to good business which is to offer a good value proposition. When this happens, content won't need to be locked or protected nearly as tightly as today.

Certainly, it is in the best interest of consumers for the individuals and companies offering content to sell the rights to the content and not the media. If I purchased a VHS 20 years ago of the first Star Wars trilogy, I should be able to download that for free today. I have paid my royalties and should not have to do so again. Similarly, If I own the Led Zeppelin library on vinyl, I should be able to download and listen to it freely today. Instead of investing in restrictive technology they should be investing in proliferation technology. The adoption rate on a single lifetime right-to-use of content would be much higher then on specific media which will inevitably be obsolete. This is also much greener as it leaves it up to the individual to decide whether they ever even need media. They could just keep their content on whatever digital device the use and be assured they would have a legal right to it moving forward. Less packaging, less waste. Less industry but we certainly shouldn't be propping up industries that are certainly on their way out anyway. This is a great idea for a business which, having written about it, I now own it and copyright it (unless I am late of course).

DAM as a Platform

Digital Asset Management has been around for 20+ years now and is generally viewed as a mature technology. This is supported by the large number of vendors selling DAM systems and the handful of open source DAM systems available.

At this point in the evolution of DAM, the actual product makes up a relatively small part of most solutions delivered to clients. While investments in training and configuration have always been part of most DAM implementations, customizations and development of purpose-built workflow systems around DAM are becoming the norm. There are still a considerable percentage of users that can benefit simply by implementing a DAM system to gain control of the plethora of content that organizations of almost any size are struggling to manage and control. However, there is significant value to be delivered to an organization by specifying the exact suite of problems they wish to solve. When those problems are document process issues, a DAM solution as a platform and some custom development to address the issues, is a great solution.

Solutions are still fairly different for most clients and often need something a stock product doesn't have - even when the product is developed for a comparable business or vertical. Being able to customize for a client's need is pretty much a must have for most opportunities, particularly the good ones. Value is derived by both vendor and client in these instances as the client gets a real solution to their problems, not just a problem like theirs. The vendor benefits from extra revenue to resolve those problems.

DAM as an industry could benefit from some consolidation as there are probably too many players for the size of the pie that is shared. There should really be no place for DAM systems with out pretty extensive APIs and even a robust development community or partner system.

How important providing solutions has become and how dramatically demand for APIs has increased was never more evident then at a partner meeting for Canto's Cumulus in 2011. Prior to this point, Canto had a Java API which is great but you must be a Java developer and a WebService API, which is even better because it works with any programming language that can consume a web service. This is much better then almost any other DAM system I am aware of, even with these 2 APIs. The web service API was based on SOAP which is an extremely verbose XML based API and, therefore, difficult to use. What really marked the sea change here was that at this meeting, 3 other APIs popped up: Canto released its CIP REST-based web service and 2 partners, Vitras and Aimtec, made it known that they each had web services for Canto as well. The partners web services were REST based as well which is superior to SOAP based web services (simple URL access and leaner JSON responses). So, this DAM system now has 5 APIs and 2 weren't even developed by the OEM. How cool is that?

Programming is no longer the domain of true developers - good, bad or ugly - and is used daily by anyone wanting to streamline a workflow. It is great to see that a non-programmer can improve efficiency on their own using scripting or simple programming. Systems developed for use by larger audiences, especially audiences with limited computer exposure, are much better created by true developers.

DAM now should be the engine that drives the car. Anyone with a DAM system should be integrating it with any other systems accessing or serving the files within.

Capitalization of Digital Assets

Over there years there has been some discussion about valuing digital assets and registering them on the balance sheet like physical assets. Michael Moon discussed this as a sort of holy grail for DAM a number of years back. He posits that the weakest purchase motivator for systems is cost reduction and the strongest is an increase to the balance sheet with anything generating revenues a close second.

I read a blog of Jeremy Wilker's on hidden costs of DAM and noticed a comment posted by Kristin Maija Peterson where she asked the question "What would it do to an organization’s balance sheet if their digital assets were insured by a third party? Would it increase the value of their digital assets, thereby increasing the value of the organization?"

This is a very interesting consideration for anyone who creates, sells or uses DAM. Certainly these digital assets have value. They have a fully burdened cost. They usually have some internal value whether past, current and future use. They potentially have a market value. Even from a common sense perspective, if you have decided to keep it, it must have some value (consideration of hoarding aside).

I recall that there were consideration to make allowances for this to GAAP that would easily allow companies rocognize digital assets on the balance sheet. In 2003, CIOinsight interviewed Michael Moon who had this to say:

• "Any digital object that follows generally accepted accounting practice for asset recognition. So if you have any kind of digital object that you can show that you have reused for a period of greater than 18 months; have captured the development expenses associated with that particular object; and can directly link the reuse of that object to a discrete sale for a revenue event or a discrete cost savings; and have taken prudent measures to protect this asset, then generally accepted accounting practices will support you recognizing that as a financial asset on the balance sheet."

Needless to say, a system would have to follow some accepted guidelines for tracking a digital asset to be able to capitalize it on the balance sheet. This is where DAM systems would shine but I haven't really herard a lot lately about companies valuing their assets to enrich their balance sheet. I'm sure there could be concerns about a company like say, CBS or Time-Warner, suddenly appreciating in value by several billion because of a recalculation on digital file value. In many cases this would be entirely valid. For example, if LucasFilm had the Star Wars franchise, when they released the more recent trilogy of movies, every asset associated with the previous three would undoubtedly increase in value. However, if shareholders didn't believe this value was real, they would start selling the stock which would actually drive down the market value of the company.

I'm getting into areas too complicated for me to speak cogently on but I am still interested in the valuation and capitalization of digital assets. After all this discussion, there is much I still don't know:

• Are companies doing it and to what degree i.e. just high quality images or are they valuing PowerPoint docs at any significant value?
• What are the guidelines for valuation?
• For companies that have done this, what has been teh market reaction to increasing asset value (you would think it would be positive but there is an element of trust here)?
• Are most current DAM offerings sufficiently tracking assets to allow for easy valuation?
  

There is very little information - let alone first hand - on this subject so anyone aware of anyone doing this, please comment or make some information available.

Preparation for a DAM Purchase

We have done many DAM implementations at our company and most succeed. We have also helped a number of clients with dormant or crippled DAM systems bring them back to life. What makes a DAM system succeed? In a word, preparation.

There are a number of reasons for DAM systems to fail: no upper level commitment; no front line commitment; no training; never installed; improperly installed. These usually lead to premature abandonment. Thus the primary reason for failure of a DAM system is lack of preparation.

Pre-purchase
We have a document that we usually give out at the start of our DAM exploration with clients early in the sales cycle. It is called the 6 Mistakes commonly made in choosing a DAM solution and how to avoid them all! Those 6 mistakes are:

1. It takes forever to find a solution and then you’re still uncertain what to get.
2. You don’t get proof it works.
3. It takes a lifetime to get installed and never gets completed.
4. Being oversold or undersold.
5. Overlooking or underestimating the need for ongoing support.
6. Making a purchase decision before you’ve confirmed the stability of the manufacturer.

The key to avoiding all of these is preparation. You should know why you need it and how you can benefit from it, what features you need, what work flow you will use and who the stakeholders are. Most of these steps can be accomplished before you even engage vendors and doing so will avoid most of the 6 mistakes. For example:

• Having an upper management stakeholder yields a budget which helps avoid being over and undersold and allows you to seriously approach vendors.
• Engaging front line stakeholders will yield a set of features and requirements for your solution which also avoid over and under selling and also makes it quicker to select your solution and evaluate the features the vendor shows (proof).
• Evaluating potential vendors via web resources shortens the time to find candidates and determine how solid a company they are.

Knowing these common mistakes allows you to address them during vendor engagement. This ensures that you get assurances that you are dealing with the right manufacturer and integrator and that you have the right solution and support package in place. Proper planning assures that you meet your timelines and start achieving ROI on the schedule you intended.

Pre-install
Once you have chosen the solution, you still have to manage the process of installation and handover. This is key because at some point, your vendor and integrator will go away and you will be responsible for running the system on a day-to-day basis. You must make sure you are ready for this.

We have a suite of service products specifically designed to get us out of the account as soon as possible and leave a fully functioning solution with a client ready to administer and use the system. These are installation, training, consulting and support products that have proven very successful in getting the client up and running as soon as we leave.

We offer user training, administrative training, support packages (the system comes with one year built in) and consulting. The critical step missed in most engagements is the time you spent before you start implementing anything, where we discuss work flow, metadata, taxonomy and organizational practices for DAM systems. The first half introduces the options and most common practices we are aware of, including: taxonomy standards, metadata and work flow with an eye to the client's use. In this session, we encourage the client to discuss this and then discuss further internally over the next few days before the second half of the session. The second half is ideally a session where we listen to what the client has decided and help them solidify this and discuss any potential opportunities or pitfalls. We also know a number of specialists who focus almost solely on metadata whom we refer them to for more specialized help. Some DAM users actually spend years developing metadata standards and work flows before they even start looking for a solution.

Proper training is essential to success and achieving your ROI with your DAM system. Only with training do you understand the capabilities and possibilities of your solution. This is the only way you can assume control of the solution and take it to new levels.

DAM as a Strategic Corporate System

We have deployed many DAM systems for clients and these are used for many different purposes. They usually have some common facets to the systems like:

• They create content that they want to share.
• The content exists in multiple formats.
• They have information about the content (metadata) that they also want to share.
• They want to share the content over the web.
• They want to secure access to the content.

Our clients who deploy these systems are in a wide variety of industries: publishing, cosmetics, library/reference, museums, hospitals, manufacturing. They use the system to sell their digital assets, to share sales and marketing collateral and to manage their brand collateral.

DAM systems are great at organizing a mess of files but their power can be extended to many other key systems throughout your organization. A natural fit is to integrate it with your PIM and your ECM/CMS systems for web publishing where the ECM/CMS manages the presentation and the DAM serves up the assets like video, images and text. Add e-commerce and you can have all the data related to a product available to the client at time of purchase. There are some great opportunities to improve your customer service too by making product collateral like manuals etc. available to clients over the web.

While these system integration exercises will yield some great benefits, they are the more obvious opportunities but there are other systems that can benefit from integration with DAM as well, some of which aren't so obvious. Integration with a PIM System (product information management system) can merge the physical and promotional aspects of a product with the sizing, pricing and costing data. Integration with an ERP system can provide much of the same benefits as a PIM with added benefits of showing inventory levels and logistic data.

The benefits to these integrations are significant. So, why aren't they done more often? The long standing issues surrounding any system integration initiative are no different when integrating DAM. There is only one right way to do do it and that involves normalizing all data to avoid duplication of data. Duplication is a common weakness of many integration projects because it undermines the benefits. Users lose faith in the system when:

• They access data that is out of date.
• They update data only to find that different data appears in other systems.
• They update data only to find that it never makes it into other systems.

Consequently, many of these systems which could benefit from integration, are often deployed as an island. The issue here though is the same: duplication. Even as an island, the DAM system plays a vital role in maintaining the versions of assets and ensuring proper renditions get to target media.  This avoids some significant branding issues for companies preventing the wrong message from getting out.

Every integration project should be committed to doing it right. Otherwise they never deliver the results intended. This means you must examine the data first and do everything possible to have a single authority for all data. Once you do this, the project is really about turning the authoritative source into a service everyone can use.

De-duplication of files

I recently read an article on VTLs that stated that the killer app for this technology could be something they called "Data de-duplication". They appeared to assume savings from not backing up the same file twice. While this is totally valid within the realm of vitualized tape libraries, it misses the main benefits of de-duplication.

Organizations are rife with files stored in multiple places. E-mails are even worse but at least most e-mails sent out to huge lists of people are relatively small in average size. Files are typically large enough to make an impact in your storage costs. Furthermore, most files that get proliferated are ones that are read and not altered like Powerpoint presentations and PDFs.

The duplicate file problem is one that should already be solved in most oranizations, by using a system to manage files. The most prevalent systems available to do this are DAM sysstems and document management systems. They store files and associated data (metadata) in a database which can be searched. These systems can also ensure a single existence of each file and control access to files. Some systems also have workflow features to control approval and flow of documents.

Using these systems to minimize duplication will solve the problem at the earliest possible stage in the document's life cycle. This will eliminate the benefit and therefore necessity of building these features into a backup system. A backup system should remain totally focused on backing up all data on volumes in the backup set. If a backup system is allowed to choose what to backup based on criteria, it opens the door for it to compromise itself with those choices.